次の方法で共有

Azure Kubernetes Service(AKS)ノードプールのノード構成をカスタマイズする

ノード構成をカスタマイズすると、ワークロードのニーズに合わせてオペレーティング システム (OS) の設定または kubelet パラメーターを調整することができます。 AKS クラスターを作成するか、クラスターにノード プールを追加すると、一般的に使用される OS と Kubelet の設定のサブセットをカスタマイズできます。 このサブセット以外の設定を構成するには、デーモン セットを使用して、ノードの AKS サポートを失うことなく必要な構成をカスタマイズします。

AKS ノード プール用のカスタム ノード構成ファイルを作成する

OS と kubelet の構成の変更では、パラメーターと必要な設定を含む新しい構成ファイルを作成する必要があります。 パラメーターの値が指定されていない場合、値は既定値に設定されます。

Note

次の例は、一般的な構成設定を示しています。 ワークロードの要件を満たすように設定を変更できます。 サポートされているカスタム構成パラメーターの完全な一覧については、「 サポートされるカスタム構成パラメーター 」セクションを参照してください。

Kubelet の構成

次の内容を持つ新しいファイル linuxkubeletconfig.json を作成します。

{
 "cpuManagerPolicy": "static",
 "cpuCfsQuota": true,
 "cpuCfsQuotaPeriod": "200ms",
 "imageGcHighThreshold": 90,
 "imageGcLowThreshold": 70,
 "topologyManagerPolicy": "best-effort",
 "allowedUnsafeSysctls": [
  "kernel.msg*",
  "net.*"
],
 "failSwapOn": false
}

OS 構成

次の内容を持つ新しいファイル linuxosconfig.json を作成します。

{
 "transparentHugePageEnabled": "madvise",
 "transparentHugePageDefrag": "defer+madvise",
 "swapFileSizeMB": 1500,
 "sysctls": {
  "netCoreSomaxconn": 163849,
  "netIpv4TcpTwReuse": true,
  "netIpv4IpLocalPortRange": "32000 60000"
 }
}

カスタム構成ファイルを使用して AKS クラスターを作成する

Note

新しい AKS クラスターを作成するときにカスタム構成ファイルを使用する場合は、次の情報に注意してください。

  • クラスターの作成時に構成を指定した場合、構成は初期ノード プール内のノードにのみ適用されます。 JSON ファイルで構成されていない設定では、既定値が保持されます。
  • CustomLinuxOsConfig は、Windows OS の種類ではサポートされていません。

az aks create コマンドを使用してカスタム構成ファイルを使用して新しいクラスターを作成し、--kubelet-configパラメーターと--linux-os-config パラメーターに構成ファイルを指定します。 次のコマンド例では、カスタムの ./linuxkubeletconfig.json ファイルと ./linuxosconfig.json ファイルを使用して新しいクラスターを作成します。

az aks create --name <cluster-name> --resource-group <resource-group-name> --kubelet-config ./linuxkubeletconfig.json --linux-os-config ./linuxosconfig.json

カスタム構成ファイルを使用してノード プールを追加する

Note

既存の AKS クラスターに新しいノード プールを追加するときにカスタム構成ファイルを使用する場合は、次の情報に注意してください。

  • 既存のクラスターに Linux ノード プールを追加する場合は、Kubelet 構成、OS 構成、またはその両方を指定できます。 Windows ノード プールを既存のクラスターに追加する場合、kubelet 構成のみを指定できます。 ノード プールを追加するときに構成を指定した場合、構成は新しいノード プール内のノードにのみ適用されます。 JSON ファイルで構成されていない設定では、既定値が保持されます。
  • CustomKubeletConfig は、Linux および Windows のノード プールでサポートされています。

az aks nodepool add コマンドを使用して新しい Linux ノード プールを作成し、--kubelet-configパラメーターと--linux-os-config パラメーターの構成ファイルを指定します。 次のコマンド例では、カスタム ./linuxkubeletconfig.json ファイルを使用して新しい Linux ノード プールを作成します。

az aks nodepool add --name <node-pool-name> --cluster-name <cluster-name> --resource-group <resource-group-name> --kubelet-config ./linuxkubeletconfig.json

設定が適用されたことを確認する

カスタム ノード構成を適用した後、 ホストに接続 し、ファイルシステムで sysctl または構成の変更が行われていることを確認することで、設定がノードに適用されたことを確認できます。

サポートされているカスタム構成パラメーター

Linux kubelet カスタム構成

パラメーター 許容される値/間隔 Default 説明
cpuManagerPolicy none、static なし 静的ポリシーにより、保証 されたポッド 内のコンテナーで、整数の CPU 要求を使用してノード上の排他的 CPU にアクセスできます。
cpuCfsQuota true、false true CPU 制限を指定するコンテナーに対する CPU CFS クォータの適用を有効または無効にします。
cpuCfsQuotaPeriod ミリ秒 (ms) 単位の間隔 100ms CPU の CFS クォータ期間値を設定します。
imageGcHighThreshold 0 ～ 100 85 イメージ ガベージ コレクションが常に実行されるようになる、ディスク使用量の割合。 ガベージコレクションを発生させる最小ディスク使用量。 イメージ ガベージ コレクションを無効にするには、100 に設定します。
imageGcLowThreshold 0 から 100、imageGcHighThreshold 以下 80 イメージ ガベージ コレクションを実行できるようになる、ディスク使用量の割合。 ガベージ コレクションをトリガーできる最小ディスク使用量。
topologyManagerPolicy none、best-effort、restricted、single-numa-node なし 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 (∞) ポッドで実行できるプロセス ID の最大数。
seccompDefault Unconfined、RuntimeDefault Unconfined すべてのワークロードのために、既定の seccomp プロファイルを設定します。 RuntimeDefault は containerd の既定の seccomp プロファイルを使用し、特定のシステム呼び出しを制限してセキュリティを強化します。 制限付きシステムコールは失敗します。 Unconfined は syscall に制限を設けず、すべてのシステム呼び出しを許可し、セキュリティを低下させます。 詳細については、 コンテナー化された既定の seccomp プロファイルを参照してください。 このパラメーターはプレビュー段階です。 で az feature register コマンドを使用して、"KubeletDefaultSeccompProfilePreview" 機能フラグを--namespace "Microsoft.ContainerService"します。

Windows kubelet カスタム構成

パラメーター 許容される値/間隔 Default 説明
imageGcHighThreshold 0 ～ 100 85 イメージ ガベージ コレクションが常に実行されるようになる、ディスク使用量の割合。 ガベージ コレクションをトリガーする最小ディスク使用量。 イメージ ガベージ コレクションを無効にするには、100 に設定します。
imageGcLowThreshold 0 から 100、imageGcHighThreshold 以下 80 イメージ ガベージ コレクションを実行できるようになる、ディスク使用量の割合。 ガベージ コレクションをトリガーできる最小ディスク使用量。
containerLogMaxSizeMB メガバイト (MB) 単位のサイズ 10 コンテナー ログ ファイルがローテーションされる前の最大サイズ (たとえば、10 MB)。
containerLogMaxFiles ≥ 2 5 コンテナーに表示できるコンテナー ログ ファイルの最大数。

Linux カスタム OS 構成設定

重要

検索と読みやすさを簡単にするために、この記事では OS の設定を名前で表示しますが、 camelCase の大文字化規則を使用して構成 JSON ファイルまたは AKS API に追加する必要があります。

たとえば、 vm.max_map_count settingを変更する場合は、構成 JSON ファイルに vmMaxMapCount するように再フォーマットする必要があります。

Linux ファイルハンドル制限

大量のトラフィックを提供する場合、そのトラフィックは通常、多数のローカル ファイルから送信されます。 次のカーネル設定と組み込みの制限を調整して、いくつかのシステム メモリを犠牲にして、より多くの処理を行うことができます。

次の表に、ノード プールごとにカスタマイズできるファイル ハンドルの制限を示します。

設定 許容される値/間隔 Ubuntu 22.04 の既定値 Ubuntu 24.04 の既定値 Azure Linux 3.0 の既定値 説明
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 は、現在のシステム全体における非同期 io 要求の数を示しています。 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 およびネットワーク オプションを使用し、ノード プールごとに調整できます。

設定 許容される値/間隔 Ubuntu 22.04 の既定値 Ubuntu 24.04 の既定値 Azure Linux 3.0 の既定値 説明
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 システムで同時に保持される timewait ソケットの最大数。 この数を超えると、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 トラフィックによってローカル ポートを選択するために使用されるローカル ポート範囲。 2 つの数値で構成されます。最初の番号は、エージェント ノードで TCP および UDP トラフィックに対して許容される最初のローカル ポートで、2 番目は最後のローカル ポート番号です。
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 524288 524288 262144 nf_conntrack は、Linux 内の NAT の接続エントリを追跡するモジュールです。 nf_conntrack モジュールでは、ハッシュ テーブルを使用して、TCP プロトコルの "確立された接続" レコードが記録されます。 nf_conntrack_max は、ハッシュ テーブル内のノードの最大数、つまり nf_conntrack モジュールまたは接続追跡テーブルのサイズでサポートされる接続の最大数です。
net.netfilter.nf_conntrack_buckets 65536 - 524288 262144 262144 262144 nf_conntrack は、Linux 内の NAT の接続エントリを追跡するモジュールです。 nf_conntrack モジュールでは、ハッシュ テーブルを使用して、TCP プロトコルの "確立された接続" レコードが記録されます。 nf_conntrack_buckets は、ハッシュ テーブルのサイズです。

Linux worker の制限

ファイル記述子の制限と同様に、プロセスで作成できるワーカーまたはスレッドの数は、カーネル設定とユーザー制限の両方により制限されます。 AKS のユーザー制限は無制限です。 次の表に、ノード プールごとにカスタマイズできるカーネル設定を示します。

設定 Ubuntu 22.04 の既定値 Ubuntu 24.04 の既定値 Azure Linux 3.0 の既定値 説明
kernel.threads-max 1030425 1030462 256596 プロセスによってワーカー スレッドをスピンアップできます。 作成できるすべてのスレッドの最大数は、カーネル設定 kernel.threads-max で設定されます。

Linux 仮想メモリ

次の表に、Linux カーネルの仮想メモリ (VM) サブシステムの操作とディスクへのダーティ データの writeout を調整するために、ノード プールごとにカスタマイズできるカーネル設定の一覧を示します。

設定 許容される値/間隔 Ubuntu 22.04 の既定値 Ubuntu 24.04 の既定値 Azure Linux 3.0 の既定値 説明
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 Transparent Hugepages は、プロセッサのメモリ マッピング ハードウェアをより効率的に使用することでパフォーマンスを向上させることを目的とした Linux カーネル機能です。 有効にすると、カーネルはできる限り hugepages を割り当てようとし、mmap リージョンが自然に整列されている2 MB の場合、Linux プロセスは 2 MB のページを受け取ります。 hugepagesがシステム全体で有効になっている場合は、アプリケーションによってメモリ リソースが多く割り当てられる場合があります。 アプリケーションは大きな領域を mmap 可能性がありますが、その 1 バイトにしか触れません。その場合、正当な理由なく 4k ページではなく 2 MB のページが割り当てられる可能性があります。 このシナリオでは、システム全体で hugepages を無効にしたり、MADV_HUGEPAGE madvise 領域内にのみ配置したりできます。
transparentHugePageDefrag always、defer、defer+madvise、madvise、never madvise madvise madvise この値により、hugepages をより多く使用できるように、カーネルでメモリの最適化をアグレッシブに使用する必要があるかどうかが制御されます。

関連コンテンツ

  • Last updated on