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

[アーティクル]
04/24/2023

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

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

構成ファイルを作成する

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

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

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

注意

Windows kubelet カスタム構成では、パラメーター imageGcHighThreshold、imageGcLowThreshold、containerLogMaxSizeMB、containerLogMaxFiles のみがサポートされます。

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

{
 "imageGcHighThreshold": 90,
 "imageGcLowThreshold": 70,
 "containerLogMaxSizeMB": 20,
 "containerLogMaxFiles": 6
}

OS 構成

Linux ノードプール
Windows ノードプール

次の内容を持つ新しいファイル 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 ファイルで構成されていない設定は、既定値のままになります。

Linux ノードプール
Windows ノードプール

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

az aks nodepool add --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --os-type Windows --kubelet-config ./windowskubeletconfig.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 の最大量

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` をより多く使用できるように、カーネルでメモリの最適化をアグレッシブに使用する必要があるかどうかが制御されます。

次のステップ

AKS クラスターを構成する方法を学習する。
クラスター内のノードイメージをアップグレード方法を学習する。
「Azure Kubernetes Service (AKS) クラスターのアップグレード」を参照し、クラスターを最新バージョンの Kubernetes にアップグレードする方法について学習する。
AKS についてよく寄せられる質問に関する記事の一覧を参照し、AKS についての一般的な質問への回答を確認する。