原生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是相當重要的，由於它能夠幫助咱們瞭解到集羣、以及在集羣上運行着的應用程序的運行情況和性能。