1. 程式人生 > >原生Kubernetes監控功能詳解-Part1

原生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/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/gke/

注意:請確保已啟用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)有充分的瞭解。

在本文中,我們重點關注了專為使用者提供監控和指標的工具。在本系列文章的下一篇中,我們將繼續分享那些關注工作負載擴縮容和生命週期管理的監控工