原生Kubernetes监控功能详解-Part2

时间 2019-12-07

标签原生 kubernetes 监控功能详解 part2 繁體版

原文原文链接

今晚20:30，Kubernetes Master Class在线培训第六期《在Kubernetes中建立高可用应用》即将开播，点击 http://live.vhall.com/847710932 便可免费预定注册！

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

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

Demo的前期准备api

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

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

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

Probe（探针）app

健康检查有两种：liveness和readiness。负载均衡

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

当你的应用程序须要花费至关长的时间来启动时，readiness探针很是有用。即便进程已经启动，在探针成功经过以前，该服务也没法工做。默认状况下，Kubernetes将在容器内的进程启动后当即开始发送流量，可是在有readiness探针的状况下，Kubernetes将在应用程序彻底启动后再容许服务路由流量。工具

liveness探针让Kubernetes知道应用程序是否处于运行状态。若是处于运行状态，则不采起任何行动。若是该应用程序未处于运行状态，Kubernetes将删除该pod并启动一个新的pod替换以前的pod。当你的应用程序中止提供请求时，liveness探针很是有用。因为进程仍在运行，所以默认状况下，Kubernetes将继续向pod发送请求。凭借liveness探针，Kubernetes将检测到应用程序再也不提供请求并将从新启动pod。性能

对于liveness和readiness检查，可使用如下类型的探针：

http：自定义探针中最多见的一种。Kubernetes ping一条路径，若是它在200-300的范围内得到http响应，则将该pod标记为健康。
command：使用此探针时，Kubernetes将在其中一个pod容器内运行命令。若是该命令返回退出代码0，则容器将标记为健康。
tcp：Kubernetes将尝试在指定端口上创建TCP链接。若是可以创建链接，则容器标记为健康。

配置探针时，可提供如下参数：

initialDelaySeconds：首次启动容器时，发送readiness/liveness探针以前等待的时间。对于liveness检查，请确保仅在应用程序准备就绪后启动探针，不然你的应用程序将会继续从新启动。
periodSeconds：执行探针的频率（默认值为10）。
timeoutSeconds：探针超时的时间，以秒为单位（默认值为1）。
successThreshold：探针成功的最小连续成功检查次数。
failureThreshold：放弃以前探针失败的次数。放弃liveness探针会致使Kubernetes从新启动pod。对于liveness探针，pod将被标记为未准备好。

Readiness探针的演示

在本节中，咱们将使用命令检查来配置readiness探针。咱们将使用默认的nginx容器部署两个副本。在容器中找到名为/tmp/healthy的文件以前，不会有任何流量发送到pod。

首先，输入如下命令建立一个readiness.yaml文件：

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:
> 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      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/ta...

等待时间结束后，咱们会发现，在高负载的标记处，部署的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是相当重要的，由于它能够帮助咱们了解到集群、以及在集群上运行着的应用程序的运行情况和性能。