次の方法で共有

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

  • [アーティクル]

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

カスタマイズされたノード構成を使用して AKS クラスターを作成する

構成ファイルを作成する

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

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"
 }
}

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

新しいクラスターを作成するときに、前の手順で作成したカスタマイズされた構成ファイルを使用して、kubelet 構成、OS 構成、またはその両方を指定できます。

注意

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

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

az aks create --name myAKSCluster --resource-group myResourceGroup --kubelet-config ./linuxkubeletconfig.json --linux-os-config ./linuxosconfig.json

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

ノード プールをクラスターに追加する場合は、前の手順で作成したカスタマイズされた構成ファイルを使用して、kubelet 構成を指定できます。 CustomKubeletConfig は、Linux および Windows のノード プールでサポートされています。

注意

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

az aks nodepool add --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --kubelet-config ./linuxkubeletconfig.json

その他の構成

次の設定を使用して、他のオペレーティング システムの設定を変更できます。

その日のメッセージ

クラスターの作成時またはノード プールの作成時に、Linux ノードでその日のメッセージを置き換えるには、ファイルの場所と一緒に --message-of-the-day フラグを渡します。

az aks create --cluster-name myAKSCluster --resource-group myResourceGroup --message-of-the-day ./newMOTD.txt
ノード プールの作成
az aks nodepool add --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --message-of-the-day ./newMOTD.txt

カスタム ノード構成のトラブルシューティング

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

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

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

Kubelet カスタム構成

Kubelet カスタム構成は、Linux および Windows ノード プールでサポートされています。 サポートされているパラメーターは異なり、以下に記載されています。

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 プロファイルを使用し、特定のシステム呼び出しを制限してセキュリティを強化します。 制限付きの syscall は失敗します。 Unconfined では syscall に制限はなく、すべてのシステム呼び出しが許可され、セキュリティが低下します。 詳細については、「containerD の既定の seccomp プロファイル」を参照してください。 このパラメーターはプレビュー段階です。 --namespace "Microsoft.ContainerService" を含めた az feature register コマンドを使用して、"KubeletDefaultSeccompProfilePreview" 機能フラグを登録 します。

Windows Kubelet カスタム構成

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

Linux カスタム OS 構成設定

重要

検索のしやすさと読みやすさのために、このドキュメントには OS 設定が名前で記載されていますが、構成 JSON ファイルまたは AKS API には キャメルケースの大文字と小文字の規則を使用して追加する必要があります。

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

ファイル ハンドルの制限

大量のトラフィックを処理する際に、トラフックが大量のローカル ファイルから来ることがよくあります。 多少のシステム メモリを費やして、より多くの処理を実行できるように、以下のカーネル設定と組み込みの制限を調整することができます。

設定 許容される値/間隔 Default 説明
fs.file-max 8192 から 12000500 709620 Linux カーネルによって割り当てられるファイル ハンドルの最大数。この値を増やすことで、開いているファイルの最大許容数を増やすことができます。
fs.inotify.max_user_watches 781250 から 2097152 1048576 システムで許容されるファイル ウォッチの最大数。 各 "ウォッチ" は 32 ビット カーネルでは約 90 バイト、64 ビット カーネルでは約 160 バイトです。
fs.aio-max-nr 65536 から 6553500 65536 aio-nr は、現在のシステム全体における非同期 io 要求の数を示しています。 aio-max-nr では、aio-nr の可能な最大値を変更できます。
fs.nr_open 8192 から 20000500 1048576 プロセスで割り当てることができるファイル ハンドルの最大数。

ソケットとネットワークの調整

非常に多数の同時セッションを処理することが期待されるエージェント ノードの場合、ノード プールごとに調整できる以下の TCP オプションとネットワーク オプションのサブセットを使用できます。

設定 許容される値/間隔 Default 説明
net.core.somaxconn 4096 から 3240000 16384 リッスンしている特定のソケットに対してキューに入れることができる接続要求の最大数。 listen (2) 関数に渡されるバックログ パラメーターの値の上限。 バックログ引数が somaxconn より大きい場合、通知なしにこの制限に切り捨てられます。
net.core.netdev_max_backlog 1000 から 3240000 1000 カーネルで処理できる速度を超えてパケットをインターフェイスで受信した場合に、INPUT 側でキューに入れられたパケットの最大数。
net.core.rmem_max 212992 から 134217728 212992 受信ソケット バッファーの最大サイズ (バイト単位)。
net.core.wmem_max 212992 から 134217728 212992 送信ソケット バッファーの最大サイズ (バイト単位)。
net.core.optmem_max 20480 から 4194304 20480 ソケットごとに許容される付加バッファーの最大サイズ (オプション メモリ バッファー)。 ソケットのオプション メモリは、ソケットの使用に関連する追加の構造体を格納するために、いくつかのケースで使用されます。
net.ipv4.tcp_max_syn_backlog 128 から 3240000 16384 接続しているクライアントから受信確認を受信していない、キューに入れられた接続要求の最大数。 この数を超えると、カーネルによって要求の破棄が開始されます。
net.ipv4.tcp_max_tw_buckets 8000 から 1440000 32768 システムで同時に保持される timewait ソケットの最大数。 この数を超えると、time-wait ソケットが直ちに破棄され、警告が出力されます。
net.ipv4.tcp_fin_timeout 5 から 120 60 ローカル側で中止されるまで FIN_WAIT_2 状態のままになる、孤立した (どのアプリケーションからも参照されなくなった) 接続の時間の長さ。
net.ipv4.tcp_keepalive_time 30 から 432000 7200 keepalive が有効になっている場合に、TCP によって keepalive メッセージが送信される頻度。
net.ipv4.tcp_keepalive_probes 1 から 15 9 接続が切断されたと判断されるまで、TCP によって送信される keepalive プローブの数。
net.ipv4.tcp_keepalive_intvl 10 - 90 75 プローブが送信される頻度。tcp_keepalive_probes で乗算することで、プローブが開始された後、応答していない接続を強制終了する時間が算出されます。
net.ipv4.tcp_tw_reuse 0 または 1 0 プロトコルの観点から安全な場合に、新しい接続に対して TIME-WAIT ソケットを再利用できるようにします。
net.ipv4.ip_local_port_range 最初: 1024 - 60999 と最後: 32768 - 65535] 最初:32768、最後:60999 TCP および UDP トラフィックによってローカル ポートを選択するために使用されるローカル ポート範囲。 2 つの数値で構成されます。最初の番号は、エージェント ノードで TCP および UDP トラフィックに対して許容される最初のローカル ポートで、2 番目は最後のローカル ポート番号です。
net.ipv4.neigh.default.gc_thresh1 128 から 80000 4096 ARP キャッシュ内のエントリの最小数。 エントリの数がこの設定を下回る場合、ガベージ コレクションはトリガーされません。
net.ipv4.neigh.default.gc_thresh2 512 から 90000 8192 ARP キャッシュ内のエントリのソフト最大数。 このソフト最大数に達してから 5 秒後に ARP ガベージ コレクションがトリガーされるため、この設定は最も重要です。
net.ipv4.neigh.default.gc_thresh3 1024 から 100000 16384 ARP キャッシュ内のエントリのハード最大数。
net.netfilter.nf_conntrack_max 131072 - 2097152 131072 nf_conntrack は、Linux 内の NAT の接続エントリを追跡するモジュールです。 nf_conntrack モジュールでは、ハッシュ テーブルを使用して、TCP プロトコルの "nf_conntrack" レコードが記録されます。 nf_conntrack_max は、ハッシュ テーブル内のノードの最大数、つまり nf_conntrack モジュールまたは接続追跡テーブルのサイズでサポートされる接続の最大数です。
net.netfilter.nf_conntrack_buckets 65536 - 524288 65536 nf_conntrack は、Linux 内の NAT の接続エントリを追跡するモジュールです。 nf_conntrack モジュールでは、ハッシュ テーブルを使用して、TCP プロトコルの "nf_conntrack" レコードが記録されます。 nf_conntrack_buckets は、ハッシュ テーブルのサイズです。

ワーカーの制限

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

設定 許容される値/間隔 Default 説明
kernel.threads-max 20 から 513785 55601 プロセスによってワーカー スレッドをスピンアップできます。 作成できるすべてのスレッドの最大数は、カーネル設定 kernel.threads-max で設定されます。

仮想メモリ

次の設定を使用して、Linux カーネルの仮想メモリ (VM) サブシステムの動作と、ディスクへのダーティ データの writeout を調整できます。

設定 許容される値/間隔 Default 説明
vm.max_map_count 65530 から 262144 65530 このファイルには、プロセスが持つことのできるメモリ マップ領域の最大数が含まれています。 メモリ マップ領域は、malloc の呼び出しの副作用として mmap、mprotect、および madvise によって直接使用されるほか、共有ライブラリの読み込み時にも使用されます。
vm.vfs_cache_pressure 1 - 100 100 この割合値により、ディレクトリおよび inode オブジェクトのキャッシュに使用されるメモリを再利用するカーネルの傾向が制御されます。
vm.swappiness 0 ～ 100 60 このコントロールは、カーネルによってメモリ ページをどの程度アグレッシブにスワップするかを定義するために使用されます。 値を大きくすると、よりアグレッシブになり、値を小さくするとスワップの量が減少します。 値を 0 に設定すると、空きページとファイルに格納されたページの量がゾーン内の高基準値を下回るまで、スワップを開始しないようにカーネルに指示されます。
swapFileSizeMB 1 MB - 一時ディスクのサイズ (/dev/sdb) なし SwapFileSizeMB により、このノード プールからエージェント ノードに作成されるスワップ ファイルのサイズが MB 単位で指定されます。
transparentHugePageEnabled always、madvise、never always Transparent Hugepages は、プロセッサのメモリ マッピング ハードウェアをより効率的に使用することでパフォーマンスを向上させることを目的とした Linux カーネル機能です。 有効にすると、カーネルにより、可能な場合は常に hugepages の割り当てが試行され、mmap 領域に 2 MB が自然に配置されている場合、Linux プロセスは 2 MB のページを受け取ります。 hugepages がシステム全体で有効になっている場合は、アプリケーションでより多くのメモリ リソースが割り当てられることがあります。 アプリケーションで、大きな領域に対して mmap が実行されたが、影響を受けたのはそのうち 1 バイトだけであったとします。その場合、特に理由なく、4 K のページの代わりに 2 MB のページが割り当てられる可能性があります。 このシナリオでは、システム全体で hugepages を無効にしたり、MADV_HUGEPAGE madvise 領域内にのみ配置したりできます。
transparentHugePageDefrag always、defer、defer+madvise、madvise、never madvise この値により、hugepages をより多く使用できるように、カーネルでメモリの最適化をアグレッシブに使用する必要があるかどうかが制御されます。

次のステップ