デフォルトの kubelet 構成がニーズを満たさない場合は、ノードプールの kubelet パラメーターをカスタマイズしてノードの動作を調整できます。たとえば、リソース予約を調整してリソース使用量を管理したり、ノードプレッシャーによる退避のしきい値をカスタマイズしてリソース不足を緩和したり、トポロジーマネージャーポリシーを変更してシステムパフォーマンスを向上させたりすることができます。
制限事項
バージョン 1.20 以降を実行する ACK クラスターのみがカスタム kubelet パラメーターをサポートします。クラスターをアップグレードするには、「ACK クラスターを手動でアップグレードする」をご参照ください。
バージョン 1.22 以降を実行する ACK Lingjun クラスターのみがカスタム kubelet パラメーターをサポートします。クラスターをアップグレードするには、「クラスターのアップグレード」をご参照ください。
クラスターのバージョンがこれらの条件を満たさない場合、予期しない動作が発生する可能性があります。
注意事項
カスタム kubelet パラメーターは、ノード構成をバッチで変更します。変更は、ノードプール内の既存のノードにすぐに反映されます。新しいノードも新しい構成を使用します。変更が有効になると、kubelet プロセスが再起動します。これは、実行中のノードとワークロードに影響を与える可能性があります。この操作はオフピーク時に実行することを推奨します。
`evictionHard`、`kubeReserved`、または `systemReserved` が構成されていない場合、システムはリソース予約にデフォルト値を使用します。デフォルト値の計算方法の詳細については、「ノードリソース予約ポリシー」をご参照ください。
リソース予約構成を変更すると、ノードの割り当て可能なリソースが減少する可能性があります。リソース使用率が高いノードでは、これによりノードのエビクションがトリガーされる可能性があります。
コンソールでサポートされていない kubelet パラメーターを定義するためにコマンドラインを使用しないでください。この操作は、重大な安定性のリスクをもたらします。ユーザーデータファイルの正確性と互換性を確保する責任はユーザーにあります。不正な構成や新しいバージョンで非推奨になった構成は、ノードが利用できなくなる原因となる可能性があります。
kubelet が起動すると、優先度に基づいてさまざまなソースからの構成がマージされます。同じ設定項目が複数の方法で設定されている場合、優先度の高い設定が優先度の低い設定を上書きします。
コンソールでノードプールの kubelet パラメーターをカスタマイズする
カスタム kubelet パラメーターが適用されると、kubelet プロセスが再起動します。これはサービスに影響を与える可能性があります。この操作はオフピーク時に実行することを推奨します。
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
クラスター ページで、管理するクラスターを見つけてその名前をクリックします。左側のナビゲーションウィンドウで、 を選択します。
Node Pools ページで、対象のノードプールの [アクション] 列で
> [Kubelet 設定] をクリックします。ページ上の注意事項を読みます。[カスタムパラメーター] をクリックし、構成するパラメーターを選択し、アップグレードするノードを指定し、一括更新ポリシーを構成します。次に、[送信] をクリックし、画面の指示に従います。
一括更新ポリシーは次のように説明されます。
バッチごとの最大同時ノード数: Kubelet 構成はバッチでノードに適用されます。このプロセスには時間がかかります。イベントリストで進行状況を表示し、一時停止、再開、キャンセルなどのプロセスを制御できます。
バッチ間の間隔: バッチ間の時間間隔。
一時停止機能を使用して、アップグレードされたノードを検証できます。タスクを一時停止すると、現在のノードの構成が完了します。まだ開始されていないノードは、タスクを再開するまで構成されません。
カスタム構成タスクはタイムリーに完了することを推奨します。一時停止されたタスクは 7 日後に自動的にキャンセルされます。関連するイベントとログもクリアされます。
コンソールを使用するだけでなく、ModifyNodePoolNodeConfig 操作を呼び出して kubelet パラメーターをカスタマイズすることもできます。次のセクションでは、ACK でサポートされているカスタマイズ可能な kubelet パラメーターについて説明します。
カスタマイズ可能な kubelet パラメーター
フィールド | 説明 | デフォルト値 | 推奨値の範囲 |
allowedUnsafeSysctls | 許可される安全でない sysctl または sysctl ワイルドカード文字 ( 重要 このパラメーターを使用する前に、リスクを慎重に評価し、可用性を確保してください。 | N/A | 次のプレフィックスを持つ sysctl 構成をサポートします。
|
containerLogMaxFiles | コンテナーのログファイルの最大数。値は 2 以上である必要があります。コンテナーランタイムは containerd である必要があります。 | 10 | [2, 10] |
containerLogMaxSize | ローテーションされる前のコンテナーログファイルの最大サイズ。コンテナーランタイムは containerd である必要があります。 | 100Mi | N/A |
cpuCFSQuota | CPU 制限のあるコンテナーに対して CPU CFS クォータの強制を有効にします。 | true | 有効値:
|
cpuCFSQuotaPeriod | CPU CFS クォータ期間を設定します。 CustomCPUCFSQuotaPeriod フィーチャーゲートを有効にする必要があります。 | 100ms | 1 ミリ秒から 1 秒までの値 (両端を含む)。 |
cpuManagerPolicy | CPU マネージャーポリシー。 | none | 有効値:
|
eventBurst | イベント作成の最大バースト。 | 10 | [1, 100]。値は |
eventRecordQPS | 1 秒あたりに生成できるイベントの数。 | 5 | [1, 50] |
evictionHard | Pod のエビクションをトリガーするハードエビクションしきい値のセット。 | imagefs.available<15%,memory.available<300Mi,nodefs.available<10%,nodefs.inodesFree<5% | なし。 |
evictionSoft | ソフトエビクションしきい値のセット。 | なし | なし。 |
evictionSoftGracePeriod | エビクション猶予期間のセット。 説明 `evictionSoft` を設定する必要があります。 | なし | なし。 |
featureGates | 実験的な機能のフィーチャーゲートを記述するキーと値のペアのセット。各ゲートは
重要
| N/A | N/A |
imageGCHighThresholdPercent | イメージの GC をトリガーするディスク使用率のパーセンテージ。ディスク使用率がこのしきい値を超えると、イメージの GC が実行されます。 この値は `imageGCLowThresholdPercent` の値より大きい必要があります。 | 85 | [60, 95] |
imageGCLowThresholdPercent | イメージの GC が実行されないディスク使用率のパーセンテージ。ディスク使用率がこのしきい値未満の場合、イメージの GC は実行されません。 この値は `imageGCHighThresholdPercent` の値より小さい必要があります。 | 80 | [30, 90] |
kubeAPIBurst | 1 秒あたりに API サーバーに送信されるバーストリクエストの最大数。 | 10 | [1, 100]。値は |
kubeAPIQPS | API サーバーへの 1 秒あたりのクエリ数 (QPS)。 | 5 | [1, 50] |
kubeReserved | Kubernetes システム用に予約されたリソース構成。 | デフォルトでは値が自動的に計算されます。詳細については、「ノードリソース予約ポリシー」をご参照ください。 | N/A |
maxPods | ノードで実行できる Pod の最大数。 重要 `maxPods` の値を変更しても、ノードに割り当てることができる IP アドレスの数には影響しません。`maxPods` の値が大きすぎると、HostNetwork モードを使用しない Pod は IP アドレスを割り当てられず、起動に失敗する可能性があります。 | N/A。値は、マシンの仕様やコンテナーネットワークプランニングなどの物理リソース構成によって異なります。 | N/A |
memoryManagerPolicy | メモリマネージャーのポリシー。 | なし | 有効値:
|
podPidsLimit | 各 Pod で使用できるプロセス ID (PID) の最大数。 | 16384 | なし。 |
readOnlyPort | 認証を必要としない kubelet の読み取り専用ポート。 |
| 0 kubelet コンテナー監視のために読み取り専用ポート (10255) を開くリスクの詳細については、「[製品変更] 以前のバージョンの ACK クラスターの監視ポートを認証済みポートに移行する」をご参照ください。 |
registryBurst | バーストイメージプルの最大数。 | 10 | [1, 100]。値は |
registryPullQPS | イメージリポジトリの最大 QPS。 | 5 | [1, 50] |
reservedMemory | NUMA ノードのメモリ予約のリスト。 | なし。 | なし。 |
serializeImagePulls | イメージをシリアルにプルします。 | False | 有効値:
|
systemReserved | システム用に予約されたリソース構成。 | デフォルトでは値が自動的に計算されます。詳細については、「ノードリソース予約ポリシー」をご参照ください。 | N/A |
topologyManagerPolicy | トポロジーマネージャーポリシー。NUMA アーキテクチャでは、データを同じ NUMA ノードに割り当てて、ノード間のアクセスを減らし、システムパフォーマンスを向上させることができます。トポロジーマネージャーは、トポロジーに合わせたリソース割り当ての決定を行うことができます。詳細については、「ノードのトポロジー管理ポリシーの制御」をご参照ください。 | none |
|
containerLogMonitorInterval | クラスターのバージョンは 1.30 以降である必要があります。 コンテナーログがローテーションのためにチェックされる間隔。 | 10s | [3s,60s] |
containerLogMaxWorkers | クラスターのバージョンは 1.30 以降である必要があります。 ログローテーションのための同時ワーカーの最大数。 | 1 | [1,20] |
tracing | クラスターのコントロールプレーンまたはデータプレーンコンポーネントのトレース分析を有効にします。 詳細については、「トレース分析の管理」をご参照ください。 | なし |
|
よくある質問
カスタム構成は非推奨になりますか?
Kubernetes の進化に伴い、一部のパラメーターやフィーチャーゲートが非推奨になったり、削除されたりすることがあります。ACK によって管理されるカスタムパラメーターが新しいバージョンに適用できない場合、関連する構成はクラスターのアップグレード中に削除されます。
構成ファイルを使用して kubelet を管理するにはどうすればよいですか?
Container Service for Kubernetes は、コミュニティのベストプラクティスに基づいて kubelet 構成の管理方法を調整します。バージョン 1.20 以降を実行するクラスターでは、非推奨の kubelet コマンドラインフラグは徐々に構成ファイルに置き換えられます。詳細については、「Kubelet 構成 (v1beta1)」をご参照ください。
新しく作成されたノードや自動スケールされたノードなどの新しいノードは、構成ファイルと元の構成方法の両方を使用します。既存のノードは影響を受けません。構成ファイルのみを使用してノードプール内のすべてのノードの構成を管理するには、「カスタマイズ可能な kubelet パラメーター」で説明されているようにカスタム構成を適用できます。
サポートされているリストにない kubelet パラメーターを変更するにはどうすればよいですか?
ACK では、カスタムパラメーターを `/etc/kubernetes/kubelet-customized-args.conf` ファイルに書き込むことができます。このファイルには、kubelet のカスタム起動パラメーターと構成オプションが格納されます。このファイルに書き込まれたパラメーターは、ノードの再起動時にノードプールのカスタム kubelet 構成機能を使用して設定された値よりも優先され、上書きされます。
kubelet パラメーターを調整すると、ノードの登録失敗や Pod のスケジューリング失敗などの問題が発生し、サービスに影響を与える可能性があります。続行する前に、変更のリスクを十分に評価することを推奨します。
(推奨) ノードプールに作成されるノードについては、ノードプールの [ユーザーデータ] セクションでスクリプトを構成して、カスタムパラメーター構成ファイルに書き込むことができます。これにより、新しいノードはデフォルトでこれらのカスタムパラメーター値を使用するようになります。
ノードプール構成の [ユーザーデータ] セクションに、次のスクリプトを追加します。
${kubelet_key}と${kubelet_value}を実際の値に置き換えます。[ユーザーデータ] セクションでは、
> /etc/kubernetes/kubelet-customized-args.conf> kubelet-customized-args.conf[事前カスタマイズされたユーザーデータ] セクションで他の方法を使用して `kubelet-customized-args.conf` を変更すると、ACK の初期化中に `/etc/kubernetes/kubelet-customized-args.conf` ファイルが上書きされます。mkdir -p /etc/kubernetes echo 'KUBELET_CUSTOMIZED_ARGS="--${kubelet_key}=${kubelet_value}"' > /etc/kubernetes/kubelet-customized-args.conf systemctl daemon-reload systemctl restart kubelet構成ページへのアクセス方法の詳細については、「ノードプールの作成と管理」をご参照ください。
ノードプール内の既存のノードについては、ノードにログインしてカスタムパラメーター構成ファイルを変更します。次に、次のコマンドを実行して構成を適用します。
systemctl daemon-reload systemctl restart kubelet
リファレンス
ノードプールの設定項目の詳細については、「ノードプールの作成と管理」をご参照ください。
ノード、Pod、または kubelet でエラーや異常な動作が発生した場合は、「異常なノードのトラブルシューティング」、「異常な Pod のトラブルシューティング」、および「ノードとノードプールに関するよくある質問」を参照して問題をトラブルシューティングしてください。

詳細については、「