Kubernetes叢集選擇最佳設定推薦方案 - daniele

• -成本（已用與浪費）
• -調整交付週期
• -過多設定

如何在群集節點中分配資源?
Kubernetes叢集中部署的Pod會消耗記憶體，CPU和儲存等資源，但是並非Kubernetes節點中的所有CPU和記憶體都可用於執行Pod。
作業系統和kubelet也需要記憶體和CPU，因此您應該照顧這些額外的資源。
如果您仔細檢視單個節點，則可以將可用資源劃分為：

1. 執行作業系統和系統守護程式所需的資源，例如SSH，systemd等。
2. 執行Kubernetes代理所需的資源，例如Kubelet，容器執行時，節點問題檢測器等。
3. Pods可用的資源。
4. 為eviction threshold.保留的資源。

所有這些配額都是可定製的。
但是請注意，為作業系統保留100MB記憶體並不意味著作業系統僅限於使用該數量。
它可能會使用更多（或更少）資源-您只是在盡力而為地分配和估計記憶體和CPU使用率。
但是，您如何決定如何分配資源？
不幸的是，由於它取決於您的群集，所以沒有固定的答案。
但是，主要的託管Kubernetes服務Google Kubernetes Engine（GKE），Azure Kubernetes Service（AKS）和Elastic Kubernetes Service（EKS）已經達成共識，值得討論它們如何劃分可用資源。
 

Google Kubernetes引擎（GKE）
Google Kubernetes Engine（GKE）具有明確定義的規則列表，用於為Node分配記憶體和CPU。
對於記憶體資源，GKE保留以下內容：

• 記憶體少於1 GB的計算機為255 MiB
• 前4GB記憶體的25％
• 接下來的4GB記憶體的20％（最多8GB）
• 接下來的8GB記憶體的10％（最多16GB）
• 接下來的112GB記憶體的6％（最高128GB）
• 超過128GB的任何記憶體的2％

• 第一核心的6％
• 下一個核心的1％（最多2個核心）
• 接下來的2個核心的0.5％（最多4個核心）
• 4個核以上的任何核的0.25％

彈性Kubernetes服務（EKS）
EKS為​​每個節點保留以下記憶體：
Reserved memory = 255MiB + 11MiB * MAX_POD_PER_INSTANCE
什麼MAX_POD_PER_INSTANCE啊，在Amazon Web Service中，每種例項型別對其可以執行的Pod數量都有不同的上限。
例如，一個m5.large例項只能執行29個Pod，但一個m5.4xlarge例項最多可以執行234個。
如果選擇m5.large，則為kubelet和代理保留的記憶體為：

Reserved memory = 255Mi + 11MiB * 29 = 574MiB

• 第一核心的6％
• 下一個核心的1％（最多2個核心）
• 接下來的2個核心的0.5％（最多4個核心）
• 4個核以上的任何核的0.25％

Azure Kubernetes服務
Azure提供了有關其資源分配的詳細說明。
為Kubelet保留的記憶體為：

• 記憶體少於1 GB的計算機為255 MiB
• 前4GB記憶體的25％
• 接下來的4GB記憶體的20％（最多8GB）
• 接下來的8GB記憶體的10％（最多16GB）
• 接下來的112GB記憶體的6％（最高128GB）
• 超過128GB的任何記憶體的2％

概括
您可能會得出這樣的結論：在最大化可分配記憶體和CPU的情況下，較大的例項是必經之路。
不幸的是，成本只是設計叢集時的一個因素。
如果您正在執行大型節點，則還應考慮：

1. 在節點上執行的Kubernetes代理的開銷-例如容器執行時（例如Docker），kubelet和cAdvisor。
2. 您的高可用性（HA）策略。可以將Pod部署到選定數量的節點上
3. 爆炸半徑。如果您只有幾個節點，那麼發生故障的節點的影響會比擁有多個節點的影響大。
4. 自動縮放的成本效益較差，因為下一個增量是一個（很大）節點。