本文列出了支援的 Azure Kubernetes Service （AKS） 節點池的自訂節點配置參數。 欲了解如何建立與套用設定檔，請參閱「 自訂 AKS 節點池的節點設定」。
Kubelet 自訂配置參數
Important
啟用不安全的系統時，你要負責節點的穩定性和工作負載行為。 不安全的系統若設定錯誤，可能導致節點不穩定或安全漏洞。 確保你了解啟用特定不安全系統的影響，並在更改後密切監控叢集的健康狀況。
Linux kubelet 自訂配置
| 參數 | 允許的值/間隔 | 預設 | Description |
|---|---|---|---|
cpuManagerPolicy |
無、靜態 | none | 靜態政策允許容器在保證的 pod 中擁有整數 CPU 請求，存取節點上的獨佔 CPU。 |
cpuCfsQuota |
真，假 | true | 啟用或停用指定 CPU 限制容器的 CPU CFS 配額強制執行。 |
cpuCfsQuotaPeriod |
間隔 (毫秒) | 100ms |
設定 CPU CFS 配額期間值。 |
imageGcHighThreshold |
0-100 | 85 | 磁碟使用量的百分比，之後映射垃圾收集一律會執行。 觸發垃圾回收的最低磁碟使用量。 若要停用映射垃圾收集，請將 設定為100。 |
imageGcLowThreshold |
0-100，不高於 imageGcHighThreshold |
80 | 永遠不會執行映射垃圾收集的磁碟使用量百分比。 可觸發記憶體回收的最小磁碟使用量。 |
topologyManagerPolicy |
none、best-effort、restricted、single-numa-node | none | 優化 NUMA 節點對齊。 欲了解更多資訊，請參閱 節點上的控制拓撲管理政策。 |
allowedUnsafeSysctls |
kernel.shm*、、 kernel.msg*、 kernel.sem、 fs.mqueue.*、 net.* |
沒有 | 不安全 sysctls 或不安全 sysctl 模式的允許清單。 |
containerLogMaxSizeMB |
大小 (MB) | 50 | 容器日誌檔案在被旋轉前的最大大小（例如10 MB）。 |
containerLogMaxFiles |
2 或更大 | 5 | 每個容器最多可保留的容器日誌檔案數量。 |
podMaxPids |
-1 到核心 PID 限制 | -1（無限大） | 一個 pod 中最多可執行的程序 ID 數量。 |
seccompDefault |
Unconfined、RuntimeDefault |
Unconfined |
為所有工作負載設定預設的 seccomp 設定檔。
RuntimeDefault 會使用 containerd 的預設 seccomp 設定檔，限制特定系統呼叫來增強安全性。 受限系統呼叫失敗。
Unconfined 不對系統調用施加限制，允許所有系統調用，從而降低安全性。 欲了解更多資訊，請參閱 容器預設的 seccomp 設定檔。 此參數處於預覽狀態。
使用az feature register命令--namespace "Microsoft.ContainerService"註冊「KubeletDefaultSeccompProfilePreview」功能標誌。 |
kubeReserved.cpuMillicores |
1 與節點池的 CPU 容量（以毫核心）相符 | 沒有 | 為 Linux 節點集區上的 Kubernetes 系統常駐程式保留 CPU。 此參數目前處於預覽階段，且需要 CustomNodeConfigPreview 功能旗標。 |
kubeReserved.memoryMB |
1 對應節點池記憶體容量（MiB） | 沒有 | 為 Linux 節點集區中的 Kubernetes 系統守護程序保留記憶體。 此參數目前處於預覽階段，且需要 CustomNodeConfigPreview 功能旗標。 |
hardEvictionThreshold.memoryAvailable |
<number>Ki、、<number>Mi<number>Gi、<number>%或百分比不超過100 |
沒有 | 設定 Linux 節點池上可用記憶體的 kubelet 硬性驅逐閾值。 此參數目前處於預覽階段，且需要 CustomNodeConfigPreview 功能旗標。 |
hardEvictionThreshold.nodeFsAvailable |
<number>Ki、、<number>Mi<number>Gi、<number>%或百分比不超過100 |
沒有 | 設定 Linux 節點集區上節點檔案系統可用空間的 kubelet 硬驅逐臨界值。 此參數目前處於預覽階段，且需要 CustomNodeConfigPreview 功能旗標。 |
hardEvictionThreshold.nodeFsInodesFree |
<number> 或 <number>% 百分比不超過100 |
沒有 | 設定 Linux 節點集區上可用節點檔案系統 Inode 的 kubelet 硬性收回閾值。 此參數目前處於預覽階段，且需要 CustomNodeConfigPreview 功能旗標。 |
Windows kubelet 自訂配置
| 參數 | 允許的值/間隔 | 預設 | Description |
|---|---|---|---|
imageGcHighThreshold |
0-100 | 85 | 磁碟使用量的百分比，之後映射垃圾收集一律會執行。 觸發垃圾回收的最低磁碟使用量。 若要停用映射垃圾收集，請將 設定為100。 |
imageGcLowThreshold |
0-100，不高於 imageGcHighThreshold |
80 | 永遠不會執行映射垃圾收集的磁碟使用量百分比。 可觸發記憶體回收的最小磁碟使用量。 |
containerLogMaxSizeMB |
大小 (MB) | 10 | 容器日誌檔案在被旋轉前的最大大小（例如10 MB）。 |
containerLogMaxFiles |
2 或更大 | 5 | 每個容器最多可保留的容器日誌檔案數量。 |
Linux 自訂作業系統設定參數
Important
為了簡化搜尋與閱讀，本文中依其名稱顯示作業系統設定，不過應該依camelCase 大小寫慣例將其加入設定 JSON 檔案或 AKS API。
例如，如果你修改 vm.max_map_count 了設定，應該重新格式化成 vmMaxMapCount 設定 JSON 檔。
Linux 檔案處理權限限制
當處理大量流量時，這些流量通常來自大量本地檔案。 你可以調整以下的核心設定和內建限制，讓你能處理更多，但會犧牲一些系統記憶體。
下表列出了每個節點池可自訂的檔案處理權限限制：
| Setting | 允許的值/間隔 | Ubuntu 22.04 預設版本 | Ubuntu 24.04 預設 | Azure Linux 3.0 預設值 | Description |
|---|---|---|---|---|---|
fs.file-max |
8192 - 9223372036854775807 | 9223372036854775807 | 9223372036854775807 | 9223372036854775807 | Linux 核心分配的最大檔案位址數。 此值設為最大可能值（2^63-1），以防止文件描述符耗盡，並確保容器化工作負載可以擁有無限的系統層級檔案句柄。 |
fs.inotify.max_user_watches |
781250 - 2097152 | 1048576 | 1048576 | 1048576 | 系統允許的檔案監看式次數上限。 每個「監看式」在 32 位元核心上大約是 90 個位元組，而在 64 位元核心上大約是 160 個位元組。 |
fs.aio-max-nr |
65536 - 6553500 | 65536 | 65536 | 65536 | aio-nr 顯示目前系統範圍內非同步 I/O 請求的數量。 aio-max-nr 可讓您變更 aio-nr 可成長為的最大值。 |
fs.nr_open |
8192 - 20000500 | 1048576 | 1048576 | 1073741816 | 程序可配置的檔案控制代碼數目上限。 |
Note
參數 fs.file-max 會根據上游預設值，在 Ubuntu 和 Azure Linux 上設定為 9223372036854775807 （已簽署 64 位整數的最大值）。 此配置：
- 防止由於全系統檔案描述元耗盡而導致的阻斷服務攻擊。
- 確保容器工作負載 永遠不會受到全系統檔案處理限制的瓶頸。
- 透過每個進程限制 （ 和
fs.nr_open） 來ulimit，這些限制仍適用於個別進程。 - 優化容器平台，當多個容器同時運行，每個容器可能開啟許多檔案與網路連線時。
Linux 插槽與網路調校
對於預期需處理大量同時會話的代理節點，你可以使用以下 TCP 和網路選項，並依節點池調整：
| Setting | 允許的值/間隔 | Ubuntu 22.04 預設版本 | Ubuntu 24.04 預設 | Azure Linux 3.0 預設值 | Description |
|---|---|---|---|---|---|
net.core.somaxconn |
4096 - 3240000 | 16384 | 16384 | 16384 | 可針對任何所指定接聽通訊端排入佇列的連線要求數目上限。 傳遞至 listen(2) 函數的待處理項目參數值上限。 如果待處理項目引數大於 somaxconn，則會以無訊息方式截斷此限制。 |
net.core.netdev_max_backlog |
1000 - 3240000 | 1000 | 1000 | 1000 | 介面接收封包的速度比核心處理封包的速度還要快時，在 INPUT 端排入佇列的封包數目上限。 |
net.core.rmem_max |
212992 - 134217728 | 1048576 | 1048576 | 212992 | 接收通訊端緩衝區大小上限 (位元組)。 |
net.core.wmem_max |
212992 - 134217728 | 212992 | 212992 | 212992 | 傳送通訊端緩衝區大小上限 (位元組)。 |
net.core.optmem_max |
20480 - 4194304 | 20480 | 131072 | 20480 | 每個通訊端允許的輔助緩衝區大小上限 (選項記憶體緩衝區)。 少數情況會使用通訊端選項記憶體來儲存與通訊端使用相關的額外結構。 |
net.ipv4.tcp_max_syn_backlog |
128 - 3240000 | 16384 | 16384 | 16384 | 最多排隊的連線請求數量，且尚未收到連接用戶端的確認。 若超過此數值，核心將開始丟棄請求。 |
net.ipv4.tcp_max_tw_buckets |
8000 - 1440000 | 262144 | 262144 | 131072 | 系統同時最多可持有的 TIME-WAIT 插槽數量。 如果超過此數目，則會立即終結時間等候通訊端，並列印出警告。 |
net.ipv4.tcp_fin_timeout |
5 - 120 | 60 | 60 | 60 | 孤立（不再被任何應用程式引用）的連線在 FIN_WAIT_2 狀態中停留的時間，直到在本地端終止。 |
net.ipv4.tcp_keepalive_time |
30 - 432000 | 7200 | 7200 | 7200 | 啟用 keepalive 時，TCP 送出 keepalive 訊息的頻率。 |
net.ipv4.tcp_keepalive_probes |
1 - 15 | 9 | 9 | 9 | TCP 在決定連線中斷之前所送出的 keepalive 探查數目。 |
net.ipv4.tcp_keepalive_intvl |
10 - 90 | 75 | 75 | 75 | 送出探查的頻率。將其乘上 tcp_keepalive_probes，即構成啟動探查之後終止未回應連線的時間。 |
net.ipv4.tcp_tw_reuse |
2 | 2 | 2 | 允許在協議安全時重用 TIME-WAIT 套接字進行新連線。 |
|
net.ipv4.ip_local_port_range |
最先：1024 - 60999，最後：32768 - 65535] | 最先：32768，最後：60999 | 最先：32768，最後：60999 | 最先：32768，最後：60999 | TCP 和 UDP 流量用來選擇本機連接埠的本機連接埠範圍。 範圍由兩個數字組成：代理節點允許的第一個本地埠（TCP 和 UDP 流量），以及最後一個本地埠號。 |
net.ipv4.neigh.default.gc_thresh1 |
128 - 80000 | 4096 | 4096 | 4096 | ARP 快取中可包含的最少條目數。 如果條目數量低於此設定，垃圾回收不會觸發。 |
net.ipv4.neigh.default.gc_thresh2 |
512 - 90000 | 8192 | 8192 | 8192 | ARP 快取中可存在的項目軟性最大數量。 這個設定可以說是最重要的，因為ARP垃圾回收會在達到軟上限後約5秒啟動。 |
net.ipv4.neigh.default.gc_thresh3 |
1024 - 100000 | 16384 | 16384 | 16384 | ARP 快取中項目數強制上限。 |
net.netfilter.nf_conntrack_max |
131072 - 2097152 | 動態計算 | 動態計算 | 動態計算 |
nf_conntrack 是一個模組，可追蹤 Linux 內 NAT 的連線項目。
nf_conntrack 模組會使用雜湊表來記錄 TCP 通訊協定的「已建立連線」記錄。
nf_conntrack_max 是雜湊表中的節點數目上限，即 nf_conntrack 模組所支援的連線數目上限或連線追蹤資料表的大小。
預設值 是根據系統記憶體動態計算，公式為： RAM_in_bytes / 16384 （或 RAM_in_MB * 64）。 例如，擁有 8 GB RAM 的虛擬機預設連線數約為 524,288 個。 實際值會依虛擬機大小與可用記憶體而有所不同。 |
net.netfilter.nf_conntrack_buckets |
65536 - 524288 | 動態計算 | 動態計算 | 動態計算 |
nf_conntrack 是一個模組，可追蹤 Linux 內 NAT 的連線項目。
nf_conntrack 模組會使用雜湊表來記錄 TCP 通訊協定的「已建立連線」記錄。
nf_conntrack_buckets 是雜湊表的大小。
預設值 根據系統記憶體動態計算，公式為： RAM_in_bytes / 16384，最小為1,024個桶，最大為262,144個桶。 預設 nf_conntrack_max 值通常設為 nf_conntrack_buckets * 4。 實際值會依虛擬機大小與可用記憶體而有所不同。 |
Linux 工作者限制
如同檔案描述項限制，程序可建立的背景工作角色或執行緒數目受到核心設定和使用者限制的限制。 AKS 上的使用者限制無限制。 下表列出了你可以依節點池自訂的核心設定：
| Setting | Ubuntu 22.04 預設版本 | Ubuntu 24.04 預設 | Azure Linux 3.0 預設值 | Description |
|---|---|---|---|---|
kernel.threads-max |
動態計算 | 動態計算 | 動態計算 | 程序可以啟動背景工作執行緒。 可建立的所有執行緒數目上限是使用核心設定 kernel.threads-max 所設定。
預設值是 根據系統記憶體動態計算，公式為： total_ram_pages / 4 （每頁通常為 4 KB）。 實際值會依虛擬機大小與可用記憶體而有所不同。 |
Linux 虛擬記憶體
下表列出了您可以在每個節點池自定義的內核設定，以調整 Linux 內核虛擬記憶體（VM）子系統的運行以及writeout 髒資料寫入磁碟的過程：
| Setting | 允許的值/間隔 | Ubuntu 22.04 預設版本 | Ubuntu 24.04 預設 | Azure Linux 3.0 預設值 | Description |
|---|---|---|---|---|---|
vm.max_map_count |
65530 | 1048576 | 1048576 | 此檔案包含程序可擁有的最大記憶體映射區域數量。 記憶體對應區域用作由 malloc、mmap 和 mprotect 直接呼叫 madvise 的副作用，同時也是載入共用程式庫時的副作用。 |
|
vm.vfs_cache_pressure |
1 - 100 | 100 | 100 | 100 | 此百分比值可控制核心回收記憶體的傾向，而此記憶體用於快取目錄和 inode 物件。 |
vm.swappiness |
0 - 100 | 60 | 60 | 60 | 此控制項用來定義核心對記憶體頁面交換的積極程度。 數值越高越激進，數值越低，交換次數越少。 值 0 會指示核心不要在可用和檔案所支援分頁數量小於區域中的上限標記之前起始交換。 |
swapFileSizeMB |
1 MB - 暫存磁碟 (/dev/sdb) 的大小 | 沒有 | 沒有 | 沒有 | SwapFileSizeMB 指定在此節點池的代理節點上建立的交換檔案大小，單位為 MB。 |
transparentHugePageEnabled |
always、madvise、never |
always |
always |
madvise |
透明 Hugepages 是一項 Linux 內核功能，旨在通過更有效地利用處理器的內存映射硬件來提高性能。 啟用後，核心會在可能的情況下分配 hugepages ，若 mmap 區域自然對齊為 2 MB，則 Linux 程序會接收 2 MB 的頁面。 在某些情況下，當 hugepages 系統層面啟用時，應用程式可能會分配更多記憶體資源。 應用程式可能 mmap 有很大的區域，但只觸及其中 1 位元組，這種情況下可能會無緣無故地分配 2 MB 頁面而非 4K 頁面。 此案例是為什麼可能全系統停用 hugepages 或只在 MADV_HUGEPAGE madvise 區域內擁有其的原因。 |
transparentHugePageDefrag |
always、、 defer、 defer+madvise、 madvise、 never |
madvise |
madvise |
madvise |
此值可控制核心是否應該積極使用記憶體壓縮，以提供更多可用的 hugepages。 |