原生Kubernetes監(jiān)控功能詳解-Part2

本周三晚20:30，Kubernetes Master Class在線(xiàn)培訓(xùn)第六期《在Kubernetes中創(chuàng)建高可用應(yīng)用》即將開(kāi)播，點(diǎn)擊鏈接：http://live.vhall.com/847710932 即可免費(fèi)預(yù)約注冊(cè)！

監(jiān)控的重要性不言而喻，它讓我們能充分了解到應(yīng)用程序的狀況。Kubernetes有很多內(nèi)置工具可供用戶(hù)們選擇，讓大家更好地對(duì)基礎(chǔ)架構(gòu)層（node）和邏輯層（pod）有充分的了解。

?

在本系列文章的第一篇中，我們關(guān)注了專(zhuān)為用戶(hù)提供監(jiān)控和指標(biāo)的工具Dashboard和cAdvisor。在本文中，我們將繼續(xù)分享關(guān)注工作負(fù)載擴(kuò)縮容和生命周期管理的監(jiān)控工具：Probe（探針）和Horizontal Pod Autoscaler（HPA）。同樣的，一切介紹都將以demo形式進(jìn)行。

Demo的前期準(zhǔn)備

在本系列文章的上一篇中，我們已經(jīng)演示了如何啟動(dòng)Rancher實(shí)例以及Kubernetes集群。在上篇文章中我們提到過(guò)，Kubernetes附帶了一些內(nèi)置的監(jiān)控工具，包括：

?

• Kubernetes dashboard：為集群上運(yùn)行的資源提供一個(gè)概覽。它還提供了一種非常基本的部署以及與這些資源進(jìn)行交互的方法。

• cAdvisor：一種用于監(jiān)控資源使用情況并分析容器性能的開(kāi)源代理。

• Liveness和Readiness Probe：主動(dòng)監(jiān)控容器的健康情況。

• Horizontal Pod Autoscaler：基于通過(guò)分析不同指標(biāo)所收集的信息，根據(jù)需要增加pod的數(shù)量。

在上篇文章了，我們深度分析了前兩個(gè)組件Kubernetes Dashboard和cAdvisor，在本文中，我們將繼續(xù)探討后兩個(gè)工具：探針及HPA。

Probe（探針）

健康檢查有兩種：liveness和readiness。

readiness探針讓Kubernetes知道應(yīng)用程序是否已準(zhǔn)備好，來(lái)為流量提供服務(wù)。只有探針允許通過(guò)時(shí)，Kubernetes才會(huì)允許服務(wù)將流量發(fā)送到pod。如果探針沒(méi)有通過(guò)，Kubernetes將停止向該P(yáng)od發(fā)送流量，直到再次通過(guò)為止。

?

當(dāng)你的應(yīng)用程序需要花費(fèi)相當(dāng)長(zhǎng)的時(shí)間來(lái)啟動(dòng)時(shí)，readiness探針?lè)浅Ｓ杏?。即使進(jìn)程已經(jīng)啟動(dòng)，在探針成功通過(guò)之前，該服務(wù)也無(wú)法工作。默認(rèn)情況下，Kubernetes將在容器內(nèi)的進(jìn)程啟動(dòng)后立即開(kāi)始發(fā)送流量，但是在有readiness探針的情況下，Kubernetes將在應(yīng)用程序完全啟動(dòng)后再允許服務(wù)路由流量。

?

liveness探針讓Kubernetes知道應(yīng)用程序是否處于運(yùn)行狀態(tài)。如果處于運(yùn)行狀態(tài)，則不采取任何行動(dòng)。如果該應(yīng)用程序未處于運(yùn)行狀態(tài)，Kubernetes將刪除該pod并啟動(dòng)一個(gè)新的pod替換之前的pod。當(dāng)你的應(yīng)用程序停止提供請(qǐng)求時(shí)，liveness探針?lè)浅Ｓ杏?。由于進(jìn)程仍在運(yùn)行，因此默認(rèn)情況下，Kubernetes將繼續(xù)向pod發(fā)送請(qǐng)求。憑借liveness探針，Kubernetes將檢測(cè)到應(yīng)用程序不再提供請(qǐng)求并將重新啟動(dòng)pod。

?

對(duì)于liveness和readiness檢查，可以使用以下類(lèi)型的探針：

• http：自定義探針中最常見(jiàn)的一種。Kubernetes ping一條路徑，如果它在200-300的范圍內(nèi)獲得http響應(yīng)，則將該pod標(biāo)記為健康。

• command：使用此探針時(shí)，Kubernetes將在其中一個(gè)pod容器內(nèi)運(yùn)行命令。如果該命令返回退出代碼0，則容器將標(biāo)記為健康。

• tcp：Kubernetes將嘗試在指定端口上建立TCP連接。如果能夠建立連接，則容器標(biāo)記為健康。

?

配置探針時(shí)，可提供以下參數(shù)：

?

• initialDelaySeconds：首次啟動(dòng)容器時(shí)，發(fā)送readiness/liveness探針之前等待的時(shí)間。對(duì)于liveness檢查，請(qǐng)確保僅在應(yīng)用程序準(zhǔn)備就緒后啟動(dòng)探針，否則你的應(yīng)用程序?qū)?huì)繼續(xù)重新啟動(dòng)。

• periodSeconds：執(zhí)行探針的頻率（默認(rèn)值為10）。

• timeoutSeconds：探針超時(shí)的時(shí)間，以秒為單位（默認(rèn)值為1）。

• successThreshold：探針成功的最小連續(xù)成功檢查次數(shù)。

• failureThreshold：放棄之前探針失敗的次數(shù)。放棄liveness探針會(huì)導(dǎo)致Kubernetes重新啟動(dòng)pod。對(duì)于liveness探針，pod將被標(biāo)記為未準(zhǔn)備好。

Readiness探針的演示

在本節(jié)中，我們將使用命令檢查來(lái)配置readiness探針。我們將使用默認(rèn)的nginx容器部署兩個(gè)副本。在容器中找到名為/tmp/healthy的文件之前，不會(huì)有任何流量發(fā)送到pod。

?

首先，輸入以下命令創(chuàng)建一個(gè)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:
??????app:?nginx

接下來(lái)，應(yīng)用YAML文件：

我們將看到正在創(chuàng)建的部署和服務(wù)：

除非readiness探針通過(guò)，否則pod將不會(huì)進(jìn)入READY狀態(tài)。在這種情況下，由于沒(méi)有名為/tmp/healthy的文件，因此將被標(biāo)記為失敗，服務(wù)將不會(huì)發(fā)送任何流量。

為了更好地理解，我們將修改兩個(gè)pod的默認(rèn)nginx索引頁(yè)面。當(dāng)被請(qǐng)求時(shí)，第一個(gè)將顯示1作為響應(yīng)，第二個(gè)將顯示2作為響應(yīng)。

?

下面將特定pod名稱(chēng)替換為計(jì)算機(jī)上部署創(chuàng)建的pod名稱(chēng)：

在第一個(gè)pod中創(chuàng)建所需的文件，以便轉(zhuǎn)換到READY狀態(tài)并可以在那里路由流量：

探針每5秒運(yùn)行一次，因此我們可能需要稍等一會(huì)兒才能看到結(jié)果：

一旦狀態(tài)發(fā)生變化，我們就可以開(kāi)始點(diǎn)擊負(fù)載均衡器的外部IP：

下面我們應(yīng)該能看到我們修改過(guò)的Nginx頁(yè)面了，它由一個(gè)數(shù)字標(biāo)識(shí)符組成：

為第二個(gè)pod創(chuàng)建文件也會(huì)導(dǎo)致該pod進(jìn)入READY狀態(tài)。此處的流量也會(huì)被重定向：

當(dāng)?shù)诙€(gè)pod標(biāo)記為READY時(shí)，該服務(wù)將向兩個(gè)pod發(fā)送流量：

此時(shí)的輸出應(yīng)該已經(jīng)指明了，流量正在兩個(gè)pod之間分配：

Liveness探針的演示

在本節(jié)中，我們將演示使用tcp檢查配置的liveness探針。如上所述，我們將使用默認(rèn)的nginx容器部署兩個(gè)副本。如果容器內(nèi)的端口80沒(méi)有正處于監(jiān)聽(tīng)狀態(tài)，則不會(huì)將流量發(fā)送到容器，并且將重新啟動(dòng)容器。

?

首先，我們來(lái)看看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

我們可以用一個(gè)命令來(lái)應(yīng)用YAML：

然后，我們可以檢查pod，并像上面一樣修改默認(rèn)的Nginx頁(yè)面以使用簡(jiǎn)單的1或2來(lái)表示響應(yīng)。

首先，找到Nginx部署給pod的名稱(chēng)：

接下來(lái)，使用數(shù)字標(biāo)識(shí)符替換每個(gè)pod中的默認(rèn)索引頁(yè)：

流量已被服務(wù)重定向，因此可立即從兩個(gè)pod獲取響應(yīng)：

同樣，響應(yīng)應(yīng)該表明流量正在兩個(gè)pod之間分配：

現(xiàn)在我們已經(jīng)準(zhǔn)備好在第一個(gè)pod中停止Nginx進(jìn)程，以查看處于運(yùn)行狀態(tài)的liveness探針。一旦Kubernetes注意到容器不再監(jiān)聽(tīng)端口80，pod的狀態(tài)將會(huì)改變并重新啟動(dòng)。我們可以觀(guān)察其轉(zhuǎn)換的一些狀態(tài)，直到再次正常運(yùn)行。

?

首先，停止其中一個(gè)pod中的Web服務(wù)器進(jìn)程：

?

現(xiàn)在，當(dāng)Kubernetes注意到探針失敗并采取措施重啟pod時(shí)，審核pod的狀態(tài)：

你可能會(huì)看到pod在再次處于健康狀況之前進(jìn)行了多種狀態(tài)的轉(zhuǎn)換：

如果我們通過(guò)我們的服務(wù)請(qǐng)求頁(yè)面，我們將從第二個(gè)pod中看到正確的響應(yīng)，即修改后的標(biāo)識(shí)符“2”。然而，剛創(chuàng)建的pod將從容器鏡像返回了默認(rèn)的Nginx頁(yè)面：

這表明Kubernetes已經(jīng)部署了一個(gè)全新的pod來(lái)替換之前失敗的pod。

Horizontal Pod Autoscaler

Horizontal Pod Autoscaler（HPA）是Kubernetes的一項(xiàng)功能，使我們能夠根據(jù)觀(guān)察到的指標(biāo)對(duì)部署、復(fù)制控制器、或副本集所需的pod數(shù)量進(jìn)行自動(dòng)擴(kuò)縮容。在實(shí)際使用中，CPU指標(biāo)通常是最主要的觸發(fā)因素，但自定義指標(biāo)也可以是觸發(fā)因素。

?

基于測(cè)量到的資源使用情況，該過(guò)程的每個(gè)部分都是自動(dòng)完成的，不需要人工干預(yù)。相關(guān)指標(biāo)可以從metrics.k8s.io、custom.metrics.k8s.io或external.metrics.k8s.io等API獲取。

?

在下文的示例中，我們將基于CPU指標(biāo)進(jìn)行演示。我們可以在這種情況下使用的命令是kubectl top pods，它將顯示pod的CPU和內(nèi)存使用情況。

?

首先，創(chuàng)建一個(gè)YAML文件，該文件將使用單個(gè)副本創(chuàng)建部署：

輸入以下內(nèi)容來(lái)應(yīng)用部署：

?

這是一個(gè)很簡(jiǎn)單的deployment，具有相同的Nginx鏡像和單個(gè)副本：

接下來(lái)，讓我們了解如何實(shí)現(xiàn)自動(dòng)縮放機(jī)制。使用kubectl get / describe hpa命令，可以查看當(dāng)前已定義的autoscaler。要定義新的autoscaler，我們可以使用kubectl create命令。但是，創(chuàng)建autoscaler的最簡(jiǎn)單方法是以現(xiàn)有部署為目標(biāo)，如下所示：

?

這將為我們之前創(chuàng)建的hpa-demo部署創(chuàng)建一個(gè)autoscaler，而且預(yù)計(jì)CPU利用率為50％。副本號(hào)在此處設(shè)為1到10之間的數(shù)字，因此當(dāng)高負(fù)載時(shí)autoscaler將創(chuàng)建的最大pod數(shù)為10。

?

你可以通過(guò)輸入以下內(nèi)容來(lái)確認(rèn)autoscaler的配置：

我們也可以用YAML格式定義它，從而更容易地進(jìn)行審查和變更管理：

為了查看HPA的運(yùn)行情況，我們需要運(yùn)行一個(gè)在CPU上創(chuàng)建負(fù)載的命令。這里有很多種方法，但一個(gè)非常簡(jiǎn)單的例子如下：

首先，檢查唯一pod上的負(fù)載。因?yàn)樗壳疤幱诳臻e狀態(tài)，所以沒(méi)有太多負(fù)載：

現(xiàn)在，讓我們?cè)诋?dāng)前pod上生成一些負(fù)載。一旦負(fù)載增加，我們應(yīng)該就能看到HPA開(kāi)始自動(dòng)創(chuàng)建一些額外的pod來(lái)處理所增加的負(fù)載。讓以下命令運(yùn)行幾秒鐘，然后停止命令：

?

檢查當(dāng)前pod上的當(dāng)前負(fù)載：

HPA開(kāi)始發(fā)揮作用，并開(kāi)始創(chuàng)建額外的pod。Kubernetes顯示部署已自動(dòng)縮放，現(xiàn)在有三個(gè)副本：

我們可以看到HPA的詳細(xì)信息以及將其擴(kuò)展到三個(gè)副本的原因：

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

由于我們停止了生成負(fù)載的命令，所以如果我們等待幾分鐘，HPA應(yīng)該注意到負(fù)載減少并縮小副本的數(shù)量。沒(méi)有高負(fù)載，就不需要?jiǎng)?chuàng)建額外的兩個(gè)pod。

autoscaler在Kubernetes中執(zhí)行縮減操作之前等待的默認(rèn)時(shí)間是5分鐘。您可以通過(guò)調(diào)整--horizontal-pod-autoscaler-downscale-delay設(shè)置來(lái)修改該時(shí)間，更多信息可以參考官方文檔：

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

?

等待時(shí)間結(jié)束后，我們會(huì)發(fā)現(xiàn)，在高負(fù)載的標(biāo)記處，部署的pod數(shù)量減少了：

pod數(shù)量會(huì)變回到基數(shù)：

如果再次檢查HPA的描述，我們將能看到減少副本數(shù)量的原因：

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

結(jié)?語(yǔ)

相信通過(guò)這兩篇系列文章，我們能夠深入地理解了Kubernetes是如何使用內(nèi)置工具為集群設(shè)置監(jiān)控的。我們知道了Kubernetes在幕后如何通過(guò)不間斷的工作來(lái)保證應(yīng)用程序的運(yùn)行，同時(shí)可以的話(huà)也應(yīng)該更進(jìn)一步去了解其背后的原理。

?

從Dashboard和探針收集所有數(shù)據(jù)，再通過(guò)cAdvisor公開(kāi)所有容器資源，可以幫助我們了解到資源限制或容量規(guī)劃。良好地監(jiān)控Kubernetes是至關(guān)重要的，因?yàn)樗梢詭椭覀兞私獾郊?、以及在集群上運(yùn)行著的應(yīng)用程序的運(yùn)行狀況和性能。