原生Kubernetes監控功能詳解-Part2

本周三晚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發送流量，直到再次通過為止。

?

當你的應用程序需要花費相當長的時間來啟動時，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:
??????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是至關重要的，因為它可以幫助我們了解到集群、以及在集群上運行著的應用程序的運行狀況和性能。