This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.5.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: 250
5.4.1. kubelet パラメーターを編集するための KubeletConfig CRD の作成 リンクのコピーリンクがクリップボードにコピーされました!
kubelet 設定は、現時点で Ignition 設定としてシリアル化されているため、直接編集することができます。ただし、新規の kubelet-config-controller
も Machine Config Controller (MCC) に追加されます。これにより、KubeletConfig
カスタムリソース (CR) を使用して kubelet パラメーターを編集できます。
kubeletConfig
オブジェクトのフィールドはアップストリーム Kubernetes から kubelet に直接渡されるため、kubelet はそれらの値を直接検証します。kubeletConfig
オブジェクトに無効な値により、クラスターノードが利用できなくなります。有効な値は、Kubernetes ドキュメント を参照してください。
以下のガイダンスを参照してください。
-
マシン設定プールごとに、そのプールに加える設定変更をすべて含めて、
KubeletConfig
CR を 1 つ作成します。同じコンテンツをすべてのプールに適用している場合には、すべてのプールにKubeletConfig
CR を 1 つだけ設定する必要があります。 -
既存の
KubeletConfig
CR を編集して既存の設定を編集するか、変更ごとに新規 CR を作成する代わりに新規の設定を追加する必要があります。CR を作成するのは、別のマシン設定プールを変更する場合、または一時的な変更を目的とした変更の場合のみにして、変更を元に戻すことができるようにすることをお勧めします。 -
必要に応じて、クラスターごとに 10 を制限し、複数の
KubeletConfig
CR を作成します。最初のKubeletConfig
CR について、Machine Config Operator (MCO) はkubelet
で追加されたマシン設定を作成します。それぞれの後続の CR で、コントローラーは数字の接尾辞が付いた別のkubelet
マシン設定を作成します。たとえば、kubelet
マシン設定があり、その接尾辞が-2
の場合に、次のkubelet
マシン設定には-3
が付けられます。
マシン設定を削除する場合は、制限を超えないようにそれらを逆の順序で削除する必要があります。たとえば、kubelet-3
マシン設定を、kubelet-2
マシン設定を削除する前に削除する必要があります。
接尾辞が kubelet-9
のマシン設定があり、別の KubeletConfig
CR を作成する場合には、kubelet
マシン設定が 10 未満の場合でも新規マシン設定は作成されません。
KubeletConfig
CR の例
oc get kubeletconfig
$ oc get kubeletconfig
NAME AGE set-max-pods 15m
NAME AGE
set-max-pods 15m
KubeletConfig
マシン設定を示す例
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 の最大数を設定する方法を示しています。
前提条件
設定するノードタイプの静的な
MachineConfigPool
CR に関連付けられたラベルを取得します。以下のいずれかの手順を実行します。マシン設定プールを表示します。
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-max-pods
$ oc label machineconfigpool worker custom-kubelet=set-max-pods
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 ワーカーノードでノードあたりの最大の Pod を設定するには、kubelet 設定を含むカスタムリソースファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記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=large-pods
$ oc label machineconfigpool worker custom-kubelet=large-pods
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-max-pods 15m
NAME AGE set-max-pods 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-max-pods -o yaml
$ oc get kubeletconfigs set-max-pods -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上記のコマンドでは
status: "True"
とtype:Success
が表示されるはずです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.3. コントロールプレーンノードのサイジング リンクのコピーリンクがクリップボードにコピーされました!
コントロールプレーンノードリソースの要件は、クラスター内のノード数によって異なります。コントロールプレーンノードのサイズについての以下の推奨内容は、テストに重点を置いた場合のコントロールプレーンの密度の結果に基づいています。コントロールプレーンのテストでは、ノード数に応じて各 namespace でクラスター全体に展開される以下のオブジェクトを作成します。
- 12 イメージストリーム
- 3 ビルド設定
- 6 ビルド
- それぞれに 2 つのシークレットをマウントする 2 Pod レプリカのある 1 デプロイメント
- 2 つのシークレットをマウントする 1 Pod レプリカのある 2 デプロイメント
- 先のデプロイメントを参照する 3 つのサービス
- 先のデプロイメントを参照する 3 つのルート
- 10 のシークレット (それらの内の 2 つは先ののデプロイメントでマウントされる)
- 10 の設定マップ (それらの内の 2 つは先のデプロイメントでマウントされる)
ワーカーノードの数 | クラスターの負荷 (namespace) | CPU コア数 | メモリー (GB) |
---|---|---|---|
25 | 500 | 4 | 16 |
100 | 1000 | 8 | 32 |
250 | 4000 | 16 | 96 |
3 つのコントロールプレーンノード (またはマスターノード) がある大規模で高密度のクラスターでは、いずれかのノードが停止、起動、または障害が発生すると、CPU とメモリーの使用量が急上昇します。障害は、コストを節約するためにシャットダウンした後にクラスターが再起動する意図的なケースに加えて、電源、ネットワーク、または基礎となるインフラストラクチャーの予期しない問題が発生することが原因である可能性があります。残りの 2 つのコントロールプレーンノードは、高可用性を維持するために負荷を処理する必要があります。これにより、リソースの使用量が増えます。これは、マスターが遮断 (cordon)、ドレイン (解放) され、オペレーティングシステムおよびコントロールプレーン Operator の更新を適用するために順次再起動されるため、アップグレード時に想定される動作になります。障害が繰り返し発生しないようにするには、コントロールプレーンノードでの全体的な 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.8 クラスターでコントロールプレーンノードのサイズを変更できません。その代わりに、ノードの合計数を見積もり、コントロールプレーンノードの推奨サイズをインストール時に使用する必要があります。
この推奨事項は、ネットワークプラグインとして OpenShift SDN を使用して OpenShift Container Platform クラスターでキャプチャーされたデータポイントに基づいています。
OpenShift Container Platform 4.8 では、デフォルトで CPU コア (500 ミリコア) の半分がシステムによって予約されます (OpenShift Container Platform 3.11 以前のバージョンと比較)。サイズはこれを考慮に入れて決定されます。
5.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 QoS (quality of service) 層
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 (この場合は
burstable
QoS 層にある Pod) が、Guaranteed
Pod に割り当てられたコアで実行できないことを確認します。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