原生Kubernetes监控功能详解-Part2

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

内容简介:今晚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》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

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

数据库系统概念

数据库系统概念

(美)Abraham Silberschatz、(美)Henry F.Korth、(美)S.Sudarshan / 杨冬青、李红燕、唐世渭 / 机械工业出版社 / 2012-3 / 99.00元

【编辑推荐】 数据库领域的殿堂级作品 夯实数据库理论基础,增强数据库技术内功的必备之选 对深入理解数据库,深入研究数据库,深入操作数据库都具有极强的指导作用! 【内容简介】 本书是数据库系统方面的经典教材之一,其内容由浅入深,既包含数据库系统基本概念,又反映数据库技术新进展。它被国际上许多著名大学所采用,包括斯坦福大学、耶鲁大学、得克萨斯大学、康奈尔大学、伊利诺伊大学......一起来看看 《数据库系统概念》 这本书的介绍吧!

Base64 编码/解码
Base64 编码/解码

Base64 编码/解码

URL 编码/解码
URL 编码/解码

URL 编码/解码

SHA 加密
SHA 加密

SHA 加密工具