インストール後の設定

手順

1. 各マシン設定プール (MCP) のクラスターで使用可能な MCO 管理ノードの数を確認するには、次のコマンドを実行します。

   $ oc get machineconfigpool

   出力例

   NAME      CONFIG                    UPDATED  UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT  AGE
   master    rendered-master-06c9c4…   True     False      False     3             3                  3                   0                     4h42m
   worker    rendered-worker-f4b64…    False    True       False     3             2                  2                   0                     4h42m

   ここでは、以下のようになります。

   UPDATED

   True ステータスは、MCO が現在のマシン設定をその MCP のノードに適用したことを示します。現在のマシン設定は、oc get mcp 出力の STATUS フィールドに指定されています。False ステータスは、MCP 内のノードが更新中であることを示します。

   UPDATING

   True ステータスは、MCO が、MachineConfigPool カスタムリソースで指定された目的のマシン設定を、その MCP 内の少なくとも 1 つのノードに適用していることを示します。目的のマシン設定は、新しく編集されたマシン設定です。更新中のノードは、スケジューリングに使用できない場合があります。False ステータスは、MCP 内のすべてのノードが更新されたことを示します。

   DEGRADED

   True ステータスは、MCO がその MCP 内の少なくとも 1 つのノードに現在のまたは目的のマシン設定を適用することをブロックされているか、設定が失敗していることを示します。機能が低下したノードは、スケジューリングに使用できない場合があります。False ステータスは、MCP 内のすべてのノードの準備ができていることを示します。

   MACHINECOUNT

   その MCP 内のマシンの総数を示します。

   READYMACHINECOUNT

   スケジューリングの準備ができているその MCP 内のマシンの総数を示します。

   UPDATEDMACHINECOUNT

   現在のマシン設定を持つ MCP 内のマシンの総数を示します。

   DEGRADEDMACHINECOUNT

   機能低下または調整不能としてマークされている、その MCP 内のマシンの総数を示します。

   前の出力では、3 つのコントロールプレーン (マスター) ノードと 3 つのワーカーノードがあります。コントロールプレーン MCP と関連するノードは、現在のマシン設定に更新されます。ワーカー MCP のノードは、目的のマシン設定に更新されています。UPDATEDMACHINECOUNT が 2 であることからわかるように、ワーカー MCP 内の 2 つのノードが更新され、1 つがまだ更新中です。DEGRADEDDMACHINECOUNT が 0 で、DEGRADE が False であることからわかるように、問題はありません。

   MCP のノードが更新されている間、CONFIG の下にリストされているマシン設定は、MCP の更新元である現在のマシン設定です。更新が完了すると、リストされたマシン設定は、MCP が更新された目的のマシン設定になります。

   注記

   ノードが遮断されている場合、そのノードは READYMACHINECOUNT には含まれませんが、MACHINECOUNT には含まれます。また、MCP ステータスは UPDATING に設定されます。ノードには現在のマシン設定があるため、UPDATEDMACHINECOUNT の合計にカウントされます。

   出力例

   NAME      CONFIG                    UPDATED  UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT  AGE
   master    rendered-master-06c9c4…   True     False      False     3             3                  3                   0                     4h42m
   worker    rendered-worker-c1b41a…   False    True       False     3             2                  3                   0                     4h42m

2. MachineConfigPool カスタムリソースを調べて MCP 内のノードのステータスを確認するには、次のコマンドを実行します。

   $ oc describe mcp worker

   出力例

   ...
     Degraded Machine Count:     0
     Machine Count:              3
     Observed Generation:        2
     Ready Machine Count:        3
     Unavailable Machine Count:  0
     Updated Machine Count:      3
   Events:                       <none>

   注記

   ノードが遮断されている場合、そのノードは Ready Machine Count に含まれません。Unavailable Machine Count に含まれます。

   出力例

   ...
     Degraded Machine Count:     0
     Machine Count:              3
     Observed Generation:        2
     Ready Machine Count:        2
     Unavailable Machine Count:  1
     Updated Machine Count:      3

3. 既存の各 MachineConfig オブジェクトを表示するには、次のコマンドを実行します。

   $ oc get machineconfigs

   出力例

   NAME                             GENERATEDBYCONTROLLER          IGNITIONVERSION  AGE
   00-master                        2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
   00-worker                        2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
   01-master-container-runtime      2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
   01-master-kubelet                2c9371fbb673b97a6fe8b1c52…     3.2.0            5h18m
   ...
   rendered-master-dde...           2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
   rendered-worker-fde...           2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m

   rendered として一覧表示された MachineConfig オブジェクトが変更されたり、削除されたりすることが意図されていないことに注意してください。

4. 特定のマシン設定 (この場合は 01-master-kubelet) の内容を表示するには、次のコマンドを実行します。

   $ oc describe machineconfigs 01-master-kubelet

   コマンドの出力は、この MachineConfig オブジェクトに設定ファイル (cloud.conf および kubelet.conf) と systemd サービス (Kubernetes Kubelet) の両方が含まれていることを示しています。

   出力例

   Name:         01-master-kubelet
   ...
   Spec:
     Config:
       Ignition:
         Version:  3.1.0
       Storage:
         Files:
           Contents:
             Source:   data:,
           Mode:       420
           Overwrite:  true
           Path:       /etc/kubernetes/cloud.conf
           Contents:
             Source:   data:,kind%3A%20KubeletConfiguration%0AapiVersion%3A%20kubelet.config.k8s.io%2Fv1beta1%0Aauthentication%3A%0A%20%20x509%3A%0A%20%20%20%20clientCAFile%3A%20%2Fetc%2Fkubernetes%2Fkubelet-ca.crt%0A%20%20anonymous...
           Mode:       420
           Overwrite:  true
           Path:       /etc/kubernetes/kubelet.conf
       Systemd:
         Units:
           Contents:  [Unit]
   Description=Kubernetes Kubelet
   Wants=rpc-statd.service network-online.target crio.service
   After=network-online.target crio.service
   
   ExecStart=/usr/bin/hyperkube \
       kubelet \
         --config=/etc/kubernetes/kubelet.conf \ ...

手順

1. chrony.conf ファイルのコンテンツを作成し、これを base64 でエンコードします。以下に例を示します。

   $ cat << EOF | base64
       pool 0.rhel.pool.ntp.org iburst 1
       driftfile /var/lib/chrony/drift
       makestep 1.0 3
       rtcsync
       logdir /var/log/chrony
   EOF

   1

   DHCP サーバーが提供するものなど、有効な到達可能なタイムソースを指定します。または、NTP サーバーの 1.rhel.pool.ntp.org、2.rhel.pool.ntp.org、または 3.rhel.pool.ntp.org のいずれかを指定できます。

   出力例

   ICAgIHNlcnZlciBjbG9jay5yZWRoYXQuY29tIGlidXJzdAogICAgZHJpZnRmaWxlIC92YXIvbGli
   L2Nocm9ueS9kcmlmdAogICAgbWFrZXN0ZXAgMS4wIDMKICAgIHJ0Y3N5bmMKICAgIGxvZ2RpciAv
   dmFyL2xvZy9jaHJvbnkK

2. MachineConfig ファイルを作成します。base64 文字列を独自に作成した文字列に置き換えます。この例では、ファイルを master ノードに追加します。これを worker に切り替えたり、worker ロールの追加の MachineConfig を作成したりできます。クラスターが使用するそれぞれのタイプのマシンについて MachineConfig ファイルを作成します。

   $ cat << EOF > ./99-masters-chrony-configuration.yaml
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 99-masters-chrony-configuration
   spec:
     config:
       ignition:
         config: {}
         security:
           tls: {}
         timeouts: {}
         version: 3.1.0
       networkd: {}
       passwd: {}
       storage:
         files:
         - contents:
             source: data:text/plain;charset=utf-8;base64,ICAgIHNlcnZlciBjbG9jay5yZWRoYXQuY29tIGlidXJzdAogICAgZHJpZnRmaWxlIC92YXIvbGliL2Nocm9ueS9kcmlmdAogICAgbWFrZXN0ZXAgMS4wIDMKICAgIHJ0Y3N5bmMKICAgIGxvZ2RpciAvdmFyL2xvZy9jaHJvbnkK
           mode: 420 1
           overwrite: true
           path: /etc/chrony.conf
     osImageURL: ""
   EOF

   1

   マシン設定ファイルの mode フィールドに 8 進数の値でモードを指定します。ファイルを作成し、変更を適用すると、mode は 10 進数の値に変換されます。コマンド oc get mc <mc-name> -o yaml で YAML ファイルを確認できます。

3. 設定ファイルのバックアップコピーを作成します。

4. 以下の 2 つの方法のいずれかで設定を適用します。

   • クラスターがまだ起動していない場合は、マニフェストファイルを生成した後に、そのファイルを <installation_directory>/openshift ディレクトリーに追加してから、クラスターの作成を継続します。

   • クラスターがすでに実行中の場合は、ファイルを適用します。

     $ oc apply -f ./99-masters-chrony-configuration.yaml

手順

1. OpenShift Container Platform クラスターの既存の MachineConfig を一覧表示し、マシン設定にラベルを付ける方法を判別します。

   $ oc get MachineConfig

   出力例

    NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
    00-master                                          5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    00-worker                                          5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    01-master-container-runtime                        5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    01-master-kubelet                                  5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    01-worker-container-runtime                        5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    01-worker-kubelet                                  5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    99-master-generated-registries                     5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    99-master-ssh                                                                                 3.1.0             77m
    99-worker-generated-registries                     5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    99-worker-ssh                                                                                 3.1.0             77m
    rendered-master-0f314bb55448c47e6776e16e608c5912   5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             42m
    rendered-master-c7761e6162e6c9538b0cdd7eef567d38   5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m

2. カーネル引数を識別する MachineConfig オブジェクトファイルを作成します (例: 05-worker-kernelarg-selinuxpermissive.yaml)。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker1
     name: 05-worker-kernelarg-selinuxpermissive2
   spec:
     config:
       ignition:
         version: 3.1.0
     kernelArguments:
       - enforcing=03

   1

   新しいカーネル引数をワーカーノードのみに適用します。

   2

   マシン設定 (05) 内の適切な場所を特定するための名前が指定されます (SELinux permissive モードを設定するためにカーネル引数を追加します)。

   3

   正確なカーネル引数を enforcing=0 として特定します。

3. 新規のマシン設定を作成します。

   $ oc create -f 05-worker-kernelarg-selinuxpermissive.yaml

4. マシン設定で新規の追加内容を確認します。

   $ oc get MachineConfig

   出力例

    NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
    00-master                                          5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    00-worker                                          5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    01-master-container-runtime                        5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    01-master-kubelet                                  5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    01-worker-container-runtime                        5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    01-worker-kubelet                                  5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
   
    05-worker-kernelarg-selinuxpermissive                                                         3.1.0             105s
   
    99-master-generated-registries                     5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    99-master-ssh                                                                                 3.1.0             77m
    99-worker-generated-registries                     5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    99-worker-ssh                                                                                 3.1.0             77m
    rendered-master-0f314bb55448c47e6776e16e608c5912   5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             42m
    rendered-master-c7761e6162e6c9538b0cdd7eef567d38   5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m

5. ノードを確認します。

   $ oc get nodes

   出力例

   NAME                           STATUS                     ROLES    AGE   VERSION
   ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.19.0
   ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.19.0
   ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.19.0
   ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.19.0
   ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.19.0
   ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.19.0

   変更が適用されているため、各ワーカーノードのスケジューリングが無効にされていることを確認できます。

6. ワーカーノードのいずれかに移動し、カーネルコマンドライン引数 (ホストの /proc/cmdline 内) を一覧表示して、カーネル引数が機能することを確認します。

   $ oc debug node/ip-10-0-141-105.ec2.internal

   出力例

   Starting pod/ip-10-0-141-105ec2internal-debug ...
   To use host binaries, run `chroot /host`
   
   sh-4.2# cat /host/proc/cmdline
   BOOT_IMAGE=/ostree/rhcos-... console=tty0 console=ttyS0,115200n8
   rootflags=defaults,prjquota rw root=UUID=fd0... ostree=/ostree/boot.0/rhcos/16...
   coreos.oem.id=qemu coreos.oem.id=ec2 ignition.platform.id=ec2 enforcing=0
   
   sh-4.2# exit

   enforcing=0 引数が他のカーネル引数に追加されていることを確認できるはずです。

手順

1. リアルタイムカーネルのマシン設定を作成します。realtime カーネルタイプの MachineConfig オブジェクトが含まれる YAML ファイル (99-worker-realtime.yaml など) を作成します。以下の例では、すべてのワーカーノードにリアルタイムカーネルを使用するようにクラスターに指示します。

   $ cat << EOF > 99-worker-realtime.yaml
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: "worker"
     name: 99-worker-realtime
   spec:
     kernelType: realtime
   EOF

2. マシン設定をクラスターに追加します。以下を入力してマシン設定をクラスターに追加します。

   $ oc create -f 99-worker-realtime.yaml

3. リアルタイムカーネルを確認します。影響を受けるそれぞれのノードの再起動後に、クラスターにログインして以下のコマンドを実行し、リアルタイムカーネルが設定されたノードのセットの通常のカーネルを置き換えていることを確認します。

   $ oc get nodes

   出力例

   NAME                                        STATUS  ROLES    AGE   VERSION
   ip-10-0-143-147.us-east-2.compute.internal  Ready   worker   103m  v1.19.0
   ip-10-0-146-92.us-east-2.compute.internal   Ready   worker   101m  v1.19.0
   ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.19.0

   $ oc debug node/ip-10-0-143-147.us-east-2.compute.internal

   出力例

   Starting pod/ip-10-0-143-147us-east-2computeinternal-debug ...
   To use host binaries, run `chroot /host`
   
   sh-4.4# uname -a
   Linux <worker_node> 4.18.0-147.3.1.rt24.96.el8_1.x86_64 #1 SMP PREEMPT RT
           Wed Nov 27 18:29:55 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

   カーネル名には rt が含まれ、PREEMPT RT のテキストは、これがリアルタイムカーネルであることを示します。

4. 通常のカーネルに戻るには、MachineConfig オブジェクトを削除します。

   $ oc delete -f 99-worker-realtime.yaml

手順

1. /etc/systemd/journald.conf ファイルの内容を作成し、これを base64 としてエンコードします。以下に例を示します。

   $ cat > /tmp/jrnl.conf <<EOF
   # Disable rate limiting
   RateLimitInterval=1s
   RateLimitBurst=10000
   Storage=volatile
   Compress=no
   MaxRetentionSec=30s
   EOF

2. 一時的な journal.conf ファイルを base64 に変換し、これを変数 (jrnl_cnf) に保存します。

   $ export jrnl_cnf=$( cat /tmp/jrnl.conf | base64 -w0 )
   $ echo $jrnl_cnf
   IyBEaXNhYmxlIHJhdGUgbGltaXRpbmcKUmF0ZUxpbWl0SW50ZXJ2YWw9MXMKUmF0ZUxpbWl0QnVyc3Q9MTAwMDAKU3RvcmFnZT12b2xhdGlsZQpDb21wcmVzcz1ubwpNYXhSZXRlbnRpb25TZWM9MzBzCg==

3. journald.conf のエンコードされた内容 (jrnl_cnf 変数) を含むマシン設定を作成します。

   $ cat > /tmp/40-worker-custom-journald.yaml <<EOF
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 40-worker-custom-journald
   spec:
     config:
       ignition:
         config: {}
         security:
           tls: {}
         timeouts: {}
         version: 3.1.0
       networkd: {}
       passwd: {}
       storage:
         files:
         - contents:
             source: data:text/plain;charset=utf-8;base64,${jrnl_cnf}
             verification: {}
           filesystem: root
           mode: 420
           path: /etc/systemd/journald.conf
       systemd: {}
     osImageURL: ""
   EOF

4. マシン設定をプールに適用します。

   $ oc apply -f /tmp/40-worker-custom-journald.yaml

5. 新規マシン設定が適用され、ノードの状態が低下した状態にないことを確認します。これには数分の時間がかかる場合があります。各ノードで新規マシン設定が正常に適用されるため、ワーカープールには更新が進行中であることが表示されます。

   $ oc get machineconfigpool
   NAME   CONFIG             UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
   master rendered-master-35 True    False    False    3            3                 3                   0                    34m
   worker rendered-worker-d8 False   True     False    3            1                 1                   0                    34m

6. 変更が適用されたことを確認するには、ワーカーノードにログインします。

   $ oc get node | grep worker
   ip-10-0-0-1.us-east-2.compute.internal   Ready    worker   39m   v0.0.0-master+$Format:%h$
   $ oc debug node/ip-10-0-0-1.us-east-2.compute.internal
   Starting pod/ip-10-0-141-142us-east-2computeinternal-debug ...
   ...
   sh-4.2# chroot /host
   sh-4.4# cat /etc/systemd/journald.conf
   # Disable rate limiting
   RateLimitInterval=1s
   RateLimitBurst=10000
   Storage=volatile
   Compress=no
   MaxRetentionSec=30s
   sh-4.4# exit

手順

1. YAML ファイル (myregistry.yaml) を作成し、そのファイルのエンコードされた base64 コンテンツを含む、 /etc/containers/registries.conf.d/99-worker-unqualified-search-registries.conf ファイルのコンテンツを保持します。以下は例になります。

   $ cat > /tmp/myregistry.yaml <<EOF
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 99-worker-unqualified-search-registries
   spec:
     config:
       ignition:
         version: 3.1.0
       storage:
         files:
         - contents:
             source: data:text/plain;charset=utf-8;base64,dW5xdWFsaWZpZWQtc2VhcmNoLXJlZ2lzdHJpZXMgPSBbJ3JlZ2lzdHJ5LmFjY2Vzcy5yZWRoYXQuY29tJywgJ2RvY2tlci5pbycsICdxdWF5LmlvJ10K
           filesystem: root
           mode: 0644
           path: /etc/containers/registries.conf.d/99-worker-unqualified-search-registries.conf
   EOF

2. マシン設定をプールに適用します。

   $ oc apply -f /tmp/myregistry.yaml

3. 新規マシン設定が適用され、ノードの状態が低下した状態にないことを確認します。これには数分の時間がかかる場合があります。各マシンで新規マシン設定が正常に適用されるため、ワーカープールには更新が進行中であることが表示されます。

   $ oc get machineconfigpool

   出力例

   NAME   CONFIG             UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
   master rendered-master-35 True    False    False    3            3                 3                   0                    34m
   worker rendered-worker-d8 False   True     False    3            1                 1                   0                    34m

4. 変更が適用されたことを確認するには、ワーカーノードにログインします。

   $ oc get node | grep worker

   出力例

   ip-10-0-0-1.us-east-2.compute.internal   Ready    worker   39m   v0.0.0-master+$Format:%h$

   $ oc debug node/ip-10-0-0-1.us-east-2.compute.internal

   出力例

   Starting pod/ip-10-0-141-142us-east-2computeinternal-debug ...
   ...

   sh-4.2# chroot /host
   sh-4.4# cat /etc/containers/registries.conf.d/99-worker-unqualified-search-registries.conf
   unqualified-search-registries = ['registry.access.redhat.com', 'docker.io', 'quay.io']
   sh-4.4# exit

手順

1. 拡張機能のマシン設定を作成します。MachineConfig extensions オブジェクトが含まれる YAML ファイル (例: 80-extensions.yaml) を作成します。この例では、クラスターに対して usbguard 拡張機能を追加するように指示します。

   $ cat << EOF > 80-extensions.yaml
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 80-worker-extensions
   spec:
     config:
       ignition:
         version: 3.1.0
     extensions:
       - usbguard
   EOF

2. マシン設定をクラスターに追加します。以下を入力してマシン設定をクラスターに追加します。

   $ oc create -f 80-extensions.yaml

   これにより、すべてのワーカーノードで usbguard の rpm パッケージがインストールされるように設定できます。

3. 拡張機能が適用されていることを確認します。

   $ oc get machineconfig 80-worker-extensions

   出力例

   NAME                 GENERATEDBYCONTROLLER IGNITIONVERSION AGE
   80-worker-extensions                       3.1.0           57s

4. 新規マシン設定が適用され、ノードの状態が低下した状態にないことを確認します。これには数分の時間がかかる場合があります。各マシンで新規マシン設定が正常に適用されるため、ワーカープールには更新が進行中であることが表示されます。

   $ oc get machineconfigpool

   出力例

   NAME   CONFIG             UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
   master rendered-master-35 True    False    False    3            3                 3                   0                    34m
   worker rendered-worker-d8 False   True     False    3            1                 1                   0                    34m

5. 拡張機能を確認します。拡張機能が適用されたことを確認するには、以下を実行します。

   $ oc get node | grep worker

   出力例

   NAME                                        STATUS  ROLES    AGE   VERSION
   ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.18.3

   $ oc debug node/ip-10-0-169-2.us-east-2.compute.internal

   出力例

   ...
   To use host binaries, run `chroot /host`
   sh-4.4# chroot /host
   sh-4.4# rpm -q usbguard
   usbguard-0.7.4-4.el8.x86_64.rpm

手順

1. Butane 設定ファイル 98-worker-firmware-blob.bu を作成します。このファイルは、root 所有でローカルストレージに書き込みできるように、検索パスを更新します。以下の例では、カスタムブロブファイルをローカルワークステーションからノードの /var/lib/firmware 下に配置しています。

   注記

   Butane の詳細は、Butane を使用したマシン設定の作成を参照してください。

   カスタムファームウェアブロブ用の Butane 設定ファイル

   variant: openshift
   version: 4.9.0
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 98-worker-firmware-blob
   storage:
     files:
     - path: /var/lib/firmware/<package_name> 1
       contents:
         local: <package_name> 2
       mode: 0644 3
   openshift:
     kernel_arguments:
       - 'firmware_class.path=/var/lib/firmware' 4

   1

   ファームウェアパッケージのコピー先となるノードのパスを設定します。

   2

   Butane を実行しているシステムのローカルファイルディレクトリーから読み取るコンテンツを含むファイルを指定します。ローカルファイルのパスは files-dir ディレクトリーからの相対パスで、以下の手順の Butane で --files-dir オプションを使用して指定する必要があります。

   3

   RHCOS ノードのファイルのパーミッションを設定します。0644 パーミッションを設定することが推奨されます。

   4

   firmware_class.path パラメーターは、ローカルワークステーションからノードのルートファイルシステムにコピーされたカスタムファームウェアブロブを検索するカーネルの検索パスをカスタマイズします。この例では、/var/lib/firmware をカスタマイズされたパスとして使用します。

2. Butane を実行して、ローカルワークステーション上の98-worker-firmware-blob.yaml という名前のファームウェアブロブのコピーを使用する MachineConfig オブジェクトファイルを生成します。ファームウェアブロブには、ノードに配信される設定が含まれます。次の例では、--files-dir オプションを使用して、ローカルファイルが配置されるワークステーション上のディレクトリーを指定します。

   $ butane 98-worker-firmware-blob.bu -o 98-worker-firmware-blob.yaml --files-dir <directory_including_package_name>

3. 以下の 2 つの方法のいずれかで、設定をノードに適用します。

   • クラスターがまだ起動していない場合は、マニフェストファイルを生成した後に、MachineConfig オブジェクトファイルを <installation_directory>/openshift ディレクトリーに追加してから、クラスターの作成を続行します。

   • クラスターがすでに実行中の場合は、ファイルを適用します。

     $ oc apply -f 98-worker-firmware-blob.yaml

     MachineConfig オブジェクト YAML ファイルは、マシンの設定を終了するために作成されます。

4. 将来的に MachineConfig オブジェクトを更新する必要がある場合に備えて、Butane 設定を保存します。

手順

1. これは、選択可能なマシン設定オブジェクトを表示します。

   $ oc get machineconfig

   デフォルトで、2 つの kubelet 関連の設定である 01-master-kubelet および 01-worker-kubelet を選択できます。

2. ノードあたりの最大 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

3. ワーカーノードでノードあたりの最大の 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: 500

   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: large-pods
     kubeletConfig:
       maxPods: <pod_count>
       kubeAPIBurst: <burst_rate>
       kubeAPIQPS: <QPS>

   1. ラベルを使用してワーカーのマシン設定プールを更新します。

      $ oc label machineconfigpool worker custom-kubelet=large-pods

   2. KubeletConfig オブジェクトを作成します。

      $ oc create -f change-maxPods-cr.yaml

   3. KubeletConfig オブジェクトが作成されていることを確認します。

      $ oc get kubeletconfig

      これにより set-max-pods が返されるはずです。

      クラスター内のワーカーノードの数によっては、ワーカーノードが 1 つずつ再起動されるのを待機します。3 つのワーカーノードを持つクラスターの場合は、10 分 から 15 分程度かかる可能性があります。

4. ワーカーノードを変更する maxPods の有無を確認します。

   $ oc describe node

   1. 以下を実行して変更を確認します。

      $ oc get kubeletconfigs set-max-pods -o yaml

      これは True と type:Success のステータスを表示します。

1. worker マシン設定プールを編集します。

   $ oc edit machineconfigpool worker

2. maxUnavailable を必要な値に設定します。

   spec:
     maxUnavailable: <node_count>

   重要

   値を設定する際に、クラスターで実行されているアプリケーションに影響を与えずに利用不可にできるワーカーノードの数を検討してください。

手順

1. pidsLimit を 2048 に引き上げるには、 logLevel を debug に、 overlaySize を 8 GB に設定し、その設定が含まれる CR ファイル (例: overlay-size.yaml) を作成します。

   $ cat << EOF > /tmp/overlay-size.yaml
   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
   EOF

2. ContainerRuntimeConfig オブジェクト設定を適用するには、以下を実行します。

   $ oc create -f /tmp/overlay-size.yaml

3. YAML ファイルが設定を適用したことを確認するには、次のコマンドを実行します。

   $ oc get ContainerRuntimeConfig
   NAME           AGE
   overlay-size   3m19s

4. worker などのマシンのプールを編集するには、以下のコマンドを実行してマシン設定プールを開きます。

   $ oc edit machineconfigpool worker

5. 新規 containerruntime オブジェクトが machineconfigs の下に表示されることを確認します。

   $ oc get machineconfigs | grep containerrun
   99-worker-generated-containerruntime   2c9371fbb673b97a6fe8b1c52691999ed3a1bfc2  3.1.0  31s

6. すべてが準備状態になるまで、マシンに展開される変更についてマシン設定プールをモニターします。

   $ 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

7. ワーカーノードに対して oc debug セッションを開き、chroot/host を実行します。

8. 以下を実行して変更を確認します。

   $ crio config | egrep 'log_level|pids_limit'

   出力例

   pids_limit = 2048
   log_level = "debug"

   $ 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"

手順

1. 設定オブジェクトを作成します。

   $ oc apply -f overlaysize.yml

2. 新規の CRI-O 設定をワーカーノードに適用するには、ワーカーのマシン設定プールを編集します。

   $ oc edit machineconfigpool worker

3. 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: ""

4. 変更を保存して、マシン設定を表示します。

   $ oc get machineconfigs

   新規の 99-worker-generated-containerruntime および rendered-worker-xyz オブジェクトが作成されます。

   出力例

   99-worker-generated-containerruntime  4173030d89fbf4a7a0976d1665491a4d9a6e54f1   2.2.0             7m42s
   rendered-worker-xyz                   4173030d89fbf4a7a0976d1665491a4d9a6e54f1   2.2.0             7m36s

5. これらのオブジェクトの作成後に、変更が適用されるようにマシン設定プールを監視します。

   $ 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% /

手順

1. クラスターにあるマシンセットを表示します。

   $ oc get machinesets -n openshift-machine-api

   マシンセットは <clusterid>-worker-<aws-region-az> の形式で一覧表示されます。

2. クラスター内にあるマシンを表示します。

   $ oc get machine -n openshift-machine-api

3. 削除するマシンに注釈を設定します。

   $ oc annotate machine/<machine_name> -n openshift-machine-api machine.openshift.io/cluster-api-delete-machine="true"

4. 削除するノードを分離して解放します。

   $ oc adm cordon <node_name>
   $ oc adm drain <node_name>

5. マシンセットをスケーリングします。

   $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

   または、以下を実行します。

   $ oc edit machineset <machineset> -n openshift-machine-api

   マシンセットをスケールアップまたはスケールダウンできます。新規マシンが利用可能になるまで数分の時間がかかります。

1. スケジューラー Operator CR を編集して、デフォルトのクラスタースコープのノードクラスターを追加します。

   $ oc edit scheduler cluster

   ノードセレクターを含むスケジューラー Operator CR のサンプル

   apiVersion: config.openshift.io/v1
   kind: Scheduler
   metadata:
     name: cluster
   ...
   
   spec:
     defaultNodeSelector: type=user-node,region=east 1
     mastersSchedulable: false
     policy:
       name: ""

   1

   適切な <key>:<value> ペアが設定されたノードセレクターを追加します。

   この変更を加えた後に、openshift-kube-apiserver プロジェクトの Pod の再デプロイを待機します。これには数分の時間がかかる場合があります。デフォルトのクラスター全体のノードセレクターは、Pod の再起動まで有効になりません。

2. マシンセットを使用するか、またはノードを直接編集してラベルをノードに追加します。

   • マシンセットを使用して、ノードの作成時にマシンセットによって管理されるノードにラベルを追加します。

     1. 以下のコマンドを実行してラベルを MachineSet オブジェクトに追加します。

        $ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api 1

        1

        それぞれのラベルに <key> /<value> ペアを追加します。

        以下に例を示します。

        $ oc patch MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

     2. oc edit コマンドを使用して、ラベルが MachineSet オブジェクトに追加されていることを確認します。

        以下に例を示します。

        $ oc edit MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

        出力例

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
        metadata:
        ...
        spec:
        ...
          template:
            metadata:
        ...
            spec:
              metadata:
                labels:
                  region: east
                  type: user-node

     3. 0 にスケールダウンし、ノードをスケールアップして、そのマシンセットに関連付けられたノードを再デプロイします。

        以下に例を示します。

        $ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

        $ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

     4. ノードの準備ができ、利用可能な状態になったら、oc get コマンドを使用してラベルがノードに追加されていることを確認します。

        $ oc get nodes -l <key>=<value>

        以下に例を示します。

        $ oc get nodes -l type=user-node

        出力例

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.18.3+002a51f

   • ラベルをノードに直接追加します。

     1. ノードの Node オブジェクトを編集します。

        $ oc label nodes <name> <key>=<value>

        たとえば、ノードにラベルを付けるには、以下を実行します。

        $ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 type=user-node region=east

     2. oc get コマンドを使用して、ラベルがノードに追加されていることを確認します。

        $ oc get nodes -l <key>=<value>,<key>=<value>

        以下に例を示します。

        $ oc get nodes -l type=user-node,region=east

        出力例

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.18.3+002a51f

手順

1. 説明されているようにマシンセット カスタムリソース (CR) サンプルを含む新規 YAML ファイルを作成し、そのファイルに <file_name>.yaml という名前を付けます。

   <clusterID> および <role> パラメーターの値を設定していることを確認します。

   1. 特定のフィールドに設定する値が不明な場合は、クラスターから既存のマシンセットを確認できます。

      $ oc get machinesets -n openshift-machine-api

      出力例

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
      agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1d   0         0                             55m
      agl030519-vplxk-worker-us-east-1e   0         0                             55m
      agl030519-vplxk-worker-us-east-1f   0         0                             55m

   2. 特定のマシンセットの値を確認します。

      $ oc get machineset <machineset_name> -n \
           openshift-machine-api -o yaml

      出力例

      ...
      template:
          metadata:
            labels:
              machine.openshift.io/cluster-api-cluster: agl030519-vplxk 1
              machine.openshift.io/cluster-api-machine-role: worker 2
              machine.openshift.io/cluster-api-machine-type: worker
              machine.openshift.io/cluster-api-machineset: agl030519-vplxk-worker-us-east-1a

      1

      クラスター ID。

      2

      デフォルトのノードラベル。

2. 新規 MachineSet CR を作成します。

   $ oc create -f <file_name>.yaml

3. マシンセットの一覧を表示します。

   $ oc get machineset -n openshift-machine-api

   出力例

   NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
   agl030519-vplxk-infra-us-east-1a    1         1         1       1           11m
   agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
   agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
   agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
   agl030519-vplxk-worker-us-east-1d   0         0                             55m
   agl030519-vplxk-worker-us-east-1e   0         0                             55m
   agl030519-vplxk-worker-us-east-1f   0         0                             55m

   新規のマシンセットが利用可能な場合、 DESIRED および CURRENT の値は一致します。マシンセットが利用可能でない場合、数分待機してからコマンドを再度実行します。

手順

1. アプリケーションノードとして機能させるワーカーノードにラベルを追加します。

   $ oc label node <node-name> node-role.kubernetes.io/app=""

2. インフラストラクチャーノードとして機能する必要のあるワーカーノードにラベルを追加します。

   $ oc label node <node-name> node-role.kubernetes.io/infra=""

3. 該当するノードに infra ロールおよび app ロールがあるかどうかを確認します。

   $ oc get nodes

4. デフォルトのクラスタースコープのセレクターを作成するには、以下を実行します。デフォルトのノードセレクターはすべての namespace で作成された Pod に適用されます。これにより、Pod の既存のノードセレクターとの交差が作成され、Pod のセレクターをさらに制限します。

   重要

   デフォルトのノードセレクターのキーが Pod のラベルのキーと競合する場合、デフォルトのノードセレクターは適用されません。

   ただし、Pod がスケジュール対象外になる可能性のあるデフォルトノードセレクターを設定しないでください。たとえば、Pod のラベルが node-role.kubernetes.io/master="" などの別のノードロールに設定されている場合、デフォルトのノードセレクターを node-role.kubernetes.io/infra="" などの特定のノードロールに設定すると、Pod がスケジュール不能になる可能性があります。このため、デフォルトのノードセレクターを特定のノードロールに設定する際には注意が必要です。

   または、プロジェクトノードセレクターを使用して、クラスター全体でのノードセレクターの競合を避けることができます。

   1. Scheduler オブジェクトを編集します。

      $ oc edit scheduler cluster

   2. 適切なノードセレクターと共に defaultNodeSelector フィールドを追加します。

      apiVersion: config.openshift.io/v1
      kind: Scheduler
      metadata:
        name: cluster
      ...
      spec:
        defaultNodeSelector: topology.kubernetes.io/region=us-east-1 1
      ...

      1

      このサンプルノードセレクターは、デフォルトで us-east-1 リージョンのノードに Pod をデプロイします。

   3. 変更を適用するためにファイルを保存します。

手順

1. 特定のラベルを持つ infra ノードとして割り当てるノードに、ラベルを追加します。

   $ oc label node <node_name> <label>

   $ oc label node ci-ln-n8mqwr2-f76d1-xscn2-worker-c-6fmtx node-role.kubernetes.io/infra=

2. ワーカーロールとカスタムロールの両方をマシン設定セレクターとして含まれるマシン設定プールを作成します。

   $ cat infra.mcp.yaml

   出力例

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfigPool
   metadata:
     name: infra
   spec:
     machineConfigSelector:
       matchExpressions:
         - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,infra]} 1
     nodeSelector:
       matchLabels:
         node-role.kubernetes.io/infra: "" 2

   1

   ワーカーロールおよびカスタムロールを追加します。

   2

   ノードに追加したラベルを nodeSelector として追加します。

   注記

   カスタムマシン設定プールは、ワーカープールからマシン設定を継承します。カスタムプールは、ワーカープールのターゲット設定を使用しますが、カスタムプールのみをターゲットに設定する変更をデプロイする機能を追加します。カスタムプールはワーカープールから設定を継承するため、ワーカープールへの変更もカスタムプールに適用されます。

3. YAML ファイルを用意した後に、マシン設定プールを作成できます。

   $ oc create -f infra.mcp.yaml

4. マシン設定をチェックして、インフラストラクチャー設定が正常にレンダリングされていることを確認します。

   $ oc get machineconfig

   出力例

   NAME                                                        GENERATEDBYCONTROLLER                      IGNITIONVERSION   CREATED
   00-master                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
   00-worker                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
   01-master-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
   01-master-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
   01-worker-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
   01-worker-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
   99-master-1ae2a1e0-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
   99-master-ssh                                                                                          2.2.0             31d
   99-worker-1ae64748-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
   99-worker-ssh                                                                                          2.2.0             31d
   rendered-infra-4e48906dca84ee702959c71a53ee80e7             365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             19s
   rendered-master-072d4b2da7f88162636902b074e9e28e            5b6fb8349a29735e48446d435962dec4547d3090   2.2.0             31d
   rendered-master-3e88ec72aed3886dec061df60d16d1af            02c07496ba0417b3e12b78fb32baf6293d314f79   2.2.0             31d
   rendered-master-419bee7de96134963a15fdf9dd473b25            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             17d
   rendered-master-53f5c91c7661708adce18739cc0f40fb            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             13d
   rendered-master-a6a357ec18e5bce7f5ac426fc7c5ffcd            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             7d3h
   rendered-master-dc7f874ec77fc4b969674204332da037            5b6fb8349a29735e48446d435962dec4547d3090   2.2.0             31d
   rendered-worker-1a75960c52ad18ff5dfa6674eb7e533d            5b6fb8349a29735e48446d435962dec4547d3090   2.2.0             31d
   rendered-worker-2640531be11ba43c61d72e82dc634ce6            5b6fb8349a29735e48446d435962dec4547d3090   2.2.0             31d
   rendered-worker-4e48906dca84ee702959c71a53ee80e7            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             7d3h
   rendered-worker-4f110718fe88e5f349987854a1147755            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             17d
   rendered-worker-afc758e194d6188677eb837842d3b379            02c07496ba0417b3e12b78fb32baf6293d314f79   2.2.0             31d
   rendered-worker-daa08cc1e8f5fcdeba24de60cd955cc3            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             13d

   新規のマシン設定には、接頭辞 rendered-infra-* が表示されるはずです。

5. オプション: カスタムプールへの変更をデプロイするには、infra などのラベルとしてカスタムプール名を使用するマシン設定を作成します。これは必須ではありませんが、説明の目的でのみ表示されていることに注意してください。これにより、インフラストラクチャーノードのみに固有のカスタム設定を適用できます。

   注記

   新規マシン設定プールの作成後に、MCO はそのプールに新たにレンダリングされた設定を生成し、そのプールに関連付けられたノードは再起動して、新規設定を適用します。

   1. マシン設定を作成します。

      $ cat infra.mc.yaml

      出力例

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        name: 51-infra
        labels:
          machineconfiguration.openshift.io/role: infra 1
      spec:
        config:
          ignition:
            version: 3.1.0
          storage:
            files:
            - path: /etc/infratest
              mode: 0644
              contents:
                source: data:,infra

      1

      ノードに追加したラベルを nodeSelector として追加します。

   2. マシン設定を infra のラベルが付いたノードに適用します。

      $ oc create -f infra.mc.yaml

6. 新規のマシン設定プールが利用可能であることを確認します。

   $ oc get mcp

   出力例

   NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   infra    rendered-infra-60e35c2e99f42d976e084fa94da4d0fc    True      False      False      1              1                   1                     0                      4m20s
   master   rendered-master-9360fdb895d4c131c7c4bebbae099c90   True      False      False      3              3                   3                     0                      91m
   worker   rendered-worker-60e35c2e99f42d976e084fa94da4d0fc   True      False      False      2              2                   2                     0                      91m

   この例では、ワーカーノードが infra ノードに変更されました。

手順

1. テイントを infra ノードに追加し、ユーザーのワークロードをこれにスケジュールできないようにします。

   1. ノードにテイントがあるかどうかを判別します。

      $ oc describe nodes <node_name>

      出力例

      oc describe node ci-ln-iyhx092-f76d1-nvdfm-worker-b-wln2l
      Name:               ci-ln-iyhx092-f76d1-nvdfm-worker-b-wln2l
      Roles:              worker
       ...
      Taints:             node-role.kubernetes.io/infra:NoSchedule
       ...

      この例では、ノードにテイントがあることを示しています。次の手順に進み、容認を Pod に追加してください。

   2. ユーザーワークロードをスケジューリングできないように、テイントを設定していない場合は、以下を実行します。

      $ oc adm taint nodes <node_name> <key>:<effect>

      以下に例を示します。

      $ oc adm taint nodes node1 node-role.kubernetes.io/infra:NoSchedule

      この例では、テイントを、キー node-role.kubernetes.io/infra およびテイントの effect NoSchedule を持つ node1 に配置します。effect が NoSchedule のノードは、テイントを容認する Pod のみをスケジュールしますが、既存の Pod はノードにスケジュールされたままになります。

      注記

      Descheduler が使用されると、ノードのテイントに違反する Pod はクラスターからエビクトされる可能性があります。

2. ルーター、レジストリーおよびモニタリングのワークロードなどの、infra ノードにスケジュールする必要のある Pod 設定の容認を追加します。以下のコードを Pod オブジェクトの仕様に追加します。

   tolerations:
     - effect: NoSchedule 1
       key: node-role.kubernetes.io/infra 2
       operator: Exists 3

   1

   ノードに追加した effect を指定します。

   2

   ノードに追加したキーを指定します。

   3

   Exists Operator を、キー node-role.kubernetes.io/infra のあるテイントがノードに存在するように指定します。

   この容認は、oc adm taint コマンドで作成されたテイントと一致します。この容認のある Pod は infra ノードにスケジュールできます。

   注記

   OLM でインストールされた Operator の Pod を infra ノードに常に移動できる訳ではありません。Operator Pod を移動する機能は、各 Operator の設定によって異なります。

3. スケジューラーを使用して Pod を infra ノードにスケジュールします。詳細は、Pod のノードへの配置の制御 についてのドキュメントを参照してください。

手順

1. ルーター Operator の IngressController カスタムリソースを表示します。

   $ oc get ingresscontroller default -n openshift-ingress-operator -o yaml

   コマンド出力は以下のテキストのようになります。

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     creationTimestamp: 2019-04-18T12:35:39Z
     finalizers:
     - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller
     generation: 1
     name: default
     namespace: openshift-ingress-operator
     resourceVersion: "11341"
     selfLink: /apis/operator.openshift.io/v1/namespaces/openshift-ingress-operator/ingresscontrollers/default
     uid: 79509e05-61d6-11e9-bc55-02ce4781844a
   spec: {}
   status:
     availableReplicas: 2
     conditions:
     - lastTransitionTime: 2019-04-18T12:36:15Z
       status: "True"
       type: Available
     domain: apps.<cluster>.example.com
     endpointPublishingStrategy:
       type: LoadBalancerService
     selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller=default

2. ingresscontroller リソースを編集し、 nodeSelector を infra ラベルを使用するように変更します。

   $ oc edit ingresscontroller default -n openshift-ingress-operator

   以下に示すように、infra ラベルを参照する nodeSelector スタンザを spec セクションに追加します。

     spec:
       nodePlacement:
         nodeSelector:
           matchLabels:
             node-role.kubernetes.io/infra: ""

3. ルーター Pod が infra ノードで実行されていることを確認します。

   1. ルーター Pod の一覧を表示し、実行中の Pod のノード名をメモします。

      $ oc get pod -n openshift-ingress -o wide

      出力例

      NAME                              READY     STATUS        RESTARTS   AGE       IP           NODE                           NOMINATED NODE   READINESS GATES
      router-default-86798b4b5d-bdlvd   1/1      Running       0          28s       10.130.2.4   ip-10-0-217-226.ec2.internal   <none>           <none>
      router-default-955d875f4-255g8    0/1      Terminating   0          19h       10.129.2.4   ip-10-0-148-172.ec2.internal   <none>           <none>

      この例では、実行中の Pod は ip-10-0-217-226.ec2.internal ノードにあります。

   2. 実行中の Pod のノードのステータスを表示します。

      $ oc get node <node_name> 1

      1

      Pod の一覧より取得した <node_name> を指定します。

      出力例

      NAME                          STATUS  ROLES         AGE   VERSION
      ip-10-0-217-226.ec2.internal  Ready   infra,worker  17h   v1.19.0

      ロールの一覧に infra が含まれているため、Pod は正しいノードで実行されます。

手順

1. config/instance オブジェクトを表示します。

   $ oc get configs.imageregistry.operator.openshift.io/cluster -o yaml

   出力例

   apiVersion: imageregistry.operator.openshift.io/v1
   kind: Config
   metadata:
     creationTimestamp: 2019-02-05T13:52:05Z
     finalizers:
     - imageregistry.operator.openshift.io/finalizer
     generation: 1
     name: cluster
     resourceVersion: "56174"
     selfLink: /apis/imageregistry.operator.openshift.io/v1/configs/cluster
     uid: 36fd3724-294d-11e9-a524-12ffeee2931b
   spec:
     httpSecret: d9a012ccd117b1e6616ceccb2c3bb66a5fed1b5e481623
     logging: 2
     managementState: Managed
     proxy: {}
     replicas: 1
     requests:
       read: {}
       write: {}
     storage:
       s3:
         bucket: image-registry-us-east-1-c92e88cad85b48ec8b312344dff03c82-392c
         region: us-east-1
   status:
   ...

2. config/instance オブジェクトを編集します。

   $ oc edit configs.imageregistry.operator.openshift.io/cluster

3. オブジェクトの spec セクションを以下の YAML のように変更します。

   spec:
     affinity:
       podAntiAffinity:
         preferredDuringSchedulingIgnoredDuringExecution:
         - podAffinityTerm:
             namespaces:
             - openshift-image-registry
             topologyKey: kubernetes.io/hostname
           weight: 100
     logLevel: Normal
     managementState: Managed
     nodeSelector:
       node-role.kubernetes.io/infra: ""

4. レジストリー Pod がインフラストラクチャーノードに移動していることを確認します。

   1. 以下のコマンドを実行して、レジストリー Pod が置かれているノードを特定します。

      $ oc get pods -o wide -n openshift-image-registry

   2. ノードに指定したラベルがあることを確認します。

      $ oc describe node <node_name>

      コマンド出力を確認し、node-role.kubernetes.io/infra が LABELS 一覧にあることを確認します。

手順

1. 以下の ConfigMap 定義を cluster-monitoring-configmap.yaml ファイルとして保存します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |+
       alertmanagerMain:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       prometheusK8s:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       prometheusOperator:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       grafana:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       k8sPrometheusAdapter:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       kubeStateMetrics:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       telemeterClient:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       openshiftStateMetrics:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       thanosQuerier:
         nodeSelector:
           node-role.kubernetes.io/infra: ""

   この設定マップを実行すると、モニタリングスタックのコンポーネントがインフラストラクチャーノードに再デプロイされます。

2. 新規の設定マップを適用します。

   $ oc create -f cluster-monitoring-configmap.yaml

3. モニタリング Pod が新規マシンに移行することを確認します。

   $ watch 'oc get pod -n openshift-monitoring -o wide'

4. コンポーネントが infra ノードに移動していない場合は、このコンポーネントを持つ Pod を削除します。

   $ oc delete pod -n openshift-monitoring <pod>

   削除された Pod からのコンポーネントが infra ノードに再作成されます。

手順

1. openshift-logging プロジェクトで ClusterLogging カスタムリソース (CR) を編集します。

   $ oc edit ClusterLogging instance

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   
   ...
   
   spec:
     collection:
       logs:
         fluentd:
           resources: null
         type: fluentd
     curation:
       curator:
         nodeSelector: 1
           node-role.kubernetes.io/infra: ''
         resources: null
         schedule: 30 3 * * *
       type: curator
     logStore:
       elasticsearch:
         nodeCount: 3
         nodeSelector: 2
           node-role.kubernetes.io/infra: ''
         redundancyPolicy: SingleRedundancy
         resources:
           limits:
             cpu: 500m
             memory: 16Gi
           requests:
             cpu: 500m
             memory: 16Gi
         storage: {}
       type: elasticsearch
     managementState: Managed
     visualization:
       kibana:
         nodeSelector: 3
           node-role.kubernetes.io/infra: ''
         proxy:
           resources: null
         replicas: 1
         resources: null
       type: kibana
   
   ...

手順

1. カスタマイズされたリソース定義を含む ClusterAutoscaler リソースの YAML ファイルを作成します。

2. クラスターにリソースを作成します。

   $ oc create -f <filename>.yaml 1

   1

   <filename> は、カスタマイズしたリソースファイルの名前です。

手順

1. カスタマイズされたリソース定義を含む MachineAutoscaler リソースの YAML ファイルを作成します。

2. クラスターにリソースを作成します。

   $ oc create -f <filename>.yaml 1

   1

   <filename> は、カスタマイズしたリソースファイルの名前です。

1. cluster という名前の FeatureGate CR を編集します。

   $ oc edit featuregate cluster

   FeatureGate カスタムリソースのサンプル

   apiVersion: config.openshift.io/v1
   kind: FeatureGate
   metadata:
     name: cluster 1
   spec:
     featureSet: IPv6DualStackNoUpgrade 2

   1

   FeatureGate CR の名前は cluster である必要があります。

   2

   IPv6DualStackNoUpgrade 機能セットを追加して、デュアルスタックネットワークモードを有効にします。

   変更を保存すると、新規マシン設定が作成され、マシン設定プールが更新され、変更が適用されている間に各ノードのスケジューリングが無効になります。

   注記

   IPv6DualStackNoUpgrade 機能セットを有効にすると、元に戻すことができず、更新もできなくなります。この機能セットは、実稼働クラスターでは推奨されません。

1. ノードのデバッグセッションを開始します。

   $ oc debug node/<node_name>

2. ルートディレクトリーをホストに切り替えます。

   sh-4.2# chroot /host

3. kubelet.conf ファイルを表示します。

   sh-4.2# cat /etc/kubernetes/kubelet.conf

   出力例

    ...
   featureGates:
     InsightsOperatorPullingSCA: true,
     LegacyNodeRoleBehavior: false
    ...

   true として一覧表示されている機能は、クラスターで有効になっています。

   注記

   一覧表示される機能は、OpenShift Container Platform のバージョンによって異なります。

手順

1. APIServer オブジェクトを変更します。

   $ oc edit apiserver

2. encryption フィールドタイプを aescbc に設定します。

   spec:
     encryption:
       type: aescbc 1

   1

   aescbc タイプは、暗号化を実行するために PKCS#7 パディングを実装している AES-CBC と 32 バイトのキーが使用されることを意味します。

3. 変更を適用するためにファイルを保存します。

   暗号化プロセスが開始されます。クラスターのサイズによっては、このプロセスが完了するまで 20 分以上かかる場合があります。

4. etcd 暗号化が正常に行われたことを確認します。

   1. OpenShift API サーバーの Encrypted ステータスを確認し、そのリソースが正常に暗号化されたことを確認します。

      $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      この出力には、暗号化が正常に実行されると EncryptionCompleted が表示されます。

      EncryptionCompleted
      All resources encrypted: routes.route.openshift.io, oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io

      出力に EncryptionInProgress が表示される場合、これは暗号化が進行中であることを意味します。数分待機した後に再試行します。

   2. Kubernetes API サーバーの Encrypted ステータス状態を確認し、そのリソースが正常に暗号化されたことを確認します。

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      この出力には、暗号化が正常に実行されると EncryptionCompleted が表示されます。

      EncryptionCompleted
      All resources encrypted: secrets, configmaps

      出力に EncryptionInProgress が表示される場合、これは暗号化が進行中であることを意味します。数分待機した後に再試行します。

手順

1. APIServer オブジェクトを変更します。

   $ oc edit apiserver

2. encryption フィールドタイプを identity に設定します。

   spec:
     encryption:
       type: identity 1

   1

   identity タイプはデフォルト値であり、暗号化は実行されないことを意味します。

3. 変更を適用するためにファイルを保存します。

   復号化プロセスが開始されます。クラスターのサイズによっては、このプロセスが完了するまで 20 分以上かかる場合があります。

4. etcd の復号化が正常に行われたことを確認します。

   1. OpenShift API サーバーの Encrypted ステータス条件を確認し、そのリソースが正常に暗号化されたことを確認します。

      $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      この出力には、復号化が正常に実行されると DecryptionCompleted が表示されます。

      DecryptionCompleted
      Encryption mode set to identity and everything is decrypted

      出力に DecryptionInProgress が表示される場合、これは復号化が進行中であることを意味します。数分待機した後に再試行します。

   2. Kubernetes API サーバーの Encrypted ステータス状態を確認し、そのリソースが正常に復号化されたことを確認します。

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      この出力には、復号化が正常に実行されると DecryptionCompleted が表示されます。

      DecryptionCompleted
      Encryption mode set to identity and everything is decrypted

      出力に DecryptionInProgress が表示される場合、これは復号化が進行中であることを意味します。数分待機した後に再試行します。

手順

1. コントロールプレーンノードのデバッグセッションを開始します。

   $ oc debug node/<node_name>

2. ルートディレクトリーをホストに切り替えます。

   sh-4.2# chroot /host

3. クラスター全体のプロキシーが有効になっている場合は、 NO_PROXY、HTTP_PROXY、および HTTPS_PROXY 環境変数をエクスポートしていることを確認します。

4. etcd-snapshot-backup.sh スクリプトを実行し、バックアップの保存先となる場所を渡します。

   ヒント

   cluster-backup.sh スクリプトは etcd Cluster Operator のコンポーネントとして維持され、etcdctl snapshot save コマンドに関連するラッパーです。

   sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backup

   スクリプトの出力例

   found latest kube-apiserver: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-6
   found latest kube-controller-manager: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-7
   found latest kube-scheduler: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-6
   found latest etcd: /etc/kubernetes/static-pod-resources/etcd-pod-3
   ede95fe6b88b87ba86a03c15e669fb4aa5bf0991c180d3c6895ce72eaade54a1
   etcdctl version: 3.4.14
   API version: 3.4
   {"level":"info","ts":1624647639.0188997,"caller":"snapshot/v3_snapshot.go:119","msg":"created temporary db file","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db.part"}
   {"level":"info","ts":"2021-06-25T19:00:39.030Z","caller":"clientv3/maintenance.go:200","msg":"opened snapshot stream; downloading"}
   {"level":"info","ts":1624647639.0301006,"caller":"snapshot/v3_snapshot.go:127","msg":"fetching snapshot","endpoint":"https://10.0.0.5:2379"}
   {"level":"info","ts":"2021-06-25T19:00:40.215Z","caller":"clientv3/maintenance.go:208","msg":"completed snapshot read; closing"}
   {"level":"info","ts":1624647640.6032252,"caller":"snapshot/v3_snapshot.go:142","msg":"fetched snapshot","endpoint":"https://10.0.0.5:2379","size":"114 MB","took":1.584090459}
   {"level":"info","ts":1624647640.6047094,"caller":"snapshot/v3_snapshot.go:152","msg":"saved","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db"}
   Snapshot saved at /home/core/assets/backup/snapshot_2021-06-25_190035.db
   {"hash":3866667823,"revision":31407,"totalKey":12828,"totalSize":114446336}
   snapshot db and kube resources are successfully saved to /home/core/assets/backup

   この例では、コントロールプレーンホストの /home/core/assets/backup/ ディレクトリーにファイルが 2 つ作成されます。

   • snapshot_<datetimestamp>.db: このファイルは etcd スナップショットです。cluster-backup.sh スクリプトで、その有効性を確認します。

   • static_kuberesources_<datetimestamp>.tar.gz: このファイルには、静的 Pod のリソースが含まれます。etcd 暗号化が有効にされている場合、etcd スナップショットの暗号化キーも含まれます。

     注記

     etcd 暗号化が有効にされている場合、セキュリティー上の理由から、この 2 つ目のファイルを etcd スナップショットとは別に保存することが推奨されます。ただし、このファイルは etcd スナップショットから復元するために必要になります。

     etcd 暗号化はキーではなく値のみを暗号化することに注意してください。つまり、リソースタイプ、namespace、およびオブジェクト名は暗号化されません。

手順

1. リーダーを最後にデフラグする必要があるため、どの etcd メンバーがリーダーであるかを判別します。

   1. etcd Pod の一覧を取得します。

      $ oc get pods -n openshift-etcd -o wide | grep -v quorum-guard | grep etcd

      出力例

      etcd-ip-10-0-159-225.example.redhat.com                3/3     Running     0          175m   10.0.159.225   ip-10-0-159-225.example.redhat.com   <none>           <none>
      etcd-ip-10-0-191-37.example.redhat.com                 3/3     Running     0          173m   10.0.191.37    ip-10-0-191-37.example.redhat.com    <none>           <none>
      etcd-ip-10-0-199-170.example.redhat.com                3/3     Running     0          176m   10.0.199.170   ip-10-0-199-170.example.redhat.com   <none>           <none>

   2. Pod を選択し、以下のコマンドを実行して、どの etcd メンバーがリーダーであるかを判別します。

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w table

      出力例

      Defaulting container name to etcdctl.
      Use 'oc describe pod/etcd-ip-10-0-159-225.example.redhat.com -n openshift-etcd' to see all of the containers in this pod.
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
      | https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
      | https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.4.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

      この出力の IS LEADER 列に基づいて、https://10.0.199.170:2379 エンドポイントがリーダーになります。このエンドポイントを直前の手順の出力に一致させると、リーダーの Pod 名は etcd-ip-10-0-199-170.example.redhat.com になります。

2. etcd メンバーのデフラグ。

   1. 実行中の etcd コンテナーに接続し、リーダーでは ない Pod の名前を渡します。

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com

   2. ETCDCTL_ENDPOINTS 環境変数の設定を解除します。

      sh-4.4# unset ETCDCTL_ENDPOINTS

   3. etcd メンバーのデフラグを実行します。

      sh-4.4# etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag

      出力例

      Finished defragmenting etcd member[https://localhost:2379]

      タイムアウトエラーが発生した場合は、コマンドが正常に実行されるまで --command-timeout の値を増やします。

   4. データベースサイズが縮小されていることを確認します。

      sh-4.4# etcdctl endpoint status -w table --cluster

      出力例

      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
      | https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.4.9 |   41 MB |     false |      false |         7 |      91624 |              91624 |        | 1
      | https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.4.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

      この例では、この etcd メンバーのデータベースサイズは、開始時のサイズの 104 MB ではなく 41 MB です。

   5. これらの手順を繰り返して他の etcd メンバーのそれぞれに接続し、デフラグします。常に最後にリーダーをデフラグします。

      etcd Pod が回復するように、デフラグアクションごとに 1 分以上待機します。etcd Pod が回復するまで、etcd メンバーは応答しません。

3. 領域のクォータの超過により NOSPACE アラームがトリガーされる場合、それらをクリアします。

   1. NOSPACE アラームがあるかどうかを確認します。

      sh-4.4# etcdctl alarm list

      出力例

      memberID:12345678912345678912 alarm:NOSPACE

   2. アラームをクリアします。

      sh-4.4# etcdctl alarm disarm

手順

1. リカバリーホストとして使用するコントロールプレーンホストを選択します。これは、復元操作を実行するホストです。

2. リカバリーホストを含む、各コントロールプレーンノードへの SSH 接続を確立します。

   Kubernetes API サーバーは復元プロセスの開始後にアクセスできなくなるため、コントロールプレーンノードにはアクセスできません。このため、別のターミナルで各コントロールプレーンホストに SSH 接続を確立することが推奨されます。

   重要

   この手順を完了しないと、復元手順を完了するためにコントロールプレーンホストにアクセスすることができなくなり、この状態からクラスターを回復できなくなります。

3. etcd バックアップディレクトリーをリカバリーコントロールプレーンホストにコピーします。

   この手順では、etcd スナップショットおよび静的 Pod のリソースを含む backup ディレクトリーを、リカバリーコントロールプレーンホストの /home/core/ ディレクトリーにコピーしていることを前提としています。

4. 他のすべてのコントロールプレーンノードで静的 Pod を停止します。

   注記

   リカバリーホストで Pod を手動で停止する必要はありません。リカバリースクリプトは、リカバリーホストの Pod を停止します。

   1. リカバリーホストではないコントロールプレーンホストにアクセスします。

   2. 既存の etcd Pod ファイルを kubelet マニフェストディレクトリーから移動します。

      $ sudo mv /etc/kubernetes/manifests/etcd-pod.yaml /tmp

   3. etcd Pod が停止していることを確認します。

      $ sudo crictl ps | grep etcd | grep -v operator

      コマンドの出力は空であるはずです。空でない場合は、数分待機してから再度確認します。

   4. 既存の Kubernetes API サーバー Pod ファイルを kubelet マニフェストディレクトリーから移動します。

      $ sudo mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp

   5. Kubernetes API サーバー Pod が停止していることを確認します。

      $ sudo crictl ps | grep kube-apiserver | grep -v operator

      コマンドの出力は空であるはずです。空でない場合は、数分待機してから再度確認します。

   6. etcd データディレクトリーを別の場所に移動します。

      $ sudo mv /var/lib/etcd/ /tmp

   7. リカバリーホストではない他のコントロールプレーンホストでこの手順を繰り返します。
5. リカバリーコントロールプレーンホストにアクセスします。

6. クラスター全体のプロキシーが有効になっている場合は、 NO_PROXY、HTTP_PROXY、および HTTPS_PROXY 環境変数をエクスポートしていることを確認します。

   ヒント

   oc get proxy cluster -o yaml の出力を確認して、プロキシーが有効にされているかどうかを確認できます。プロキシーは、httpProxy、httpsProxy、および noProxy フィールドに値が設定されている場合に有効にされます。

7. リカバリーコントロールプレーンホストで復元スクリプトを実行し、パスを etcd バックアップディレクトリーに渡します。

   $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/backup

   スクリプトの出力例

   ...stopping kube-scheduler-pod.yaml
   ...stopping kube-controller-manager-pod.yaml
   ...stopping etcd-pod.yaml
   ...stopping kube-apiserver-pod.yaml
   Waiting for container etcd to stop
   .complete
   Waiting for container etcdctl to stop
   .............................complete
   Waiting for container etcd-metrics to stop
   complete
   Waiting for container kube-controller-manager to stop
   complete
   Waiting for container kube-apiserver to stop
   ..........................................................................................complete
   Waiting for container kube-scheduler to stop
   complete
   Moving etcd data-dir /var/lib/etcd/member to /var/lib/etcd-backup
   starting restore-etcd static pod
   starting kube-apiserver-pod.yaml
   static-pod-resources/kube-apiserver-pod-7/kube-apiserver-pod.yaml
   starting kube-controller-manager-pod.yaml
   static-pod-resources/kube-controller-manager-pod-7/kube-controller-manager-pod.yaml
   starting kube-scheduler-pod.yaml
   static-pod-resources/kube-scheduler-pod-8/kube-scheduler-pod.yaml

   注記

   最後の etcd バックアップの後にノード証明書が更新された場合、復元プロセスによってノードが NotReady 状態になる可能性があります。

8. ノードをチェックして、Ready 状態であることを確認します。

   1. 以下のコマンドを実行します。

      $ oc get nodes -w

      出力例

      NAME                STATUS  ROLES          AGE     VERSION
      host-172-25-75-28   Ready   master         3d20h   v1.23.3+e419edf
      host-172-25-75-38   Ready   infra,worker   3d20h   v1.23.3+e419edf
      host-172-25-75-40   Ready   master         3d20h   v1.23.3+e419edf
      host-172-25-75-65   Ready   master         3d20h   v1.23.3+e419edf
      host-172-25-75-74   Ready   infra,worker   3d20h   v1.23.3+e419edf
      host-172-25-75-79   Ready   worker         3d20h   v1.23.3+e419edf
      host-172-25-75-86   Ready   worker         3d20h   v1.23.3+e419edf
      host-172-25-75-98   Ready   infra,worker   3d20h   v1.23.3+e419edf

      すべてのノードが状態を報告するのに数分かかる場合があります。

   2. NotReady 状態のノードがある場合は、ノードにログインし、各ノードの /var/lib/kubelet/pki ディレクトリーからすべての PEM ファイルを削除します。ノードに SSH 接続するか、Web コンソールのターミナルウィンドウを使用できます。

      $  ssh -i <ssh-key-path> core@<master-hostname>

      サンプル pki ディレクトリー

      sh-4.4# pwd
      /var/lib/kubelet/pki
      sh-4.4# ls
      kubelet-client-2022-04-28-11-24-09.pem  kubelet-server-2022-04-28-11-24-15.pem
      kubelet-client-current.pem              kubelet-server-current.pem

9. すべてのコントロールプレーンホストで kubelet サービスを再起動します。

   1. リカバリーホストから以下のコマンドを実行します。

      $ sudo systemctl restart kubelet.service

   2. 他のすべてのコントロールプレーンホストでこの手順を繰り返します。

10. 保留中の CSR を承認します。

    1. 現在の CSR の一覧を取得します。

       $ oc get csr

       出力例

       NAME        AGE    SIGNERNAME                                    REQUESTOR                                                                   CONDITION
       csr-2s94x   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 1
       csr-4bd6t   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 2
       csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 3
       csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 4
       ...

       1 1 2

       保留中の kubelet サービス CSR (ユーザーがプロビジョニングしたインストール用)。

       3 4

       保留中の node-bootstrapper CSR。

    2. CSR の詳細をレビューし、これが有効であることを確認します。

       $ oc describe csr <csr_name> 1

       1

       <csr_name> は、現行の CSR の一覧からの CSR の名前です。

    3. それぞれの有効な node-bootstrapper CSR を承認します。

       $ oc adm certificate approve <csr_name>

    4. ユーザーによってプロビジョニングされるインストールの場合は、それぞれの有効な kubelet 提供の CSR を承認します。

       $ oc adm certificate approve <csr_name>

11. 単一メンバーのコントロールプレーンが正常に起動していることを確認します。

    1. リカバリーホストから etcd コンテナーが実行中であることを確認します。

       $ sudo crictl ps | grep etcd | grep -v operator

       出力例

       3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0

    2. リカバリーホストから、etcd Pod が実行されていることを確認します。

       $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd

       注記

       このコマンドを実行する前に oc login の実行を試行し、以下のエラーを受信すると、認証コントローラーが起動し、再試行するまでしばらく待機します。

       Unable to connect to the server: EOF

       出力例

       NAME                                             READY   STATUS      RESTARTS   AGE
       etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s

       ステータスが Pending の場合や出力に複数の実行中の etcd Pod が一覧表示される場合、数分待機してから再度チェックを行います。

12. etcd の再デプロイメントを強制的に実行します。

    クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1

    1

    forceRedeploymentReason 値は一意である必要があります。そのため、タイムスタンプが付加されます。

    etcd クラスター Operator が再デプロイメントを実行すると、初期ブートストラップのスケールアップと同様に、既存のノードが新規 Pod と共に起動します。

13. すべてのノードが最新のリビジョンに更新されていることを確認します。

    クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

    etcd の NodeInstallerProgressing 状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力には AllNodesAtLatestRevision が表示されます。

    AllNodesAtLatestRevision
    3 nodes are at revision 7 1

    1

    この例では、最新のリビジョン番号は 7 です。

    出力に 2 nodes are at revision 6; 1 nodes are at revision 7 などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。

14. etcd の再デプロイ後に、コントロールプレーンの新規ロールアウトを強制的に実行します。kubelet が内部ロードバランサーを使用して API サーバーに接続されているため、Kubernetes API サーバーは他のノードに再インストールされます。

    クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

    1. Kubernetes API サーバーの新規ロールアウトを強制的に実行します。

       $ oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

       すべてのノードが最新のリビジョンに更新されていることを確認します。

       $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

       NodeInstallerProgressing 状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力には AllNodesAtLatestRevision が表示されます。

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

       この例では、最新のリビジョン番号は 7 です。

       出力に 2 nodes are at revision 6; 1 nodes are at revision 7 などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。

    2. Kubernetes コントローラーマネージャーの新規ロールアウトを強制的に実行します。

       $ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

       すべてのノードが最新のリビジョンに更新されていることを確認します。

       $ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

       NodeInstallerProgressing 状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力には AllNodesAtLatestRevision が表示されます。

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

       この例では、最新のリビジョン番号は 7 です。

       出力に 2 nodes are at revision 6; 1 nodes are at revision 7 などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。

    3. Kubernetes スケジューラーの新規ロールアウトを強制的に実行します。

       $ oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

       すべてのノードが最新のリビジョンに更新されていることを確認します。

       $ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

       NodeInstallerProgressing 状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力には AllNodesAtLatestRevision が表示されます。

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

       この例では、最新のリビジョン番号は 7 です。

       出力に 2 nodes are at revision 6; 1 nodes are at revision 7 などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。

15. すべてのコントロールプレーンホストが起動しており、クラスターに参加していることを確認します。

    クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

    $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd

    出力例

    etcd-ip-10-0-143-125.ec2.internal                2/2     Running     0          9h
    etcd-ip-10-0-154-194.ec2.internal                2/2     Running     0          9h
    etcd-ip-10-0-173-171.ec2.internal                2/2     Running     0          9h

1. YAML ファイルを以下のようなオブジェクト定義で作成します。

   apiVersion: policy/v1beta1 1
   kind: PodDisruptionBudget
   metadata:
     name: my-pdb
   spec:
     minAvailable: 2  2
     selector:  3
       matchLabels:
         foo: bar

   1

   PodDisruptionBudget は policy/v1beta1 API グループの一部です。

   2

   同時に利用可能である必要のある Pod の最小数。これには、整数またはパーセンテージ (例: 20%) を指定する文字列を使用できます。

   3

   一連のリソースに対するラベルのクエリー。matchLabels と matchExpressions の結果は論理的に結合されます。

   または、以下を実行します。

   apiVersion: policy/v1beta1 1
   kind: PodDisruptionBudget
   metadata:
     name: my-pdb
   spec:
     maxUnavailable: 25% 2
     selector: 3
       matchLabels:
         foo: bar

   1

   PodDisruptionBudget は policy/v1beta1 API グループの一部です。

   2

   同時に利用不可にできる Pod の最大数。これには、整数またはパーセンテージ (例: 20%) を指定する文字列を使用できます。

   3

   一連のリソースに対するラベルのクエリー。matchLabels と matchExpressions の結果は論理的に結合されます。

2. 以下のコマンドを実行してオブジェクトをプロジェクトに追加します。

   $ oc create -f </path/to/file> -n <project_name>

手順

1. Web コンソールの Administrator パースペクティブで、Workloads → Secrets に移動します。

2. Secrets ページの表で、クラウドプロバイダーのルートシークレットを見つけます。

   プラットフォーム	シークレット名
   AWS	aws-creds
   Azure	azure-credentials
   GCP	gcp-credentials
   RHOSP	openstack-credentials
   RHV	ovirt-credentials
   vSphere	vsphere-creds

3. シークレットと同じ行にある Options メニュー をクリックし、Edit Secret を選択します。
4. Value フィールドの内容を記録します。この情報を使用して、認証情報の更新後に値が異なることを確認できます。
5. Value フィールドのテキストをクラウドプロバイダーの新規の認証情報で更新し、Save をクリックします。

6. クラスターの CCO が mint モードを使用するように設定されている場合、個別の CredentialsRequest オブジェクトによって参照される各コンポーネントシークレットを削除します。

   1. cluster-admin ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。

   2. 参照されたすべてのコンポーネントシークレットの名前および namespace を取得します。

      $ oc -n openshift-cloud-credential-operator get CredentialsRequest -o json | jq -r '.items[] | select (.spec.providerSpec.kind=="<provider_spec>") | .spec.secretRef'

      ここで、<provider_spec> はクラウドプロバイダーの対応する値になります。

      プラットフォーム	<provider_spec>
      AWS	AWSProviderSpec
      Azure	AzureProviderSpec
      GCP	GCPProviderSpec

      AWS の部分的なサンプル出力

      {
        "name": "ebs-cloud-credentials",
        "namespace": "openshift-cluster-csi-drivers"
      }
      {
        "name": "cloud-credential-operator-iam-ro-creds",
        "namespace": "openshift-cloud-credential-operator"
      }
      ...

   3. 参照されるコンポーネントの各シークレットを削除します。

      $ oc delete secret <secret_name> -n <secret_namespace>

      ここで、<secret_name> はシークレットの名前であり、<secret_namespace> はシークレットが含まれる namespace です。

      AWS シークレットの削除例

      $ oc delete secret ebs-cloud-credentials -n openshift-cluster-csi-drivers

      プロバイダーコンソールから認証情報を手動で削除する必要はありません。参照されるコンポーネントのシークレットを削除すると、CCO はプラットフォームから既存の認証情報を削除し、新規の認証情報を作成します。

7. 認証情報が変更されたことを確認するには、以下を実行します。

   1. Web コンソールの Administrator パースペクティブで、Workloads → Secrets に移動します。
   2. Value フィールドの内容が以前に記録された情報とは異なることを確認します。

手順

1. Web コンソールの Administrator パースペクティブで、Workloads → Secrets に移動します。

2. Secrets ページの表で、AWS の aws-creds ルートシークレットを見つけます。

   プラットフォーム	シークレット名
   AWS	aws-creds

3. シークレットと同じ行にある Options メニュー をクリックし、Delete Secret を選択します。

手順

1. ミラーリングする特定のイメージストリームのイメージにアクセスします。

   $ oc get is <imagestream> -n openshift -o json | jq .spec.tags[].from.name | grep registry.redhat.io

2. ネットワークが制限された環境で必要とするイメージストリームに関連付けられた registry.redhat.io のイメージを定義されたミラーのいずれかにミラーリングします。

   $ oc image mirror registry.redhat.io/rhscl/ruby-25-rhel7:latest ${MIRROR_ADDR}/rhscl/ruby-25-rhel7:latest

3. クラスターのイメージ設定オブジェクトを作成します。

   $ oc create configmap registry-config --from-file=${MIRROR_ADDR_HOSTNAME}..5000=$path/ca.crt -n openshift-config

4. クラスターのイメージ設定オブジェクトに、ミラーに必要な信頼される CA を追加します。

   $ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-config"}}}' --type=merge

5. Cluster Samples Operator 設定オブジェクトの samplesRegistry フィールドを、ミラー設定で定義されたミラーの場所の hostname の部分を含むように更新します。

   $ oc edit configs.samples.operator.openshift.io -n openshift-cluster-samples-operator

   注記

   これは、イメージストリームのインポートプロセスでミラーまたは検索メカニズムが使用されないので必要になります。

6. Cluster Samples Operator 設定オブジェクトの skippedImagestreams フィールドにミラーリングされないイメージストリームを追加します。または、サンプルイメージストリームのいずれもサポートする必要がない場合は、Cluster Samples Operator を Cluster Samples Operator 設定オブジェクトの Removed に設定します。

   注記

   Cluster Samples Operator は、イメージストリームのインポートに失敗した場合にアラートを発行しますが、Cluster Samples Operator は定期的に再試行する場合もあれば、それらを再試行していないように見える場合もあります。

   openshift namespace のテンプレートの多くはイメージストリームを参照します。そのため、Removed を使用してイメージストリームとテンプレートの両方を除去すると、イメージストリームのいずれかが欠落しているためにテンプレートが正常に機能しない場合にテンプレートの使用を試行する可能性がなくなります。

手順

1. ミラーレジストリーの信頼される CA を Cluster Samples Operator 設定の一部としてクラスターのイメージ設定オブジェクトに追加していない場合は、以下の手順を実行します。

   1. クラスターのイメージ設定オブジェクトを作成します。

      $ oc create configmap registry-config --from-file=${MIRROR_ADDR_HOSTNAME}..5000=$path/ca.crt -n openshift-config

   2. クラスターのイメージ設定オブジェクトに、ミラーに必要な信頼される CA を追加します。

      $ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-config"}}}' --type=merge

2. インストールペイロードからデフォルトの must-gather イメージをインポートします。

   $ oc import-image is/must-gather -n openshift

手順

1. クラスターの kubeconfig ファイルおよびクラスターのインストールに使用したインストールプログラムがマシン上にあることを確認します。これを実行する 1 つの方法として、クラスターのインストールに使用したマシンと同じマシンを使用することができます。
2. マシンを、コンピュートマシンとして使用する予定のすべての RHEL ホストにアクセスできるように設定します。Bastion と SSH プロキシーまたは VPN の使用など、所属する会社で許可されるすべての方法を利用できます。

3. すべての RHEL ホストへの SSH アクセスを持つユーザーを Playbook を実行するマシンで設定します。

   重要

   SSH キーベースの認証を使用する場合、キーを SSH エージェントで管理する必要があります。

4. これを実行していない場合には、マシンを RHSM に登録し、 OpenShift サブスクリプションのプールをこれにアタッチします。

   1. マシンを RHSM に登録します。

      # subscription-manager register --username=<user_name> --password=<password>

   2. RHSM から最新のサブスクリプションデータをプルします。

      # subscription-manager refresh

   3. 利用可能なサブスクリプションを一覧表示します。

      # subscription-manager list --available --matches '*OpenShift*'

   4. 直前のコマンドの出力で、OpenShift Container Platform サブスクリプションのプール ID を見つけ、これをアタッチします。

      # subscription-manager attach --pool=<pool_id>

5. OpenShift Container Platform 4.6 で必要なリポジトリーを有効にします。

   # subscription-manager repos \
       --enable="rhel-7-server-rpms" \
       --enable="rhel-7-server-extras-rpms" \
       --enable="rhel-7-server-ansible-2.9-rpms" \
       --enable="rhel-7-server-ose-4.6-rpms"

6. openshift-ansible を含む必要なパッケージをインストールします。

   # yum install openshift-ansible openshift-clients jq

   openshift-ansible パッケージはインストールプログラムユーティリティーを提供し、Ansible Playbook などのクラスターに RHEL コンピュートノードを追加するために必要な他のパッケージおよび関連する設定ファイルをプルします。openshift-clients は oc CLI を提供し、jq パッケージはコマンドライン上での JSON 出力の表示方法を向上させます。

1. 各ホストで RHSM に登録します。

   # subscription-manager register --username=<user_name> --password=<password>

2. RHSM から最新のサブスクリプションデータをプルします。

   # subscription-manager refresh

3. 利用可能なサブスクリプションを一覧表示します。

   # subscription-manager list --available --matches '*OpenShift*'

4. 直前のコマンドの出力で、OpenShift Container Platform サブスクリプションのプール ID を見つけ、これをアタッチします。

   # subscription-manager attach --pool=<pool_id>

5. yum リポジトリーをすべて無効にします。

   1. 有効にされている RHSM リポジトリーをすべて無効にします。

      # subscription-manager repos --disable="*"

   2. 残りの yum リポジトリーを一覧表示し、repo id にあるそれらの名前をメモします (ある場合) 。

      # yum repolist

   3. yum-config-manager を使用して、残りの yum リポジトリーを無効にします。

      # yum-config-manager --disable <repo_id>

      または、すべてのリポジトリーを無効にします。

      # yum-config-manager --disable \*

      利用可能なリポジトリーが多い場合には、数分の時間がかかることがあります。

6. OpenShift Container Platform 4.6 で必要なリポジトリーのみを有効にします。

   # subscription-manager repos \
       --enable="rhel-7-server-rpms" \
       --enable="rhel-7-fast-datapath-rpms" \
       --enable="rhel-7-server-extras-rpms" \
       --enable="rhel-7-server-optional-rpms" \
       --enable="rhel-7-server-ose-4.6-rpms"

7. ホストで firewalld を停止し、無効にします。

   # systemctl disable --now firewalld.service

   注記

   firewalld は、後で有効にすることはできません。これを実行する場合、ワーカー上の OpenShift Container Platform ログにはアクセスできません。

1. コンピュートマシンホストおよび必要な変数を定義する /<path>/inventory/hosts という名前の Ansible インベントリーファイルを作成します。

   [all:vars]
   ansible_user=root 1
   #ansible_become=True 2
   
   openshift_kubeconfig_path="~/.kube/config" 3
   
   [new_workers] 4
   mycluster-rhel7-0.example.com
   mycluster-rhel7-1.example.com

   1

   Ansible タスクをリモートコンピュートマシンで実行するユーザー名を指定します。

   2

   ansible_user の root を指定しない場合、ansible_become を True に設定し、ユーザーに sudo パーミッションを割り当てる必要があります。

   3

   クラスターの kubeconfig ファイルへのパスを指定します。

   4

   クラスターに追加する各 RHEL マシンを一覧表示します。各ホストについて完全修飾ドメイン名を指定する必要があります。この名前は、クラスターがマシンにアクセスするために使用するホスト名であるため、マシンにアクセスできるように正しいパブリックまたはプライベートの名前を設定します。

2. Ansible Playbook ディレクトリーに移動します。

   $ cd /usr/share/ansible/openshift-ansible

3. Playbook を実行します。

   $ ansible-playbook -i /<path>/inventory/hosts playbooks/scaleup.yml 1

   1

   <path> については、作成した Ansible インベントリーファイルへのパスを指定します。

手順

1. マシンの一覧を表示し、RHCOS コンピューマシンのノード名を記録します。

   $ oc get nodes -o wide

2. それぞれの RHCOS コンピュートマシンについて、ノードを削除します。

   1. oc adm cordon コマンドを実行して、ノードにスケジュール対象外 (unschedulable) のマークを付けます。

      $ oc adm cordon <node_name> 1

      1

      RHCOS コンピュートマシンのノード名を指定します。

   2. ノードからすべての Pod をドレイン (解放) します。

      $ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets 1

      1

      分離した RHCOS コンピュートマシンのノード名を指定します。

   3. ノードを削除します。

      $ oc delete nodes <node_name> 1

      1

      ドレイン (解放) した RHCOS コンピュートマシンのノード名を指定します。

3. コンピュートマシンの一覧を確認し、RHEL ノードのみが残っていることを確認します。

   $ oc get nodes -o wide

4. RHCOS マシンをクラスターのコンピュートマシンのロードバランサーから削除します。仮想マシンを削除したり、RHCOS コンピュートマシンの物理ハードウェアを再イメージ化したりできます。

手順

1. ISO ファイルを使用して、追加のコンピュートマシンに RHCOS をインストールします。クラスターのインストール前にマシンを作成する際に使用したのと同じ方法を使用します。

   • ディスクに ISO イメージを書き込み、これを直接起動します。
   • LOM インターフェイスで ISO リダイレクトを使用します。
2. インスタンスの起動後に、TAB または E キーを押してカーネルコマンドラインを編集します。

3. パラメーターをカーネルコマンドラインに追加します。

   coreos.inst.install_dev=sda 1
   coreos.inst.ignition_url=http://example.com/worker.ign 2

   1

   インストール先のシステムのブロックデバイスを指定します。

   2

   コンピュート Ignition 設定ファイルの URL を指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。

4. Enter を押してインストールを完了します。RHCOS のインストール後に、システムは再起動します。システムの再起動後、指定した Ignition 設定ファイルを適用します。
5. 継続してクラスター用の追加のコンピュートマシンを作成します。

手順

1. RHCOS イメージの PXE または iPXE インストールが正常に行われていることを確認します。

   • PXE の場合:

     DEFAULT pxeboot
     TIMEOUT 20
     PROMPT 0
     LABEL pxeboot
         KERNEL http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> 1
         APPEND initrd=http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img 2

     1

     HTTP サーバーにアップロードしたライブ kernel ファイルの場所を指定します。

     2

     HTTP サーバーにアップロードした RHCOS ファイルの場所を指定します。initrd パラメーターはライブ initramfs ファイルの場所であり、coreos.inst.ignition_url パラメーター値はワーカー Ignition 設定ファイルの場所であり、coreos.live.rootfs_url パラメーター値はライブ rootfs ファイルの場所になります。coreos.inst.ignition_url および coreos.live.rootfs_url パラメーターは HTTP および HTTPS のみをサポートします。

1. PXE または iPXE インフラストラクチャーを使用して、クラスターに必要なコンピュートマシンを作成します。

手順

1. クラスターがマシンを認識していることを確認します。

   $ oc get nodes

   出力例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  63m  v1.19.0
   master-1  Ready     master  63m  v1.19.0
   master-2  Ready     master  64m  v1.19.0

   出力には作成したすべてのマシンが一覧表示されます。

   注記

   上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。

2. 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。

   $ oc get csr

   出力例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   ...

   この例では、2 つのマシンがクラスターに参加しています。この一覧にはさらに多くの承認された CSR が表示される可能性があります。

3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

   注記

   CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認されたら、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要です。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に machine-approver によって自動的に承認されます。

   注記

   ベアメタルおよび他のユーザーによってプロビジョニングされるインフラストラクチャーなどのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、oc exec、 oc rsh、および oc logs コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR が system:node または system:admin グループの node-bootstrapper サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。

   • それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> は、現行の CSR の一覧からの CSR の名前です。

   • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve

     注記

     一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。

4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。

   $ oc get csr

   出力例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
   csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
   ...

5. 残りの CSR が承認されず、それらが Pending ステータスにある場合、クラスターマシンの CSR を承認します。

   • それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> は、現行の CSR の一覧からの CSR の名前です。

   • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。

   $ oc get nodes

   出力例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  73m  v1.20.0
   master-1  Ready     master  73m  v1.20.0
   master-2  Ready     master  74m  v1.20.0
   worker-0  Ready     worker  11m  v1.20.0
   worker-1  Ready     worker  11m  v1.20.0

   注記

   サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。

手順

1. マシンヘルスチェックの定義を含む healthcheck.yml ファイルを作成します。

2. healthcheck.yml ファイルをクラスターに適用します。

   $ oc apply -f healthcheck.yml

手順

1. クラスターにあるマシンセットを表示します。

   $ oc get machinesets -n openshift-machine-api

   マシンセットは <clusterid>-worker-<aws-region-az> の形式で一覧表示されます。

2. クラスター内にあるマシンを表示します。

   $ oc get machine -n openshift-machine-api

3. 削除するマシンに注釈を設定します。

   $ oc annotate machine/<machine_name> -n openshift-machine-api machine.openshift.io/cluster-api-delete-machine="true"

4. 削除するノードを分離して解放します。

   $ oc adm cordon <node_name>
   $ oc adm drain <node_name>

5. マシンセットをスケーリングします。

   $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

   または、以下を実行します。

   $ oc edit machineset <machineset> -n openshift-machine-api

   マシンセットをスケールアップまたはスケールダウンできます。新規マシンが利用可能になるまで数分の時間がかかります。

手順

1. これは、選択可能なマシン設定オブジェクトを表示します。

   $ oc get machineconfig

   デフォルトで、2 つの kubelet 関連の設定である 01-master-kubelet および 01-worker-kubelet を選択できます。

2. ノードあたりの最大 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

3. ワーカーノードでノードあたりの最大の 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: 500

   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: large-pods
     kubeletConfig:
       maxPods: <pod_count>
       kubeAPIBurst: <burst_rate>
       kubeAPIQPS: <QPS>

   1. ラベルを使用してワーカーのマシン設定プールを更新します。

      $ oc label machineconfigpool worker custom-kubelet=large-pods

   2. KubeletConfig オブジェクトを作成します。

      $ oc create -f change-maxPods-cr.yaml

   3. KubeletConfig オブジェクトが作成されていることを確認します。

      $ oc get kubeletconfig

      これにより set-max-pods が返されるはずです。

      クラスター内のワーカーノードの数によっては、ワーカーノードが 1 つずつ再起動されるのを待機します。3 つのワーカーノードを持つクラスターの場合は、10 分 から 15 分程度かかる可能性があります。

4. ワーカーノードを変更する maxPods の有無を確認します。

   $ oc describe node

   1. 以下を実行して変更を確認します。

      $ oc get kubeletconfigs set-max-pods -o yaml

      これは True と type:Success のステータスを表示します。

1. worker マシン設定プールを編集します。

   $ oc edit machineconfigpool worker

2. maxUnavailable を必要な値に設定します。

   spec:
     maxUnavailable: <node_count>

   重要

   値を設定する際に、クラスターで実行されているアプリケーションに影響を与えずに利用不可にできるワーカーノードの数を検討してください。

手順

1. オプション: ノードにラベルを指定します。

   # oc label node perf-node.example.com cpumanager=true

2. CPU マネージャーを有効にする必要のあるノードの MachineConfigPool を編集します。この例では、すべてのワーカーで CPU マネージャーが有効にされています。

   # oc edit machineconfigpool worker

3. ラベルをワーカーのマシン設定プールに追加します。

   metadata:
     creationTimestamp: 2020-xx-xxx
     generation: 3
     labels:
       custom-kubelet: cpumanager-enabled

4. KubeletConfig、cpumanager-kubeletconfig.yaml、カスタムリソース (CR) を作成します。直前の手順で作成したラベルを参照し、適切なノードを新規の kubelet 設定で更新します。machineConfigPoolSelector セクションを参照してください。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: cpumanager-enabled
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: cpumanager-enabled
     kubeletConfig:
        cpuManagerPolicy: static 1
        cpuManagerReconcilePeriod: 5s 2

   1

   ポリシーを指定します。

   • noneこのポリシーは、既存のデフォルト CPU アフィニティースキームを明示的に有効にし、スケジューラーが自動的に実行するもの以外のアフィニティーを提供しません。
   • staticこのポリシーにより、特定のリソース特性を持つ Pod の CPU アフィニティーを増やし、これらの Pod のノードにおける排他性を付与することができます。

   2

   オプション:CPU マネージャーの調整頻度を指定します。デフォルトは 5s です。

5. 動的な kubelet 設定を作成します。

   # oc create -f cpumanager-kubeletconfig.yaml

   これにより、CPU マネージャー機能が kubelet 設定に追加され、必要な場合には Machine Config Operator (MCO) がノードを再起動します。CPU マネージャーを有効にするために再起動する必要はありません。

6. マージされた kubelet 設定を確認します。

   # oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7

   出力例

          "ownerReferences": [
               {
                   "apiVersion": "machineconfiguration.openshift.io/v1",
                   "kind": "KubeletConfig",
                   "name": "cpumanager-enabled",
                   "uid": "7ed5616d-6b72-11e9-aae1-021e1ce18878"
               }
           ]

7. ワーカーで更新された kubelet.conf を確認します。

   # oc debug node/perf-node.example.com
   sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager

   出力例

   cpuManagerPolicy: static        1
   cpuManagerReconcilePeriod: 5s   2

   1 2

   これらの設定は、KubeletConfig CR を作成する際に定義されたものです。

8. コア 1 つまたは複数を要求する Pod を作成します。制限および要求の CPU の値は整数にする必要があります。これは、対象の Pod 専用のコア数です。

   # cat cpumanager-pod.yaml

   出力例

   apiVersion: v1
   kind: Pod
   metadata:
     generateName: cpumanager-
   spec:
     containers:
     - name: cpumanager
       image: gcr.io/google_containers/pause-amd64:3.0
       resources:
         requests:
           cpu: 1
           memory: "1G"
         limits:
           cpu: 1
           memory: "1G"
     nodeSelector:
       cpumanager: "true"

9. Pod を作成します。

   # oc create -f cpumanager-pod.yaml

10. Pod がラベル指定されたノードにスケジュールされていることを確認します。

    # oc describe pod cpumanager

    出力例

    Name:               cpumanager-6cqz7
    Namespace:          default
    Priority:           0
    PriorityClassName:  <none>
    Node:  perf-node.example.com/xxx.xx.xx.xxx
    ...
     Limits:
          cpu:     1
          memory:  1G
        Requests:
          cpu:        1
          memory:     1G
    ...
    QoS Class:       Guaranteed
    Node-Selectors:  cpumanager=true

11. cgroups が正しく設定されていることを確認します。pause プロセスのプロセス ID (PID) を取得します。

    # ├─init.scope
    │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 17
    └─kubepods.slice
      ├─kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice
      │ ├─crio-b5437308f1a574c542bdf08563b865c0345c8f8c0b0a655612c.scope
      │ └─32706 /pause

    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

    出力例

    cpuset.cpus 1
    tasks 32706

12. 対象のタスクで許可される CPU 一覧を確認します。

    # grep ^Cpus_allowed_list /proc/32706/status

    出力例

     Cpus_allowed_list:    1

13. システム上の別の 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

    出力例

    ...
    Capacity:
     attachable-volumes-aws-ebs:  39
     cpu:                         2
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      8162900Ki
     pods:                        250
    Allocatable:
     attachable-volumes-aws-ebs:  39
     cpu:                         1500m
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      7548500Ki
     pods:                        250
    -------                               ----                           ------------  ----------  ---------------  -------------  ---
      default                                 cpumanager-6cqz7               1 (66%)       1 (66%)     1G (12%)         1G (12%)       29m
    
    Allocated resources:
      (Total limits may be over 100 percent, i.e., overcommitted.)
      Resource                    Requests          Limits
      --------                    --------          ------
      cpu                         1440m (96%)       1 (66%)

    この仮想マシンには、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

1. 設定するノードタイプの静的な MachineConfigPool CRD に関連付けられたラベルを取得します。以下のいずれかの手順を実行します。

   1. マシン設定を表示します。

      # oc describe machineconfig <name>

      以下に例を示します。

      # oc describe machineconfig 00-worker

      出力例

      Name:         00-worker
      Namespace:
      Labels:       machineconfiguration.openshift.io/role=worker 1

      1

      デバイスマネージャーに必要なラベル。

手順

1. 設定変更のためのカスタムリソース (CR) を作成します。

   Device Manager CR の設定例

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: devicemgr 1
   spec:
     machineConfigPoolSelector:
       matchLabels:
          machineconfiguration.openshift.io: devicemgr 2
     kubeletConfig:
       feature-gates:
         - DevicePlugins=true 3

   1

   CR に名前を割り当てます。

   2

   Machine Config Pool からラベルを入力します。

   3

   DevicePlugins を 'true` に設定します。

2. デバイスマネージャーを作成します。

   $ oc create -f devicemgr.yaml

   出力例

   kubeletconfig.machineconfiguration.openshift.io/devicemgr created

3. デバイスマネージャーが実際に有効にされるように、/var/lib/kubelet/device-plugins/kubelet.sock がノードで作成されていることを確認します。これは、デバイスマネージャーの gRPC サーバーが新規プラグインの登録がないかどうかリッスンする UNIX ドメインソケットです。このソケットファイルは、デバイスマネージャーが有効にされている場合にのみ Kubelet の起動時に作成されます。

手順

1. Pod 仕様を tolerations スタンザを含めるように編集して、容認を Pod に追加します。

   Equal 演算子を含む Pod 設定ファイルのサンプル

   spec:
   ....
     template:
   ....
       spec:
         tolerations:
         - key: "key1" 1
           value: "value1"
           operator: "Equal"
           effect: "NoExecute"
           tolerationSeconds: 3600 2

   1

   テイントおよび容認コンポーネント の表で説明されている toleration パラメーターです。

   2

   tolerationSeconds パラメーターは、エビクトする前に Pod をどの程度の期間ノードにバインドさせるかを指定します。

   以下に例を示します。

   Exists 演算子を含む Pod 設定ファイルのサンプル

   spec:
   ....
     template:
   ....
       spec:
         tolerations:
         - key: "key1"
           operator: "Exists" 1
           effect: "NoExecute"
           tolerationSeconds: 3600

   1

   Exists Operator は value を取りません。

   この例では、テイントを、キー key1、値 value1、およびテイント effect NoExecute を持つ node1 にテイントを配置します。

2. テイントおよび容認コンポーネント の表で説明されているパラメーターと共に以下のコマンドを使用してテイントをノードに追加します。

   $ oc adm taint nodes <node_name> <key>=<value>:<effect>

   以下に例を示します。

   $ oc adm taint nodes node1 key1=value1:NoExecute

   このコマンドは、キー key1、値 value1、および effect NoExecute を持つテイントを node1 に配置します。

   注記

   NoSchedule テイントをコントロールプレーンノード (別名マスターノード) に追加する場合、ノードには、デフォルトで追加される node-role.kubernetes.io/master=:NoSchedule テイントが必要です。

   以下に例を示します。

   apiVersion: v1
   kind: Node
   metadata:
     annotations:
       machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
       machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
   ...
   spec:
     taints:
     - effect: NoSchedule
       key: node-role.kubernetes.io/master
   ...

   Pod の容認はノードのテイントに一致します。いずれかの容認のある Pod は node1 にスケジュールできます。

手順

1. Pod 仕様を tolerations スタンザを含めるように編集して、容認を Pod に追加します。

   Equal 演算子を含む Pod 設定ファイルのサンプル

   spec:
   ....
     template:
   ....
       spec:
         tolerations:
         - key: "key1" 1
           value: "value1"
           operator: "Equal"
           effect: "NoExecute"
           tolerationSeconds: 3600 2

   1

   テイントおよび容認コンポーネント の表で説明されている toleration パラメーターです。

   2

   tolerationSeconds パラメーターは、エビクトする前に Pod をどの程度の期間ノードにバインドさせるかを指定します。

   以下に例を示します。

   Exists 演算子を含む Pod 設定ファイルのサンプル

   spec:
     tolerations:
     - key: "key1"
       operator: "Exists"
       effect: "NoExecute"
       tolerationSeconds: 3600

2. テイントを MachineSet オブジェクトに追加します。

   1. テイントを付けるノードの MachineSet YAML を編集するか、または新規 MachineSet オブジェクトを作成できます。

      $ oc edit machineset <machineset>

   2. テイントを spec.template.spec セクションに追加します。

      マシンセット仕様のテイントの例

      spec:
      ....
        template:
      ....
          spec:
            taints:
            - effect: NoExecute
              key: key1
              value: value1
      ....

      この例では、キー key1、値 value1、およびテイント effect NoExecute を持つテイントをノードに配置します。

   3. マシンセットを 0 にスケールダウンします。

      $ oc scale --replicas=0 machineset <machineset> -n openshift-machine-api

      マシンが削除されるまで待機します。

   4. マシンセットを随時スケールアップします。

      $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

      マシンが起動するまで待ちます。テイントは MachineSet オブジェクトに関連付けられたノードに追加されます。

1. 対応するテイントをそれらのノードに追加します。

   以下に例を示します。

   $ oc adm taint nodes node1 dedicated=groupName:NoSchedule

2. カスタム受付コントローラーを作成して容認を Pod に追加します。

1. 容認を特別なハードウェアを必要とする Pod に追加します。

   以下に例を示します。

   spec:
     tolerations:
       - key: "disktype"
         value: "ssd"
         operator: "Equal"
         effect: "NoSchedule"
         tolerationSeconds: 3600

2. 以下のコマンドのいずれかを使用して、特殊ハードウェアを持つノードにテイントを設定します。

   $ oc adm taint nodes <node-name> disktype=ssd:NoSchedule

   または、以下を実行します。

   $ oc adm taint nodes <node-name> disktype=ssd:PreferNoSchedule

1. ノードからテイントを削除するには、以下を実行します。

   $ oc adm taint nodes <node-name> <key>-

   以下に例を示します。

   $ oc adm taint nodes ip-10-0-132-248.ec2.internal key1-

   出力例

   node/ip-10-0-132-248.ec2.internal untainted

2. Pod から容認を削除するには、容認を削除するための Pod 仕様を編集します。

   spec:
     tolerations:
     - key: "key2"
       operator: "Exists"
       effect: "NoExecute"
       tolerationSeconds: 3600

1. cpumanager-enabled カスタムリソース (CR) で Topology Manager 割り当てポリシーを設定します。

   $ oc edit KubeletConfig cpumanager-enabled

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: cpumanager-enabled
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: cpumanager-enabled
     kubeletConfig:
        cpuManagerPolicy: static 1
        cpuManagerReconcilePeriod: 5s
        topologyManagerPolicy: single-numa-node 2

   1

   このパラメーターは static である必要があります。

   2

   選択した Topology Manager 割り当てポリシーを指定します。このポリシーは single-numa-node になります。使用できる値は、default、best-effort、restricted、single-numa-node です。

1. OpenShift Container Platform Web コンソールで、Home → Projects に移動します。

   1. Create Project をクリックします。
   2. clusterresourceoverride-operator をプロジェクトの名前として指定します。
   3. Create をクリックします。

2. Operators → OperatorHub に移動します。

   1. 利用可能な Operator の一覧から ClusterResourceOverride Operator を選択し、Install をクリックします。
   2. Install Operator ページで、A specific Namespace on the cluster が Installation Mode について選択されていることを確認します。
   3. clusterresourceoverride-operator が Installed Namespace について選択されていることを確認します。
   4. Update Channel および Approval Strategy を選択します。
   5. Install をクリックします。

3. Installed Operators ページで、ClusterResourceOverride をクリックします。

   1. ClusterResourceOverride Operator の詳細ページで、Create Instance をクリックします。

   2. Create ClusterResourceOverride ページで、YAML テンプレートを編集して、必要に応じてオーバーコミット値を設定します。

      apiVersion: operator.autoscaling.openshift.io/v1
      kind: ClusterResourceOverride
      metadata:
        name: cluster 1
      spec:
        podResourceOverride:
          spec:
            memoryRequestToLimitPercent: 50 2
            cpuRequestToLimitPercent: 25 3
            limitCPUToMemoryPercent: 200 4

      1

      名前は cluster でなければなりません。

      2

      オプション:コンテナーメモリーの制限を上書きするためのパーセンテージが使用される場合は、これを 1-100 までの値で指定します。デフォルトは 50 です。

      3

      オプション:コンテナー CPU の制限を上書きするためのパーセンテージが使用される場合は、これを 1-100 までの値で指定します。デフォルトは 25 です。

      4

      オプション:コンテナーメモリーの制限を上書きするためのパーセンテージが使用される場合は、これを指定します。1Gi の RAM の 100 パーセントでのスケーリングは、1 CPU コアに等しくなります。これは、CPU 要求を上書きする前に処理されます (設定されている場合)。デフォルトは 200 です。

   3. Create をクリックします。

4. クラスターカスタムリソースのステータスをチェックして、受付 Webhook の現在の状態を確認します。

   1. ClusterResourceOverride Operator ページで、cluster をクリックします。

   2. ClusterResourceOverride Details ページで、 YAML をクリックします。Webhook の呼び出し時に、mutatingWebhookConfigurationRef セクションが表示されます。

      apiVersion: operator.autoscaling.openshift.io/v1
      kind: ClusterResourceOverride
      metadata:
        annotations:
          kubectl.kubernetes.io/last-applied-configuration: |
            {"apiVersion":"operator.autoscaling.openshift.io/v1","kind":"ClusterResourceOverride","metadata":{"annotations":{},"name":"cluster"},"spec":{"podResourceOverride":{"spec":{"cpuRequestToLimitPercent":25,"limitCPUToMemoryPercent":200,"memoryRequestToLimitPercent":50}}}}
        creationTimestamp: "2019-12-18T22:35:02Z"
        generation: 1
        name: cluster
        resourceVersion: "127622"
        selfLink: /apis/operator.autoscaling.openshift.io/v1/clusterresourceoverrides/cluster
        uid: 978fc959-1717-4bd1-97d0-ae00ee111e8d
      spec:
        podResourceOverride:
          spec:
            cpuRequestToLimitPercent: 25
            limitCPUToMemoryPercent: 200
            memoryRequestToLimitPercent: 50
      status:
      
      ....
      
          mutatingWebhookConfigurationRef: 1
            apiVersion: admissionregistration.k8s.io/v1beta1
            kind: MutatingWebhookConfiguration
            name: clusterresourceoverrides.admission.autoscaling.openshift.io
            resourceVersion: "127621"
            uid: 98b3b8ae-d5ce-462b-8ab5-a729ea8f38f3
      
      ....

      1

      ClusterResourceOverride 受付 Webhook への参照。

1. Cluster Resource Override の namespace を作成します。

   1. Cluster Resource Override Operator の Namespace オブジェクト YAML ファイル (cro-namespace.yaml など) を作成します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: clusterresourceoverride-operator

   2. namespace を作成します。

      $ oc create -f <file-name>.yaml

      以下に例を示します。

      $ oc create -f cro-namespace.yaml

2. Operator グループを作成します。

   1. Cluster Resource Override Operator の OperatorGroup オブジェクトの YAML ファイル (cro-og.yaml など) を作成します。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: clusterresourceoverride-operator
        namespace: clusterresourceoverride-operator
      spec:
        targetNamespaces:
          - clusterresourceoverride-operator

   2. Operator グループを作成します。

      $ oc create -f <file-name>.yaml

      以下に例を示します。

      $ oc create -f cro-og.yaml

3. サブスクリプションを作成します。

   1. Cluster Resource Override Operator の Subscription オブジェクト YAML ファイル (cro-sub.yaml など) を作成します。

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: clusterresourceoverride
        namespace: clusterresourceoverride-operator
      spec:
        channel: "4.6"
        name: clusterresourceoverride
        source: redhat-operators
        sourceNamespace: openshift-marketplace

   2. サブスクリプションを作成します。

      $ oc create -f <file-name>.yaml

      以下に例を示します。

      $ oc create -f cro-sub.yaml

4. ClusterResourceOverride カスタムリソース (CR) オブジェクトを clusterresourceoverride-operator namespace に作成します。

   1. clusterresourceoverride-operator namespace に切り替えます。

      $ oc project clusterresourceoverride-operator

   2. Cluster Resource Override Operator の ClusterResourceOverride オブジェクト YAML ファイル (cro-cr.yaml など) を作成します。

      apiVersion: operator.autoscaling.openshift.io/v1
      kind: ClusterResourceOverride
      metadata:
          name: cluster 1
      spec:
        podResourceOverride:
          spec:
            memoryRequestToLimitPercent: 50 2
            cpuRequestToLimitPercent: 25 3
            limitCPUToMemoryPercent: 200 4

      1

      名前は cluster でなければなりません。

      2

      オプション:コンテナーメモリーの制限を上書きするためのパーセンテージが使用される場合は、これを 1-100 までの値で指定します。デフォルトは 50 です。

      3

      オプション:コンテナー CPU の制限を上書きするためのパーセンテージが使用される場合は、これを 1-100 までの値で指定します。デフォルトは 25 です。

      4

      オプション:コンテナーメモリーの制限を上書きするためのパーセンテージが使用される場合は、これを指定します。1Gi の RAM の 100 パーセントでのスケーリングは、1 CPU コアに等しくなります。これは、CPU 要求を上書きする前に処理されます (設定されている場合)。デフォルトは 200 です。

   3. ClusterResourceOverride オブジェクトを作成します。

      $ oc create -f <file-name>.yaml

      以下に例を示します。

      $ oc create -f cro-cr.yaml

5. クラスターカスタムリソースのステータスをチェックして、受付 Webhook の現在の状態を確認します。

   $ oc get clusterresourceoverride cluster -n clusterresourceoverride-operator -o yaml

   Webhook の呼び出し時に、mutatingWebhookConfigurationRef セクションが表示されます。

   出力例

   apiVersion: operator.autoscaling.openshift.io/v1
   kind: ClusterResourceOverride
   metadata:
     annotations:
       kubectl.kubernetes.io/last-applied-configuration: |
         {"apiVersion":"operator.autoscaling.openshift.io/v1","kind":"ClusterResourceOverride","metadata":{"annotations":{},"name":"cluster"},"spec":{"podResourceOverride":{"spec":{"cpuRequestToLimitPercent":25,"limitCPUToMemoryPercent":200,"memoryRequestToLimitPercent":50}}}}
     creationTimestamp: "2019-12-18T22:35:02Z"
     generation: 1
     name: cluster
     resourceVersion: "127622"
     selfLink: /apis/operator.autoscaling.openshift.io/v1/clusterresourceoverrides/cluster
     uid: 978fc959-1717-4bd1-97d0-ae00ee111e8d
   spec:
     podResourceOverride:
       spec:
         cpuRequestToLimitPercent: 25
         limitCPUToMemoryPercent: 200
         memoryRequestToLimitPercent: 50
   status:
   
   ....
   
       mutatingWebhookConfigurationRef: 1
         apiVersion: admissionregistration.k8s.io/v1beta1
         kind: MutatingWebhookConfiguration
         name: clusterresourceoverrides.admission.autoscaling.openshift.io
         resourceVersion: "127621"
         uid: 98b3b8ae-d5ce-462b-8ab5-a729ea8f38f3
   
   ....

   1

   ClusterResourceOverride 受付 Webhook への参照。

1. ClusterResourceOverride CR を編集します。

   apiVersion: operator.autoscaling.openshift.io/v1
   kind: ClusterResourceOverride
   metadata:
       name: cluster
   spec:
     podResourceOverride:
       spec:
         memoryRequestToLimitPercent: 50 1
         cpuRequestToLimitPercent: 25 2
         limitCPUToMemoryPercent: 200 3

   1

   オプション:コンテナーメモリーの制限を上書きするためのパーセンテージが使用される場合は、これを 1-100 までの値で指定します。デフォルトは 50 です。

   2

   オプション:コンテナー CPU の制限を上書きするためのパーセンテージが使用される場合は、これを 1-100 までの値で指定します。デフォルトは 25 です。

   3

   オプション:コンテナーメモリーの制限を上書きするためのパーセンテージが使用される場合は、これを指定します。1Gi の RAM の 100 パーセントでのスケーリングは、1 CPU コアに等しくなります。これは、CPU 要求を上書きする前に処理されます (設定されている場合)。デフォルトは 200 です。

2. 以下のラベルが Cluster Resource Override Operator がオーバーコミットを制御する必要のある各プロジェクトの namespace オブジェクトに追加されていることを確認します。

   apiVersion: v1
   kind: Namespace
   metadata:
   
    ...
   
     labels:
       clusterresourceoverrides.admission.autoscaling.openshift.io/enabled: "true" 1
   
    ...

   1

   このラベルを各プロジェクトに追加します。

前提条件

1. 設定するノードタイプの静的な MachineConfigPool CRD に関連付けられたラベルを取得します。以下のいずれかの手順を実行します。

   1. マシン設定プールを表示します。

      $ 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: small-pods 1

      1

      ラベルが追加されると、labels の下に表示されます。

   2. ラベルが存在しない場合は、キー/値のペアを追加します。

      $ oc label machineconfigpool worker custom-kubelet=small-pods

手順

1. 設定変更のためのカスタムリソース (CR) を作成します。

   CPU 制限を無効化する設定例

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: disable-cpu-units 1
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: small-pods 2
     kubeletConfig:
       cpuCfsQuota: 3
         - "false"

   1

   CR に名前を割り当てます。

   2

   設定の変更を適用するラベルを指定します。

   3

   cpuCfsQuota パラメーターを false に設定します。

1. プロジェクトのオブジェクトファイルを編集します。

2. 以下のアノテーションを追加します。

   quota.openshift.io/cluster-resource-override-enabled: "false"

3. プロジェクトのオブジェクトを作成します。

   $ oc create -f <file-name>.yaml

1. 1 つ以上の Pod で現在実行されているイメージの一覧
2. ホストで利用可能なイメージの一覧

前提条件

1. 設定するノードタイプの静的な MachineConfigPool CRD に関連付けられたラベルを取得します。以下のいずれかの手順を実行します。

   1. マシン設定プールを表示します。

      $ oc describe machineconfigpool <name>

      以下に例を示します。

      $ oc describe machineconfigpool worker

      出力例

      Name:         worker
      Namespace:
      Labels:       custom-kubelet=small-pods 1

      1

      ラベルが追加されると、Labels の下に表示されます。

   2. ラベルが存在しない場合は、キー/値のペアを追加します。

      $ oc label machineconfigpool worker custom-kubelet=small-pods

手順

1. 設定変更のためのカスタムリソース (CR) を作成します。

   重要

   ファイルシステムが 1 つの場合、または /var/lib/kubelet と /var/lib/containers/ が同じファイルシステムにある場合、最も大きな値の設定が満たされるとエビクションがトリガーされます。ファイルシステムはエビクションをトリガーします。

   コンテナーのガベージコレクション CR のサンプル設定:

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: worker-kubeconfig 1
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: small-pods 2
     kubeletConfig:
       evictionSoft: 3
         memory.available: "500Mi" 4
         nodefs.available: "10%"
         nodefs.inodesFree: "5%"
         imagefs.available: "15%"
         imagefs.inodesFree: "10%"
       evictionSoftGracePeriod:  5
         memory.available: "1m30s"
         nodefs.available: "1m30s"
         nodefs.inodesFree: "1m30s"
         imagefs.available: "1m30s"
         imagefs.inodesFree: "1m30s"
       evictionHard: 6
         memory.available: "200Mi"
         nodefs.available: "5%"
         nodefs.inodesFree: "4%"
         imagefs.available: "10%"
         imagefs.inodesFree: "5%"
       evictionPressureTransitionPeriod: 0s 7
       imageMinimumGCAge: 5m 8
       imageGCHighThresholdPercent: 80 9
       imageGCLowThresholdPercent: 75 10

   1

   オブジェクトの名前。

   2

   セレクターラベル。

   3

   エビクションのタイプ: evictionSoft または evictionHard。

   4

   特定のエビクショントリガーシグナルに基づくエビクションのしきい値。

   5

   ソフトエビクションの猶予期間。このパラメーターは、eviction-hard には適用されません。

   6

   特定のエビクショントリガーシグナルに基づくエビクションのしきい値。evictionHard の場合、これらのパラメーターをすべて指定する必要があります。すべてのパラメーターを指定しないと、指定したパラメーターのみが適用され、ガベージコレクションが正しく機能しません。

   7

   エビクション不足の状態から移行するまでの待機時間。

   8

   ガベージコレクションによって削除されるまでの未使用のイメージの有効期間。

   9

   イメージのガべージコレクションをトリガーするディスク使用量のパーセント (整数で表される) です。

   10

   イメージのガべージコレクションが解放しようとするディスク使用量のパーセント (整数で表される) です。

2. オブジェクトを作成します。

   $ oc create -f <file-name>.yaml

   以下に例を示します。

   $ oc create -f gc-container.yaml

   出力例

   kubeletconfig.machineconfiguration.openshift.io/gc-container created

3. ガベージコレクションがアクティブであることを確認します。カスタムリソースで指定した Machine Config Pool では、変更が完全に実行されるまで UPDATING が 'true` と表示されます。

   $ oc get machineconfigpool

   出力例

   NAME     CONFIG                                   UPDATED   UPDATING
   master   rendered-master-546383f80705bd5aeaba93   True      False
   worker   rendered-worker-b4c51bb33ccaae6fc4a6a5   False     True

手順

1. 以下を実行します。

   $ oc get Tuned/default -o yaml -n openshift-cluster-node-tuning-operator

手順

1. ポリシールールを作成します。

   1. <policy_name>.yaml ファイルを作成します。

      $ touch <policy_name>.yaml

      ここでは、以下のようになります。

      <policy_name>

      ネットワークポリシーファイル名を指定します。

   2. 作成したばかりのファイルで、以下の例のようなネットワークポリシーを定義します。

      すべての namespace のすべての Pod から ingress を拒否します。

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: deny-by-default
      spec:
        podSelector:
        ingress: []

      同じ namespace のすべての Pod から ingress を許可します。

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: allow-same-namespace
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}

2. ネットワークポリシーオブジェクトを作成するには、以下のコマンドを入力します。

   $ oc apply -f <policy_name>.yaml -n <namespace>

   ここでは、以下のようになります。

   <policy_name>

   ネットワークポリシーファイル名を指定します。

   <namespace>

   オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

   出力例

   networkpolicy "default-deny" created

手順

1. 以下の NetworkPolicy オブジェクトを作成します。

   1. allow-from-openshift-ingress という名前のポリシー:

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-ingress
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                policy-group.network.openshift.io/ingress: ""
        podSelector: {}
        policyTypes:
        - Ingress
      EOF

   2. allow-from-openshift-monitoring という名前のポリシー。

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-monitoring
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: monitoring
        podSelector: {}
        policyTypes:
        - Ingress
      EOF

   3. allow-same-namespace という名前のポリシー:

      $ cat << EOF| oc create -f -
      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: allow-same-namespace
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}
      EOF

2. オプション: 以下のコマンドを実行し、ネットワークポリシーオブジェクトが現在のプロジェクトに存在することを確認します。

   $ oc describe networkpolicy

   出力例

   Name:         allow-from-openshift-ingress
   Namespace:    example1
   Created on:   2020-06-09 00:28:17 -0400 EDT
   Labels:       <none>
   Annotations:  <none>
   Spec:
     PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
     Allowing ingress traffic:
       To Port: <any> (traffic allowed to all ports)
       From:
         NamespaceSelector: network.openshift.io/policy-group: ingress
     Not affecting egress traffic
     Policy Types: Ingress
   
   
   Name:         allow-from-openshift-monitoring
   Namespace:    example1
   Created on:   2020-06-09 00:29:57 -0400 EDT
   Labels:       <none>
   Annotations:  <none>
   Spec:
     PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
     Allowing ingress traffic:
       To Port: <any> (traffic allowed to all ports)
       From:
         NamespaceSelector: network.openshift.io/policy-group: monitoring
     Not affecting egress traffic
     Policy Types: Ingress

手順

1. cluster-admin 権限を持つユーザーとしてログインしている。

2. デフォルトのプロジェクトテンプレートを生成します。

   $ oc adm create-bootstrap-project-template -o yaml > template.yaml

3. オブジェクトを追加するか、または既存オブジェクトを変更することにより、テキストエディターで生成される template.yaml ファイルを変更します。

4. プロジェクトテンプレートは、openshift-config namespace に作成される必要があります。変更したテンプレートを読み込みます。

   $ oc create -f template.yaml -n openshift-config

5. Web コンソールまたは CLI を使用し、プロジェクト設定リソースを編集します。

   • Web コンソールの使用

     1. Administration → Cluster Settings ページに移動します。
     2. Global Configuration をクリックし、すべての設定リソースを表示します。
     3. Project のエントリーを見つけ、Edit YAML をクリックします。

   • CLI の使用

     1. project.config.openshift.io/cluster リソースを編集します。

        $ oc edit project.config.openshift.io/cluster

6. spec セクションを、projectRequestTemplate および name パラメーターを組み込むように更新し、アップロードされたプロジェクトテンプレートの名前を設定します。デフォルト名は project-request です。

   カスタムプロジェクトテンプレートを含むプロジェクト設定リソース

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestTemplate:
       name: <template_name>

7. 変更を保存した後、変更が正常に適用されたことを確認するために、新しいプロジェクトを作成します。