搞Kubernetes運維的朋友應(yīng)該都有這種經(jīng)歷集群跑起來了Pod也在轉(zhuǎn)但是你想看看每個節(jié)點還剩多少內(nèi)存、某個應(yīng)用最近半小時CPU是不是飆了卻發(fā)現(xiàn)無從下手。直接kubectl top node敲下去報錯說metrics API不可用因為沒有部署采集組件。這時候最經(jīng)典也最實用的一套組合拳就是Kubernetes監(jiān)控里最常見的搭配Metrics Server負責采集節(jié)點和Pod的CPU、內(nèi)存數(shù)據(jù)Dashboard負責把數(shù)據(jù)變成可視化的界面。今天這篇就把這套監(jiān)控組合從部署到排查完整走一遍講清楚每一步的原理、選擇和避坑點。這套方案適合誰適合剛把集群跑起來、需要基礎(chǔ)資源監(jiān)控看板的運維和開發(fā)也適合準備自己搭一套輕量監(jiān)控體系、但暫時不想上Prometheus那套重型方案的人。它能解決的核心問題很直接在Dashboard里直接看節(jié)點和Pod的歷史與實時資源占用曲線執(zhí)行kubectl top不再報錯HPA也能正常拿到指標。1. 基礎(chǔ)認知為什么是Metrics Server加Dashboard1.1 先搞清楚Kubernetes監(jiān)控體系的分層Kubernetes監(jiān)控不是一個單一的東西而是分了好幾層。從下往上大致是物理資源層節(jié)點CPU、內(nèi)存、磁盤、系統(tǒng)組件層kubelet、API Server、調(diào)度器自己的狀態(tài)、應(yīng)用層容器內(nèi)的業(yè)務(wù)指標比如請求量、延遲和事件層Pod調(diào)度失敗、驅(qū)逐等。我們平時聊的先搭個監(jiān)控看看絕大多數(shù)場景指的都是第一層也就是資源指標。這批數(shù)據(jù)的來源是每臺節(jié)點上的kubelet它內(nèi)置了一個叫cAdvisor的組件負責采集容器和節(jié)點的CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤等原始數(shù)據(jù)。難點在于kubelet把數(shù)據(jù)采上來之后是通過一個本地接口暴露的你不可能每次都跑到每臺機器上去看。所以需要一個集群層面的組件把這些數(shù)據(jù)匯總并且按照標準的Kubernetes API方式暴露出來。這就是Metrics Server的核心價值。它把kubelet采集到的數(shù)據(jù)聚合然后注冊成metrics.k8s.io這個API之后你用kubectl top也好Dashboard也好HPA也好都從這個API拿數(shù)據(jù)。1.2 為什么第一套監(jiān)控推薦這兩個而不是直接上Prometheus很多人會覺得既然要做監(jiān)控為什么不一步到位直接上Prometheus加Grafana我的看法是分階段。Prometheus體系功能強大但學習曲線和組件數(shù)量都不是零成本的你需要部署Prometheus自身、node-exporter、kube-state-metrics還要學PromQL寫查詢這對剛接觸Kubernetes監(jiān)控的人來說是個不小的臺階。Metrics Server配合Dashboard這套組合的優(yōu)勢在于輕量、官方維護、零查詢語言負擔。Metrics Server本身就是Kubernetes官方的插件部署起來就是一組鏡像加幾個YAML。Dashboard同樣是官方項目提供了Web界面點幾下就能看到集群資源水位。它不追求深度分析但能把節(jié)點是不是快滿了哪個Pod在持續(xù)占內(nèi)存這類最要命的問題用曲線直觀呈現(xiàn)出來。等這套基礎(chǔ)監(jiān)控跑明白了再上Prometheus做更細粒度的告警和歷史數(shù)據(jù)持久化是更平滑的路徑。1.3 這套組合的數(shù)據(jù)通路到底是怎么走的先說清一條完整的數(shù)據(jù)鏈路后面排查問題全靠它。Pod在節(jié)點上跑節(jié)點上的kubelet通過cAdvisor采集容器CPU和內(nèi)存的使用數(shù)據(jù)。Metrics Server通過kubelet的10250端口的只讀接口把每個Pod的指標樣本抓取下來聚合后緩存在自己的內(nèi)存里并且通過Kubernetes的聚合API層注冊成metrics.k8s.io。Dashboard在展示資源圖表時向后端API Server發(fā)起查詢API Server把請求代理給Metrics ServerMetrics Server返回內(nèi)存里的緩存數(shù)據(jù)Dashboard再繪制成曲線圖。這條鏈路里有三個關(guān)鍵點值得圈出來Metrics Server本身不落庫數(shù)據(jù)是內(nèi)存中的臨時快照所以你看不到很久以前的歷史數(shù)據(jù)默認只保留最近幾分鐘的窗口。metrics.k8s.io這個API是聚合API由APIService對象注冊檢查這個對象的健康狀態(tài)是排查kubectl top沒數(shù)據(jù)的第一步。Dashboard查詢的是實時指標它本身不直接和kubelet通信所有數(shù)據(jù)都經(jīng)過API Server代理所以權(quán)限模型走的是RBAC那一套Dashboard需要配置ServiceAccount和對應(yīng)的ClusterRole。理解這條鏈路之后你就會發(fā)現(xiàn)很多所謂奇怪的問題其實一點都不奇怪只是鏈路里某個環(huán)節(jié)沒就位。2. 部署前準備版本適配與工具選型2.1 版本適配是第一個隱形坑我見過太多人部署失敗第一反應(yīng)是網(wǎng)絡(luò)問題或者YAML寫錯了其實往往是被版本適配坑的。Metrics Server和Kubernetes主版本之間是有對應(yīng)關(guān)系的不匹配的時候會出現(xiàn)證書校驗失敗、API無法注冊這類莫名其妙的問題。以當前主流版本為例Kubernetes 1.19到1.25對應(yīng)Metrics Server v0.6.x鏡像是registry.k8s.io/metrics-server/metrics-server:v0.6.4。Kubernetes 1.26及以上推薦Metrics Server v0.7.x或者更新的v1.x版本因為kubelet的TLS證書行為有變化舊版本會握手失敗。還需要留意容器運行時。如果節(jié)點用的containerd而不用DockerMetrics Server本身沒影響但Dashboard的鏡像拉取策略和網(wǎng)絡(luò)設(shè)置有時會有小坑這個后面會單獨說。判斷版本匹配的一個笨但有效的辦法去Metrics Server官方GitHub的README里找到Compatibility表格對著看。不要憑感覺選最新版本最新版本不一定兼容你的集群。2.2 我用的環(huán)境與工具清單我這次演示的標準環(huán)境是某公司內(nèi)部測試集群用kubeadm方式安裝的Kubernetes v1.28版節(jié)點上容器運行時為containerd網(wǎng)絡(luò)插件用的是Calico。這樣的環(huán)境應(yīng)該能覆蓋大部分生產(chǎn)或測試場景的共性。需要用到的工具有kubectl本地操作集群的客戶端版本最好和集群小版本差異不超過一個版本。helm雖然這篇主要以純YAML部署為主但我會提到用helm做Dashboard部署的替代方式官方chart維護起來會方便一些。瀏覽器加一個SSH端口轉(zhuǎn)發(fā)工具因為Dashboard大多數(shù)時候不會暴露成LoadBalancer服務(wù)而是通過kubectl port-forward訪問。強調(diào)一下雖然我用的是RHEL類的Linux發(fā)行版做跳板機但kubectl port-forward的用法在所有平臺上都一樣。2.3 為什么建議用官方Y(jié)AML而不是自己寫Metrics Server和Dashboard官方都提供了標準的部署YAML分別是components.yaml和recommended.yaml。直接用的理由有三個第一這兩份文件里的鏡像地址、權(quán)限綁定、啟動參數(shù)都是經(jīng)過大量生產(chǎn)環(huán)境驗證的自己拍腦袋寫的配置很容易漏掉必需的參數(shù)比如--kubelet-preferred-address-typesInternalIP這類細節(jié)。第二官方文件里有配套的RBAC對象ServiceAccount、ClusterRole、ClusterRoleBinding都是齊的少一個Dashboard就登錄不進去。第三升級的時候直接替換文件就能平滑跟進不用手工比對差異。當然直接用不意味著閉眼用。內(nèi)網(wǎng)環(huán)境拉不了外部鏡像的情況很常見你需要提前把鏡像docker pull或者ctr pull下來打上tag推到自己的私有倉庫然后修改YAML里的image字段。這是標準的離線部署操作后面排查章節(jié)會再提到和鏡像拉取相關(guān)的坑。2.4 端口和網(wǎng)絡(luò)層面的預期Metrics Server跑起來后默認監(jiān)聽443端口它需要訪問每個節(jié)點的kubelet 10250端口。這一步在使用網(wǎng)絡(luò)安全策略NetworkPolicy的集群里尤其要留意如果那個命名空間默認禁止進站流量Metrics Server到節(jié)點的抓取會失敗表現(xiàn)就是Pod起來了但所有指標都拉不到甚至API注冊不成功。Dashboard主容器默認監(jiān)聽8443端口通過kubectl port-forward直接轉(zhuǎn)發(fā)到本地的某個端口訪問。如果集群里的Ingress已經(jīng)配置好也可以選擇用Ingress暴露但需要額外處理TLS證書和Dashboard自身的認證方式我建議你在第一次部署時就用端口轉(zhuǎn)發(fā)簡單直接。3. Metrics Server部署與深度解析3.1 部署Metrics Server的標準步驟部署的第一步是拉取官方清單文件。wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml然后直接應(yīng)用kubectl apply -f components.yaml等一兩分鐘檢查Pod狀態(tài)kubectl get pods -n kube-system -l app.kubernetes.io/namemetrics-server正常情況下應(yīng)該看到類似這樣的輸出NAME READY STATUS RESTARTS AGE metrics-server-7d5b6d9c9b-x4k2m 1/1 Running 0 96s接著驗證API是否注冊成功kubectl get apiservice v1beta1.metrics.k8s.io輸出中的AVAILABLE列應(yīng)該是True。這一步是我在所有集群上的必查項因為Pod處于Running狀態(tài)并不能說明API一定可用。再驗證數(shù)據(jù)采集是否正常kubectl top node kubectl top pod -A如果你看到類似error: metrics not available yet的提示先別慌多數(shù)情況下只是因為Metrics Server才啟動第一輪采集還沒完成。等一分鐘再敲一次。如果反復都是這個錯誤就需要按第五章的排查思路去查了。3.2 核心原理聚合API與參數(shù)選擇Metrics Server能讓你用kubectl top這種原生命令查指標是因為Kubernetes提供了一套聚合API機制。簡單說你可以自己寫一個后端服務(wù)提供一組特定格式的API然后通過創(chuàng)建APIService對象告訴API Server這個路徑的請求代理給那個服務(wù)處理。Metrics Server正是這么做的它把自己注冊成了metrics.k8s.io這個API組。在components.yaml里你可能會注意到Metrics Server Deployment里有一堆啟動參數(shù)這些參數(shù)是部署后能不能成功采數(shù)據(jù)的關(guān)鍵。拿最常見的幾個來說--kubelet-preferred-address-typesInternalIP告訴Metrics Server優(yōu)先使用節(jié)點的內(nèi)網(wǎng)IP去訪問kubelet而不是主機名。如果你的集群DNS解析有問題不加這個參數(shù)會解析到錯誤地址導致抓取失敗。--cert-dir/tmpMetrics Server自己也需要TLS證書默認會掛載一個臨時目錄存放自簽證書。如果你看到日志里報找不到證書多半是CERT_DIR沒有指向Deployment里指定的volume路徑。--kubelet-use-node-status-port新版本默認行為是使用節(jié)點狀態(tài)里上報的端口適用面更廣。另一個需要理解的點是cAdvisor數(shù)據(jù)源。Metrics Server本身不采集數(shù)據(jù)它是向每個節(jié)點上的kubelet發(fā)請求kubelet再從cAdvisor拿數(shù)據(jù)返回。所以如果你單獨啟用了某種運行時隔離策略或者kubelet配置了自定義的cgroup驅(qū)動Metrics Server得到的數(shù)值可能會和你在宿主機上用free看到的有偏差這在容器化資源統(tǒng)計里是正常的不用糾結(jié)。3.3 鏡像拉取問題的常見解法國內(nèi)網(wǎng)絡(luò)環(huán)境拉registry.k8s.io的鏡像經(jīng)常失敗這是部署Metrics Server時最普遍的障礙。解決方案很直接用鏡像代理或者先拉到本地再推私有倉庫。以containerd運行時為例可以這樣操作ctr -n k8s.io images pull registry.k8s.io/metrics-server/metrics-server:v0.6.4如果這個地址也超時可以用一些公共鏡像倉庫的代理地址先拉取然后重新打tagctr -n k8s.io images pull docker.io/mirrorgooglecontainers/metrics-server:v0.6.4 ctr -n k8s.io images tag docker.io/mirrorgooglecontainers/metrics-server:v0.6.4 registry.k8s.io/metrics-server/metrics-server:v0.6.4然后修改components.yaml里的image字段指向你自己的私有倉庫地址再apply即可。需要注意改鏡像地址的同時imagePullPolicy最好設(shè)置成IfNotPresent避免節(jié)點在鏡像已經(jīng)存在的情況下還要去遠程倉庫校驗。3.4 高可用與多副本部署生產(chǎn)環(huán)境如果只有單副本Metrics Server一旦Pod被重新調(diào)度監(jiān)控會短暫中斷。用Deployment默認的replicas: 1在測試環(huán)境沒問題但如果有條件建議調(diào)整為兩個副本spec: replicas: 2 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 maxSurge: 1配兩個副本之后還需要在spec.template.spec里加上調(diào)度分散的配置比如podAntiAffinity讓兩個Pod盡量不落在同一節(jié)點上。另外多副本模式有個細節(jié)Metrics Server的啟動參數(shù)里不要加--metric-resolution這種會導致數(shù)據(jù)不一致的參數(shù)保持默認即可因為每個副本都是獨立從kubelet抓取數(shù)據(jù)是同一份快照副本之間不需要同步。3.5 安全加固限制Metrics Server的訪問范圍Metrics Server作為集群內(nèi)的一個高權(quán)限組件它默認可以獲取所有命名空間的資源指標。如果集群安全要求嚴可以通過RBAC對它做約束。components.yaml里有個ClusterRole叫system:metrics-server它的規(guī)則列表指定了可以讀取nodes/metrics、pods等資源。盡量不要去擴大它的權(quán)限范圍如果業(yè)務(wù)上有隔離需求可以考慮用--metric-resolution和--kubelet-only組合限制它只從kubelet拿數(shù)據(jù)不讓它直接訪問Pod的Exec接口之類的。另外Metrics Server的ServiceAccount在kube-system命名空間平時很少被單獨審計建議在部署后第一時間給這個ServiceAccount打上標簽方便后續(xù)結(jié)合策略引擎做異常檢測。4. Dashboard部署與登錄配置4.1 部署Dashboard主體Metrics Server是數(shù)據(jù)采集層Dashboard是展示層兩者配合起來才能看到曲線。Dashboard官方提供的部署文件叫recommended.yaml里面包含了所有必要資源對象。kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml這個清單會創(chuàng)建kubernetes-dashboard命名空間部署Deployment、Service、ServiceAccount還有一系列RBAC規(guī)則。默認情況下Dashboard的Service類型是ClusterIP端口443這意味著只有集群內(nèi)部可以訪問。這也是我們接下來需要用端口轉(zhuǎn)發(fā)訪問的原因。查看Dashboard Pod狀態(tài)kubectl get pods -n kubernetes-dashboard因為Dashboard鏡像比較大加上有時候解析慢Pod在ContainerCreating階段多停一會兒是正常的。遇到ImagePullBackOff就按鏡像拉取問題處理思路和前面Metrics Server一樣。4.2 Dashboard的認證方式Token登錄Dashboard默認不支持賬號密碼登錄可以用兩種方式認證一種是Kubeconfig一種是Token。實際運維里Token方式最常用因為它只依賴Kubernetes自身的ServiceAccount機制不需要額外配置。創(chuàng)建一個專門給Dashboard用的管理員ServiceAccountapiVersion: v1 kind: ServiceAccount metadata: name: admin-user namespace: kubernetes-dashboard再創(chuàng)建一個ClusterRoleBinding把它綁到集群管理員角色上apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: admin-user roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: admin-user namespace: kubernetes-dashboard然后取得這個ServiceAccount的Token。新版本Kubernetes里ServiceAccount會自動創(chuàng)建對應(yīng)的Secret名稱一般是admin-user-token-xxxxx。獲取令牌的命令是kubectl -n kubernetes-dashboard create token admin-user這條命令會生成一個有時效的Token默認有效期為1小時適合臨時登錄。如果你希望Token長期有效傳統(tǒng)做法是直接讀取Secret里的token字段kubectl get secret -n kubernetes-dashboard $(kubectl get secret -n kubernetes-dashboard -lapp.kubernetes.io/componentkubernetes-dashboard -o jsonpath{.items[0].metadata.name}) -o jsonpath{.data.token} | base64 -d不過提醒一句長期Token增加了泄露風險。如果是臨時演示或排查用create token就好如果需要長期用建議通過外部密鑰管理系統(tǒng)來簽發(fā)和輪換而不是把Token硬編碼到腳本里。4.3 訪問Dashboard端口轉(zhuǎn)發(fā)與Ingress選型登錄和訪問是很多人第一次卡住的地方。端口轉(zhuǎn)發(fā)的方式很簡單在一臺能連通Kubernetes API Server的機器上執(zhí)行kubectl port-forward -n kubernetes-dashboard service/kubernetes-dashboard 8080:443然后本地瀏覽器訪問https://localhost:8080瀏覽器會提示證書不受信任這是正常的因為Dashboard用的是自簽證書選擇繼續(xù)訪問即可。需要注意端口轉(zhuǎn)發(fā)只適合臨時使用或者你本機直連的情況。如果集群有多個節(jié)點其他同事也要訪問Dashboard每次都讓人家自己轉(zhuǎn)發(fā)就很麻煩。這時候可以配置Ingress。Dashboard的Service是HTTPS的所以Ingress需要配置TLS后端協(xié)議也要設(shè)為HTTPS。具體的注解取決于你用的Ingress Controller以常見的Nginx Ingress為例apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: dashboard namespace: kubernetes-dashboard annotations: nginx.ingress.kubernetes.io/backend-protocol: HTTPS nginx.ingress.kubernetes.io/ssl-passthrough: true spec: ingressClassName: nginx tls: - hosts: - dashboard.example.com secretName: kubernetes-dashboard-tls rules: - host: dashboard.example.com http: paths: - path: / pathType: Prefix backend: service: name: kubernetes-dashboard port: number: 443這里用了ssl-passthrough因為Dashboard是自簽HTTPS證書如果Ingress再終止TLS會多一層證書問題。生產(chǎn)環(huán)境建議把Dashboard置于內(nèi)部域名下不要暴露到公網(wǎng)畢竟Dashboard有集群管理權(quán)限暴露公網(wǎng)等于把鑰匙掛在門上。4.4 登錄后的界面布局與核心功能用Token登錄后你會進入Dashboard主界面。左側(cè)導航有幾個核心區(qū)域先說最常用的。集群概覽頂部直接展示節(jié)點數(shù)、命名空間數(shù)、內(nèi)存請求總量等摘要數(shù)字下方是按節(jié)點排列的資源使用量條形圖。節(jié)點列表點開某個節(jié)點可以看到該節(jié)點上所有Pod的列表以及每個Pod的實時CPU、內(nèi)存占用還有節(jié)點的壓力狀態(tài)。工作負載按Deployment、StatefulSet、DaemonSet等分類查看點進去能看到每個工作負載的Pod列表、重啟次數(shù)、調(diào)度事件以及日志入口。服務(wù)和Ingress查看服務(wù)暴露方式調(diào)試端口映射很方便。垂直Pod自動擴縮容和水平Pod自動擴縮容如果你配置了HPADashboard里可以直接看到當前目標指標和實際指標值。Dashboard里最讓我受用的一個功能是查看某個Pod的日志不再需要kubectl logs -f一條條敲。有一個點必須提醒Dashboard默認顯示的CPU指標是Core數(shù)量內(nèi)存是字節(jié)數(shù)如果你在圖表里看到數(shù)值變化規(guī)律詭異先確認單位再下結(jié)論。4.5 自定義Dashboard資源配額與隔離如果團隊里有多個人共同使用Dashboard通常不希望所有人都拿到cluster-admin權(quán)限。更合理的做法是按角色拆分查看類權(quán)限綁定到view這個ClusterRole需要重啟Pod的再給一個包含delete權(quán)限的自定義Role。Dashboard自帶的RBAC模型和Kubernetes原生的RBAC是一致的所以控制好ServiceAccount的權(quán)限就控制了Dashboard的權(quán)限。如果你在Dashboard里創(chuàng)建了自定義資源比如某個命名空間下的DeploymentDashboard會直接用你的ServiceAccount身份去調(diào)用API Server權(quán)限校驗是實時的。這個設(shè)計既方便又危險有時候你在Dashboard里刪東西刪不掉是因為當前Token對應(yīng)的角色沒有對應(yīng)命名空間的刪除權(quán)限這恰恰說明權(quán)限隔離生效了是好事。5. 實操過程從零到有一次完整走通5.1 完整命令時間線為了讓你對這個過程有整體把握我把從零部署到成功看到Pod曲線的完整命令時間線放在這里。這部分每一行我都實際跑過你可以照抄。第一段部署Metrics Serverkubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml等Pod起來之后驗證kubectl get pods -n kube-system -l app.kubernetes.io/namemetrics-server kubectl get apiservice v1beta1.metrics.k8s.io kubectl top node第二段部署Dashboardkubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml kubectl get pods -n kubernetes-dashboard -w第三段創(chuàng)建登錄賬號和獲取Tokenkubectl create -f dashboard-adminuser.yaml kubectl -n kubernetes-dashboard create token admin-user第四段訪問Dashboardkubectl port-forward -n kubernetes-dashboard service/kubernetes-dashboard 8080:443瀏覽器打開https://localhost:8080粘貼Token登錄。進到界面以后點節(jié)點列表找到某個節(jié)點點擊進去在Dashboards那個區(qū)域就能看到CPU和內(nèi)存的曲線圖。5.2 理解你看到的指標CPU與內(nèi)存曲線怎么讀登錄Dashboard之后很多人第一反應(yīng)是這曲線怎么看著不對。這里把讀圖的邏輯講清楚。Dashboard里節(jié)點的CPU使用率是Metrics Server返回的實時樣本它代表的是節(jié)點上所有容器進程CPU使用量的總和除以節(jié)點可分配的CPU核數(shù)。注意它不包含系統(tǒng)進程和內(nèi)核本身的開銷所以你會看到節(jié)點CPU使用率即使業(yè)務(wù)很忙也很難沖到100%因為有一部分CPU被kubelet、系統(tǒng)守護進程等占用但Metrics Server沒有統(tǒng)計進去。內(nèi)存同理節(jié)點內(nèi)存使用率是Pod實際占用的量不包含Page Cache因此和free命令看到的used差別很大是正常的。某個Pod的CPU曲線出現(xiàn)尖峰不代表就是應(yīng)用故障有可能是初始化容器在跑數(shù)據(jù)遷移或者Java應(yīng)用的JIT編譯瞬間占滿核。要結(jié)合重啟次數(shù)和調(diào)度事件一起判斷才不容易誤判故障。我自己踩過這樣的坑一個Pod因為OOMKilled反復重啟但CPU曲線看起來一點都不忙后來發(fā)現(xiàn)是內(nèi)存配額設(shè)置得太低OOM發(fā)生在內(nèi)存維度跟CPU沒關(guān)系。5.3 讓Dashboard顯示HPA目標指標Dashboard支持查看HPA狀態(tài)前提是你的集群里已經(jīng)安裝了Metrics Server。在Dashboard左側(cè)導航找Horizontal Pod Autoscalers打開某個HPA的詳情頁能看到目標指標比如CPU利用率的當前值和目標值。如果當前值一直顯示unknown基本可以斷定Metrics Server沒有就緒回到第3章去查。這里有一個配置細節(jié)值得單獨說HPA如果想按Pod的平均CPU利用率擴縮容需要在Deployment上設(shè)置正確的resources.requests.cpu因為HPA的利用率是當前使用量除以請求量沒有requestsHPA就沒有計算基礎(chǔ)Dashboard上也沒法顯示百分比。很多人部署了HPA但一直不生效問題往往出在資源請求沒有設(shè)置。5.4 實操中我建議你補充的三個小工具Metrics Server和Dashboard不是萬能的它們在歷史趨勢、告警方面很弱所以我在實踐里會給這套組合補充三個輕量工具kube-state-metrics它把集群里各種對象的狀態(tài)變成Prometheus格式的指標比如Deployment的期望副本數(shù)和實際副本數(shù)。Metrics Server只關(guān)心運行中的Pod資源使用而kube-state-metrics能反映配置層面的漂移。node-problem-detector檢測節(jié)點層面的異常比如內(nèi)核死鎖、容器運行時無響應(yīng)。這個東西是DaemonSet部署成本很低但能補齊Dashboard看不到的底層故障。sloop開源的小工具可以按時間線展示Pod的調(diào)度歷史和狀態(tài)變化對排查某個Pod為什么被驅(qū)逐特別有用。這些工具不是必選項但加上了之后你會發(fā)現(xiàn)這套監(jiān)控從能看變成了能查。5.5 從演示走向生產(chǎn)參數(shù)調(diào)整與資源配額演示環(huán)境里使用默認參數(shù)沒問題但生產(chǎn)環(huán)境有幾個硬性要求建議提前調(diào)好。Metrics Server的Deployment需要顯式聲明資源requestsresources: requests: memory: 100Mi cpu: 100m不建議把requests設(shè)得太低否則在內(nèi)存緊張的節(jié)點上Metrics Server可能被判定為不可調(diào)度而監(jiān)控組件恰恰是最不該缺失的。Dashboard的Deployment默認資源請求比較保守在大量并發(fā)訪問時會OOM。我在并發(fā)量高的環(huán)境會把它調(diào)到memory: 512Mi同時加上limits防止它把節(jié)點內(nèi)存吃滿。Dashboard的容器主要是渲染和代理API內(nèi)存是主要瓶頸。另外Dashboard的Service默認是ClusterIP如果你需要跨集群訪問而又不想開Ingress可以臨時改Service類型為NodePort但訪問時一定記得加TLS。端口轉(zhuǎn)發(fā)適合排障NodePort適合短期的跨網(wǎng)絡(luò)測試長期使用我更傾向于Ingress加內(nèi)部DNS。6. 常見問題與排查技巧實錄6.1 Metrics Server一直不Ready這是部署Metrics Server遇到最多的狀況。Pod狀態(tài)ContainerCreating一直不動一般就是鏡像拉不下來按照鏡像代理的方式處理。如果Pod顯示CrashLoopBackOff先看日志kubectl logs -n kube-system -l app.kubernetes.io/namemetrics-server日志里常見的錯誤是unable to fully discover metrics: unable to fetch metrics from node。這種多半是kubelet的證書問題。Kubernetes 1.26以上的集群里kubelet會生成一個由集群根CA簽名的服務(wù)證書但如果你沒有把根CA配置到kubelet的--tls-cert-file參數(shù)里Metrics Server和kubelet之間會TLS握手失敗。解決辦法是給Metrics Server加上啟動參數(shù)--kubelet-insecure-tls但這只是臨時繞過證書驗證。正規(guī)做法是把集群CA加入Metrics Server的信任列表也就是修改Deployment的volume和volumeMount把宿主機的/etc/kubernetes/pki/ca.crt掛載進去。生產(chǎn)環(huán)境我建議用正規(guī)做法--kubelet-insecure-tls能用但本質(zhì)上是關(guān)閉了TLS驗證審計時不好看。6.2 metrics.k8s.io的ABAC問題還有一個很不起眼但是坑過人的點如果集群開啟了ABAC模式Metrics Server的注冊可能不會生效。雖然現(xiàn)在幾乎都是RBAC但老集群偶爾還會遇到。驗證方法是在Master節(jié)點上查API Server的啟動參數(shù)看有沒有--authorization-modeABAC。如果確實開了需要把Metrics Server的ServiceAccount加入ABAC策略文件否則kubectl top會一直報metrics.k8s.io is forbidden。不過這種場景現(xiàn)在比較少見遇到的話基本上是歷史原因短平快的處理方案是建議集群遷移時切到RBAC模式。6.3 Dashboard登錄后白屏或空白我遇到過Dashboard能訪問但登錄后頁面空白的情況。排查步驟按照這個順序來瀏覽器F12看控制臺有沒有報錯。常見的報錯是failed to fetch metrics這種就回去查Metrics Server跟Dashboard本身沒有關(guān)系。確認Token是真正的服務(wù)賬號Token。新版Kubernetes里如果你用kubectl get secret admin-user-token-xxx -o jsonpath{.data.token}取出來的Token有些場景因為--legacy-service-account-token-clean-up的啟動參數(shù)會被標記為無效Dashboard登錄會直接失敗。確認瀏覽器沒有攔截跨域請求。Dashboard自身的API請求是從頁面發(fā)到集群API Server如果中間有代理做了攔截就會出現(xiàn)白屏。白屏問題九成以上都是Token或者Metrics API不通Dashboard本身極少掛。6.4 數(shù)值顯示NaN或者負數(shù)有段時間我配置了Metrics Server的自定義參數(shù)Dashboard里顯示CPU利用率為NaN排查下來發(fā)現(xiàn)是抓取間隔調(diào)得太短Metrics Server在API Server做聚合時累計的計算窗口產(chǎn)生了邊界問題CPU平均值算出來是空的。后來我把配置恢復默認數(shù)值就正常了。內(nèi)存使用量為負數(shù)的情況多半發(fā)生在你給Pod設(shè)置的limits.memory小于實際節(jié)點上的Page Cache統(tǒng)計口徑時雖然少見但遇上不要緊張懷疑統(tǒng)計口徑差異而不是組件故障。6.5 端口轉(zhuǎn)發(fā)可以訪問但Ingress訪問不通這個區(qū)別很典型。端口轉(zhuǎn)發(fā)是直接走API Server代理如果轉(zhuǎn)發(fā)通了說明Dashboard后端本身沒問題。Ingress不通問題大多在Ingress Controller的HTTPS后端配置。你可以先關(guān)掉Ingress里的ssl-passthrough改用nginx.ingress.kubernetes.io/backend-protocol: HTTPS并確保證書Secret里的私鑰和證書是配套的。還有一種情況是Ingress Controller自己沒有監(jiān)聽443端口檢查Controller的Service里是否暴露了443把它映射到宿主機端口即可。這類網(wǎng)絡(luò)問題有個萬能的排查起點在集群內(nèi)curl一下Dashboard Service地址確認后端可達再從Ingress Controller所在節(jié)點curl Service地址逐段縮小范圍問題很快就定位了。我實際用了這一套組合很久最大的感觸是它幫我擋掉了大量半夜接到告警但不知道集群怎么了的焦慮。Metrics Server加Dashboard的監(jiān)控能力雖然不算深但覆蓋面剛剛好尤其是對中小規(guī)模集群從節(jié)點CPU到Pod內(nèi)存再到HPA目標用一對組合就能講清楚集群的大部分故事。踩過幾次坑之后我現(xiàn)在的習慣是每次部署完都順手把kubectl top node跑一遍把輸出存下來當作集群初始狀態(tài)的基線。如果以后要繼續(xù)往深走可以在同一套鏈路里再引入Prometheus做長期存儲和告警但第一步先讓Dashboard上的曲線亮起來這比什么都有說服力。