2022 COSCUP - GKE Backend Cluster 除雷分享

希望以此分享，來節省各位除雷的時間

Transcript

1. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz Brent Chang Engineering Manager, SRE GKE backend cluster 除雷分享
2. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz 2 • 17LIVE 架構簡介 • 為何突然踩那麼多雷? • 壓測找到的 insight ◦ route-based vs vpc-native ◦ pod limit per svc • 日常維運 ◦ kube-dns-autoscaler ◦ GKE auto-upgrade
3. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz Brent Chang 3 講者是誰? Engineering Manager, SRE • CKA、6x GCP、2x AWS 認證 • 2x CAT、2x DOG • GDG Cloud co-organizer • GCP LINE Group 版主 • ISO 27001/27017 被稽核員(X
4. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz Brent Chang 4 不立仇家聲明 • 講者跟 GCP 沒有仇，也不是嫌 GCP 有多爛 • 踩雷不代表產品爛、而是特定的使用方式會有特定的限制 也期望各位未來一路順暢，都碰不到類似案例 • 僅以此次分享，讓各位遇到類似案例時能夠省去一些時間
5. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz 17LIVE 後端架構簡介 5 revprox -> 17LIVE 自己開發的 API gateway worker -> 搭配 GCP Pub/Sub 非同步處理 etcd -> 動態 config 調整 Redis Enterprise + MongoDB Atlas
6. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz SUPERSONIC 6 日本大牌 + DJ 透過 17LIVE 全球直播 不需買票即可參與 • 超大量的同時觀看數 • 串流、後端壓力激增 • 與 QA 1:1 壓力測試 為何突然踩那麼多雷?
7. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz 7 壓測發現的 Insight： Route-based GKE Cluster 機器長出來卻死一堆!?
8. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz Route-based GKE Cluster 8 每建立一個 GKE Node (VM)，都會建立一個靜態路由 (Static Route) VPC Peering 可交換的靜態路由數量有 Quota 限制，預設 300 條 Backend Cluster <--> VPC Peering (export custom route) <--> Redis Enterprise
9. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz 9 爆炸實況
10. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz 10 爆炸實況
11. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz VPC-Native GKE Cluster 11 每一個 GKE Node，不會再有一個靜態路由 (Static Route) 不會受到前述的 GCP Quota 限制 但其他的 Quota 還是得注意
12. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz 12 壓測發現的 Insight： 原來每個 Kubernetes Service 後面的 pod 數量有上限!?
13. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz 17LIVE Pre-scaling 預熱機制 13 行銷活動都是突發流量，單靠 Horizontalpodautoscaler (HPA) 長 pod 來不及 → Kubernetes Cronjob 每分鐘讀取 etcd 設定 → 時間到就 patch HPA minReplica；時間結束就慢慢降回來
14. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz 壓測 GKE 1.18 Cluster，QPS 驟降 14 1. Pod 長完了，請 QA 開始壓測 2. 測到一半，發現後端服務的 QPS 驟降 3. 當時 kube-api server 也連不上 4. 出現了 GKE 正在修復 Cluster 的訊息．．．
15. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz GKE Product team 如是說 15 “The GKE team explained for GKE 1.19+ 1k pods is the maximum that you can use without having issues behind one service. Beyond that number it can generate some instability. Hence, it is advised to use multiple services if possible.” GKE 團隊解釋了 GKE 1.19+ 1,000 pod 是單一個 service 可以使用的最大值。 超出這個數字可能會產生一些不穩定性。 因此，如果會超過 1,000 pod，盡可能使用多個 service 去拆分。 More info: https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-li mits/thresholds.md
16. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz 16 日常維運小發現： 神秘的 dial tcp: i/o timeout kube-dns 搞的鬼!?
17. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz Backend: 反應有時連線 redis 時，會拿到 dial tcp: i/o timeout 的錯誤訊息 一般 timeout 會是如下所示，有 IP 跟 Port dial tcp 123.123.123.123:1234: i/o timeout dial tcp: i/o timeout 17
18. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz Backend: 反應有時連線 redis 時，會拿到 dial tcp: i/o timeout 的錯誤訊息 一般 timeout 會是如下所示，有 IP 跟 Port dial tcp 123.123.123.123:1234: i/o timeout Source Code 發現是 DNS 解析過久，拿不到 IP timeout 導致 Source code link https://cs.opensource.google/go/go/+/master:src/net/dial.go;l=412 dial tcp: i/o timeout 18
19. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz Backend: 反應有時連線 redis 時，會拿到 dial tcp: i/o timeout 的錯誤訊息 一般 timeout 會是如下所示，有 IP 跟 Port dial tcp 123.123.123.123:1234: i/o timeout Source Code 發現是 DNS 解析過久，拿不到 IP timeout 導致 Source code link https://cs.opensource.google/go/go/+/master:src/net/dial.go;l=412 啟用 NodeLocal DNSCache → 無改善 調整 kube-dns-autoscaler 讓 kube-dns pod 數量調升才緩解 dial tcp: i/o timeout 19
20. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz 20 日常維運小發現： GKE auto-upgrade 也有雷!?
21. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz GKE auto-upgrade 會有什麼雷? 21 如果 Container 無法正常啟動 但沒有 exit code，且 LivenessProbe/ReadinessProbe 沒設定好的話...
22. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz GKE auto-upgrade 會有什麼雷? 22 如果 Container 無法正常啟動 但沒有 exit code，且 LivenessProbe/ReadinessProbe 沒設定好的話... → Kubernetes 會認為 Pod 是好的，雖然服務全掛...
23. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz GKE auto-upgrade 會有什麼雷? 23 如果 Container 無法正常啟動 但沒有 exit code，且 LivenessProbe/ReadinessProbe 沒設定好的話... → Kubernetes 會認為 Pod 是好的，雖然服務全掛... → Auto-upgrade 導致的 Pod 重新部署，反而成為踩雷的引線
24. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz GKE Master Kubernetes 版本會持續更新 雖然可以搭配 release channel ，或 static version 控制想要的版本，但還是會被 更新，不啟用 auto upgrade 也一樣 GKE 不啟用 auto-upgrade 會有什麼雷? 24
25. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz GKE Master Kubernetes 版本會持續更新 雖然可以搭配 release channel ，或選擇 static version 控制想要的版本，但還是會被更新 → Master 跟 Node Pool 的 Kubernetes 版本差異過大時，Master 會認不得 Node Orz → 血淚實測 1.20.12 的 Master，會認不得 1.12.9 的 Node Pool GKE 不啟用 auto-upgrade 會有什麼雷? 25
26. 2021.09.10 brand & marketing 17LIVE Japan inc. abcdefghijklmnopqrst uvwxyz 26 Thank You