4.4. MCO 関連のカスタムリソースの設定
MCO は MachineConfig
オブジェクトを管理する以外にも、2 つのカスタムリソース (CR)(KubeletConfig
および ContainerRuntimeConfig
) を管理します。これらの CR を使用すると、Kubelet および CRI-O コンテナーランタイムサービスの動作に影響を与えるノードレベルの設定を変更することができます。
4.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
NAME AGE set-max-pods 15m
KubeletConfig
マシン設定を示す例
$ oc get mc | grep kubelet
... 99-worker-generated-kubelet-1 b5c5119de007945b6fe6fb215db3b8e2ceb12511 3.2.0 26m ...
以下の手順は、ワーカーノードでノードあたりの Pod の最大数を設定する方法を示しています。
前提条件
設定するノードタイプの静的な
MachineConfigPool
CR に関連付けられたラベルを取得します。以下のいずれかの手順を実行します。マシン設定プールを表示します。
$ oc describe machineconfigpool <name>
以下に例を示します。
$ oc describe machineconfigpool worker
出力例
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: creationTimestamp: 2019-02-08T14:52:39Z generation: 1 labels: custom-kubelet: set-max-pods 1
- 1
- ラベルが追加されると、
labels
の下に表示されます。
ラベルが存在しない場合は、キー/値のペアを追加します。
$ oc label machineconfigpool worker custom-kubelet=set-max-pods
手順
これは、選択可能なマシン設定オブジェクトを表示します。
$ oc get machineconfig
デフォルトで、2 つの kubelet 関連の設定である
01-master-kubelet
および01-worker-kubelet
を選択できます。ノードあたりの最大 Pod の現在の値を確認します。
$ oc describe node <node_name>
以下に例を示します。
$ oc describe node ci-ln-5grqprb-f76d1-ncnqq-worker-a-mdv94
Allocatable
スタンザでvalue: pods: <value>
を検索します。出力例
Allocatable: attachable-volumes-aws-ebs: 25 cpu: 3500m hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 15341844Ki pods: 250
ワーカーノードでノードあたりの最大の Pod を設定するには、kubelet 設定を含むカスタムリソースファイルを作成します。
apiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig metadata: name: set-max-pods spec: machineConfigPoolSelector: matchLabels: custom-kubelet: set-max-pods 1 kubeletConfig: maxPods: 500 2
注記kubelet が API サーバーと通信する速度は、1 秒あたりのクエリー (QPS) およびバースト値により異なります。デフォルト値の
50
(kubeAPIQPS
の場合) および100
(kubeAPIBurst
の場合) は、各ノードで制限された Pod が実行されている場合には十分な値です。ノード上に CPU およびメモリーリソースが十分にある場合には、kubelet QPS およびバーストレートを更新することが推奨されます。apiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig metadata: name: set-max-pods spec: machineConfigPoolSelector: matchLabels: custom-kubelet: set-max-pods kubeletConfig: maxPods: <pod_count> kubeAPIBurst: <burst_rate> kubeAPIQPS: <QPS>
ラベルを使用してワーカーのマシン設定プールを更新します。
$ oc label machineconfigpool worker custom-kubelet=large-pods
KubeletConfig
オブジェクトを作成します。$ oc create -f change-maxPods-cr.yaml
KubeletConfig
オブジェクトが作成されていることを確認します。$ oc get kubeletconfig
出力例
NAME AGE set-max-pods 15m
クラスター内のワーカーノードの数によっては、ワーカーノードが 1 つずつ再起動されるのを待機します。3 つのワーカーノードを持つクラスターの場合は、10 分 から 15 分程度かかる可能性があります。
変更がノードに適用されていることを確認します。
maxPods
値が変更されたワーカーノードで確認します。$ oc describe node <node_name>
Allocatable
スタンザを見つけます。... Allocatable: attachable-volumes-gce-pd: 127 cpu: 3500m ephemeral-storage: 123201474766 hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 14225400Ki pods: 500 1 ...
- 1
- この例では、
pods
パラメーターはKubeletConfig
オブジェクトに設定した値を報告するはずです。
KubeletConfig
オブジェクトの変更を確認します。$ oc get kubeletconfigs set-max-pods -o yaml
これは、以下の例のように
True
およびtype:Success
のステータスを表示します。spec: kubeletConfig: maxPods: 500 machineConfigPoolSelector: matchLabels: custom-kubelet: set-max-pods status: conditions: - lastTransitionTime: "2021-06-30T17:04:07Z" message: Success status: "True" type: Success
4.4.2. CRI-O パラメーターを編集するための ContainerRuntimeConfig CR の作成
特定のマシン設定プール (MCP) に関連付けられたノードの OpenShift Container Platform CRI-O ランタイムに関連付けられる設定の一部を変更することができます。ContainerRuntimeConfig
カスタムリソース (CR) を使用して、設定値を設定し、MCP に一致するラベルを追加します。次に、MCO は関連付けられたノードで crio.conf
および storage.conf
設定ファイルを更新された値を使用して再ビルドします。
ContainerRuntimeConfig
CR を使用して実装された変更を元に戻すには、CR を削除する必要があります。マシン設定プールからラベルを削除しても、変更は元に戻されません。
ContainerRuntimeConfig
CR を使用して以下の設定を変更することができます。
-
PIDs limit:
pidsLimit
パラメーターは、コンテナーで許可されるプロセスの最大数である CRI-Opids_limit
パラメーターを設定します。デフォルトは 1024 (pids_limit = 1024
) です。 -
Log level:
logLevel
パラメーターは CRI-Olog_level
パラメーターを設定します。これはログメッセージの詳細レベルです。デフォルトはinfo
(log_level = info
) です。他のオプションには、fatal
、panic
、error
、warn
、debug
、およびtrace
が含まれます。 -
Overlay size:
overlaySize
パラメーターは、コンテナーイメージの最大サイズである CRI-O Overlay ストレージドライバーのsize
パラメーターを設定します。 -
Maximum log size:
logSizeMax
パラメーターは CRI-Olog_size_max
パラメーターを設定します。これは、コンテナーログファイルに許可される最大サイズです。デフォルトは無制限 (log_size_max = -1
) です。これが正数に設定される場合、8192 以上にする必要があり、ConMon の読み取りバッファーよりも小さくすることはできません。ConMon は、単一コンテナーのコンテナーマネージャー (Podman、CRI-O など) と OCI ランタイム (runc または crun など) との間の通信を監視するプログラムです。
マシン設定プールごとに、そのプールに加える設定変更をすべて含めて、ContainerRuntimeConfig
CR を 1 つ割り当てる必要があります。同じコンテンツをすべてのプールに適用している場合には、すべてのプールに必要となるのは ContainerRuntimeConfig
CR 1 つだけです。
既存の ContainerRuntimeConfig
CR を編集して既存の設定を編集するか、変更ごとに新規 CR を作成する代わりに新規の設定を追加する必要があります。異なるマシン設定プールを変更する場合や、変更が一時的で元に戻すことができる場合のみ、新しい ContainerRuntimeConfig
CR の作成を推奨しています。
必要に応じて複数の ContainerRuntimeConfig
CR を作成できます。この場合、制限はクラスターごとに 10 個となっています。最初の ContainerRuntimeConfig
CR について、MCO は containerruntime
で追加されたマシン設定を作成します。それぞれの後続の CR で、コントローラーは数字の接尾辞が付いた新規の containerruntime
マシン設定を作成します。たとえば、containerruntime
マシン設定に -2
接尾辞がある場合、次の containerruntime
マシン設定が -3
を付けて追加されます。
マシン設定を削除する場合、制限を超えないようにそれらを逆の順序で削除する必要があります。たとえば、containerruntime-3
マシン設定を、containerruntime-2
マシン設定を削除する前に削除する必要があります。
接尾辞が containerruntime-9
のマシン設定があり、別の ContainerRuntimeConfig
CR を作成する場合には、containerruntime
マシン設定が 10 未満の場合でも新規マシン設定は作成されません。
複数の ContainerRuntimeConfig
CR を示す例
$ oc get ctrcfg
出力例
NAME AGE ctr-pid 24m ctr-overlay 15m ctr-level 5m45s
複数の containerruntime
マシン設定を示す例
$ oc get mc | grep container
出力例
... 01-master-container-runtime b5c5119de007945b6fe6fb215db3b8e2ceb12511 3.2.0 57m ... 01-worker-container-runtime b5c5119de007945b6fe6fb215db3b8e2ceb12511 3.2.0 57m ... 99-worker-generated-containerruntime b5c5119de007945b6fe6fb215db3b8e2ceb12511 3.2.0 26m 99-worker-generated-containerruntime-1 b5c5119de007945b6fe6fb215db3b8e2ceb12511 3.2.0 17m 99-worker-generated-containerruntime-2 b5c5119de007945b6fe6fb215db3b8e2ceb12511 3.2.0 7m26s ...
以下の例では、pids_limit
を 2048 に引き上げ、log_level
を debug
に設定し、オーバーレイサイズを 8 GB に設定し、log_size_max
を無制限に設定します。
ContainerRuntimeConfig
CR の例
apiVersion: machineconfiguration.openshift.io/v1 kind: ContainerRuntimeConfig metadata: name: overlay-size spec: machineConfigPoolSelector: matchLabels: pools.operator.machineconfiguration.openshift.io/worker: '' 1 containerRuntimeConfig: pidsLimit: 2048 2 logLevel: debug 3 overlaySize: 8G 4 logSizeMax: "-1" 5
手順
ContainerRuntimeConfig
CR を使用して CRI-O 設定を変更するには、以下を実行します。
ContainerRuntimeConfig
CR の YAML ファイルを作成します。apiVersion: machineconfiguration.openshift.io/v1 kind: ContainerRuntimeConfig metadata: name: overlay-size spec: machineConfigPoolSelector: matchLabels: pools.operator.machineconfiguration.openshift.io/worker: '' 1 containerRuntimeConfig: 2 pidsLimit: 2048 logLevel: debug overlaySize: 8G logSizeMax: "-1"
ContainerRuntimeConfig
CR を作成します。$ oc create -f <file_name>.yaml
CR が作成されたことを確認します。
$ oc get ContainerRuntimeConfig
出力例
NAME AGE overlay-size 3m19s
新規の
containerruntime
マシン設定が作成されていることを確認します。$ oc get machineconfigs | grep containerrun
出力例
99-worker-generated-containerruntime 2c9371fbb673b97a6fe8b1c52691999ed3a1bfc2 3.2.0 31s
すべてが準備状態にあるものとして表示されるまでマシン設定プールをモニターします。
$ oc get mcp worker
出力例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE worker rendered-worker-169 False True False 3 1 1 0 9h
設定が CRI-O で適用されたことを確認します。
マシン設定プールのノードに対して
oc debug
セッションを開き、chroot /host
を実行します。$ oc debug node/<node_name>
sh-4.4# chroot /host
crio.conf
ファイルの変更を確認します。sh-4.4# crio config | egrep 'log_level|pids_limit|log_size_max'
出力例
pids_limit = 2048 log_size_max = -1 log_level = "debug"
'storage.conf' ファイルの変更を確認します。
sh-4.4# head -n 7 /etc/containers/storage.conf
出力例
[storage] driver = "overlay" runroot = "/var/run/containers/storage" graphroot = "/var/lib/containers/storage" [storage.options] additionalimagestores = [] size = "8G"
4.4.3. CRI-O を使用した Overlay のデフォルトのコンテナールートパーティションの最大サイズの設定
各コンテナーのルートパーティションには、基礎となるホストの利用可能なディスク領域がすべて表示されます。以下のガイダンスに従って、すべてのコンテナーのルートディスクの最大サイズを設定します。
Overlay の最大サイズ、およびログレベルや PID 制限などの他の CRI-O オプションを設定するには、以下の ContainerRuntimeConfig
カスタムリソース定義 (CRD) を作成できます。
apiVersion: machineconfiguration.openshift.io/v1 kind: ContainerRuntimeConfig metadata: name: overlay-size spec: machineConfigPoolSelector: matchLabels: custom-crio: overlay-size containerRuntimeConfig: pidsLimit: 2048 logLevel: debug overlaySize: 8G
手順
設定オブジェクトを作成します。
$ oc apply -f overlaysize.yml
新規の CRI-O 設定をワーカーノードに適用するには、ワーカーのマシン設定プールを編集します。
$ oc edit machineconfigpool worker
ContainerRuntimeConfig
CRD に設定したmatchLabels
名に基づいてcustom-crio
ラベルを追加します。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: creationTimestamp: "2020-07-09T15:46:34Z" generation: 3 labels: custom-crio: overlay-size machineconfiguration.openshift.io/mco-built-in: ""
変更を保存して、マシン設定を表示します。
$ oc get machineconfigs
新規の
99-worker-generated-containerruntime
およびrendered-worker-xyz
オブジェクトが作成されます。出力例
99-worker-generated-containerruntime 4173030d89fbf4a7a0976d1665491a4d9a6e54f1 3.2.0 7m42s rendered-worker-xyz 4173030d89fbf4a7a0976d1665491a4d9a6e54f1 3.2.0 7m36s
これらのオブジェクトの作成後に、変更が適用されるようにマシン設定プールを監視します。
$ oc get mcp worker
ワーカーノードには、マシン数、更新数およびその他の詳細と共に
UPDATING
がTrue
として表示されます。出力例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE worker rendered-worker-xyz False True False 3 2 2 0 20h
完了すると、ワーカーノードは
UPDATING
をFalse
に戻し、UPDATEDMACHINECOUNT
数はMACHINECOUNT
に一致します。出力例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE worker rendered-worker-xyz True False False 3 3 3 0 20h
ワーカーマシンを見ると、新規の 8 GB の最大サイズの設定がすべてのワーカーに適用されていることを確認できます。
出力例
head -n 7 /etc/containers/storage.conf [storage] driver = "overlay" runroot = "/var/run/containers/storage" graphroot = "/var/lib/containers/storage" [storage.options] additionalimagestores = [] size = "8G"
コンテナー内では、ルートパーティションが 8 GB であることを確認できます。
出力例
~ $ df -h Filesystem Size Used Available Use% Mounted on overlay 8.0G 8.0K 8.0G 0% /