デフォルトの kubelet 設定が要件を満たさない場合、ノードプールの kubelet パラメーターをカスタマイズしてノードの動作を調整できます。たとえば、リソース予約を調整してリソース使用量を管理したり、ノードプレッシャーによるエビクションのしきい値をカスタマイズしてリソース不足を緩和したり、トポロジー管理ポリシーを変更してシステムパフォーマンスを向上させたりすることができます。
制限事項
バージョン 1.20 以降を実行する ACK クラスターのみが、カスタム kubelet パラメーターをサポートします。クラスターをアップグレードするには、「クラスターの手動アップグレード」をご参照ください。
バージョン 1.22 以降を実行する ACK Lingjun クラスターのみが、カスタム kubelet パラメーターをサポートします。クラスターをアップグレードするには、「クラスターのアップグレード」をご参照ください。
ご利用のクラスターのバージョンがこれらの条件を満たさない場合、予期しない動作が発生する可能性があります。
注意事項
カスタム kubelet パラメーターは、ノードプール内の既存ノードの設定を一括で変更します。この変更はすぐに有効になります。新しく追加されるノードにも新しい設定が適用されます。変更が有効になると kubelet プロセスが再起動するため、実行中のノードやワークロードに影響を与える可能性があります。この操作は、オフピーク時に実行することを推奨します。
evictionHard、kubeReserved、またはsystemReservedが設定されていない場合、システムはリソース予約にデフォルト値を使用します。デフォルト値の計算方法の詳細については、「ノードリソース予約ポリシー」をご参照ください。リソース予約設定の変更により、ノードの割り当て可能なリソースが減少する可能性があります。リソース使用率が高いノードでは、これによりノードのエビクションがトリガーされることがあります。
コンソールでサポートされていない kubelet パラメーターをコマンドラインで定義しないでください。この操作は、安定性に重大なリスクをもたらします。ユーザーデータファイルの正確性と互換性は、お客様の責任となります。不正な設定や新しいバージョンで非推奨となった設定は、ノードが利用できなくなる原因となる可能性があります。
kubelet の起動時に、異なるソースからの設定が優先度に基づいてマージされます。同じ設定項目が複数の方法で設定されている場合、優先度の高い設定が優先度の低い設定を上書きします。
コンソールでのノードプールに対する kubelet パラメーターのカスタマイズ
カスタム kubelet パラメーターが適用されると、kubelet プロセスが再起動します。これにより、サービスに影響が及ぶ可能性があります。この操作は、オフピーク時に実行することを推奨します。
ACK コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。
クラスターリスト ページで、対象クラスターの名前をクリックします。左側のナビゲーションウィンドウで、 をクリックします。
ノードプールページで、対象のノードプールの[操作]列で
> [Kubelet 設定]をクリックします。ページ上の注意事項を読み、[カスタムパラメーター] をクリックし、設定するパラメーターを選択し、アップグレードするノードを指定し、一括更新ポリシーを設定します。その後、[送信] をクリックし、画面の指示に従います。
一括更新ポリシーは以下の通りです:
[バッチごとの最大並列ノード数]:kubelet 設定はバッチでノードに適用されます。このプロセスには時間がかかります。イベントリストで進捗状況の確認や、一時停止、再開、キャンセルなどの操作ができます。
[バッチ間の間隔]:バッチ間の時間間隔。
一時停止機能を使用して、アップグレードされたノードを検証できます。タスクを一時停止すると、現在のノードの設定は完了しますが、まだ開始されていないノードは、タスクを再開するまで設定されません。
カスタム設定タスクは、できるだけ早く完了してください。7 日が経過すると、一時停止中のタスクは自動的にキャンセルされ、関連するイベントとログはクリアされます。
コンソールを使用する以外に、ModifyNodePoolNodeConfig 操作を呼び出して kubelet パラメーターをカスタマイズすることもできます。次のセクションでは、ACK でサポートされているカスタマイズ可能な kubelet パラメーターについて説明します。
カスタマイズ可能な kubelet パラメーター
フィールド | 説明 | デフォルト値 | 推奨値の範囲 |
allowedUnsafeSysctls | 許可される安全でない sysctl または sysctl ワイルドカード文字 ( 重要 このパラメーターを使用する前に、リスクを慎重に評価し、可用性を確保してください。 | N/A | 以下のプレフィックスを持つ sysctl 設定をサポートします:
|
containerLogMaxFiles | コンテナのログファイルの最大数。値は 2 以上である必要があります。コンテナランタイムは containerd である必要があります。 | 10 | [2, 10] |
containerLogMaxSize | ローテーションされる前のコンテナログファイルの最大サイズ。コンテナランタイムは containerd である必要があります。 |
| N/A |
cpuCFSQuota | CPU 制限のあるコンテナに対して CPU CFS クォータの強制を有効にします。 | true | 有効な値:
|
cpuCFSQuotaPeriod | CPU CFS クォータ期間を設定します。 CustomCPUCFSQuotaPeriod 機能ゲートを有効にする必要があります。 |
| 1 ミリ秒から 1 秒までの値 (両端を含む)。 |
cpuManagerPolicy | CPU マネージャーポリシー。 | none | 有効な値:
|
eventBurst | バースト時のイベントレコードのピーク数。 | 10 | [1, 100]; 値は |
eventRecordQPS | 1 秒あたりに生成できるイベントの数。 | 5 | [1, 50] |
evictionHard | Pod のエビクションをトリガーするハードエビクションしきい値のセット。 |
| なし |
evictionSoft | ソフトエビクションしきい値のセット。 | なし | なし |
evictionSoftGracePeriod | エビクション猶予期間のセット。 説明
| なし | なし |
featureGates | 実験的な機能のための機能ゲートを記述するキーと値のペアのセット。各ゲートは
重要
| N/A | N/A |
imageGCHighThresholdPercent | イメージ GC をトリガーするディスク使用率のパーセンテージ。ディスク使用率がこのしきい値を超えると、イメージ GC が実行されます。 この値は | 85 | [60, 95] |
imageGCLowThresholdPercent | イメージ GC が実行されないディスク使用率のパーセンテージ。ディスク使用率がこのしきい値を下回る場合、イメージ GC は実行されません。 この値は | 80 | [30, 90] |
kubeAPIBurst | API サーバーに 1 秒あたりに送信されるバーストリクエストの最大数。 | 10 | [1, 100]; 値は |
kubeAPIQPS | API サーバーへの秒間クエリ数 (QPS)。 | 5 | [1, 50] |
kubeReserved | Kubernetes システム用に予約されたリソース設定。 | デフォルトでは値が自動的に計算されます。詳細については、「ノードリソース予約ポリシー」をご参照ください。 | N/A |
maxPods | ノードで実行できる Pod の最大数。 重要
| N/A。値は、マシンの仕様やコンテナネットワーク計画などの物理リソース設定に依存します。 | N/A |
memoryManagerPolicy | メモリマネージャーのポリシー。 | なし | 有効な値:
|
podPidsLimit | 各 Pod で使用できるプロセス ID (PID) の最大数。
|
| なし |
readOnlyPort | 認証を必要としない kubelet の読み取り専用ポート。 |
|
kubelet コンテナ監視のために読み取り専用ポート ( |
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 を管理する方法
ACK は、コミュニティのベストプラクティスに基づいて kubelet の設定管理方法を調整しています。バージョン 1.20 以降を実行するクラスターでは、非推奨の kubelet コマンドラインフラグは徐々に構成ファイルに置き換えられます。詳細については、「Kubelet Configuration (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.confmkdir -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 のトラブルシューティング」、および「ノードとノードプールに関するよくある質問」をご参照ください。

詳細については、「