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

How to plan kubernetes

Kyle Bai
January 10, 2017

How to plan kubernetes

菜鳥時期的爛爛簡報之一

Kyle Bai

January 10, 2017
Tweet

More Decks by Kyle Bai

Other Decks in Technology

Transcript

  1. Kubernetes Master Kubernetes Master 包含了了四個基本組件: • Etcd: 是 CoreOS 團隊發起的⼀一個管理理設定資訊

    和服務發現(service discovery)的專案。 • API Server:以 REST APIs 介⾯面⽅方式提供所有業 務邏輯CURD操作。 • Controller Manager Server:所有其他叢集級 功能都是透過控制管理理器(Controller Manager)來來 操作。 • Scheduler:負責整個分散式系統的資源排程。
  2. Kubernetes Node(Minion) Kubernetes Node 包含了了四個基本組件: • Kubelet:負責管理理的映像檔、容器與資料 Volume等操作。也是連接 Master 的橋樑。

    • Kube-proxy: 為了了解決外部網路路能夠群曲跨 機器叢集中容器提供的應⽤用服務⽽而設計。⽀支 援 TCP,UDP stream forwarding 或 round robin TCP,UDP forwarding。 • Container:基於 Docker engine 來來執⾏行行應⽤用 程式容器實例例。
  3. Etcd - Distributed reliable key-value store • 類似⽬目錄樹狀狀結構 • JSON/REST

    API • 使⽤用 Discovery URL • 使⽤用 Raft ⼀一致性演算法提 供容錯與⾼高可靠
  4. Kubernetes 有什什麼好處? Kubernetes 管理理跨區域與主機的容器節點,提供基本部署、維運、管理理,以及執⾏行行各項應⽤用程 式。Kubernetes 為IT⼈人員帶來來以下幾項好處 : • 管理理與操作簡單,不需要太多複雜元件設定,且⽀支援 Heapster/Grafana/Influx

    監控服務。 • 提供Controller與Scheduler管理理叢集以及應⽤用程式資源與調度。 • 簡單地擴展、遷移與升級Kubernetes元件。 • 提供負載平衡、容錯、Namespace、Auto scale與本地讀寫等功能。 • ⽀支援各種雲端平台部署與作業系統,No vendor lock-in。 • ⽀支援 Federation 與 Hybrid。 • Community and Enterprise Support。
  5. 哪些適合使⽤用 Kubernetes? Kubernetes 提供了了以 Pod 為最⼩小的部署單位,並提供副本功能來來⽀支撐可靠性,在 這些功能下較適合: • 網⾴頁式應⽤用程式 &

    部分叢集化資料庫系統 • CI/CD 建置提交 & ⾃自助測試環境 • Microservices & API Gateway • 開發、測試與產品需要⾼高⼀一致時 • Linux 基礎的非圖形化應⽤用程式 • 巨量量資料運算框架,如:Spark、MapReduce
  6. Kubernetes 不是新解藥 Kubernetes 並不是任何應⽤用都適合,當應⽤用程式需要特定系統與相依性⾼高時,就無法提供最 佳的結果,例例如: • Windows 系統與 GUI 應⽤用程式

    • 過於老舊的 Legacy code • 應⽤用程式元件耦合性過⾼高或需要相依 IP 位址 • 需要 Linux Kernel 進⾏行行溝通的能⼒力力,如:KVM • ⼤大量量網路路 I/O 傳輸效能需求(如: Ceph, 部分資料庫系統) • 環境需要特定硬體驅動程式時,如 GPU(nvidia-docker) 1. 資料庫不適合Docker及容器化的7⼤大原因 2. Docker架構優缺點⼤大剖析
  7. Master/Nodes 數量量 Masters Nodes Notes 1 1 Master與Nodes在同⼀一台節點中,最基本入⾨門款,主要⽤用於學習基礎操作與開發使 ⽤用。 1

    1 Master與Nodes分離,也是常⾒見見的開發與學習⽤用環境,只適合⽤用於測試Nodes的最 ⼤大單節點負載效能與壓測。 1 3 這種規劃適合做無HA Master的功能驗證,由於⼯工作節點數多,能夠測試⼯工作節點 的容錯能⼒力力與⾃自動擴展應⽤用等。單⼀一Master,故不適合當作⽣生產環境使⽤用。 3 1 這種規劃主要專注測試Kubernetes功能的可靠性,由於Master是三台,故能夠允許 ⼩小故障發⽣生。但是這樣架構無法提供應⽤用程式的可靠性與負載平衡。 3 3 適合POC節點規劃,有Master服務的HA,以及應⽤用程式能夠部署在各⼯工作節上,提 供副本與負載平衡。但是若若副本數預設是三份,那當掛掉 3 5 適合Production節點規劃,提供Master的可靠性,且⼯工作節點可以允許應⽤用程式有 更更⾼高可靠性與負載平衡。
  8. 不同場景的最低需求 Purpose Masters Nodes Master 
 CPU Master Memory Node

    
 CPU Node Memory Development 1 3 1 1GB 1 1GB POC 3 3 2+ 4GB+ 4+ 8GB+ Production 3+ 3+ 4+ 16GB+ 8+ 32GB+
  9. Node 調整計算(1/2) 下表假設為節點和 Pod 的最⼤大 Size 限制: 類型 最⼤大值 Maximum

    nodes per cluster 10 Maximum pods per cluster 200 Maximum pods per node 20 Maximum pods per core 500m=0.5 m = millicores
  10. Node 調整計算(2/2) 透過以下確定每個節點預計適合多少個 Pod(Over ratio = 15%): 因此需要 230 /

    20 = 11.5 台 Node,即⾄至少 12 台節點,⽽而若若想計算每台 Node 需要核⼼心數,則結果為 115 / 12 = 9.58,Range為 8 - 10 Core: over = overcommit and overhead
  11. Node 規劃前能知道對⽅方越多越好 比如說以下幾個能夠幫助規劃的資訊: 1. 客⼾戶要做什什麼應⽤用,多⼤大⼯工作負載,是否為 Linux-based。 2. 若若應⽤用是叢集架構服務,需要多少副本數或節點數。如 MongoDB 3.

    若若有既有環境想轉移,原本規模多少。如有36vCore與36GB記憶體提供給 Redis • Simple Kubernetes Planning • 英華達 Kubernetes 建置規劃 over = overcommit and overhead
  12. Etcd 是儲存 kubernetes 元件相關狀狀態資訊的 key/value store,所以不能亂掛: Etcd cluster size 叢集⼤大⼩小

    最⼤大容錯數 說明 1 0 No safety at all 3 1 Minimum for safe setup 4 1 Minimum for safe setup, the same as 3 node cluster 5 2 Even better safety 7 3 Great safety 9 4 Some performance impact possible 11 5 Becoming impractical and slow Typically deployed with 2n+1 peer services.
  13. Kubernetes 元件 HA 說明 Role Style Notes Etcd Active-active Fully

    redundant deployment with load balancing API Server Active-active Managed by HAProxy Controller Manager Server Active-passive One instance is elected as a cluster leader at a time. Watches etcd for changes to leader. Schedule Active-passive One instance is elected as a cluster leader at a time. Watches etcd for changes to leader. HAProxy Active-passive Balances load between API master endpoints
  14. Kubernetes 各元件資源配額 Role Request CPU Request Memory Limits CPU Limits

    Memory Etcd 500m core 256Mi 1 core 1Gi API Server 250m core 256Mi 1 core 512Mi Controller Manager Server 200m core 128Mi 500m core 256Mi Schedule 100m core 64Mi 500m core 128Mi HAProxy+keepalived 250m core 128Mi 500m core 368Mi 1.3 core 832Mi 3.5 core 2304Mi
  15. 網路路溝通元件選擇(1/2) Kubernetes 現在主要的網路路⽅方案有以下: • Tunneling Protocol 或 Overlay Networking •

    Flannel:UDP廣播,VXLan。 • Weave:UDP廣播,本機建立新的 br 透過 PCAP 互聯聯。 • Open vSwitch(OVS):基於VXLAN和GRE,效能損失較嚴重。 這種⽅方式在 IaaS 很常⾒見見,主要是為了了解決規模增加與複雜性⽽而使⽤用的做法。
  16. 網路路溝通元件選擇(2/2) • 路路由⽅方式(Routing),典型的有以下: • Calico:基於 BGP 協定路路由,⽀支援 ACL(access-list) 控制,並對混合雲親和 度⾼高。

    • Macvlan:以邏輯和 Kernete 層來來看隔離性與效能最佳,是基於2層做隔離, 所以需要2層路路由器⽀支援,也因這問題,比較少服務商提供。 路路由⽅方案⼀一般是從3層或者2層實現隔離和跨主機容器互聯聯的,出問題比較容易易除 錯,但規模越複雜越⼤大就會遇到問題。