2.3. MCO 関連のカスタムリソースの設定
MCO は MachineConfig オブジェクトを管理する以外にも、2 つのカスタムリソース (CR)(KubeletConfig および ContainerRuntimeConfig) を管理します。これらの CR を使用すると、Kubelet および CRI-O コンテナーランタイムサービスの動作に影響を与えるノードレベルの設定を変更することができます。
2.3.1. kubelet パラメーターを編集するための KubeletConfig CRD の作成
kubelet 設定は、現時点で Ignition 設定としてシリアル化されているため、直接編集することができます。ただし、新規の kubelet-config-controller も Machine Config Controller (MCC) に追加されます。これにより、KubeletConfig カスタムリソース (CR) を作成して kubelet パラメーターを編集することができます。
kubeletConfig オブジェクトのフィールドはアップストリーム Kubernetes から kubelet に直接渡されるため、kubelet はそれらの値を直接検証します。kubeletConfig オブジェクトに無効な値により、クラスターノードが利用できなくなります。有効な値は、Kubernetes ドキュメント を参照してください。
手順
これは、選択可能なマシン設定オブジェクトを表示します。
$ oc get machineconfig
デフォルトで、2 つの kubelet 関連の設定である
01-master-kubeletおよび01-worker-kubeletを選択できます。ノードあたりの最大 Pod の現在の値を確認するには、以下を実行します。
# oc describe node <node-ip> | grep Allocatable -A6
value: pods: <value>を検索します。以下は例になります。
# oc describe node ip-172-31-128-158.us-east-2.compute.internal | grep Allocatable -A6
出力例
Allocatable: attachable-volumes-aws-ebs: 25 cpu: 3500m hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 15341844Ki pods: 250
ワーカーノードでノードあたりの最大の Pod を設定するには、kubelet 設定を含むカスタムリソースファイルを作成します。たとえば、
change-maxPods-cr.yamlを使用します。apiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig metadata: name: set-max-pods spec: machineConfigPoolSelector: matchLabels: custom-kubelet: large-pods kubeletConfig: maxPods: 500kubelet が 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: large-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
これにより
set-max-podsが返されるはずです。クラスター内のワーカーノードの数によっては、ワーカーノードが 1 つずつ再起動されるのを待機します。3 つのワーカーノードを持つクラスターの場合は、10 分 から 15 分程度かかる可能性があります。
ワーカーノードを変更する
maxPodsの有無を確認します。$ oc describe node
以下を実行して変更を確認します。
$ oc get kubeletconfigs set-max-pods -o yaml
これは
Trueとtype:Successのステータスを表示します。
手順
デフォルトでは、kubelet 関連の設定を利用可能なワーカーノードに適用する場合に 1 つのマシンのみを利用不可の状態にすることが許可されます。大規模なクラスターの場合、設定の変更が反映されるまでに長い時間がかかる可能性があります。プロセスのスピードを上げるためにマシン数の調整をいつでも実行することができます。
workerマシン設定プールを編集します。$ oc edit machineconfigpool worker
maxUnavailableを必要な値に設定します。spec: maxUnavailable: <node_count>
重要値を設定する際に、クラスターで実行されているアプリケーションに影響を与えずに利用不可にできるワーカーノードの数を検討してください。