乾貨 | Kubernetes 監控詳解

做者：Carlos Arilla

翻譯：Bach（才雲）

校對：bot（才雲）、星空下的文仔（才雲）

若是想要監控 Kubernetes，包括基礎架構平臺和正在運行的工做負載，傳統的監控工具和流程可能還不夠用。就目前而言，監控 Kubernetes 並非件容易的事。

K8sMeetup

爲何監控 Kubernetes 很難？

Kubernetes 已經席捲了整個容器生態系統，它充當着容器分佈式部署的大腦，旨在使用跨主機集羣分佈的容器來管理面向服務的應用程序。Kubernetes 提供了用於應用程序部署、調度、更新、服務發現和擴展的機制，可是監控 Kubernetes 呢？

雖然 Kubernetes 能夠極大地簡化將應用程序在容器以及跨雲的部署過程，但它會爲平常任務、應用程序性能管理、服務可見性以及典型的「監控->警報->故障排除」工做流程增長了複雜性。

舊版監控工具從靜態目標中收集指標，用於監控服務器和服務，這些工具過去工做良好，但如今沒法正常工做。下面就是這些工具如今沒法監控 Kubernetes 的緣由：

Kubernetes 增長了基礎架構的複雜性

爲了簡化應用程序部署，基礎架構增長了新的複雜性層：動態配置的 IaaS、自動配置的配置管理工具以及編排平臺（如 Kubernetes），它們都位於裸機或虛擬基礎架構與支持應用程序的服務之間，所以在控制平面上監控 Kubernetes 安全也是工做的一部分。

微服務架構

除了增長基礎架構的複雜性以外，微服務還被設計了新的應用程序，其中相互通訊的組件數量也會按數量級增長。每一個服務分佈在多個實例中，而且容器能夠根據須要在基礎結構中移動。這就是監控 Kubernetes 編排狀態對於瞭解 Kubernetes 執行工做相當重要的緣由。咱們要驗證服務的全部實例都已啓動並運行。

原生雲爆炸的規模要求

咱們須要監控系統，這樣能爲高水平的服務目標發出警報，另外咱們也要保留粒度以根據須要檢查各個組件。當採用雲原生架構時，它們帶來了變化也帶走了愈來愈多的小組件。這就影響了 Kubernetes 監控方法和工具。

隨着指標數量的激增，傳統的監控系統已沒法跟上。雖然過去咱們能知道每一個服務組件有多少個實例以及它們位於何處，但如今狀況已再也不如此。如今指標一般具備必定的基數，Kubernetes 會有一些多維級別，例如集羣、節點、命名空間、Service 等。許多標籤的表明屬性來自於微服務的邏輯、應用程序版本、API 端點、特定資源或操做等。

另外，容器不會永遠運行下去。據一份容器使用狀況報告顯示，22％ 的容器壽命不超過 10 秒，54％ 的容器壽命不到 5 分鐘。這會形成很大的變更，容器 ID、Pod 名稱之類的標籤始終在變化，這也是咱們在處理新標籤時卻再也看不到它們的緣由。

如今，咱們若是將度量標準的名稱、標籤與實際值、時間戳一塊兒使用，在短期內，就將擁有成千上萬個數據點，即便是在小型 Kubernetes 集羣中，也將生成數十萬個時間序列，若是是中型基礎架構，可能就是數百萬個。這就是爲何 Kubernetes 監控工具須要準備好擴展成千上萬個指標。

容器可見性不足

容器的生命週期是短暫的，它一旦死亡，內部的全部東西都將消失，咱們沒法使用 SSH 或查看日誌。容器很是適合操做，咱們能夠打包、隔離應用程序，在任何地方以一致的方式部署它們，可是同時，它們一樣會成爲難以排除故障的黑盒。監控工具能夠經過系統調用跟蹤從而提供詳盡的可見性，這樣咱們能夠查看容器內發生的每一個進程、文件或網絡鏈接，從而更快地對問題進行故障排除。

考慮到這些因素，咱們能夠更好地理解爲何監控 Kubernetes 與監控服務器、VM 甚至是雲實例有很大不一樣。

K8sMeetup

Kubernetes 監控的用例

Kubernetes 集羣具備多個組件和層，在每一個組件和層中，咱們須要監控不一樣的故障點。如下是 Kubernetes 監控的一些典型用例：

監控 Kubernetes 集羣和節點

經過監控集羣，您能夠全面瞭解整個平臺的運行情況和容量。具體的用例以下：

• 集羣資源使用狀況：集羣基礎架構充分利用了嗎？仍是產能過剩？
• 項目和團隊分攤資源：每一個項目或團隊的資源使用量是多少？
• 節點可用性和運行情況：是否有足夠的節點可用於複製咱們的應用程序？咱們會耗盡資源嗎？

監控 Kubernetes deployment 和 Pod

查看諸如命名空間、deployment、副本集或 DaemonSet 之類的 Kubernetes constructs，咱們能夠了解應用程序是否已正確部署。例如：

• Pod 丟失（Missing）和失敗：Pod 是否在咱們的應用程序中運行？多少 Pod 快死亡了？
• 正在運行的實例與所需的實例：每一個 Service 實際準備了多少個實例？咱們須要多少個？
• 請求和限制的 Pod 資源使用狀況：是否設置了 CPU 和內存的請求和限制？它們的實際做用是什麼？

監控 Kubernetes 應用

歸根結底，應用的監控纔是最重要的。下面是應用監控的一部分：

• 應用程序可用性：應用程序是否響應？
• 應用程序運行情況和性能：咱們有多少個請求？多少響應能力或延遲時間？咱們有沒有出錯？

K8sMeetup

Kubernetes 監控工具

與大多數平臺同樣，Kubernetes 具備一組基本工具，能夠監控平臺，包括基於物理基礎架構之上的 Kubernetes 構造。因爲 Kubernetes 具備可擴展性，它會添加其餘組件以得到 Kubernetes 可見性。讓咱們來看一下 Kubernetes 監控設置的部分：

• cadvisor 和 heapster
• Kubernetes metric server
• Kubernetes 儀表板(Dashboard)
• Kubernetes kube-state-metrics
• Kubernetes liveness 和 readiness 探針
• 用於 Kubernetes 監控的 Prometheus

cAdvisor 和 heapster

cAdvisor 是一個開源容器資源使用收集器。它專爲容器而構建，支持本地 Docker 容器。cAdisor 會自動發現給定節點中的全部容器，並收集CPU、內存、文件系統和網絡使用狀況統計信息，不過它僅會收集基本資源利用率。僅當容器具備 X％CPU 利用率時，cAdvisor 才能告訴咱們應用程序的實際性能。cAdvisor 自己並不提供任何長期存儲或分析功能。

在 Kubernetes 上，節點的 kubelet 能夠安裝 cAdvisor 來監控 Pod 容器資源。

爲了進一步處理這些數據，咱們須要一些東西來整合整個集羣中的數據。最受歡迎的選擇是 Heapster。就像任何應用程序同樣，Heapster 在集羣中做爲 Pod 運行。Heapster Pod 從 kubelet 獲取有用數據，而 kubelet 自己的數據則是從 cAdvisor 獲得，而後 Heapster 按窗格將信息分組，其中也包括相關標籤。

在 Kubernetes 中使用 Heapster 和 cAdvisor 進行監控。資料來源：blog.kubernetes.io

Heapster 是一個收集者，而不是採集者，它只是讓咱們收集整個集羣中的 cAdvisor 數據。咱們須要將這些數據推送到可配置的後端進行存儲和可視化。咱們能夠添加可視化層（例如 Grafana）查看數據。

雖然 cAdvisor 仍然是經過 kubelet 的默認 Pod 監控組件，但 Heapster 已被棄用，如今 Kubernetes 經過 metric-server 使用指標。

Kubernetes metric server

從 Kubernetes v1.8 開始，來自 Kubernetes 和 cAdvisor 的資源使用狀況指標能夠經過 Kubernetes metric server API 得到，這與公開 Kubernetes API 的方式相同。

不過此服務也不容許咱們隨時間存儲值，而且缺少可視化或分析功能。Kubernetes metric server 可用於 Kubernetes 的高級編排，例如 Horizontal Pod Autoscaler 自動伸縮。

Kubernetes 儀表板（Dashboard）

Kubernetes 儀表板提供了一種簡單的方式，讓咱們經過 Kubernetes 命名空間和工做量查看環境。它提供了一種一致的方式來可視化基本數據，包括基本的 CPU、內存數據。另外，咱們還能夠從儀表板進行管理並採起措施，不過這就涉及到了多租戶集羣上的安全問題，須要設置適當的 RBAC 特權。

Kubernetes kube-state-metrics

還有一個組件是 kube-state-metrics，這是一項附加服務，它與 Kubernetes metrics-server 一塊兒運行，可輪詢 Kubernetes API 並將 Kubernetes 構造的特徵轉換爲指標。kube-state-metrics 能夠解決如下問題：

• 如今計劃了多少個副本？目前有多少可用？
• 有多少個 Pod 正在運行、已中止、已終止？
• 此 Pod 已重啓多少次？

咱們如今對在 Kubernetes 環境中構建合理的監控有了必定了解，雖然仍然沒有詳細的應用程序監控（例如：個人數據庫服務的響應時間是多少？），但至少能夠看到基礎主機、Kubernetes 節點以及 Kubernetes 狀態的一些監控。

Kubernetes liveness 和 readiness 探針

Kubernetes 探針發揮了按期監控 Pod 的運行情況和可用性的重要做用。它可讓咱們經過針對端點的請求和運行命令來任意定義「活動性」。如下是基於運行 cat 命令的 liveness 探針的簡單示例：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    image: gcr.io/google_containers/busybox
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5 

#source https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

用於 Kubernetes 監控的 Prometheus

Prometheus 是一個是開源的時間序列數據庫，它和 Kubernetes 同樣是 CNCF 項目。Prometheus 監控是圍繞 Prometheus 服務器的整個監控堆棧，該服務器會收集並存儲度量，另外還有用於儀表板的 Grafana。

Prometheus 入門很是容易，只要簡單設置 Prometheus、Grafana 和不多的元素便可。Prometheus 是監控 Kubernetes 的一種不錯方法，咱們能夠對本身的 Kubernetes 實施 DIY Prometheus 監控。

儘管一開始使用 Prometheus 監控 Kubernetes 真的很簡單，可是之後 DevOps 團隊會很快意識到 Prometheus 也有一些使用障礙，例如規模、RBAC 以及一些團隊合規性問題。

K8sMeetup

總結

Kubernetes 監控的事實標準是由許多開源工具構建的，例如 cAdvisor、Kubernetes metric server、kube-state-metrics 和 Prometheus。總而言之，咱們要考慮以適合的方式來監控咱們的 Kubernetes。

原文地址：https://mp.weixin.qq.com/s/NimzBHGHCxjTamWyoOyC1A