Upgrade to Pro — share decks privately, control downloads, hide ads and more …

20211122_ Kubernetes 多叢集及單叢集架構選擇探討

Phil Huang
November 22, 2021

20211122_ Kubernetes 多叢集及單叢集架構選擇探討

Phil Huang

November 22, 2021
Tweet

More Decks by Phil Huang

Other Decks in Technology

Transcript

  1. #pichuang # whois Phil Huang 黃秉鈞 • 一週七睡,一週三練;上班專業,下班躺平 • Cloud

    Native Taiwan User Group (CNTUG) 打雜工 • blog.pichuang.com.tw Ref: https://www.linkedin.com/in/phil-huang-09b09895/ 4
  2. #pichuang Kubernetes, Ranked by Power 6 Certified Kubernetes Administrator /

    Certified Kubernetes Application Developer Kubernetes API Service Kubernetes Master Node Kubernetes Worker Node *本文以後的顏色並無特殊意義,只是便於區分不同 Kubernetes 叢集
  3. #pichuang 何謂 1 個 Kubernetes 節點 (Node)? Kubernetes runs your

    workload by placing containers into Pods to run on Nodes 9 • 一台虛擬機 (VM) 或實體機 (BM),上面只要能運行 Kubernetes Pods 即可,無論 Linux or Windows, 無論 x86_64 or ppc 都隸屬這個範圍 • 絕大數狀況下,節點分法為 2 種角色 (Roles) ◦ Master Node (後面簡稱 Master) ◦ Worker Node (後面簡稱 Worker) Ref: https://kubernetes.io/docs/concepts/architecture/nodes/ This is a Master Node This is a Worker Node This is a Master + Worker Node
  4. #pichuang 何謂 1 座 Kubernetes 叢集 (Cluster)? • 前提:Master 又稱

    Control Plane,同時承載 Kubernetes Controller 及 etcd 叢集等服務 • 主要是以可單獨運行之 Kubernetes API 為主,而與 Master 跟 Worker 數量皆無關 10 Ref: https://kubernetes.io/docs/concepts/overview/kubernetes-api/ kubectl cluster-info kubectl master is running at https://api.pink.square:8443 kubectl master is running at https://api.green.square:8443
  5. #pichuang Kubernetes API Server 是什麼長相? • 真身為一個內建於 Master 的 RESTful

    API Service,負責處理所有 Kubernetes API 溝通 • 本身為 Stateless 服務,故最外層可以採用 L4 或 L7 等級的 Load Balancer 做負載均衡 11 curl -o /dev/null -s -w “%{http_code}\n” https://10.20.2.1:8443 L4 LB (Active) curl -o /dev/null -s -w “%{http_code}\n” https://10.10.1.1:8443 200 200 L4 LB (Standby) L4 LB 443:8443 443:8443 10.10.1.1 10.20.2.1 *本簡報因需要大量解釋 Kubernetes API 的角色,故特別從 Master 節點服務抽象拉出來示意 kube-api-server kube-api-server kube-api-server kube-api-server 10.10.1.10 10.20.2.10 10.20.2.11 10.20.2.12
  6. #pichuang Kubernetes Auto Scaling 這句話是什麼意思? • 2 個角度 ◦ Infra

    Resource Scaling:當叢集不能滿足當前計算資源時,以 Cluster Autoscaler (CA) 為核心, 自動擴增 Machine,如通用 VM、GPU VM、Spot VM 等,以增加計算資源 ◦ Application Scaling:當工作負載不能滿足當前業務量時,以 Horizontal Pod Autoscaler (HPA) 和 Vertical Pod Autoscaler (VPA) 為核心,自動複製 (Replicas) Pod 或調整 Pod 本身資源,以應 對當前工作負載 • Infra Resource Scaling 和 Application Scaling 可以各自單獨使用,或一起使用 • 常見使用情境 ◦ 有突發流量類型業務,人工無法立即應對,如敗家活動、疫苗註冊系統 ◦ 共享 GPU 推理與訓練,如 X 光圖、信用卡身分證照相掃描、 AOI 光學檢測 ◦ 批次處理系統 ◦ 大規模 HPC 計算 13
  7. #pichuang Worker 若想無腦擴增縮減 (Scale Up/Down)該怎麼辦? GCP Azure AWS vSphere Auto

    Scaling API Managed Instance Groups (MIG) Virtual Machine Scale Sets (VMSS) Auto Scaling Groups (ASG) Resource Pool + vSphere built-in API Machine Pool * Azure MachinePool AWS MachinePool vSphere DeploymentZones Machine CRD GCP VM Azure VM AWS VM vSphere VM Ref: https://cluster-api.sigs.k8s.io/reference/providers.html https://cluster-api.sigs.k8s.io/user/quick-start.html#required-configuration-for-common-providers • 建議採用已有支援 Cluster API 之基礎平台為主 • 同一 Machine Pool 內,Machine Type 、VM Configuration 需一致 • 呈上,不同 Machine Type,需拆分不同 Machine Pool • 可選採用 Cluster Autoscaler (CA):根據資源使用率,自動水平擴縮容 Worker *: 小弟才疏學淺找不到 =_= 請好心人補充 14 Node++ +
  8. #pichuang Kubernetes 節點池範例 15 Name: Node-Pool-1 OS: Ubuntu 20.04 CPU:

    4c RAM: 8g Owner: SRE-TEAM Name: Node-Pool-2 OS: Ubuntu 20.04 CPU: 8c RAM: 16G Owner: APP-TEAM Name: Node-Pool-3 OS: Ubuntu 20.04 CPU: 64c RAM: 128G Owner: AI-TEAM 4c/8g 4c/8g 4c/8g 8c/16g 8c/16g 8c/16g 64c/128g 64c/128g 64c/128g • 同 1 個叢集,3 個不同節點池 kubectl get nodes 12
  9. #pichuang 單叢集內 Nodes 通訊需求 • 任意 Nodes 跟 Master 間

    API 溝通,都採用 “Hub-and-Spoke” API 設計模式,意指全部 Kubernetes 操作都要通過 Kubernetes API Serivce 溝通,不分 CLI / GUI / IDE 等 • 常見 Kubernetes API 網路溝通,主要分 2 個類型 a. 在 Master 內的 etcd cluster 間通訊 b. Nodes ↔ Kubernetes API 相互之間溝通 16 Ref: https://kubernetes.io/docs/concepts/architecture/control-plane-node-communication/ kubectl get handsome
  10. #pichuang 關於 Master 間通訊 你應該要瞭解的事情 • 大多數廠商會把 Etcd 跟 Kubernetes

    主要組件一起放在 Master Node,所以大部分可以預設綁再一起 • 關於 Network Throughput 和 CPU/Memory 消耗,Etcd 節 點過多,效能越低,生產環境以 3 節點為建議值 • 關於 Network Latency,任意 etcd 節點間 RTT 不要高於 ETCD_HEATBEAT_INTERNVAL (default: 100ms) 值,詳參 • 關於 Disk I/O,用 FIO 測試放置 etcd database 的硬碟 ,99.00th 不要高於 10000 us,詳參 Etcd 節點數 最少選舉節點 故障容許節點 1 1 0 2 2 0 3 2 1 5 3 2 17 (X) (O) (!?)
  11. #pichuang 關於 Nodes 間通訊 你應該要知道的事情 (1/2) Ref: https://github.com/kubernetes-sigs/kubespray/blob/master/docs/kubernetes-reliability.md • Nodes

    間溝通,主要是依靠 Kubernetes API Server 和節點上的 kubelet 相互溝通,參閱 Kubernetes API 服務及跟各組件的交互關係 • Controller Manager 作為叢集內部的資源管理控制中心,當 Node 失效的時候,會自動 啟動修復流程,盡 可能恢復到 “期望狀態 (Desired State)” 18 kubelet kubelet kubelet kubelet kubelet kubelet kubelet kube-controller-manager kube-controller-manager kube-controller-manager
  12. #pichuang 關於 Nodes 間通訊 你應該要知道的事情 (2/2) Ref: https://github.com/kubernetes-sigs/kubespray/blob/master/docs/kubernetes-reliability.md • Node

    失聯狀態更新順序: Ready > NotReady > Unhealthy • 節點如果不幸失聯, Pod 並不會立即遷移到其他節點上,預設上會是 5 m 以上才會開始在別的節點重 啟 19
  13. #pichuang Kubernetes 多租戶議題 (1/2) Ref: SmallTown - Multi-Tenancy Kubernetes Cluster

    Part 1: 認命吧!有一好,就沒兩好! 軟多租戶 Soft Multi-Tenancy 硬多租戶 Hard Multi-Tenancy 單租戶 Single-Tenancy 租戶系統邊界 Kubernetes Namespace Kubernetes Cluster / Cloud Provider Kubernetes Cluster 隔離性 邏輯隔離 (共用 Kubernetes API) 主管叢集:邏輯隔離 (共用 Kubernetes API) 租戶叢集:實體隔離 (不共用 Kubernetes API) 實體隔離 (不共用 Kubernetes API) 4C’s Security Code / Container Code / Container / Cluster / Cloud Cluster / Cloud Network 重視東西向 Network Policy 的設計 重視南北向 Ingress 的設計 重視南北向 Ingress 的設計 Resource Management Ops 採 Resource Quotas 限制特定 Namespace 資源用量 Ops 採 VM 為主的估算, 限定 Cluster 資源用量 Ops 採 VM 為主的估算, 限定 Cluster 資源用量 白話文 Ops 建立單一 Kubernetes 塞全部 App 部門人在裡面 Ops 先建立主管叢集之後 再對個 App 部門發 Kubernetes 每個 App 部門自建一座 Kubernetes • 首先,多租戶跟單租戶在架構設計上是可以單獨使用或同時使用,廣義來說相互都兼具能力 • 其次,多租戶還有分 2 個: ◦ Soft Multi-Tenancy:最常見,以 Namespace 作為系統界線,CNCF CKA/CKAD 考試都是考基於這個的操作 ◦ Hard Multi-Tenancy:乙方 Infra Provider 會出現的設計,以一座主管叢集為核心,上面再長 Kubernetes 作為系 統邊界,後者長出來的 Kubernetes 也包含 Soft Multi-Tenancy 的能力,如 Managed Cluster 服務都算是 • 結論,反正就是你起碼會有一座 Kubernetes ,然後討論 Kubernetes API 要不要共用就對了 • 下表論述以 地端 Ops 維運人員角度為主 21
  14. #pichuang Kubernetes 多租戶議題 (2/2) • 決大部分會從軟多租戶轉為考慮單租戶的考量,都是跟 Kubernetes API 和資源隔離性的取捨有關,理由如以下但不限於 :

    ◦ 不同環境的網路隔離,如 DR ◦ Kubernetes 合規性,如 PCI-DSS、HIPPA 等不能於同一座混用合規檢測 ◦ 不同專案性質,如核心系統、以 API Gateway 為主的 MASA 設計、共享服務平台 (CI/CD)、GPU 分享等 ◦ 底層 CPU 架構集不同,如 x86_64、ppc 等 ◦ 不同部門權限 / 內帳切割議題 • 採用多叢集 Kubernetes 架構設計長期來看是必然的選擇 • 採用初期架構取捨 ◦ 多叢集 Kubernetes 管理複雜性提升,包含生命週期管理、監控可視化、日誌收集 ◦ 多叢集 Kubernetes 設計複雜性提升,包含網路、儲存、應用程式架構設計需求 => 其實,蓋 Kubernetes 跟蓋住宅大樓的設計邏輯是差不多的,詳參給行銷與業務的 Kubernetes 101 中翻中介紹 22
  15. #pichuang 情境需求:4 座不同的平台上要跑同一個服務 (1/2) 23 • 延伸單 1 Kubernetes 叢集

    分散四地 • 總數 15 台 VM • 當一座 Kubernetes 管理 龍潭 台北 香港 日本 kubectl get nodes 15
  16. #pichuang 24 單叢集 v.s. 延伸單叢集 v.s. 多叢集 • 單叢集、多叢集架構設計沒什麼問題,取捨點是在於 Kubernetes

    多租戶的需求 • 延伸單叢集,需考驗 Node 間通訊網路、Node 失效 (Failure) 及恢復 (Recover) 的狀況 ◦ 除了 Network 需考量以外,還有 Storage 的設計也須考量 單叢集 Single Cluster 延伸單叢集 (Wide Cluster / Stretch Cluster) 多叢集 Multi Cluster 幾個 Kubernetes 叢集? 1 1 4 Master Node 在哪裏 特定一朵雲上 特定一朵雲上 每一朵雲都有 Worker Node 在哪裏 跟 Master Node 一起 放在特定一朵雲上 不一定跟 Master Node 放在一起 每一朵雲都有 現實 技術可行且合理 技術雖可行但複雜,實踐路漫長 理由請回去參考單叢集的設計 技術可行且合理,但有 OPEX/CAPEX 考量 OPEX
  17. #pichuang • 以下條件可以考慮 ◦ 錢太多:想一下 kubelet ↔ etcd 進出流量成本 ◦

    你不想睡覺了:想一下點到點網路可控嗎? ◦ 全做在特定的公雲上:這我還真的沒話 說 XD Ref: https://azurespeedtest.azurewebsites.net/ https://cloudpingtest.com/gcp 技術雖可行,實踐路漫長 25
  18. #pichuang 情境需求:4 座不同的平台上要跑同一個服務 (2/2) 26 • 4 個 Kubernetes 叢集

    分散四地 • 24 台 VM • 你要一次管 4 座 Kubernetes 龍潭 台北 香港 日本 6 6 kubectl config use-context taipei kubectl get nodes kubectl config use-context japen kubectl get nodes
  19. #pichuang 多 Kubernetes 統一管理方式 27 龍潭 台北 香港 日本 6

    6 6 6 多叢集管理平台 叢集生命 週期管理 Policy 管理 Complian ce RBAC • Kubernetes 座數多的時候,會需要這種服務管理 Policy
  20. #pichuang KubeFed 也能管多叢集? • KubeFed 偏向與 ArgoCD / Flux 一樣,針對多叢集上的應用程式交付和管理,並非針對平台資源管理

    • 因 GitOps 的使用上較為貼近 Kubernetes Native API 使用,所以近期並不是討論的很熱烈,參 閱 hwchiu 淺談 GitOps 的概念 28 Ref: https://github.com/kubernetes-sigs/kubefed https://www.hwchiu.com/gitops.html
  21. #pichuang 參考 CNCF End User Tech Radar • 相關解釋,可直接參考 Hwchiu

    所寫的 CNCF MultiCluster 使 用者調查報告 • 內容主要都比較偏向多叢集的 應用程式部署,如 ArgoCD、 Flow 等,而不是平台管理機制 ,如 Open Policy Agent 等 29 Ref: https://radar.cncf.io/2021-06-multicluster-management https://www.hwchiu.com/cncf-tech-radar-multicluster.html
  22. #pichuang 今天我沒講什麼? • 基於 Kubernetes 為主的應用服務 (Application) ◦ 多叢集持續交付 GitOps:

    Argo / Flux / Jenkins ◦ 單叢集應用程式部署 Helm / Kustomize • 基於 Kubernetes 為主的平台技術 (Infra) ◦ 服務統一治理 Service Mesh Governance:isito / linkerd ◦ 備份 Backup: Velero,參閱 20210812 如何採用雲原生作法 Velero 備份還原你的 Kubernetes 叢集? ◦ 日誌 Logging ◦ 指標 Metrics:Prometheus ◦ 儲存 Storage:File / Object / Block ◦ 服務入口 Ingress:GSLB / SLB ◦ 資安 Security ◦ 單叢集內之容器網路 Container Networking ◦ 跨叢集間之容器網路 Cross Cluster Networking* ◦ 權限治理 IAM ◦ 金鑰管理 KMS 30 *: 太早期了 各位先好好睡覺比較實在