原生Kubernetes监控功能详解-Part2

栏目: 编程工具 · 发布时间: 5年前

内容简介:今晚20:30,Kubernetes Master Class在线培训第六期《在Kubernetes中创建高可用应用》即将开播,点击监控的重要性不言而喻,它让我们能充分了解到应用程序的状况。Kubernetes有很多内置工具可供用户们选择,让大家更好地对基础架构层(node)和逻辑层(pod)有充分的了解。在本系列文章的第一篇中,我们关注了专为用户提供监控和指标的工具Dashboard和cAdvisor。在本文中,我们将继续分享关注工作负载扩缩容和生命周期管理的监控工具:Probe(探针)和Horizont

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

原生Kubernetes监控功能详解-Part2

监控的重要性不言而喻,它让我们能充分了解到应用程序的状况。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发送流量,直到再次通过为止。

当你的应用程序需要花费相当长的时间来启动时,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文件:

原生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

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文件:

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

Liveness探针的演示

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

首先,我们来看看liveness探针演示文件:

原生Kubernetes监控功能详解-Part2
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:

原生Kubernetes监控功能详解-Part2

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

首先,找到Nginx部署给pod的名称:

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2 原生Kubernetes监控功能详解-Part2

这表明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文件,该文件将使用单个副本创建部署:

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2
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/tas ... cale/

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

原生Kubernetes监控功能详解-Part2

pod数量会变回到基数:

原生Kubernetes监控功能详解-Part2

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

原生Kubernetes监控功能详解-Part2
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是至关重要的,因为它可以帮助我们了解到集群、以及在集群上运行着的应用程序的运行状况和性能。


以上所述就是小编给大家介绍的《原生Kubernetes监控功能详解-Part2》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Remote

Remote

Jason Fried、David Heinemeier Hansson / Crown Business / 2013-10-29 / CAD 26.95

The “work from home” phenomenon is thoroughly explored in this illuminating new book from bestselling 37signals founders Fried and Hansson, who point to the surging trend of employees working from hom......一起来看看 《Remote》 这本书的介绍吧!

JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

正则表达式在线测试
正则表达式在线测试

正则表达式在线测试

HEX CMYK 转换工具
HEX CMYK 转换工具

HEX CMYK 互转工具