ACK需要佔用一定的節點資源來為kube組件和system進程預留資源，從而保證OS核心和系統服務、Kubernetes守護進程的正常運行。這會導致節點的資源總數Capacity與可分配的資源數Allocatable之間存在差異。ACK存在預設的資源預留策略，也支援通過kubelet配置自訂資源預留。
使用限制
僅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%)。最終取11 * ($max_num_pods) + 255與節點記憶體資源的 25%的較小值。
$max_num_pods：節點支援的最大Pod數量。說明叢集網路外掛程式不同，單節點支援的最大Pod數量計算方式也不同。詳細說明和計算方式，請參見節點最大Pod數說明。
您可以登入Container Service管理主控台，在節點頁面的節點列表查看最大Pod數量。
Terway：
單節點支援的最大Pod數 = 節點最大容器網路Pod數 + 主機網路Pod數。Flannel：由您在建立叢集時自行設定。
節點記憶體資源：以系統實際可用的記憶體資源為準。單位為MiB。執行個體規格定義中的記憶體大小指所有可用記憶體，其中也包含了系統佔用的部分。因此系統即時可用記憶體會小於執行個體規格定義，請參見購買執行個體後查看記憶體大小，為什麼和購買時的執行個體規格定義不一致？。
例如，如果您的叢集使用Terway網路外掛程式的共用ENI多IP模式，節點規格為256 GiB的ecs.g7.16xlarge，此時節點支援的最大Pod數量為(8 - 1) x 30 + 3= 213個，則節點總記憶體預留量 = min(11 x (210 + 3) + 255 , 256 x 1024 x 25%) = 2598 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 | 15 | 70 | 420 | 100 | 1024 |
4 | 8 | 48 | 80 | 783 | 100 | 1843 | |
8 | 16 | 48 | 90 | 783 | 200 | 2662 | |
16 | 32 | 213 | 110 | 2598 | 400 | 3645 | |
32 | 64 | 213 | 150 | 2598 | 800 | 5611 | |
64 | 128 | 213 | 230 | 2598 | 1600 | 9543 | |
128 | 256 | 423 | 390 | 4908 | 2400 | 12164 | |
ECS ebmc7a執行個體規格 | 256 | 512 | 453 | 710 | 5238 | 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。