原生Kubernetes監控功能詳解-Part1

Kubernetes是一個開源的容器編排框架，它爲咱們提供了一種簡單的部署、擴展和監控的方法。本文將討論Kubernetes的內置監控功能，如Kubernetes dashboard、cAdvisor等。爲便於更好地理解，文內還提供了演示。

---

介 紹

Kubernetes是一個開源的容器編排框架，它爲咱們提供了一種簡單的部署、擴展和監控的方法。在本文中，咱們將討論Kubernetes的內置監控功能。爲了便於讀者更好地理解，本文包含了一些演示。

Kubernetes架構概述

在基礎架構級別，Kubernetes集羣是一組各自發揮特定功能的物理機或虛擬機。充當主要角色的物理機或虛擬機負責整個操做，並協調在全部node上運行的容器管理。

Master組件管理pod的生命週期：

• apiserver：爲全部其餘master組件公開API的主組件
• scheduler：負責依照pod規範中的信息來決定pod應該運行在哪一個node上
• controller-manager：負責node管理（檢測node是否出現故障）、pod複製和endpoint建立
• etcd：用於存儲全部內部集羣數據的鍵/值存儲

Node組件是Kubernetes中由master管理的worker機器。每一個node都包含運行pod所需的必要組件：

• kubelet：處理master及其上運行的node之間的全部通訊。它與容器運行時配合，負責部署和監控容器
• kube-proxy：負責維護node的網絡規則，還負責處理pod、node和外部之間的通訊。
• 容器運行時：在node上運行容器。

從邏輯角度看，一個Kubernetes部署，是由在集羣中各自發揮做用的各個組件組成：

• Pod：Kubernetes內部的基本部署單位。一個pod由一個或多個容器組成，這些容器共享網絡命名空間和IP地址。
• Service：充當負載均衡器。它們在池（一組pod）以前提供IP地址，且還提供控制訪問IP地址的策略。
• ReplicaSet：由deployment控制，負責確保deployment所需數量的pod都正常運行。
• Namespace(命名空間)：爲pod或service等不一樣類型的資源定義邏輯隔離。
• Metadata：根據容器的部署特徵對容器進行標記。

監控Kubernetes

若咱們想要預測問題並發現開發或部署中潛在的瓶頸，那麼對應用程序進行監控是必不可少的。

爲了幫助監控集羣和構成部署的許多活動組件，Kubernetes提供了一些內置的監控功能：

• Kubernetes dashboard：爲集羣上運行的資源提供一個概覽。它還提供了一種很是基本的部署以及與這些資源進行交互的方法。
• cAdvisor：一種用於監控資源使用狀況並分析容器性能的開源代理。
• Liveness和Readiness Probe：主動監控容器的健康狀況。
• Horizontal Pod Autoscaler：基於經過分析不一樣指標所收集的信息，根據須要增長pod的數量。

在本文中，咱們將重點介紹前兩個內置工具。在本系列文章的下一篇中，咱們將介紹其餘的監控工具。

Kubernetes中有許多指標須要監控。正如咱們會以兩種不一樣的方式（基礎架構和邏輯）描述架構那樣，咱們也能夠將監控分爲兩個主要組件：監控集羣自己以及集羣上運行的工做負載監控。

集羣監控

全部集羣都應監控底層服務器組件，由於服務器層的問題每每都會出如今工做負載中。監控node資源時要注意的一些指標包括CPU、磁盤和網絡帶寬。瞭解這些指標可讓咱們知道是否須要對集羣進行擴容或縮容（若是企業使用的是雲提供商，對運行成本很看重，那麼這一點更尤爲重要）。

工做負載監控

咱們還須要考慮與部署及其pod相關的指標。其中重要的一點，是將deployment中當下運行的pod數量與指望的數量進行對比。此外，咱們還應當注意健康檢查、容器指標以及最終的應用指標。

前期準備

在如下部分中，咱們將以demo的形式逐一介紹列出的內置監控功能，爲此咱們須要作的前期準備有：

• 谷歌雲平臺賬戶：使用免費試用版的便可，若你使用的是其餘的主流雲平臺，操做方法也是相似的。
• 用於運行Rancher的主機：能夠是我的PC / Mac或公有云中的VM。
• 谷歌雲SDK：應與運行Rancher的主機上的kubectl一塊兒安裝。經過使用你的憑據進行身份驗證（gcloud init和gcloud auth login），確保gcloud能夠訪問你的谷歌雲賬戶。

啓動Rancher實例

第一步，啓動Rancher實例。Rancher有一份很是直觀的入門指南可供參考：https://rancher.com/quick-start/

使用Rancher部署GKE集羣

按照操做指南，使用Rancher設置和配置Kubernetes集羣：

https://rancher.com/docs/ranc...

注意：請確保已啓用Kubernetes Dashboard，咱們這裏使用的Kubernetes 版本爲v.1.10。

圖1 使用Rancher建立Kubernetes集羣

Kubernetes Dashboard

Kubernetes dashboard是基於Web的Kubernetes用戶界面，咱們可使用它來對應用程序進行故障排除並管理集羣資源。

而Rancher，能幫助用戶一鍵安裝dashboard。dashboard的主要用途包括：

• 對集羣資源進行概述（包括總體狀況和每一個node的狀況），顯示全部命名空間，列出定義的全部存儲類
• 顯示集羣上運行的全部應用程序
• 提供關於集羣中Kubernetes資源狀態以及可能出現的任何錯誤的信息

要訪問dashboard，咱們須要在咱們的計算機和Kubernetes API服務器之間代理請求。輸入如下代碼便可使用kubectl啓動代理服務器：

代理服務器將在後臺啓動，輸出相似於下文的內容：

如今，要查看dashboard，請經過瀏覽器訪問如下地址：

http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/

而後，咱們須要在登陸頁面輸入相應的憑據：

圖2 Dashboard登陸

下面咱們未來了解如何使用服務賬戶機制，建立具備管理員權限的用戶。咱們將使用兩個YAML文件。

一個YAML文件用於建立服務賬戶：

另外一個YAML文件將爲咱們的用戶建立ClusterRoleBinding：

應用兩個YAML文件，來建立其定義的對象：

建立用戶並設置了正確的權限後，咱們須要找到令牌才能登陸：

kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}')

在Kubernetes dashboard憑據提示中選擇「Token（令牌）」，而後在字段中輸入你在上面檢索的值以進行身份驗證。

Kubernetes Dashboard包含幾個主要視圖：

• 管理視圖：列出了node、命名空間和持久卷以及其餘詳細信息。咱們能夠得到node的集成頁面（CPU和內存使用狀況）以及每一個node的單獨詳細信息頁面，顯示其指標、規範、狀態、分配的資源和pod。
• 工做負載視圖：顯示了在選定的命名空間中運行的全部應用程序。總結了關於工做負載的重要信息，例如StatefulSet或部署中準備好的pod數量或pod的當前內存使用狀況。
• 服務發現和負載均衡視圖：顯示了向外部公開服務的Kubernetes資源，並在集羣內啓用服務發現。
• 配置和存儲視圖：顯示了應用程序使用的持久卷聲明資源。配置視圖顯示了用於在集羣中運行的應用程序實時配置的全部Kubernetes資源。

在沒有任何工做負載運行的狀況下，dashboard頁面將爲空，由於此時在Kubernetes上不會部署任何內容。若是要瀏覽 dashboard提供的全部視圖，最佳選擇是部署使用不一樣工做負載類型的應用程序（StatefulSet、部署、副本集等）。這篇如何在Kubernetes上部署Redis的文章就是一個很好的示例，它展現了部署一個Redis集羣（具備卷聲明和configMaps的有狀態集）和一個測試應用程序（一個Kubernetes部署）時，dashboard會如何顯示相關信息。

配置完工做負載後，咱們能夠關閉一個node，而後檢查不一樣的選項卡，以查看一些更新：

圖3 Stateful Set的dashboard頁面

圖4 Pod的dashboard頁面

cAdvisor

cAdvisor是一個集成到kubelet二進制文件中的開源代理，主要用於監控資源使用狀況並分析容器的性能。cAdvisor會收集關於在給定node上運行的全部容器的CPU、內存、文件和網絡使用狀況的統計信息（cAdvisor不在pod層運行）。除核心指標外，cAdvisor還會監控事件。用戶可使用諸如kubectl top之類的命令直接訪問指標，也可使用調度程序執行調度層的指標（例如使用autoscaling）。

須要注意的是，cAdvisor不會長期存儲某些指標，所以若是須要使用該功能，則應尋找專用的監控工具。

從Kubernetes版本1.10起，cAdvisor的UI已經差很少被棄用了，Kubernetes 1.12版本以後cAdvisor的UI會被完全刪除。Rancher可讓你選擇用於集羣的Kubernetes版本。在爲此演示設置基礎架構時，咱們將集羣配置爲使用版本1.10，所以咱們仍然能夠訪問cAdvisor UI。

要訪問cAdvisor UI，咱們須要在咱們的計算機和Kubernetes API服務器之間進行代理。輸入如下命令啓動代理服務器的本地實例：

接下來，找到node的名稱：

你能夠經過如下地址在瀏覽器中查看UI，將node名稱替換爲你在命令行中找到的標識符：

http://localhost:8001/api/v1/nodes/gke-c-plnf4-default-pool-5eb56043-23p5:4194/proxy/containers/

圖5 初始cAdvisor UI

圖6 cAdvisor UI概述和流程

爲了確認kubelet正在監聽端口4194，你能夠登陸到node查看更多信息：

咱們能夠確認，在咱們的Kubernetes版本中，kubelet進程經過該端口提供cAdvisor Web UI：

若是你運行的Kubernetes版本爲1.12或更高，由於cAdvisorUI已被刪除，所以kubelet不會再監聽4194端口了。你可使用上面的命令進行確認。不過，因爲cAdvisor是kubelet二進制文件的一部分，所以相關指標仍然存在。

kubelet二進制文件使用Prometheus展現格式公開了全部runtime和cAdvisor指標：

http://localhost:8001/api/v1/nodes/gke-c-plnf4-default-pool-5eb56043-23p5/proxy/metrics/cadvisor

圖7 cAdvisor指標端點

在一大堆輸出中，你能夠重點查找和關注的指標有：

CPU:

• ocontainer_cpu_user_seconds_total：以秒爲單位，「用戶」累計消耗CPU的時間
• ocontainer_cpu_system_seconds_total：以秒爲單位，「系統」累計消耗CPU的時間
• ocontainer_cpu_usage_seconds_total：以秒爲單位，累計消耗CPU的時間（上述總和）

內存:

• ocontainer_memory_cache：頁面緩存內存的字節數
• ocontainer_memory_swap：容器交換使用狀況，以字節爲單位
• ocontainer_memory_usage_bytes：當前內存使用狀況，以字節爲單位，包括全部內存
• ocontainer_memory_max_usage_bytes：以字節爲單位，最大內存使用量

磁盤:

• ocontainer_fs_io_time_seconds_total：執行I/O所花費的時間，以秒爲單位
• ocontainer_fs_io_time_weighted_seconds_total：累計加權I/O時間，以秒爲單位
• ocontainer_fs_writes_bytes_total：寫入的累計字節數
• ocontainer_fs_reads_bytes_total：讀取的累計字節數

網絡:

• ocontainer_network_receive_bytes_total：接收的累計字節數
• ocontainer_network_receive_errors_total：接收時遇到的累計錯誤數
• ocontainer_network_transmit_bytes_total：傳輸的累計字節數
• ocontainer_network_transmit_errors_total：傳輸時遇到的累計錯誤數

一些其餘有用的指標：

• / healthz：用於肯定cAdvisor是否健康的端點
• / healthz / ping：檢查與etcd的鏈接情況
• / spec：返回cAdvisor MachineInfo()的端點

例如，要查看cAdvisor MachineInfo()，咱們能夠訪問：

http://localhost:8001/api/v1/nodes/gke-c-plnf4-default-pool-5eb56043-23p5:10255/proxy/spec/

圖8 cAdvisor規範端點

pod端點爲node上運行的pod提供與kubectl get pods -o json相同的輸出：

http://localhost:8001/api/v1/nodes/gke-c-plnf4-default-pool-5eb56043-23p5:10255/proxy/pods/

圖9 cAdvisor pod端點

一樣，也能夠經過訪問如下連接來獲取日誌：

http://localhost:8001/logs/kube-apiserver.log

結 語

監控的重要性不言而喻，它讓咱們能充分了解到應用程序的情況。Kubernetes有不少內置工具可供用戶們選擇，讓你們更好地對基礎架構層（node）和邏輯層（pod）有充分的瞭解。

在本文中，咱們重點關注了專爲用戶提供監控和指標的工具。在本系列文章的下一篇中，咱們將繼續分享那些關注工做負載擴縮容和生命週期管理的監控工具，敬請期待。