動 手 玩耍 K8s Cluster https://reurl.cc/nN59zl 

請進去這邊 -> https://reurl.cc/nN59zl • 認領 一 個 Cluster，並且打勾 • 使 用 密碼 sre_summit_2024 去貼上 private_key • 記得權限 600 • 使 用 [email protected] 搭配這把 key 登入三台機器 • Port: 31111 -> Grafana • Port: 31112 -> Prometheus • 請 用 sudo 的 方 式執 行 kubectl • 請先確保 自己 可以連進去到所有節點 並且有能 力 於 master 節點運 行 kubectl versions • 節點都是 Debian 的系統 

環境介紹 • 三台機器搭建的 K8s • 請 用 提供的 private key 存取 • 三台機器都有 public IP • 每個環境都預先安裝好 • Prometheus: 31112 • Grafana: 31111 • 用 Public IP + Port 即可存取 

Cluster Provider https://docs.cloudnative.tw/ 

環境介紹 • Master 機器下有 一 個名為 sre-2024-workshop 的資料夾 • 裡 面 有 q1~q10 對應 10 個問題的相關檔案 (除了 q2) • *.yaml -> 每個問題需要部署的腳本 • App -> 每個 image 的 source code • 基本上你不需要重新 Build Image，專 心 看 YAML 與 source code 找出問題 並且修復即可 • 資料夾內的 others 有描述如何安裝 kube-prometheus-stack，包含 Grafana + Prometheus 的安裝 方 式 

Question 1 • 觸發條件: 部署 q1/deploy.yaml • 症狀 • Application 大 概70秒左右後會 crash • 目 標 • 其不會 Crash 

A 1 • 問題點有兩個 • OOM • Liveness Probe • 調 高 兩者的 limit 即可 • CPU • Memory 

Question 2 • 觸發條件: N/A • 症狀 • Kubectl get nodes 後有節點發 生 顯 示 not ready • 目 標 • 修正節點，讓節點運作正常 

A 2 • 節點的 Kubelet 因為 swap 的關係沒有辦法起來 • 關閉 swap 並且重啟 kubelet 即可 • sudo swapoff -a • sudo systemctl restart kubelet 

Question 3 • 觸發條件: 部署 q3/deploy.yaml 且確保 Q2 問題已經修復 • 症狀 • kubectl get pods 後，發現每個副本都 crash，但是有些會顯 示 invalid • 目 標 • 找出原因，解釋為什麼是 invalid • 修復，讓其正確顯 示 

A 3 • sudo timedatectl set-ntp on 

Question 4 • 觸發條件: 部署 q4/deploy.yaml • 症狀 • Client 沒有辦法連接到 Server，顯 示 Response Code:000 • 目 標 • Client 可以順利連接 

A 4 • 問題點有多個 • Server: Service 沒有連接好 • Client 的參數 port 是 8080，但是 service 是 80 

Question 5 • 觸發條件: 部署 q5/deploy.yaml • 症狀 • Statefulset application 跑不起來 • 目 標 • 如何再不移除 PVC 的情況下修好問題，並且可以 用 deploy.yaml 順利部署 • 意思就是 kubectl get sts q5 -o yaml 必須是要可以反應最新資訊 

A 5 • 問題點有多個 • Statefulset 空間不夠 • 解法 • 編輯 PVC，改動 大 小 • 本來的 deploy.yaml 也需要 一 起改變 • sudo kubectl delete sts --cascade=orphan q5 • 單純刪掉紀錄，但是物件不刪除 • 這樣就可以重新 用 更新過的 YAML Apply 過去 

Question 6 • 觸發條件: 部署 q6/deploy.yaml • 症狀 • Server 會定期列印出收到的檔案內容 • 透過 kubectl edit cm q6-con f igmap 去更新內容，結果內容似乎都不會反應 回去 Pod 內 • 目 標 • 可以修改 Con f igMap 的內容且 Pod 可以順利看到更新後的結果 

A 6 • 問題點有多個 • Con f igMap 若採取 subpath 的話，背後的設計會使得 目 前的更新機制無法運 作 • 簡單 方 法就是不要 用 subpath，複雜的解法會需要針對 soft link 進 行一 些處 理 • 拔掉 subpath，根據 mountPath & env (DATA_PATH) 進 行 調整 

Question 7 • 觸發條件: 部署 q7/deploy.yaml • 症狀 • 希望透過 HPA 的機制，讓 Server 自 動根據 CPU 用 量去調整 • 大 量的 Client 去打流量，結果 HAP 好像不如預期 • 目 標 • 找出原因 • 行 有餘 力 就解決 

A 7 • 沒有安裝 metrics server • Prometheus 可以收集並不代表 HPA 就可以正常運作 

Question 8 • 觸發條件: 部署 q8/deploy.yaml • 症狀 • 部署 一 個 ReadWriteOnce 的 PVC • 有兩個 Deployment 都不 小心 去使 用 到該 PVC • 很多 Pod 似乎都可以同時使 用 • 目 標 • 發 生 什麼事情？ 說好的 ReadWriteOnce 呢 

A 8 • ReadWriteOnce 的單位是 Node 不是 Pod • 因此如果多個 Pod 屬於同講 Node，還是可以 一 起共享 • 要改 用 • ReadWriteOncePod 才是真正 一 個 Pod 使 用 ，同時其他的會直接卡 Pending 

Question 9 • 觸發條件: 部署 q9/deploy.yaml • 症狀 • Server 有實作 Prometheus Endpoint，但是似乎 Prometheus 網 頁 都看不到 • 也有部署 ServiceMonitor • 目 標 • 可以透過 IP:31112 看到該 App 分享的 Metrics • q9_http_request_total 

A 9 • ServiceMonitor 有東 西 不正確 • 沒有和 Prometheus 的 Label 一 致 • sudo kubectl -n monitoring get prometheus -o yaml • serviceMonitorSewlector • 也沒有和 Service 的 Label 一 樣 

Question 10 • 觸發條件: 部署 q10/*.yaml • 症狀 • 部署的服務，透過 Grafana 內的 q10 dashboard 觀察 HTTP latency，看來 P90 後數值都飆 高 • 目 標 • 找到原因並且修復 

A 10 • CPU Throttling，調 高 CPU Limit 即可舒緩