kubernetes快速进阶与实战（原生Kubernetes监控功能详解-Part2）

kubernetes快速进阶与实战（原生Kubernetes监控功能详解-Part2）我们将看到正在创建的部署和服务：apiVersion: apps/v1 kind: Deployment metadata: name: readiness-demo spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx ports: - containerPort: 80 readinessProbe: exec: command: - ls - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5 --- apiVersion: v1 kind: Service metada

本周三晚20:30，kubernetes Master Class在线培训第六期《在Kubernetes中创建高可用应用》即将开播，点击链接：http://live.vhall.com/847710932 即可免费预约注册！

监控的重要性不言而喻，它让我们能充分了解到应用程序的状况。Kubernetes有很多内置工具可供用户们选择，让大家更好地对基础架构层（node）和逻辑层（pod）有充分的了解。

在本系列文章的第一篇中，我们关注了专为用户提供监控和指标的工具Dashboard和cAdvisor。在本文中，我们将继续分享关注工作负载扩缩容和生命周期管理的监控工具：Probe（探针）和Horizontal Pod Autoscaler（HPA）。同样的，一切介绍都将以demo形式进行。

Demo的前期准备

在本系列文章的上一篇中，我们已经演示了如何启动Rancher实例以及Kubernetes集群。在上篇文章中我们提到过，Kubernetes附带了一些内置的监控工具，包括：

• Kubernetes dashboard：为集群上运行的资源提供一个概览。它还提供了一种非常基本的部署以及与这些资源进行交互的方法。
• cAdvisor：一种用于监控资源使用情况并分析容器性能的开源代理。
• Liveness和Readiness Probe：主动监控容器的健康情况。
• Horizontal Pod Autoscaler：基于通过分析不同指标所收集的信息，根据需要增加pod的数量。

在上篇文章了，我们深度分析了前两个组件Kubernetes Dashboard和cAdvisor，在本文中，我们将继续探讨后两个工具：探针及HPA。

Probe（探针）

健康检查有两种：liveness和readiness。

readiness探针让Kubernetes知道应用程序是否已准备好，来为流量提供服务。只有探针允许通过时，Kubernetes才会允许服务将流量发送到pod。如果探针没有通过，Kubernetes将停止向该Pod发送流量，直到再次通过为止。

apiVersion: apps/v1 kind: Deployment metadata: name: readiness-demo spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx ports: - containerPort: 80 readinessProbe: exec: command: - ls - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: lb spec: type: LoadBalancer ports: - port: 80 protocol: TCP targetPort: 80 selector: app: nginx

接下来，应用YAML文件：

我们将看到正在创建的部署和服务：

除非readiness探针通过，否则pod将不会进入READY状态。在这种情况下，由于没有名为/tmp/healthy的文件，因此将被标记为失败，服务将不会发送任何流量。

为了更好地理解，我们将修改两个pod的默认nginx索引页面。当被请求时，第一个将显示1作为响应，第二个将显示2作为响应。

下面将特定pod名称替换为计算机上部署创建的pod名称：

在第一个pod中创建所需的文件，以便转换到READY状态并可以在那里路由流量：

探针每5秒运行一次，因此我们可能需要稍等一会儿才能看到结果：

一旦状态发生变化，我们就可以开始点击负载均衡器的外部IP：

下面我们应该能看到我们修改过的Nginx页面了，它由一个数字标识符组成：

为第二个pod创建文件也会导致该pod进入READY状态。此处的流量也会被重定向：

当第二个pod标记为READY时，该服务将向两个pod发送流量：

此时的输出应该已经指明了，流量正在两个pod之间分配：

Liveness探针的演示

在本节中，我们将演示使用tcp检查配置的liveness探针。如上所述，我们将使用默认的nginx容器部署两个副本。如果容器内的端口80没有正处于监听状态，则不会将流量发送到容器，并且将重新启动容器。

首先，我们来看看liveness探针演示文件：

apiVersion: apps/v1 kind: Deployment metadata: name: liveness-demo spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx ports: - containerPort: 80 livenessProbe: tcpSocket: port: 80 initialDelaySeconds: 15 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: lb spec: type: LoadBalancer ports: - port: 80 protocol: TCP targetPort: 80 selector: app: nginx

我们可以用一个命令来应用YAML：

然后，我们可以检查pod，并像上面一样修改默认的Nginx页面以使用简单的1或2来表示响应。

首先，找到Nginx部署给pod的名称：

接下来，使用数字标识符替换每个pod中的默认索引页：

流量已被服务重定向，因此可立即从两个pod获取响应：

同样，响应应该表明流量正在两个pod之间分配：

现在我们已经准备好在第一个pod中停止Nginx进程，以查看处于运行状态的liveness探针。一旦Kubernetes注意到容器不再监听端口80，pod的状态将会改变并重新启动。我们可以观察其转换的一些状态，直到再次正常运行。

首先，停止其中一个pod中的Web服务器进程：

现在，当Kubernetes注意到探针失败并采取措施重启pod时，审核pod的状态：

你可能会看到pod在再次处于健康状况之前进行了多种状态的转换：

如果我们通过我们的服务请求页面，我们将从第二个pod中看到正确的响应，即修改后的标识符“2”。然而，刚创建的pod将从容器镜像返回了默认的Nginx页面：

这表明Kubernetes已经部署了一个全新的pod来替换之前失败的pod。

Horizontal Pod Autoscaler

Horizontal Pod Autoscaler（HPA）是Kubernetes的一项功能，使我们能够根据观察到的指标对部署、复制控制器、或副本集所需的pod数量进行自动扩缩容。在实际使用中，CPU指标通常是最主要的触发因素，但自定义指标也可以是触发因素。

基于测量到的资源使用情况，该过程的每个部分都是自动完成的，不需要人工干预。相关指标可以从metrics.k8s.io、custom.metrics.k8s.io或external.metrics.k8s.io等API获取。

在下文的示例中，我们将基于CPU指标进行演示。我们可以在这种情况下使用的命令是kubectl top pods，它将显示pod的CPU和内存使用情况。

首先，创建一个YAML文件，该文件将使用单个副本创建部署：

输入以下内容来应用部署：

这是一个很简单的deployment，具有相同的Nginx镜像和单个副本：

接下来，让我们了解如何实现自动缩放机制。使用kubectl get / describe hpa命令，可以查看当前已定义的autoscaler。要定义新的autoscaler，我们可以使用kubectl create命令。但是，创建autoscaler的最简单方法是以现有部署为目标，如下所示：

这将为我们之前创建的hpa-demo部署创建一个autoscaler，而且预计CPU利用率为50％。副本号在此处设为1到10之间的数字，因此当高负载时autoscaler将创建的最大pod数为10。

你可以通过输入以下内容来确认autoscaler的配置：

我们也可以用YAML格式定义它，从而更容易地进行审查和变更管理：

为了查看HPA的运行情况，我们需要运行一个在CPU上创建负载的命令。这里有很多种方法，但一个非常简单的例子如下：

首先，检查唯一pod上的负载。因为它目前处于空闲状态，所以没有太多负载：

现在，让我们在当前pod上生成一些负载。一旦负载增加，我们应该就能看到HPA开始自动创建一些额外的pod来处理所增加的负载。让以下命令运行几秒钟，然后停止命令：

检查当前pod上的当前负载：

HPA开始发挥作用，并开始创建额外的pod。Kubernetes显示部署已自动缩放，现在有三个副本：

我们可以看到HPA的详细信息以及将其扩展到三个副本的原因：

Name: hpa-demo Namespace: default Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"autoscaling/v1" "kind":"HorizontalPodAutoscaler" "metadata":{"annotations":{} "name":"hpa-demo" "namespace":"default"} "spec":{"maxRepli... CreationTimestamp: Sat 30 Mar 2019 17:43:50 0200 Reference: Deployment/hpa-demo Metrics: ( current / target ) resource cpu on pods (as a percentage of request): 104% (104m) / 50% Min replicas: 1 Max replicas: 10 Conditions: Type Status reason Message ---- ------ ------ ------- AbleToScale True ReadyForNewScale recommended size matches current size ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request) ScalingLimited False DesiredWithinRange the desired count is within the acceptable range Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulRescale 15s horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target

由于我们停止了生成负载的命令，所以如果我们等待几分钟，HPA应该注意到负载减少并缩小副本的数量。没有高负载，就不需要创建额外的两个pod。

autoscaler在Kubernetes中执行缩减操作之前等待的默认时间是5分钟。您可以通过调整--horizontal-pod-autoscaler-downscale-delay设置来修改该时间，更多信息可以参考官方文档：

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

等待时间结束后，我们会发现，在高负载的标记处，部署的pod数量减少了：

pod数量会变回到基数：

如果再次检查HPA的描述，我们将能看到减少副本数量的原因：

Name: hpa-demo Namespace: default Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"autoscaling/v1" "kind":"HorizontalPodAutoscaler" "metadata":{"annotations":{} "name":"hpa-demo" "namespace":"default"} "spec":{"maxRepli... CreationTimestamp: Sat 30 Mar 2019 17:43:50 0200 Reference: Deployment/hpa-demo Metrics: ( current / target ) resource cpu on pods (as a percentage of request): 0% (0) / 50% Min replicas: 1 Max replicas: 10 Conditions: Type Status Reason Message ---- ------ ------ ------- AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 1 ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request) ScalingLimited True TooFewReplicas the desired replica count is increasing faster than the maximum scale rate Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target Normal SuccessfulRescale 13s horizontal-pod-autoscaler New size: 1; reason: All metrics below target 结 语

相信通过这两篇系列文章，我们能够深入地理解了Kubernetes是如何使用内置工具为集群设置监控的。我们知道了Kubernetes在幕后如何通过不间断的工作来保证应用程序的运行，同时可以的话也应该更进一步去了解其背后的原理。

从Dashboard和探针收集所有数据，再通过cAdvisor公开所有容器资源，可以帮助我们了解到资源限制或容量规划。良好地监控Kubernetes是至关重要的，因为它可以帮助我们了解到集群、以及在集群上运行着的应用程序的运行状况和性能。