20201111_我的 Kubernetes 怪怪的

https://docs.google.com/presentation/d/1qbszbhD6hzVUIlhhYtlNxZqGKEMjkZ895sdMbSAQXmo/edit?usp=sharing

1. 我的 Kubernetes 怪怪ㄉ~ Phil Huang 黃秉鈞 pichuang@pichuang.com.tw 2020/11/11
2. Phil Huang 黃秉鈞 • 近期靠高度執行力減肥 20KG 達標的男人 • Cloud Native Taiwan User Group 社群打雜工 • 正職是 Red Hat Solution Architect Ref: https://www.facebook.com/paulintoro/ 1.8K 觀看次數...
3. 開始之前 工商一下 • 加入 分享 響噹噹 - Cloud Native Taiwan User Group • 2020/12/18 晚上會有年尾 CNTUG 社群活動，徵求講者啊啊啊啊~~
4. 不知道你是否有這種困擾... • kubectl 指令下去感覺有點緩慢 • kubectl get pods 狀態好像跟你想的有點不太一樣 • kubectl creafe -f xxx.yaml 怎麼跑的跟我想的不太一樣 你的 YAML
5. 如何快速判斷到底是不是 Application 問題? • 大多數的使用狀況，都是會先懷疑 Application 跑在 Kubernetes 之上 是不是有漏寫物件 • Learnk8s 有提供針對單一 Namespace 裡的 Kubernetes Pod / Service 基礎除錯的偵錯處理 • 有高清無碼 PDF 版可以下載、列 印、貼牆壁 Ref: https://learnk8s.io/troubleshooting-deployments
6. 那我為什麼站在這邊? • Kubernetes 是 IT 行業事實平台標準 • 因為近年公有雲技術興起，技術路線 選擇自然也有分地端、雲端 ◦ 代管: GKS / AKS / EKS ◦ 自建: Vanilla Kubernetes / Red Hat OpenShift / VMware Tanzu • 地端選擇自行維運路線比較多 • 個人工作比較偏照顧地端 Infra 團隊 的感受 Ref: https://learnk8s.io/troubleshooting-deployments
7. 當你自建 Kubernetes 的時候 遇到ㄧ些靈異現象... • 相較於 Master 被各大公有雲代管的模式，自建需要更深入了解各組件溝通 的細節，首先是跨節點網路溝通 • Kubernetes 基礎網路溝通 a. Container to Container b. Pod to Pod in the same node c. Pod to Pod across different nodes d. Pod to Service e. Service to Internet Ref: https://speakerdeck.com/pichuang/how-do-i-troubleshooting-on-container-more-than-docker
8. 網路好像沒問題...難道是 Kubernetes 本身異常? • 可以從了解 Kubernetes Pod 生命週期的緣起，來了解 Kubernetes 各組件 相互溝通的順序關係，比較方便你進行偵錯 • 雖然大部分常見的問題都是跟某個組件有關係... • 如果你有以下問題...這文章很適合你閱讀 a. 誰負責新建 Pod? 新建完的 Pod 狀態是什麼? b. 誰負責放置 Pod? 放置完的 Pod 狀態是什麼? c. 誰負責整個消息傳遞，以確保各組件能 夠相互合作? Ref: https://blog.pichuang.com.tw/20201009-kubernetes-api-communication/
9. • 無論是什麼方式，主要溝 通都是跟 Kubernetes API Server 溝通 • 常見問題 ◦ 根本就連錯網址 = = ◦ 被防火牆擋住 Kubernetes API Server Ref: https://blog.pichuang.com.tw/20201009-kubernetes-api-communication/
10. • 所使用的物件 (e.g. Node / Service / Endpoint / Replica / Pods) 都會由 kube-controller-manager 新建執行出來 • 它會最大化嘗試執行出 如宣告預期的結果 • 常見問題 ◦ 沒有對應 CRD 可以用 ◦ CRD 本身程式寫錯邏輯 Controller Manager Ref: https://blog.pichuang.com.tw/20201009-kubernetes-api-communication/
11. • Kubernetes 核心中的核 心 • 負責儲存整座集群狀態 的地方 • etcd 本身依循 Raft 演算 法，具備強一致性 • 常見問題 ◦ etcd 所使用的Disk IOPS 太慢 ◦ etcd 節點之間的 Latency 超過選舉時間導致異常 Etcd Cluster Ref: https://blog.pichuang.com.tw/20201009-kubernetes-api-communication/
12. • 檢查現行可被配置的 Node 的資源狀態及負責 指派 Pod 到適合的節點 上 • 常見問題 ◦ Pod Pending 真的資源不 夠，他不知道怎麼放，而不 是他壞了 ◦ Pod Waiting 放置到正確 節點，但沒有動作，主要是 拉 Image 問題居多 Kube Scheduler Ref: https://blog.pichuang.com.tw/20201009-kubernetes-api-communication/
13. • 監控實際上節點資源使 用狀態，並回報給 Master • 收到指令後呼叫 High-Level Container Runtime (CRI-O / Dockerd / Containerd) 執行實際容器 • 常見問題 ◦ Container Runtime 、作業 系統關聯性問題 Kubelet Ref: https://blog.pichuang.com.tw/20201009-kubernetes-api-communication/
14. 實務經驗上... • 只要跟 Application 無關的話，肯定先猜 etcd 是不是有異常 ◦ 測試 End-to-End 之間的 RTT (Round Trip Time) ◦ 測試 etcd 所使用的硬碟是不是 IOPS 過低，使用 SSD 是最簡單的解決辦法 Ref: https://blog.pichuang.com.tw/20201009-kubernetes-api-communication/
15. ping: RTT 不要高於 ETCD_HEARTBEAT_INTERVAL Ref: https://blog.pichuang.com.tw/20200528-openshift-etcd-operator-1/
16. fio: fdatasync - 99.00th 不要高於 10000 1 ms = 1000 us 1.631 ms = 1631 us
17. Thank You~