ACK需要佔用一定的節點資源來為kube組件和system進程預留資源,從而保證OS核心和系統服務、Kubernetes守護進程的正常運行。這會導致節點的資源總數Capacity與可分配的資源數Allocatable之間存在差異。ACK存在預設的資源預留策略,也支援通過kubelet配置自訂資源預留。
使用限制
僅1.20及以上版本的ACK叢集支援自訂節點資源預留策略。如果您的叢集版本為1.20以下,請參見手動升級叢集升級叢集。
影響範圍
自訂資源預留及其影響範圍
您可以參見自訂節點池kubelet配置修改資源預留的取值。修改後,節點池中的已有節點將即時生效,新增節點(例如擴縮容的新節點、通過添加已有節點新增的ECS執行個體)也會使用該配置。
不支援通過黑屏手動修改kubelet設定檔,以避免配置衝突,導致後續節點池營運過程中的非預期結果。
改變資源預留的值可能會造成節點的可分配資源變少。對於資源水位較高的節點,可能會觸發節點驅逐。請合理配置取值。
預設資源預留影響範圍
ACK可能會迭代節點資源預留的預設取值。迭代後,如果您在節點池維度更新了節點配置,例如叢集升級、節點池升級、修改節點池自訂kubelet參數等,節點將自動使用新的資源預留策略。如果您沒有相關營運操作,出於穩定性考量,節點池中的已有節點不會自動生效新的資源預留策略。
如果某個已有節點需要使用新的資源預留策略,您可以將該節點移除出叢集,再重新添加已有節點。新添加的節點會預設執行新的資源預留策略。移除節點和添加節點的標準操作及帶來的影響,請參見移除節點、添加已有節點。
查詢節點可分配資源
執行以下命令,查看節點的資源總量和可分配資源。
kubectl describe node [NODE_NAME] | grep Allocatable -B 7 -A 6
預期輸出:
Capacity:
cpu: 4 #節點的CPU總核心數。
ephemeral-storage: 123722704Ki #節點的臨時儲存總量,單位KiB。
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 7925980Ki #節點的記憶體總量,單位KiB。
pods: 64
Allocatable:
cpu: 3900m #節點可分配的CPU核心數。
ephemeral-storage: 114022843818 #節點可分配的臨時儲存,單位Byte。
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 5824732Ki #節點可分配的記憶體,單位KiB。
pods: 64
計算節點可分配資源
可分配資源的計算公式:可分配資源(Allocatable) = 總資源(Capacity)-預留資源(Reserved)-驅逐閾值(Eviction-Threshold)
公式說明:
資源預留策略說明
節點的預留資源量通常要考慮以下因素:
由於較高規格的ECS節點通常會運行更多的Pod,為了保證節點的效能,ACK會為Kubernetes組件預留更多資源。
由於Windows節點需要使用額外的資源來運行Windows作業系統和Windows Server相關組件,Windows節點通常會比Linux節點需要更多的預留資源。更多資訊,請參見建立Windows節點池。
ACK會根據CPU和記憶體所在的不同區間來計算預留的資源量,節點的總預留資源量等於各區間的預留資源量之和。ACK在1.28進行了資源預留策略演算法的調優,減少了CPU和記憶體資源的預留。推薦您升級叢集,請參見手動升級叢集。
預留資源套件括為kube組件預留的資源(kubeReserved)和為system進程預留的資源(systemReserved)。kubeReserved和systemReserved各占預留資源的50%。例如,節點總CPU 4 Core,則在1.28及以上的叢集中,預留CPU資源為80 millicore,其中kubeReserved佔用40 milliCore,systemReserved佔用40 milliCore;在1.20及以上至1.28以下的叢集中,預留CPU為100 milliCore,其中kubeReserved佔用50 milliCore,systemReserved佔用50 millicore。
CPU資源預留策略
1.28及以上
計算節點的總CPU預留量示意圖如下所示。
以32核的節點為例,總的CPU預留量計算如下:
1000 x 6% +1000 x 1% + 1000 x 2 x 0.5% + (32000-4000) × 0.25% = 150 milliCore
1.20及以上至1.28以下
計算節點的總CPU預留量示意圖如下所示。
以32核的節點為例,總的CPU預留量計算如下:
100+(32000-4000)× 2.5%=800 milliCore
記憶體資源預留策略
1.28及以上
計算節點的總記憶體預留量計算公式為節點總記憶體預留量 = min(11 x $max_num_pods + 255, 節點記憶體資源 x 25%)
。其中,$max_num_pods
為節點支援的最大Pod數量,節點記憶體資源
單位為MiB,最終取11 * $max_num_pods + 255
與節點記憶體資源的 25%
的較小值。
叢集使用不同的網路外掛程式時,節點支援的最大Pod數量計算方式也不同。
如果叢集網路外掛程式為Terway,節點允許建立的最大Pod數量依賴於ECS執行個體規格所提供的彈性網卡數量。關於不同Terway模式下如何計算節點支援的最大Pod數量,請參見使用Terway網路外掛程式;關於如何查看節點支援的最大Pod數量,請參見使用Terway網路外掛程式。您也可以登入Container Service管理主控台,在節點頁面的節點列表查看最大Pod數量。
如果叢集網路外掛程式為Flannel,節點支援的最大Pod數量由您在建立叢集時自行設定。您可以登入Container Service管理主控台,在節點頁面的節點列表查看最大Pod數量。
例如,如果您的叢集使用Terway網路外掛程式的共用ENI多IP模式,節點規格為256 GiB的ecs.g7.16xlarge,此時節點支援的最大Pod數量為(8 - 1) x 30 = 210個
,則節點總記憶體預留量 = min(11 x 210 + 255 , 256 x 1024 x 25%) = 2565 MiB
。
1.20及以上至1.28以下
計算節點的總記憶體預留量示意圖如下所示。
以256 GiB記憶體的節點為例,總的記憶體預留量計算如下:
4 × 25%+(8-4)× 20%+(16-8)× 10%+(128-16)× 6%+(256-128)× 2%=11.88 GiB
ACK節點預設預留資源樣本
關於ECS執行個體規格的詳細資料,請參見執行個體規格類型系列。
節點總資源 | 預留資源(1.28及以上) | 預留資源(1.20及以上至1.28以下) | |||||
樣本執行個體規格 | CPU(Core) | Memory (GiB) | 節點最大Pod數 (以Terway共用ENI多IP模式為例) | CPU (milicore) | Memory (MiB) | CPU(millicore) | Memory(MiB) |
ECS c7執行個體規格 | 2 | 4 | 12 | 70 | 387 | 100 | 1024 |
4 | 8 | 45 | 80 | 750 | 100 | 1843 | |
8 | 16 | 45 | 90 | 750 | 200 | 2662 | |
16 | 32 | 210 | 110 | 2565 | 400 | 3645 | |
32 | 64 | 210 | 150 | 2565 | 800 | 5611 | |
64 | 128 | 210 | 230 | 2565 | 1600 | 9543 | |
128 | 256 | 420 | 390 | 4875 | 2400 | 12164 | |
ECS ebmc7a執行個體規格 | 256 | 512 | 450 | 710 | 5205 | 3040 | 17407 |
常見問題
如何查看節點總CPU和記憶體?
CPU
執行如下命令,查詢節點總CPU。
cat /proc/cpuinfo | grep processor
預期輸出:
processor : 0
processor : 1
processor : 2
processor : 3
記憶體
執行如下命令,查詢節點總記憶體。
cat /proc/meminfo | grep MemTotal
預期輸出:
MemTotal: 7660952 kB
相關文檔
關於如何配置自訂資源預留和驅逐閾值以及相關注意事項,請參見自訂節點池kubelet配置。
根據可分配資源,您可以為業務Pod設定所需資源(request),節點上所有業務Pod所需資源之和不應該大於節點的可分配資源,否則業務Pod會因節點容量不足而調度失敗。ACK為K8s原生的工作負載提供了資源畫像能力,通過對資源使用量歷史資料的分析,輔助您填寫Pod所需資源。設定業務Pod所需資源的具體操作,請參見建立無狀態工作負載Deployment。
如果您希望對已存在節點應用自訂資源預留策略,您可以將已有節點移除出叢集,然後重新添加節點。新添加的節點會預設執行自訂資源預留策略。移除節點和添加節點的標準操作及帶來的影響,請參見移除節點、添加已有節點。