インストール後の設定

手順

1. Azure アカウントにログインします。

   $ az login

2. ストレージアカウントを作成し、arm64 仮想ハードディスク (VHD) をストレージアカウントにアップロードします。OpenShift Container Platform インストールプログラムはリソースグループを作成しますが、ブートイメージをカスタムの名前付きリソースグループにアップロードすることもできます。

   $ az storage account create -n ${STORAGE_ACCOUNT_NAME} -g ${RESOURCE_GROUP} -l westus --sku Standard_LRS 1

   1

   westus オブジェクトはリージョンの例です。

3. 生成したストレージアカウントを使用してストレージコンテナーを作成します。

   $ az storage container create -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME}

4. URL と ARM64 VHD 名を抽出するには、OpenShift Container Platform インストールプログラムの JSON ファイルを使用する必要があります。

   1. 次のコマンドを実行して、URL フィールドを抽出し、ファイル名として RHCOS_VHD_ORIGIN_URL に設定します。

      $ RHCOS_VHD_ORIGIN_URL=$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.aarch64."rhel-coreos-extensions"."azure-disk".url')

   2. 次のコマンドを実行して、aarch64 VHD 名を抽出し、ファイル名として BLOB_NAME に設定します。

      $ BLOB_NAME=rhcos-$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.aarch64."rhel-coreos-extensions"."azure-disk".release')-azure.aarch64.vhd

5. Shared Access Signature (SAS) トークンを生成します。このトークンを使用して、次のコマンドで RHCOS VHD をストレージコンテナーにアップロードします。

   $ end=`date -u -d "30 minutes" '+%Y-%m-%dT%H:%MZ'`

   $ sas=`az storage container generate-sas -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME} --https-only --permissions dlrw --expiry $end -o tsv`

6. RHCOS VHD をストレージコンテナーにコピーします。

   $ az storage blob copy start --account-name ${STORAGE_ACCOUNT_NAME} --sas-token "$sas" \
    --source-uri "${RHCOS_VHD_ORIGIN_URL}" \
    --destination-blob "${BLOB_NAME}" --destination-container ${CONTAINER_NAME}

   次のコマンドを使用して、コピープロセスのステータスを確認できます。

   $ az storage blob show -c ${CONTAINER_NAME} -n ${BLOB_NAME} --account-name ${STORAGE_ACCOUNT_NAME} | jq .properties.copy

   出力例

   {
    "completionTime": null,
    "destinationSnapshot": null,
    "id": "1fd97630-03ca-489a-8c4e-cfe839c9627d",
    "incrementalCopy": null,
    "progress": "17179869696/17179869696",
    "source": "https://rhcos.blob.core.windows.net/imagebucket/rhcos-411.86.202207130959-0-azure.aarch64.vhd",
    "status": "success", 1
    "statusDescription": null
   }

   1

   status パラメーターに success オブジェクトが表示されたら、コピープロセスは完了です。

7. 次のコマンドを使用してイメージギャラリーを作成します。

   $ az sig create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME}

   イメージギャラリーを使用してイメージ定義を作成します。次のコマンド例では、rhcos-arm64 がイメージ定義の名前です。

   $ az sig image-definition create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME} --gallery-image-definition rhcos-arm64 --publisher RedHat --offer arm --sku arm64 --os-type linux --architecture Arm64 --hyper-v-generation V2

8. VHD の URL を取得してファイル名として RHCOS_VHD_URL に設定するには、次のコマンドを実行します。

   $ RHCOS_VHD_URL=$(az storage blob url --account-name ${STORAGE_ACCOUNT_NAME} -c ${CONTAINER_NAME} -n "${BLOB_NAME}" -o tsv)

9. RHCOS_VHD_URL ファイル、ストレージアカウント、リソースグループ、およびイメージギャラリーを使用して、イメージバージョンを作成します。次の例では、1.0.0 がイメージバージョンです。

   $ az sig image-version create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME} --gallery-image-definition rhcos-arm64 --gallery-image-version 1.0.0 --os-vhd-storage-account ${STORAGE_ACCOUNT_NAME} --os-vhd-uri ${RHCOS_VHD_URL}

10. arm64 ブートイメージが生成されました。次のコマンドを使用して、イメージの ID にアクセスできます。

    $ az sig image-version show -r $GALLERY_NAME -g $RESOURCE_GROUP -i rhcos-arm64 -e 1.0.0

    次の例のイメージ ID は、コンピュートマシンセットの recourseID パラメーターで使用されます。

    resourceID の例

    /resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Compute/galleries/${GALLERY_NAME}/images/rhcos-arm64/versions/1.0.0

検証

1. 次のコマンドを入力して、新しい ARM64 マシンが実行されていることを確認します。

   $ oc get machineset -n openshift-machine-api

   出力例

   NAME                                                DESIRED  CURRENT  READY  AVAILABLE  AGE
   <infrastructure_id>-arm64-machine-set-0                   2        2      2          2  10m

2. 次のコマンドを使用すると、ノードの準備ができており、スケジュール可能であることを確認できます。

   $ oc get nodes

検証

1. 次のコマンドを入力して、コンピューティングマシンセットのリストを表示します。

   $ oc get machineset -n openshift-machine-api

   作成した ARM64 マシンセットを確認できます。

   出力例

   NAME                                                DESIRED  CURRENT  READY  AVAILABLE  AGE
   <infrastructure_id>-aws-arm64-machine-set-0                   2        2      2          2  10m

2. 次のコマンドを使用すると、ノードの準備ができており、スケジュール可能であることを確認できます。

   $ oc get nodes

手順

1. 次のコマンドを実行して、クラスターから Ignition 設定ファイルを抽出します。

   $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign

2. クラスターからエクスポートした worker.ign Ignition 設定ファイルを HTTP サーバーにアップロードします。これらのファイルの URL をメモします。

3. Ignition ファイルが URL で利用可能であることを検証できます。次の例では、コンピュートノードの Ignition 設定ファイルを取得します。

   $ curl -k http://<HTTP_server>/worker.ign

4. 次のコマンドを実行すると、新しいマシンを起動するための ISO イメージにアクセスできます。

   RHCOS_VHD_ORIGIN_URL=$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.<architecture>.artifacts.metal.formats.iso.disk.location')

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

   • ディスクに ISO イメージを書き込み、これを直接起動します。
   • LOM インターフェイスで ISO リダイレクトを使用します。

6. オプションを指定したり、ライブ起動シーケンスを中断したりせずに、RHCOS ISO イメージを起動します。インストーラーが RHCOS ライブ環境でシェルプロンプトを起動するのを待ちます。

   注記

   RHCOS インストールの起動プロセスを中断して、カーネル引数を追加できます。ただし、この ISO 手順では、カーネル引数を追加する代わりに、次の手順で概説するように coreos-installer コマンドを使用する必要があります。

7. coreos-installer コマンドを実行し、インストール要件を満たすオプションを指定します。少なくとも、ノードタイプの Ignition 設定ファイルを参照する URL と、インストール先のデバイスを指定する必要があります。

   $ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> --ignition-hash=sha512-<digest> 12

   1

   コア ユーザーにはインストールを実行するために必要な root 権限がないため、sudo を使用して coreos-installer コマンドを実行する必要があります。

   2

   --ignition-hash オプションは、Ignition 設定ファイルを HTTP URL を使用して取得し、クラスターノードの Ignition 設定ファイルの信頼性を検証するために必要です。<digest> は、先の手順で取得した Ignition 設定ファイル SHA512 ダイジェストです。

   注記

   TLS を使用する HTTPS サーバーを使用して Ignition 設定ファイルを提供する場合は、coreos-installer を実行する前に、内部認証局 (CA) をシステムのトラストストアに追加できます。

   以下の例では、/dev/sda デバイスへのブートストラップノードのインストールを初期化します。ブートストラップノードの Ignition 設定ファイルは、IP アドレス 192.168.1.2 で HTTP Web サーバーから取得されます。

   $ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b

8. マシンのコンソールで RHCOS インストールの進捗を監視します。

   重要

   OpenShift Container Platform のインストールを開始する前に、各ノードでインストールが成功していることを確認します。インストールプロセスを監視すると、発生する可能性のある RHCOS インストールの問題の原因を特定する上でも役立ちます。

9. 継続してクラスター用の追加のコンピュートマシンを作成します。

手順

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 のみをサポートします。

     注記

     この設定では、グラフィカルコンソールを使用するマシンでシリアルコンソールアクセスを有効にしません。別のコンソールを設定するには、APPEND 行に 1 つ以上の console= 引数を追加します。たとえば、console=tty0 console=ttyS0 を追加して、最初の PC シリアルポートをプライマリーコンソールとして、グラフィカルコンソールをセカンダリーコンソールとして設定します。詳細は、How does one set up a serial terminal and/or console in Red Hat Enterprise Linux? を参照してください。

   • iPXE (x86_ 64 + aarch64):

     kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2
     initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img 3
     boot

     1

     HTTP サーバーにアップロードした RHCOS ファイルの場所を指定します。kernel パラメーター値は kernel ファイルの場所であり、initrd=main 引数は UEFI システムでの起動に必要であり、coreos.live.rootfs_url パラメーター値はワーカー Ignition 設定ファイルの場所であり、coreos.inst.ignition_url パラメーター値は rootfs のライブファイルの場所です。

     2

     複数の NIC を使用する場合、ip オプションに単一インターフェイスを指定します。たとえば、eno1 という名前の NIC で DHCP を使用するには、ip=eno1:dhcp を設定します。

     3

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

     注記

     この設定では、グラフィカルコンソールを備えたマシンでのシリアルコンソールアクセスは有効になりません。別のコンソールを設定するには、kernel 行に 1 つ以上の console= 引数を追加します。たとえば、console=tty0 console=ttyS0 を追加して、最初の PC シリアルポートをプライマリーコンソールとして、グラフィカルコンソールをセカンダリーコンソールとして設定します。詳細は、How does one set up a serial terminal and/or console in Red Hat Enterprise Linux? と、「高度な RHCOS インストール設定」セクションの「PXE および ISO インストール用シリアルコンソールの有効化」を参照してください。

     注記

     aarch64 アーキテクチャーで CoreOS kernel をネットワークブートするには、IMAGE_GZIP オプションが有効になっているバージョンの iPXE ビルドを使用する必要があります。iPXE の IMAGE_GZIP オプション を参照してください。

   • aarch64 上の PXE (第 2 段階として UEFI および GRUB を使用) の場合:

     menuentry 'Install CoreOS' {
         linux rhcos-<version>-live-kernel-<architecture>  coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2
         initrd rhcos-<version>-live-initramfs.<architecture>.img 3
     }

     1

     HTTP/TFTP サーバーにアップロードした RHCOS ファイルの場所を指定します。kernel パラメーター値は、TFTP サーバー上の kernel ファイルの場所になります。coreos.live.rootfs_url パラメーター値は rootfs ファイルの場所であり、coreos.inst.ignition_url パラメーター値は HTTP サーバー上のブートストラップ Ignition 設定ファイルの場所になります。

     2

     複数の NIC を使用する場合、ip オプションに単一インターフェイスを指定します。たとえば、eno1 という名前の NIC で DHCP を使用するには、ip=eno1:dhcp を設定します。

     3

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

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

手順

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

   $ oc get nodes

   出力例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  63m  v1.26.0
   master-1  Ready     master  63m  v1.26.0
   master-2  Ready     master  64m  v1.26.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 によって自動的に承認されます。

   注記

   ベアメタルおよび他の user-provisioned infrastructure などのマシン 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.26.0
   master-1  Ready     master  73m  v1.26.0
   master-2  Ready     master  74m  v1.26.0
   worker-0  Ready     worker  11m  v1.26.0
   worker-1  Ready     worker  11m  v1.26.0

   注記

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

1. 遮断。MCO は、ノードを追加のワークロードに対してスケジュール不可としてマークします。
2. ドレイン。MCO は、ノード上で実行中のすべてのワークロードを終了します。その結果、ワークロードが他のノードに再スケジュールされます。
3. 適用。MCO は、必要に応じて新しい設定をノードに書き込みます。
4. 再起動します。MCO はノードを再起動します。
5. 遮断解除。MCO は、ノードをワークロードに対してスケジュール可能としてマークします。

手順

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 つがまだ更新中です。DEGRADEDMACHINECOUNT が 0 で、DEGRADED が 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.2.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 ファイルのコンテンツを含む Butane 設定を作成します。たとえば、ワーカーノードで chrony を設定するには、99-worker-chrony.bu ファイルを作成します。

   注記

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

   variant: openshift
   version: 4.13.0
   metadata:
     name: 99-worker-chrony 1
     labels:
       machineconfiguration.openshift.io/role: worker 2
   storage:
     files:
     - path: /etc/chrony.conf
       mode: 0644 3
       overwrite: true
       contents:
         inline: |
           pool 0.rhel.pool.ntp.org iburst 4
           driftfile /var/lib/chrony/drift
           makestep 1.0 3
           rtcsync
           logdir /var/log/chrony

   1 2

   コントロールプレーンノードでは、これらの両方の場所で worker の代わりに master を使用します。

   3

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

   4

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

2. Butane を使用して、ノードに配信される設定を含む MachineConfig オブジェクトファイル (99-worker-chrony.yaml) を生成します。

   $ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml

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

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

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

     $ oc apply -f ./99-worker-chrony.yaml

手順

1. 指定されたノードロールの chronyd を無効にする MachineConfig CR を作成します。

   1. 以下の YAML を disable-chronyd.yaml ファイルに保存します。

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: <node_role> 1
        name: disable-chronyd
      spec:
        config:
          ignition:
            version: 3.2.0
          systemd:
            units:
              - contents: |
                  [Unit]
                  Description=NTP client/server
                  Documentation=man:chronyd(8) man:chrony.conf(5)
                  After=ntpdate.service sntp.service ntpd.service
                  Conflicts=ntpd.service systemd-timesyncd.service
                  ConditionCapability=CAP_SYS_TIME
                  [Service]
                  Type=forking
                  PIDFile=/run/chrony/chronyd.pid
                  EnvironmentFile=-/etc/sysconfig/chronyd
                  ExecStart=/usr/sbin/chronyd $OPTIONS
                  ExecStartPost=/usr/libexec/chrony-helper update-daemon
                  PrivateTmp=yes
                  ProtectHome=yes
                  ProtectSystem=full
                  [Install]
                  WantedBy=multi-user.target
                enabled: false
                name: "chronyd.service"

      1

      chronyd を無効にするノードロール (例: master)。

   2. 以下のコマンドを実行して MachineConfig CR を作成します。

      $ oc create -f disable-chronyd.yaml

手順

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

   $ oc get MachineConfig

   出力例

   NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
   00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-master-ssh                                                                                 3.2.0             40m
   99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-worker-ssh                                                                                 3.2.0             40m
   rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

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:
     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                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   05-worker-kernelarg-selinuxpermissive                                                         3.2.0             105s
   99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-master-ssh                                                                                 3.2.0             40m
   99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-worker-ssh                                                                                 3.2.0             40m
   rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

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

   $ oc get nodes

   出力例

   NAME                           STATUS                     ROLES    AGE   VERSION
   ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.26.0
   ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.26.0
   ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.26.0
   ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.26.0
   ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.26.0
   ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.26.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. インストール後にコントロールプレーンノードでマルチパスを有効にするには、以下を実行します。

   • 以下の例のように、master ラベルを追加し、マルチパスカーネル引数を特定するようクラスターに指示する 99-master-kargs-mpath.yaml などのマシン設定ファイルを作成します。

     apiVersion: machineconfiguration.openshift.io/v1
     kind: MachineConfig
     metadata:
       labels:
         machineconfiguration.openshift.io/role: "master"
       name: 99-master-kargs-mpath
     spec:
       kernelArguments:
         - 'rd.multipath=default'
         - 'root=/dev/disk/by-label/dm-mpath-root'

2. インストール後にワーカーノードでマルチパスを有効にするには、以下を実行します。

   • worker ラベルを追加し、マルチパスカーネル引数などを特定するようクラスターに指示する 99-worker-kargs-mpath.yaml などのマシン設定ファイルを作成します。

     apiVersion: machineconfiguration.openshift.io/v1
     kind: MachineConfig
     metadata:
       labels:
         machineconfiguration.openshift.io/role: "worker"
       name: 99-worker-kargs-mpath
     spec:
       kernelArguments:
         - 'rd.multipath=default'
         - 'root=/dev/disk/by-label/dm-mpath-root'

3. 以前に作成したマスターまたはワーカー YAML ファイルのいずれかを使用して新規のマシン設定を作成します。

   $ oc create -f ./99-worker-kargs-mpath.yaml

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

   $ oc get MachineConfig

   出力例

   NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
   00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-master-ssh                                                                                 3.2.0             40m
   99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-worker-kargs-mpath                              52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             105s
   99-worker-ssh                                                                                 3.2.0             40m
   rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

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

   $ oc get nodes

   出力例

   NAME                           STATUS                     ROLES    AGE   VERSION
   ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.26.0
   ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.26.0
   ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.26.0
   ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.26.0
   ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.26.0
   ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.26.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
   ...
   rd.multipath=default root=/dev/disk/by-label/dm-mpath-root
   ...
   
   sh-4.2# exit

   追加したカーネル引数が表示されるはずです。

手順

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.26.0
   ip-10-0-146-92.us-east-2.compute.internal   Ready   worker   101m  v1.26.0
   ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.26.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 ファイルが含まれる Butane 設定ファイル 40-worker-custom -journald.bu を作成します。

   注記

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

   variant: openshift
   version: 4.13.0
   metadata:
     name: 40-worker-custom-journald
     labels:
       machineconfiguration.openshift.io/role: worker
   storage:
     files:
     - path: /etc/systemd/journald.conf
       mode: 0644
       overwrite: true
       contents:
         inline: |
           # Disable rate limiting
           RateLimitInterval=1s
           RateLimitBurst=10000
           Storage=volatile
           Compress=no
           MaxRetentionSec=30s

2. Butane を使用して、ワーカーノードに配信される設定を含む MachineConfig オブジェクトファイル (40-worker-custom-journald.yaml) を生成します。

   $ butane 40-worker-custom-journald.bu -o 40-worker-custom-journald.yaml

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

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

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
   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. 拡張機能のマシン設定を作成します。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.2.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.2.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.26.0

   $ 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.13.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. オペレーティングシステムでサポートされているツールを使用して、ハッシュ化されたパスワードを作成します。たとえば次のコマンドを実行し、mkpasswd を使用してハッシュ化されたパスワードを作成します。

   $ mkpasswd -m SHA-512 testpass

   出力例

   $ $6$CBZwA6s6AVFOtiZe$aUKDWpthhJEyR3nnhM02NM1sKCpHn9XN.NPrJNQ3HYewioaorpwL3mKGLxvW0AOb4pJxqoqP4nFX77y0p00.8.

2. core ユーザー名とハッシュ化されたパスワードを含むマシン設定ファイルを作成します。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: set-core-user-password
   spec:
     config:
       ignition:
         version: 3.2.0
       passwd:
         users:
         - name: core 1
           passwordHash: <password> 2

   1

   これは core である必要があります。

   2

   core アカウントで使用するハッシュ化されたパスワード。

3. 次のコマンドを実行して、マシン設定を作成します。

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

   ノードは再起動せず、しばらくすると使用可能になります。次の例に示すように、oc get mcp を使用して、マシン設定プールが更新されるのを監視できます。

   NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master   rendered-master-d686a3ffc8fdec47280afec446fce8dd   True      False      False      3              3                   3                     0                      64m
   worker   rendered-worker-4605605a5b1f9de1d061e9d350f251e5   False     True       False      3              0                   0                     0                      64m

検証

1. ノードが UPDATED=True 状態に戻ったら、次のコマンドを実行してノードのデバッグセッションを開始します。

   $ oc debug node/<node_name>

2. 次のコマンドを実行して、デバッグシェル内のルートディレクトリーとして /host を設定します。

   sh-4.4# chroot /host

3. /etc/shadow ファイルの内容を確認します。

   出力例

   ...
   core:$6$2sE/010goDuRSxxv$o18K52wor.wIwZp:19418:0:99999:7:::
   ...

   ハッシュ化されたパスワードは、core ユーザーに割り当てられます。

前提条件

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

   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: set-max-pods 1

      1

      ラベルが追加されると、labels の下に表示されます。

   2. ラベルが存在しない場合は、キー/値のペアを追加します。

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods

手順

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

   $ oc get machineconfig

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

2. ノードあたりの最大 Pod の現在の値を確認します。

   $ oc describe node <node_name>

   以下に例を示します。

   $ oc describe node ci-ln-5grqprb-f76d1-ncnqq-worker-a-mdv94

   Allocatable スタンザで value: pods: <value> を検索します。

   出力例

   Allocatable:
    attachable-volumes-aws-ebs:  25
    cpu:                         3500m
    hugepages-1Gi:               0
    hugepages-2Mi:               0
    memory:                      15341844Ki
    pods:                        250

3. ワーカーノードでノードあたりの最大の Pod を設定するには、kubelet 設定を含むカスタムリソースファイルを作成します。

   重要

   特定のマシン設定プールをターゲットとする kubelet 設定は、依存するプールにも影響します。たとえば、ワーカーノードを含むプール用の kubelet 設定を作成すると、インフラストラクチャーノードを含むプールを含むすべてのサブセットプールにも設定が適用されます。これを回避するには、ワーカーノードのみを含む選択式を使用して新しいマシン設定プールを作成し、kubelet 設定でこの新しいプールをターゲットにする必要があります。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: set-max-pods
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: set-max-pods 1
     kubeletConfig:
       maxPods: 500 2

   1

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

   2

   kubelet 設定を追加します。この例では、maxPods を使用してノードあたりの最大 Pod を設定します。

   注記

   kubelet が API サーバーと通信する速度は、1 秒あたりのクエリー (QPS) およびバースト値により異なります。デフォルト値の 50 (kubeAPIQPS の場合) および 100 (kubeAPIBurst の場合) は、各ノードで制限された Pod が実行されている場合には十分な値です。ノード上に CPU およびメモリーリソースが十分にある場合には、kubelet QPS およびバーストレートを更新することが推奨されます。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: set-max-pods
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: set-max-pods
     kubeletConfig:
       maxPods: <pod_count>
       kubeAPIBurst: <burst_rate>
       kubeAPIQPS: <QPS>

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

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods

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

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

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

      $ oc get kubeletconfig

      出力例

      NAME                AGE
      set-max-pods        15m

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

4. 変更がノードに適用されていることを確認します。

   1. maxPods 値が変更されたワーカーノードで確認します。

      $ oc describe node <node_name>

   2. Allocatable スタンザを見つけます。

       ...
      Allocatable:
        attachable-volumes-gce-pd:  127
        cpu:                        3500m
        ephemeral-storage:          123201474766
        hugepages-1Gi:              0
        hugepages-2Mi:              0
        memory:                     14225400Ki
        pods:                       500 1
       ...

      1

      この例では、pods パラメーターは KubeletConfig オブジェクトに設定した値を報告するはずです。

5. KubeletConfig オブジェクトの変更を確認します。

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

   これは、以下の例のように True および type:Success のステータスを表示します。

   spec:
     kubeletConfig:
       maxPods: 500
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: set-max-pods
   status:
     conditions:
     - lastTransitionTime: "2021-06-30T17:04:07Z"
       message: Success
       status: "True"
       type: Success

1. ContainerRuntimeConfig CR の YAML ファイルを作成します。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: ContainerRuntimeConfig
   metadata:
    name: overlay-size
   spec:
    machineConfigPoolSelector:
      matchLabels:
        pools.operator.machineconfiguration.openshift.io/worker: '' 1
    containerRuntimeConfig: 2
      logLevel: debug
      overlaySize: 8G

   1

   変更する必要のあるマシン設定プールのラベルを指定します。

   2

   必要に応じてパラメーターを設定します。

2. ContainerRuntimeConfig CR を作成します。

   $ oc create -f <file_name>.yaml

3. CR が作成されたことを確認します。

   $ oc get ContainerRuntimeConfig

   出力例

   NAME           AGE
   overlay-size   3m19s

4. 新規の containerruntime マシン設定が作成されていることを確認します。

   $ oc get machineconfigs | grep containerrun

   出力例

   99-worker-generated-containerruntime   2c9371fbb673b97a6fe8b1c52691999ed3a1bfc2  3.2.0  31s

5. すべてが準備状態にあるものとして表示されるまでマシン設定プールをモニターします。

   $ 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

6. 設定が CRI-O で適用されたことを確認します。

   1. マシン設定プールのノードに対して oc debug セッションを開き、chroot /host を実行します。

      $ oc debug node/<node_name>

      sh-4.4# chroot /host

   2. crio.conf ファイルの変更を確認します。

      sh-4.4# crio config | grep 'log_level'

      出力例

      log_level = "debug"

   3. `storage.conf` ファイルの変更を確認します。

      sh-4.4# head -n 7 /etc/containers/storage.conf

      出力例

      [storage]
        driver = "overlay"
        runroot = "/var/run/containers/storage"
        graphroot = "/var/lib/containers/storage"
        [storage.options]
          additionalimagestores = []
          size = "8G"

手順

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   3.2.0             7m42s
   rendered-worker-xyz                   4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.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/delete-machine="true"

4. 次のいずれかのコマンドを実行して、コンピュートマシンセットをスケーリングします。

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

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

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

   ヒント

   または、以下の YAML を適用してコンピュートマシンセットをスケーリングすることもできます。

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineSet
   metadata:
     name: <machineset>
     namespace: openshift-machine-api
   spec:
     replicas: 2

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

   重要

   デフォルトでは、マシンコントローラーは、成功するまでマシンによってサポートされるノードをドレイン (解放) しようとします。Pod 中断バジェットの設定が間違っているなど、状況によっては、ドレイン操作が成功しない可能性があります。排水操作が失敗した場合、マシンコントローラーはマシンの取り外しを続行できません。

   特定のマシンの machine.openshift.io/exclude-node-draining にアノテーションを付けると、ノードのドレイン (解放) を省略できます。

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

   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

        ヒント

        あるいは、以下の YAML を適用してコンピュートマシンセットにラベルを追加することもできます。

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
        metadata:
          name: <machineset>
          namespace: openshift-machine-api
        spec:
          template:
            spec:
              metadata:
                labels:
                  region: "east"
                  type: "user-node"

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

        以下に例を示します。

        $ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

        MachineSet オブジェクトの例

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
          ...
        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.26.0

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

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

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

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

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

        ヒント

        あるいは、以下の YAML を適用してノードにラベルを追加することもできます。

        kind: Node
        apiVersion: v1
        metadata:
          name: <node_name>
          labels:
            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.26.0

手順

1. ローカルゾーンのサブネットで動作するエッジワーカーノードにデプロイされるサンプルアプリケーションの deployment リソース YAML ファイルを作成します。エッジワーカーノードのテイントに一致する正しい許容値を指定していることを確認してください。

   ローカルゾーンのサブネットで動作するエッジワーカーノード用に設定された deployment リソースの例

   kind: Namespace
   apiVersion: v1
   metadata:
     name: <local_zone_application_namespace>
   ---
   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: <pvc_name>
     namespace: <local_zone_application_namespace>
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 10Gi
     storageClassName: gp2-csi 1
     volumeMode: Filesystem
   ---
   apiVersion: apps/v1
   kind: Deployment 2
   metadata:
     name: <local_zone_application> 3
     namespace: <local_zone_application_namespace> 4
   spec:
     selector:
       matchLabels:
         app: <local_zone_application>
     replicas: 1
     template:
       metadata:
         labels:
           app: <local_zone_application>
           zone-group: ${ZONE_GROUP_NAME} 5
       spec:
         securityContext:
           seccompProfile:
             type: RuntimeDefault
         nodeSelector: 6
           machine.openshift.io/zone-group: ${ZONE_GROUP_NAME}
         tolerations: 7
         - key: "node-role.kubernetes.io/edge"
           operator: "Equal"
           value: ""
           effect: "NoSchedule"
         containers:
           - image: openshift/origin-node
             command:
              - "/bin/socat"
             args:
               - TCP4-LISTEN:8080,reuseaddr,fork
               - EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"'
             imagePullPolicy: Always
             name: echoserver
             ports:
               - containerPort: 8080
             volumeMounts:
               - mountPath: "/mnt/storage"
                 name: data
         volumes:
         - name: data
           persistentVolumeClaim:
             claimName: <pvc_name>

   1

   storageClassName: ローカルゾーン設定の場合、gp2-csi を指定する必要があります。

   2

   kind: deployment リソースを定義します。

   3

   name: Local Zone アプリケーションの名前を指定します。たとえば、local-zone-demo-app-nyc-1 です。

   4

   namespace: ユーザーワークロードを実行する AWS Local Zone 用の namespace を定義します。例: local-zone-app-nyc-1a

   5

   zone-group: ゾーンが属するグループを定義します。たとえば、us-east-1-iah-1

   6

   nodeSelector: 指定されたラベルに一致するエッジワーカーノードをターゲットとします。

   7

   tolerations: Local Zone ノードの MachineSet マニフェストで定義された taints と一致する値を設定します。

2. ノードの service リソース YAML ファイルを作成します。このリソースは、対象のエッジワーカーノードからローカルゾーンネットワーク内で実行されるサービスに Pod を公開します。

   ローカルゾーンのサブネットで動作するエッジワーカーノード用に設定された service リソースの例

   apiVersion: v1
   kind: Service 1
   metadata:
     name:  <local_zone_application>
     namespace: <local_zone_application_namespace>
   spec:
     ports:
       - port: 80
         targetPort: 8080
         protocol: TCP
     type: NodePort
     selector: 2
       app: <local_zone_application>

   1

   kind: service リソースを定義します。

   2

   selector: マネージド Pod に適用されるラベルタイプを指定します。

1. 中規模のワーカーのレイテンシープロファイルに移動します。

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

      $ oc edit nodes.config/cluster

   2. spec.workerLatencyProfile: MediumUpdateAverageReaction を追加します。

      node.config オブジェクトの例

      apiVersion: config.openshift.io/v1
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v1
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        workerLatencyProfile: MediumUpdateAverageReaction 1
      
      # ...

      1

      中規模のワーカーレイテンシーポリシーを指定します。

      変更が適用されると、各ワーカーノードでのスケジューリングは無効になります。

2. 必要に応じて、ワーカーのレイテンシーが低いプロファイルに移動します。

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

      $ oc edit nodes.config/cluster

   2. spec.workerLatencyProfile の値を LowUpdateSlowReaction に変更します。

      node.config オブジェクトの例

      apiVersion: config.openshift.io/v1
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v1
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        workerLatencyProfile: LowUpdateSlowReaction 1
      
      # ...

      1

      低ワーカーレイテンシーポリシーの使用を指定します。

手順

1. コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。

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

2. オプション: 特定のフィールドに設定する値がわからない場合は、クラスターから既存のコンピュートマシンセットを確認できます。

   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. 特定のコンピュートマシンセットカスタムリソース (CR) 値を表示するには、以下のコマンドを実行します。

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

      出力例

      apiVersion: machine.openshift.io/v1beta1
      kind: MachineSet
      metadata:
        labels:
          machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
        name: <infrastructure_id>-<role> 2
        namespace: openshift-machine-api
      spec:
        replicas: 1
        selector:
          matchLabels:
            machine.openshift.io/cluster-api-cluster: <infrastructure_id>
            machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
        template:
          metadata:
            labels:
              machine.openshift.io/cluster-api-cluster: <infrastructure_id>
              machine.openshift.io/cluster-api-machine-role: <role>
              machine.openshift.io/cluster-api-machine-type: <role>
              machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
          spec:
            providerSpec: 3
              ...

      1

      クラスターインフラストラクチャー ID。

      2

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

      注記

      user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。

      3

      コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細は、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。

3. 次のコマンドを実行して MachineSet CR を作成します。

   $ oc create -f <file_name>.yaml

手順

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: node-role.kubernetes.io/infra="" 1
      # ...

      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   3.2.0             31d
   00-worker                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   01-master-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   01-master-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   01-worker-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   01-worker-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   99-master-1ae2a1e0-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   99-master-ssh                                                                                          3.2.0             31d
   99-worker-1ae64748-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   99-worker-ssh                                                                                          3.2.0             31d
   rendered-infra-4e48906dca84ee702959c71a53ee80e7             365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             23m
   rendered-master-072d4b2da7f88162636902b074e9e28e            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
   rendered-master-3e88ec72aed3886dec061df60d16d1af            02c07496ba0417b3e12b78fb32baf6293d314f79   3.2.0             31d
   rendered-master-419bee7de96134963a15fdf9dd473b25            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             17d
   rendered-master-53f5c91c7661708adce18739cc0f40fb            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             13d
   rendered-master-a6a357ec18e5bce7f5ac426fc7c5ffcd            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             7d3h
   rendered-master-dc7f874ec77fc4b969674204332da037            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
   rendered-worker-1a75960c52ad18ff5dfa6674eb7e533d            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
   rendered-worker-2640531be11ba43c61d72e82dc634ce6            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
   rendered-worker-4e48906dca84ee702959c71a53ee80e7            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             7d3h
   rendered-worker-4f110718fe88e5f349987854a1147755            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             17d
   rendered-worker-afc758e194d6188677eb837842d3b379            02c07496ba0417b3e12b78fb32baf6293d314f79   3.2.0             31d
   rendered-worker-daa08cc1e8f5fcdeba24de60cd955cc3            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.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.2.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. taint を infra ノードに追加し、ユーザーのワークロードをこれにスケジュールできないようにします。

   1. ノードに taint があるかどうかを判別します。

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

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

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

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

      以下に例を示します。

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

      ヒント

      または、以下の YAML を適用して taint を追加できます。

      kind: Node
      apiVersion: v1
      metadata:
        name: <node_name>
        labels:
          ...
      spec:
        taints:
          - key: node-role.kubernetes.io/infra
            effect: NoSchedule
            value: reserved
        ...

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

      注記

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

   3. 上記の NoSchedule Effect の taint とともに、NoExecute Effect の taint を追加します。

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

      以下に例を示します。

      $ oc adm taint nodes node1 node-role.kubernetes.io/infra=reserved:NoExecute

      ヒント

      または、以下の YAML を適用して taint を追加できます。

      kind: Node
      apiVersion: v1
      metadata:
        name: <node_name>
        labels:
          ...
      spec:
        taints:
          - key: node-role.kubernetes.io/infra
            effect: NoExecute
            value: reserved
        ...

      この例では、taint を、node-role.kubernetes.io/infra キーおよび NoExecute effect の taint を持つ node1 に配置します。NoExecute effect を持つノードは、taint を容認する Pod のみをスケジュールします。effect は、一致する toleration を持たないノードから既存の Pod を削除します。

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

   tolerations:
     - effect: NoSchedule 1
       key: node-role.kubernetes.io/infra 2
       value: reserved 3
     - effect: NoExecute 4
       key: node-role.kubernetes.io/infra 5
       operator: Exists 6
       value: reserved 7

   1

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

   2

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

   3

   ノードに追加したキーと値のペア taint の値を指定します。

   4

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

   5

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

   6

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

   7

   ノードに追加したキーと値のペア taint の値を指定します。

   こ toleration は、oc adm taint コマンドで作成された taint と一致します。この toleration のある 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

     spec:
       nodePlacement:
         nodeSelector: 1
           matchLabels:
             node-role.kubernetes.io/infra: ""
         tolerations:
         - effect: NoSchedule
           key: node-role.kubernetes.io/infra
           value: reserved
         - effect: NoExecute
           key: node-role.kubernetes.io/infra
           value: reserved

   1

   適切な値が設定された nodeSelector パラメーターを、移動する必要のあるコンポーネントに追加します。表示されている形式の nodeSelector を使用することも、ノードに指定された値に基づいて <key>: <value> ペアを使用することもできます。インフラストラクチャーノードに taint を追加した場合は、一致する toleration も追加します。

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.26.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

   spec:
     affinity:
       podAntiAffinity:
         preferredDuringSchedulingIgnoredDuringExecution:
         - podAffinityTerm:
             namespaces:
             - openshift-image-registry
             topologyKey: kubernetes.io/hostname
           weight: 100
     logLevel: Normal
     managementState: Managed
     nodeSelector: 1
       node-role.kubernetes.io/infra: ""
     tolerations:
     - effect: NoSchedule
       key: node-role.kubernetes.io/infra
       value: reserved
     - effect: NoExecute
       key: node-role.kubernetes.io/infra
       value: reserved

   1

   適切な値が設定された nodeSelector パラメーターを、移動する必要のあるコンポーネントに追加します。表示されている形式の nodeSelector を使用することも、ノードに指定された値に基づいて <key>: <value> ペアを使用することもできます。インフラストラクチャーノードに taint を追加した場合は、一致する toleration も追加します。

3. レジストリー 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. cluster-monitoring-config config map を編集し、nodeSelector を変更して infra ラベルを使用します。

   $ oc edit configmap cluster-monitoring-config -n openshift-monitoring

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |+
       alertmanagerMain:
         nodeSelector: 1
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       prometheusK8s:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       prometheusOperator:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       k8sPrometheusAdapter:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       kubeStateMetrics:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       telemeterClient:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       openshiftStateMetrics:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       thanosQuerier:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute

   1

   適切な値が設定された nodeSelector パラメーターを、移動する必要のあるコンポーネントに追加します。表示されている形式の nodeSelector を使用することも、ノードに指定された値に基づいて <key>: <value> ペアを使用することもできます。インフラストラクチャーノードにテイントを追加した場合は、一致する容認も追加します。

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

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

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

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

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

手順

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. OpenShift Container Platform Web コンソールで、Administration → Custom Resource Definitions ページに切り替えます。
2. Custom Resource Definitions ページで、FeatureGate をクリックします。
3. Custom Resource Definition Details ページで、Instances タブをクリックします。
4. cluster フィーチャーゲートをクリックし、YAML タブをクリックします。

5. cluster インスタンスを編集して特定の機能セットを追加します。

   警告

   クラスターで TechPreviewNoUpgrade 機能セットを有効にすると、元に戻すことができず、マイナーバージョンの更新が妨げられます。本番クラスターでは、この機能セットを有効にしないでください。

   フィーチャーゲートカスタムリソースのサンプル

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

   1

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

   2

   有効にする機能セットを追加します。

   • TechPreviewNoUpgrade は、特定のテクノロジープレビュー機能を有効にします。

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

1. Web コンソールの Administrator パースペクティブで、Compute → Nodes に移動します。
2. ノードを選択します。
3. Node details ページで Terminal をクリックします。

4. ターミナルウィンドウで、root ディレクトリーを /host に切り替えます。

   sh-4.2# chroot /host

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

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

   出力例

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

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

   注記

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

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

   $ oc edit featuregate cluster

   警告

   クラスターで TechPreviewNoUpgrade 機能セットを有効にすると、元に戻すことができず、マイナーバージョンの更新が妨げられます。本番クラスターでは、この機能セットを有効にしないでください。

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

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

   1

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

   2

   有効にする機能セットを追加します。

   • TechPreviewNoUpgrade は、特定のテクノロジープレビュー機能を有効にします。

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

1. Web コンソールの Administrator パースペクティブで、Compute → Nodes に移動します。
2. ノードを選択します。
3. Node details ページで Terminal をクリックします。

4. ターミナルウィンドウで、root ディレクトリーを /host に切り替えます。

   sh-4.2# chroot /host

5. 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. spec.encryption.type フィールドを aesgcm または aescbc に設定します。

   spec:
     encryption:
       type: aesgcm 1

   1

   AES-CBC 暗号化の場合は aescbc に、AES-GCM 暗号化の場合は aesgcm に設定します。

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

   暗号化プロセスが開始されます。etcd データベースのサイズによっては、このプロセスが完了するまでに 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

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

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

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

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

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

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

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

      $ oc get authentication.operator.openshift.io -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. コントロールプレーンノードの root としてデバッグセッションを開始します。

   $ oc debug --as-root node/<node_name>

2. デバッグシェルで root ディレクトリーを /host に変更します。

   sh-4.4# chroot /host

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

   $ export HTTP_PROXY=http://<your_proxy.example.com>:8080

   $ export HTTPS_PROXY=https://<your_proxy.example.com>:8080

   $ export NO_PROXY=<example.com>

4. デバッグシェルで cluster-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. リカバリーホストとして使用するコントロールプレーンホストを選択します。これは、復元操作を実行するホストです。

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

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

   重要

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

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

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

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

   注記

   リカバリーホストで静的 Pod を停止する必要はありません。

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

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

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

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

      $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"

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

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

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

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

      $ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"

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

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

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

   7. /etc/kubernetes/manifests/keepalived.yaml ファイルが存在し、ノードが削除された場合は、次の手順に従います。

      1. /etc/kubernetes/manifests/keepalived.yaml ファイルを kubelet マニフェストディレクトリーから移動します。

         $ sudo mv -v /etc/kubernetes/manifests/keepalived.yaml /tmp

      2. keepalived デーモンによって管理されているコンテナーが停止していることを確認します。

         $ sudo crictl ps --name keepalived

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

      3. コントロールプレーンに仮想 IP (VIP) が割り当てられているかどうかを確認します。

         $ ip -o address | egrep '<api_vip>|<ingress_vip>'

      4. 報告された仮想 IP ごとに、次のコマンドを実行して仮想 IP を削除します。

         $ sudo ip address del <reported_vip> dev <reported_vip_device>

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

6. keepalived デーモンが使用されている場合は、リカバリーコントロールプレーンノードが仮想 IP を所有していることを確認します。

   $ ip -o address | grep <api_vip>

   仮想 IP のアドレスが存在する場合、出力内で強調表示されます。仮想 IP が設定されていないか、正しく設定されていない場合、このコマンドは空の文字列を返します。

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

   ヒント

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

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

   $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/assets/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 状態になる可能性があります。

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

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

      $ oc get nodes -w

      出力例

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

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

   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

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

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

       $ sudo systemctl restart kubelet.service

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

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

    注記

    単一ノードクラスターや 3 つのスケジュール可能なコントロールプレーンノードで構成されるクラスターなど、ワーカーノードを持たないクラスターには、承認する保留中の 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>

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

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

       $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"

       出力例

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

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

       $ oc -n openshift-etcd get pods -l k8s-app=etcd

       出力例

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

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

13. OVNKubernetes ネットワークプラグインを使用している場合は、リカバリーコントロールプレーンホストではないコントロールプレーンホストに関連付けられているノードオブジェクトを削除します。

    $ oc delete node <non-recovery-controlplane-host-1> <non-recovery-controlplane-host-2>

14. Cluster Network Operator (CNO) が OVN-Kubernetes コントロールプレーンを再デプロイし、回復していないコントローラー IP アドレスを参照していないことを確認します。この結果を確認するには、以下のコマンドの出力を定期的に確認します。空の結果が返されるまで待ってから、次の手順ですべてのホスト上の Open Virtual Network (OVN) Kubernetes Pod の再起動に進みます。

    $ oc -n openshift-ovn-kubernetes get ds/ovnkube-master -o yaml | grep -E '<non-recovery_controller_ip_1>|<non-recovery_controller_ip_2>'

    注記

    OVN-Kubernetes コントロールプレーンが再デプロイされ、直前のコマンドが空の出力を返すまでに 5-10 分以上かかる場合があります。

15. OVN-Kubernetes ネットワークプラグインを使用している場合は、すべてのホストで Open Virtual Network (OVN) Kubernetes Pod を再起動します。

    注記

    検証および変更用の受付 Webhook は Pod を拒否することができます。failurePolicy を Fail に設定して追加の Webhook を追加すると、Pod が拒否され、復元プロセスが失敗する可能性があります。これは、クラスターの状態の復元中に Webhook を保存および削除することで回避できます。クラスターの状態が正常に復元された後に、Webhook を再度有効にできます。

    または、クラスターの状態の復元中に failurePolicy を一時的に Ignore に設定できます。クラスターの状態が正常に復元された後に、failurePolicy を Fail にすることができます。

    1. ノースバウンドデータベース (nbdb) とサウスバウンドデータベース (sbdb) を削除します。Secure Shell (SSH) を使用してリカバリーホストと残りのコントロールプレーンノードにアクセスし、次のコマンドを実行します。

       $ sudo rm -f /var/lib/ovn/etc/*.db

    2. 次のコマンドを実行して、すべての OVN-Kubernetes コントロールプレーン Pod を削除します。

       $ oc delete pods -l app=ovnkube-master -n openshift-ovn-kubernetes

    3. 次のコマンドを実行して、OVN-Kubernetes コントロールプレーン Pod が再度デプロイされ、Running 状態になっていることを確認します。

       $ oc get pods -l app=ovnkube-master -n openshift-ovn-kubernetes

       出力例

       NAME                   READY   STATUS    RESTARTS   AGE
       ovnkube-master-nb24h   4/4     Running   0          48s

    4. 次のコマンドを実行して、すべての ovnkube-node Pod を削除します。

       $ oc get pods -n openshift-ovn-kubernetes -o name | grep ovnkube-node | while read p ; do oc delete $p -n openshift-ovn-kubernetes ; done

    5. 次のコマンドを実行して、すべての ovnkube-node Pod が再度デプロイされ、Running 状態になっていることを確認します。

       $ oc get  pods -n openshift-ovn-kubernetes | grep ovnkube-node

16. 他の非復旧のコントロールプレーンマシンを 1 つずつ削除して再作成します。マシンが再作成された後、新しいリビジョンが強制され、etcd が自動的にスケールアップします。

    • ユーザーがプロビジョニングしたベアメタルインストールを使用する場合は、最初に作成したときと同じ方法を使用して、コントロールプレーンマシンを再作成できます。詳細は、「ユーザーによってプロビジョニングされるクラスターのベアメタルへのインストール」を参照してください。

      警告

      リカバリーホストのマシンを削除し、再作成しないでください。

    • installer-provisioned infrastructure を実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。

      警告

      リカバリーホストのマシンを削除し、再作成しないでください。

      installer-provisioned infrastructure でのベアメタルインストールの場合、コントロールプレーンマシンは再作成されません。詳細は、「ベアメタルコントロールプレーンノードの交換」を参照してください。

      1. 失われたコントロールプレーンホストのいずれかのマシンを取得します。

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

         $ oc get machines -n openshift-machine-api -o wide

         出力例:

         NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
         clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped 1
         clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
         clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
         clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
         clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
         clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

         1

         これは、失われたコントロールプレーンホストのコントロールプレーンマシンです (ip-10-0-131-183.ec2.internal)。

      2. 以下を実行して、失われたコントロールプレーンホストのマシンを削除します。

         $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1

         1

         失われたコントロールプレーンホストのコントロールプレーンマシンの名前を指定します。

         失われたコントロールプレーンホストのマシンを削除すると、新しいマシンが自動的にプロビジョニングされます。

      3. 以下を実行して、新しいマシンが作成されたことを確認します。

         $ oc get machines -n openshift-machine-api -o wide

         出力例:

         NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
         clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
         clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
         clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-173-171.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8  running 1
         clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
         clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
         clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

         1

         新規マシン clustername-8qw5l-master-3 が作成され、Provisioning から Running にフェーズが変更されると準備状態になります。

         新規マシンが作成されるまでに数分の時間がかかる場合があります。etcd クラスター Operator はマシンまたはノードが正常な状態に戻ると自動的に同期します。

      4. リカバリーホストではない喪失したコントロールプレーンホストで、これらのステップを繰り返します。

17. 次のコマンドを入力して、クォーラムガードをオフにします。

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    このコマンドにより、シークレットを正常に再作成し、静的 Pod をロールアウトできるようになります。

18. リカバリーホスト内の別のターミナルウィンドウで、次のコマンドを実行してリカバリー kubeconfig ファイルをエクスポートします。

    $ export KUBECONFIG=/etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost-recovery.kubeconfig

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

    リカバリー kubeconfig ファイルをエクスポートしたのと同じターミナルウィンドウで、次のコマンドを実行します。

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

    1

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

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

20. 次のコマンドを入力して、クォーラムガードをオンに戻します。

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'

21. 次のコマンドを入力して、unsupportedConfigOverrides セクションがオブジェクトから削除されたことを確認できます。

    $ oc get etcd/cluster -oyaml

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

    クラスターにアクセスできるターミナルで、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 などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。

23. 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 などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。

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

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

    $ oc -n openshift-etcd get pods -l k8s-app=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/v1 1
   kind: PodDisruptionBudget
   metadata:
     name: my-pdb
   spec:
     minAvailable: 2  2
     selector:  3
       matchLabels:
         name: my-pod

   1

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

   2

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

   3

   一連のリソースに対するラベルのクエリー。matchLabels と matchExpressions の結果は論理的に結合されます。プロジェクト内のすべての Pod を選択するには、このパラメーターを空白のままにします (例: selector {})。

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

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

   1

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

   2

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

   3

   一連のリソースに対するラベルのクエリー。matchLabels と matchExpressions の結果は論理的に結合されます。プロジェクト内のすべての Pod を選択するには、このパラメーターを空白のままにします (例: selector {})。

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

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

手順

1. PodDisruptionBudget オブジェクトを定義する YAML ファイルを作成し、正常でない Pod のエビクションポリシーを指定します。

   pod-disruption-budget.yaml ファイルの例

   apiVersion: policy/v1
   kind: PodDisruptionBudget
   metadata:
     name: my-pdb
   spec:
     minAvailable: 2
     selector:
       matchLabels:
         name: my-pod
     unhealthyPodEvictionPolicy: AlwaysAllow 1

   1

   正常でない Pod エビクションポリシーとして IfHealthyBudget または AlwaysAllow のいずれかを選択します。unhealthyPodEvictionPolicy フィールドが空の場合、デフォルトは IfHealthyBudget です。

2. 以下のコマンドを実行して PodDisruptionBudget オブジェクトを作成します。

   $ oc create -f pod-disruption-budget.yaml

手順

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

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

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

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

6. vSphere CSI Driver Operator が有効になっていない vSphere クラスターの認証情報を更新する場合は、Kubernetes コントローラーマネージャーを強制的にロールアウトして更新された認証情報を適用する必要があります。

   注記

   vSphere CSI Driver Operator が有効になっている場合、この手順は不要です。

   更新された vSphere 認証情報を適用するには、cluster-admin ロールを持つユーザーとして OpenShift Container Platform CLI にログインし、以下のコマンドを実行します。

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

   認証情報がロールアウトされている間、Kubernetes Controller Manager Operator のステータスは Progressing=true を報告します。ステータスを表示するには、次のコマンドを実行します。

   $ oc get co kube-controller-manager

7. クラスターの 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> はクラウドプロバイダーの対応する値になります。

      • AWS: AWSProviderSpec
      • 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> \1
        -n <secret_namespace> 2

      1

      シークレットの名前を指定します。

      2

      シークレットを含む namespace を指定します。

      AWS シークレットの削除例

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

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

1. Web コンソールの Administrator パースペクティブで、Workloads → Secrets に移動します。
2. Value フィールドの内容が変更されていることを確認します。

手順

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

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

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

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

手順

1. クラスターの kubeconfig ファイルおよびクラスターのインストールに使用したインストールプログラムが RHEL 8 マシン上にあることを確認します。これを実行する 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.13 で必要なリポジトリーを有効にします。

   # subscription-manager repos \
       --enable="rhel-8-for-x86_64-baseos-rpms" \
       --enable="rhel-8-for-x86_64-appstream-rpms" \
       --enable="rhocp-4.13-for-rhel-8-x86_64-rpms"

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

   # yum install openshift-ansible openshift-clients jq

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