7.4. ノードホストに関する推奨プラクティス
				OpenShift Container Platform ノードの設定ファイルには、重要なオプションが含まれています。たとえば、podsPerCore および maxPods の 2 つのパラメーターはノードにスケジュールできる Pod の最大数を制御します。
			
両方のオプションが使用されている場合、2 つの値の低い方の値により、ノード上の Pod 数が制限されます。これらの値を超えると、以下の状態が生じる可能性があります。
- CPU 使用率の増大。
- Pod のスケジューリングの速度が遅くなる。
- (ノードのメモリー量によって) メモリー不足のシナリオが生じる可能性。
- IP アドレスのプールを消費する。
- リソースのオーバーコミット、およびこれによるアプリケーションのパフォーマンスの低下。
Kubernetes では、単一コンテナーを保持する Pod は実際には 2 つのコンテナーを使用します。2 つ目のコンテナーは実際のコンテナーの起動前にネットワークを設定するために使用されます。そのため、10 の Pod を使用するシステムでは、実際には 20 のコンテナーが実行されていることになります。
クラウドプロバイダーからのディスク IOPS スロットリングは CRI-O および kubelet に影響を与える可能性があります。ノード上に多数の I/O 集約型 Pod が実行されている場合、それらはオーバーロードする可能性があります。ノード上のディスク I/O を監視し、ワークロード用に十分なスループットを持つボリュームを使用することが推奨されます。
				podsPerCore パラメーターは、ノードのプロセッサーコアの数に基づいて、ノードが実行できる Pod の数を設定します。たとえば、4 プロセッサーコアを搭載したノードで podsPerCore が 10 に設定される場合、このノードで許可される Pod の最大数は 40 になります。
			
kubeletConfig: podsPerCore: 10
kubeletConfig:
  podsPerCore: 10
				podsPerCore を 0 に設定すると、この制限が無効になります。デフォルトは 0 です。podsPerCore パラメーターの値は、maxPods パラメーターの値を超えることはできません。
			
				maxPods パラメーターは、ノードのプロパティーに関係なく、ノードが実行できる Pod の数を固定値に設定します。
			
 kubeletConfig:
    maxPods: 250
 kubeletConfig:
    maxPods: 2507.4.1. Kubelet パラメーターを編集するための KubeletConfig CR の作成
					kubelet 設定は、現時点で Ignition 設定としてシリアル化されているため、直接編集することができます。ただし、新規の kubelet-config-controller も Machine Config Controller (MCC) に追加されます。これにより、KubeletConfig カスタムリソース (CR) を使用して kubelet パラメーターを編集できます。
				
						kubeletConfig オブジェクトのフィールドはアップストリーム Kubernetes から kubelet に直接渡されるため、kubelet はそれらの値を直接検証します。kubeletConfig オブジェクトに無効な値があると、クラスターノードを利用できなくなる可能性があります。有効な値は、Kubernetes ドキュメント を参照してください。
					
以下のガイダンスを参照してください。
- 
							既存の KubeletConfigCR を編集して既存の設定を編集するか、変更ごとに新規 CR を作成する代わりに新規の設定を追加する必要があります。CR を作成するのは、別のマシン設定プールを変更する場合、または一時的な変更を目的とした変更の場合のみにして、変更を元に戻すことができるようにすることを推奨します。
- 
							マシン設定プールごとに、そのプールに加える設定変更をすべて含めて、KubeletConfigCR を 1 つ作成します。
- 
							必要に応じて、クラスターごとに 10 個を上限として、複数の KubeletConfigCR を作成します。最初のKubeletConfigCR について、Machine Config Operator (MCO) はkubeletで追加されたマシン設定を作成します。それぞれの後続の CR で、コントローラーは数字の接尾辞が付いた別のkubeletマシン設定を作成します。たとえば、kubeletマシン設定があり、その接尾辞が-2の場合に、次のkubeletマシン設定には-3が付けられます。
						kubelet またはコンテナーのランタイム設定をカスタムマシン設定プールに適用する場合、machineConfigSelector のカスタムロールは、カスタムマシン設定プールの名前と一致する必要があります。
					
						たとえば、次のカスタムマシン設定プールの名前は infra であるため、カスタムロールも infra にする必要があります。
					
					マシン設定を削除する場合は、制限を超えないようにそれらを逆の順序で削除する必要があります。たとえば、kubelet-3 マシン設定を、kubelet-2 マシン設定を削除する前に削除する必要があります。
				
						接尾辞が kubelet-9 のマシン設定があり、別の KubeletConfig CR を作成する場合には、kubelet マシン設定が 10 未満の場合でも新規マシン設定は作成されません。
					
KubeletConfig CR の例
oc get kubeletconfig
$ oc get kubeletconfigNAME AGE set-kubelet-config 15m
NAME                      AGE
set-kubelet-config        15mKubeletConfig マシン設定を示す例
oc get mc | grep kubelet
$ oc get mc | grep kubelet... 99-worker-generated-kubelet-1 b5c5119de007945b6fe6fb215db3b8e2ceb12511 3.2.0 26m ...
...
99-worker-generated-kubelet-1                  b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             26m
...次の手順は、ノードあたりの Pod の最大数、ノードあたりの PID の最大数、およびワーカーノード上のコンテナーログの最大サイズを設定する方法を示した例です。
前提条件
- 設定するノードタイプの静的な - MachineConfigPoolCR に関連付けられたラベルを取得します。以下のいずれかの手順を実行します。- マシン設定プールを表示します。 - oc describe machineconfigpool <name> - $ oc describe machineconfigpool <name>- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 以下に例を示します。 - oc describe machineconfigpool worker - $ oc describe machineconfigpool worker- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- ラベルが追加されると、labelsの下に表示されます。
 
- ラベルが存在しない場合は、キー/値のペアを追加します。 - oc label machineconfigpool worker custom-kubelet=set-kubelet-config - $ oc label machineconfigpool worker custom-kubelet=set-kubelet-config- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
手順
- 選択可能なマシン設定オブジェクトを表示します。 - oc get machineconfig - $ oc get machineconfig- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - デフォルトで、2 つの kubelet 関連の設定である - 01-master-kubeletおよび- 01-worker-kubeletを選択できます。
- ノードあたりの最大 Pod の現在の値を確認します。 - oc describe node <node_name> - $ oc describe node <node_name>- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 以下に例を示します。 - oc describe node ci-ln-5grqprb-f76d1-ncnqq-worker-a-mdv94 - $ oc describe node ci-ln-5grqprb-f76d1-ncnqq-worker-a-mdv94- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - Allocatableスタンザで- value: pods: <value>を検索します。- 出力例 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 必要に応じてワーカーノードを設定します。 - kubelet 設定を含む次のような YAML ファイルを作成します。 重要- 特定のマシン設定プールをターゲットとする kubelet 設定は、依存するプールにも影響します。たとえば、ワーカーノードを含むプール用の kubelet 設定を作成すると、インフラストラクチャーノードを含むプールを含むすべてのサブセットプールにも設定が適用されます。これを回避するには、ワーカーノードのみを含む選択式を使用して新しいマシン設定プールを作成し、kubelet 設定でこの新しいプールをターゲットにする必要があります。 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 
											podPidsLimitを使用して、任意の Pod 内の PID の最大数を設定します。
- 
											containerLogMaxSizeを使用して、コンテナーログファイルがローテーションされる前の最大サイズを設定します。
- maxPodsを使用して、ノードあたりの Pod の最大数を設定します。注記- kubelet が API サーバーと通信する速度は、1 秒あたりのクエリー (QPS) およびバースト値により異なります。デフォルト値の - 50(- kubeAPIQPSの場合) および- 100(- kubeAPIBurstの場合) は、各ノードで制限された Pod が実行されている場合には十分な値です。ノード上に CPU およびメモリーリソースが十分にある場合には、kubelet QPS およびバーストレートを更新することが推奨されます。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
- 
											
- ラベルを使用してワーカーのマシン設定プールを更新します。 - oc label machineconfigpool worker custom-kubelet=set-kubelet-config - $ oc label machineconfigpool worker custom-kubelet=set-kubelet-config- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- KubeletConfigオブジェクトを作成します。- oc create -f change-maxPods-cr.yaml - $ oc create -f change-maxPods-cr.yaml- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
検証
- KubeletConfigオブジェクトが作成されていることを確認します。- oc get kubeletconfig - $ oc get kubeletconfig- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - NAME AGE set-kubelet-config 15m - NAME AGE set-kubelet-config 15m- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - クラスター内のワーカーノードの数によっては、ワーカーノードが 1 つずつ再起動されるのを待機します。3 つのワーカーノードを持つクラスターの場合は、10 分から 15 分程度かかる可能性があります。 
- 変更がノードに適用されていることを確認します。 - maxPods値が変更されたワーカーノードで確認します。- oc describe node <node_name> - $ oc describe node <node_name>- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Allocatableスタンザを見つけます。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- この例では、podsパラメーターはKubeletConfigオブジェクトに設定した値を報告するはずです。
 
 
- KubeletConfigオブジェクトの変更を確認します。- oc get kubeletconfigs set-kubelet-config -o yaml - $ oc get kubeletconfigs set-kubelet-config -o yaml- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - これは、以下の例のように - Trueおよび- type:Successのステータスを表示します。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
7.4.3. コントロールプレーンノードのサイジング
コントロールプレーンノードのリソース要件は、クラスター内のノードとオブジェクトの数とタイプによって異なります。次のコントロールプレーンノードサイズの推奨事項は、コントロールプレーン密度に焦点を当てたテストまたは クラスター密度 の結果に基づいています。このテストでは、指定された数の namespace にわたって次のオブジェクトを作成します。
- 1 イメージストリーム
- 1 ビルド
- 
							5 つのデプロイメント、sleep状態の 2 つの Pod レプリカ、4 つのシークレット、4 つの config map、およびそれぞれ 1 つの下位 API ボリュームのマウント
- 5 つのサービス。それぞれが以前のデプロイメントの 1 つの TCP/8080 および TCP/8443 ポートを指します。
- 以前のサービスの最初を指す 1 つのルート
- 2048 個のランダムな文字列文字を含む 10 個のシークレット
- 2048 個のランダムな文字列文字を含む 10 個の config map
| ワーカーノードの数 | クラスター密度 (namespace) | CPU コア数 | メモリー (GB) | 
|---|---|---|---|
| 24 | 500 | 4 | 16 | 
| 120 | 1000 | 8 | 32 | 
| 252 | 4000 | 16、ただし OVN-Kubernetes ネットワークプラグインを使用する場合は 24 | 64、ただし OVN-Kubernetes ネットワークプラグインを使用する場合は 128 | 
| 501、ただし OVN-Kubernetes ネットワークプラグインではテストされていません | 4000 | 16 | 96 | 
上の表のデータは、r5.4xlarge インスタンスをコントロールプレーンノードとして使用し、m5.2xlarge インスタンスをワーカーノードとして使用する、AWS 上で実行される OpenShift Container Platform をベースとしています。
3 つのコントロールプレーンノードを持つ大規模で高密度なクラスターでは、いずれかのノードが停止、再起動、または障害が発生すると、CPU とメモリーの使用量が急増します。障害は、電源、ネットワーク、または基礎となるインフラストラクチャーの予期しない問題、またはコストを節約するためにシャットダウンした後にクラスターが再起動する意図的なケースが原因である可能性があります。残りの 2 つのコントロールプレーンノードは、高可用性を維持するために負荷を処理する必要があります。これにより、リソースの使用量が増えます。この動作はアップグレード時にも予想されます。オペレーティングシステムの更新とコントロールプレーン Operator の更新を適用するために、コントロールプレーンノードに cordon (スケジューリング対象からの除外) と drain (Pod の退避) が実行され、ノードが順次再起動されるためです。障害が繰り返し発生しないようにするには、コントロールプレーンノードでの全体的な CPU およびメモリーリソース使用状況を、利用可能な容量の最大 60% に維持し、使用量の急増に対応できるようにします。リソース不足による潜在的なダウンタイムを回避するために、コントロールプレーンノードの CPU およびメモリーを適宜増やします。
						ノードのサイジングは、クラスター内のノードおよびオブジェクトの数によって異なります。また、オブジェクトがそのクラスター上でアクティブに作成されるかどうかによっても異なります。オブジェクトの作成時に、コントロールプレーンは、オブジェクトが running フェーズにある場合と比較し、リソースの使用状況においてよりアクティブな状態になります。
					
Operator Lifecycle Manager (OLM) はコントロールプレーンノードで実行され、OLM のメモリーフットプリントは OLM がクラスター上で管理する必要のある namespace およびユーザーによってインストールされる Operator の数によって異なります。OOM による強制終了を防ぐには、コントロールプレーンノードのサイズを適切に設定する必要があります。以下のデータポイントは、クラスター最大のテストの結果に基づいています。
| namespace 数 | アイドル状態の OLM メモリー (GB) | ユーザー Operator が 5 つインストールされている OLM メモリー (GB) | 
|---|---|---|
| 500 | 0.823 | 1.7 | 
| 1000 | 1.2 | 2.5 | 
| 1500 | 1.7 | 3.2 | 
| 2000 | 2 | 4.4 | 
| 3000 | 2.7 | 5.6 | 
| 4000 | 3.8 | 7.6 | 
| 5000 | 4.2 | 9.02 | 
| 6000 | 5.8 | 11.3 | 
| 7000 | 6.6 | 12.9 | 
| 8000 | 6.9 | 14.8 | 
| 9000 | 8 | 17.7 | 
| 10,000 | 9.9 | 21.6 | 
以下の設定でのみ、実行中の OpenShift Container Platform 4.13 クラスターでコントロールプレーンのノードサイズを変更できます。
- ユーザーがプロビジョニングしたインストール方法でインストールされたクラスター。
- installer-provisioned infrastructure インストール方法でインストールされた AWS クラスター。
- コントロールプレーンマシンセットを使用してコントロールプレーンマシンを管理するクラスター。
他のすべての設定では、合計ノード数を見積もり、インストール時に推奨されるコントロールプレーンノードサイズを使用する必要があります。
この推奨事項は、ネットワークプラグインとして OpenShift SDN を使用して OpenShift Container Platform クラスターでキャプチャーされたデータポイントに基づいています。
OpenShift Container Platform 4.13 では、OpenShift Container Platform 3.11 以前のバージョンと比較すると、CPU コア (500 ミリコア) の半分がデフォルトでシステムによって予約されるようになりました。サイズはこれを考慮に入れて決定されます。
7.4.4. CPU マネージャーの設定
手順
- オプション: ノードにラベルを指定します。 - oc label node perf-node.example.com cpumanager=true - # oc label node perf-node.example.com cpumanager=true- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- CPU マネージャーを有効にする必要のあるノードの - MachineConfigPoolを編集します。この例では、すべてのワーカーで CPU マネージャーが有効にされています。- oc edit machineconfigpool worker - # oc edit machineconfigpool worker- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- ラベルをワーカーのマシン設定プールに追加します。 - metadata: creationTimestamp: 2020-xx-xxx generation: 3 labels: custom-kubelet: cpumanager-enabled- metadata: creationTimestamp: 2020-xx-xxx generation: 3 labels: custom-kubelet: cpumanager-enabled- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- KubeletConfig、- cpumanager-kubeletconfig.yaml、カスタムリソース (CR) を作成します。直前の手順で作成したラベルを参照し、適切なノードを新規の kubelet 設定で更新します。- machineConfigPoolSelectorセクションを参照してください。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 動的な kubelet 設定を作成します。 - oc create -f cpumanager-kubeletconfig.yaml - # oc create -f cpumanager-kubeletconfig.yaml- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - これにより、CPU マネージャー機能が kubelet 設定に追加され、必要な場合には Machine Config Operator (MCO) がノードを再起動します。CPU マネージャーを有効にするために再起動する必要はありません。 
- マージされた kubelet 設定を確認します。 - oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7 - # oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- ワーカーで更新された - kubelet.confを確認します。- oc debug node/perf-node.example.com - # oc debug node/perf-node.example.com sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - cpuManagerPolicy: static cpuManagerReconcilePeriod: 5s - cpuManagerPolicy: static- 1 - cpuManagerReconcilePeriod: 5s- 2 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- コア 1 つまたは複数を要求する Pod を作成します。制限および要求の CPU の値は整数にする必要があります。これは、対象の Pod 専用のコア数です。 - cat cpumanager-pod.yaml - # cat cpumanager-pod.yaml- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Pod を作成します。 - oc create -f cpumanager-pod.yaml - # oc create -f cpumanager-pod.yaml- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Pod がラベル指定されたノードにスケジュールされていることを確認します。 - oc describe pod cpumanager - # oc describe pod cpumanager- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- cgroupsが正しく設定されていることを確認します。- pauseプロセスのプロセス ID (PID) を取得します。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - Quality of Service (QoS) 層 - Guaranteedの Pod は、- kubepods.sliceに配置されます。他の QoS 層の Pod は、- kubepodsの子である- cgroupsに配置されます。- cd /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope for i in `ls cpuset.cpus tasks` ; do echo -n "$i "; cat $i ; done - # cd /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope # for i in `ls cpuset.cpus tasks` ; do echo -n "$i "; cat $i ; done- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - cpuset.cpus 1 tasks 32706 - cpuset.cpus 1 tasks 32706- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 対象のタスクで許可される CPU リストを確認します。 - grep ^Cpus_allowed_list /proc/32706/status - # grep ^Cpus_allowed_list /proc/32706/status- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - Cpus_allowed_list: 1 - Cpus_allowed_list: 1- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- システム上の別の Pod (この場合は - burstableQoS 層にある Pod) が、- GuaranteedPod に割り当てられたコアで実行できないことを確認します。- cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus 0 oc describe node perf-node.example.com - # cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus 0 # oc describe node perf-node.example.com- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - この仮想マシンには、2 つの CPU コアがあります。 - system-reserved設定は 500 ミリコアを予約し、- Node Allocatableの量になるようにノードの全容量からコアの半分を引きます。ここで- Allocatable CPUは 1500 ミリコアであることを確認できます。これは、それぞれがコアを 1 つ受け入れるので、CPU マネージャー Pod の 1 つを実行できることを意味します。1 つのコア全体は 1000 ミリコアに相当します。2 つ目の Pod をスケジュールしようとする場合、システムは Pod を受け入れますが、これがスケジュールされることはありません。- NAME READY STATUS RESTARTS AGE cpumanager-6cqz7 1/1 Running 0 33m cpumanager-7qc2t 0/1 Pending 0 11s - NAME READY STATUS RESTARTS AGE cpumanager-6cqz7 1/1 Running 0 33m cpumanager-7qc2t 0/1 Pending 0 11s- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow