Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

インストール後の設定

OpenShift Container Platform 4.16

OpenShift Container Platform の Day 2 オペレーション

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、OpenShift Container Platform のインストール後のアクティビティーに関する手順およびガイダンスを説明します。

第1章 インストール後の設定の概要
リンクのコピー

OpenShift Container Platform のインストール後に、クラスター管理者は以下のコンポーネントを設定し、カスタマイズできます。

  • マシン
  • ベアメタル
  • クラスター
  • ノード
  • ネットワーク
  • ストレージ
  • ユーザー
  • アラートおよび通知

1.1. インストール後の設定タスク
リンクのコピー

インストール後の設定タスクを実行して、ニーズに合わせて環境を設定できます。

次のリストにインストール後の設定の詳細を示します。

  • オペレーティングシステム機能の設定: Machine Config Operator (MCO) は MachineConfig オブジェクトを管理します。MCO を使用すると、ノードとカスタムリソースを設定できます。

  • ベアメタルノードの設定: Bare Metal Operator (BMO) を使用してベアメタルホストを管理できます。BMO は次の操作を完了できます。

    • ホストのハードウェアの詳細を検査し、ベアメタルホストに報告します。
    • ファームウェアを検査し、BIOS を設定します。
    • 必要なイメージでホストをプロビジョニングします。
    • ホストをプロビジョニングする前または後に、ホストのディスクの内容をクリーンアップします。

  • クラスター機能の設定: OpenShift Container Platform クラスターの以下の機能を変更できます。

    • イメージレジストリー
    • ネットワーク設定
    • イメージビルドの動作
    • アイデンティティープロバイダー
    • etcd の設定
    • ワークロードを処理するマシンセットの作成
    • クラウドプロバイダーの認証情報の管理

  • プライベートクラスターの設定: デフォルトでは、インストールプログラムはパブリックにアクセス可能な DNS とエンドポイントを使用して、OpenShift Container Platform をプロビジョニングします。内部ネットワーク内からのみクラスターにアクセスできるようにするには、次のコンポーネントを設定してプライベートにします。

    • DNS
    • Ingress コントローラー
    • API サーバー

  • ノード操作の実施: デフォルトでは、OpenShift Container Platform は Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートマシンを使用します。次のノード操作を実行できます。

    • コンピュートマシンの追加および削除
    • taint および toleration 追加および削除
    • ノードあたりの Pod の最大数の設定
    • Device Manager の有効化

  • ユーザーの設定: ユーザーは、OAuth アクセストークンを使用して API に対して認証を行うことができます。次のタスクを実行するように OAuth を設定できます。

    • アイデンティティープロバイダーを指定します。
    • ロールベースのアクセス制御を使用して、ユーザーにパーミッションを定義し付与します。
    • OperatorHub から Operator をインストールします。
  • アラート通知の設定: デフォルトでは、発生中のアラートは Web コンソールのアラート UI に表示されます。外部システムにアラート通知を送信するように OpenShift Container Platform を設定することもできます。

第2章 プライベートクラスターの設定
リンクのコピー

OpenShift Container Platform バージョン 4.16 クラスターのインストール後に、そのコアコンポーネントの一部を private に設定できます。

2.1. プライベートクラスター
リンクのコピー

デフォルトで、OpenShift Container Platform は一般にアクセス可能な DNS およびエンドポイントを使用してプロビジョニングされます。プライベートクラスターのデプロイ後に DNS、Ingress コントローラー、および API サーバーを private に設定できます。

重要

クラスターにパブリックサブネットがある場合、管理者により作成されたロードバランサーサービスはパブリックにアクセスできる可能性があります。クラスターのセキュリティーを確保するには、これらのサービスに明示的にプライベートアノテーションが付けられていることを確認してください。

2.1.1. DNS
リンクのコピー

OpenShift Container Platform を installer-provisioned infrastructure にインストールする場合、インストールプログラムは既存のパブリックゾーンにレコードを作成し、可能な場合はクラスター独自の DNS 解決用のプライベートゾーンを作成します。パブリックゾーンおよびプライベートゾーンの両方で、インストールプログラムまたはクラスターが Ingress オブジェクトの *.apps、および API サーバーの api の DNS エントリーを作成します。

*.apps レコードはパブリックゾーンとプライベートゾーンのどちらでも同じであるため、パブリックゾーンを削除する際に、プライベートゾーンではクラスターのすべての DNS 解決をシームレスに提供します。

2.1.2. Ingress コントローラー
リンクのコピー

デフォルトの Ingress オブジェクトはパブリックとして作成されるため、ロードバランサーはインターネットに接続され、パブリックサブネットで使用されます。

Ingress Operator は、カスタムのデフォルト証明書を設定するまで、プレースホルダーとして機能する Ingress コントローラーのデフォルト証明書を生成します。実稼働クラスターで Operator が生成するデフォルト証明書は使用しないでください。Ingress Operator は、独自の署名証明書または生成するデフォルト証明書をローテーションしません。Operator が生成するデフォルト証明書は、設定するカスタムデフォルト証明書のプレースホルダーとして使用されます。

2.1.3. API サーバー
リンクのコピー

デフォルトでは、インストールプログラムは内部トラフィックと外部トラフィックの両方で使用するための API サーバーの適切なネットワークロードバランサーを作成します。

Amazon Web Services (AWS) では、個別のパブリックロードバランサーおよびプライベートロードバランサーが作成されます。ロードバランサーは、クラスター内で使用するために追加ポートが内部で利用可能な場合を除き、常に同一です。インストールプログラムは API サーバー要件に基づいてロードバランサーを自動的に作成または破棄しますが、クラスターはそれらを管理または維持しません。クラスターの API サーバーへのアクセスを保持する限り、ロードバランサーを手動で変更または移動できます。パブリックロードバランサーの場合、ポート 6443 は開放され、ヘルスチェックが HTTPS について /readyz パスに対して設定されます。

Google Cloud では、内部 API トラフィックと外部 API トラフィックの両方を管理するために単一のロードバランサーが作成されるため、ロードバランサーを変更する必要はありません。

Microsoft Azure では、パブリックおよびプライベートロードバランサーの両方が作成されます。ただし、現在の実装には制限があるため、プライベートクラスターで両方のロードバランサーを保持します。

2.2. プライベートゾーンで公開する DNS レコードの設定
リンクのコピー

すべての OpenShift Container Platform クラスターでは、パブリックかプライベートかにかかわらず、DNS レコードはデフォルトでパブリックゾーンに公開されます。

DNS レコードをパブリックに公開しない場合は、クラスター DNS 設定からパブリックゾーンを削除できます。内部ドメイン名、内部 IP アドレス、組織内のクラスターの数などの機密情報を公開しない場合や、レコードを公開する必要がない場合もあります。クラスター内のサービスに接続できるすべてのクライアントが、プライベートゾーンの DNS レコードを持つプライベート DNS サービスを使用する場合、クラスターのパブリック DNS レコードは必要ありません。

クラスターをデプロイした後、DNS カスタムリソース (CR) を変更して、プライベートゾーンのみを使用するように DNS を変更できます。このように DNS CR を変更すると、その後に作成される DNS レコードはパブリック DNS サーバーに公開されなくなり、DNS レコードに関する情報は内部ユーザーだけに限定されます。これは、クラスターをプライベートに設定する場合、または DNS レコードをパブリックに解決する必要がない場合に適用できます。

または、プライベートクラスターでも DNS レコード用のパブリックゾーンを保持し、クライアントがそのクラスターで実行されているアプリケーションの DNS 名を解決できるようにすることも可能です。たとえば組織は、パブリックインターネットに接続するマシンを所有し、特定のプライベート IP 範囲に対して VPN 接続を確立してプライベート IP アドレスに接続することができます。これらのマシンからの DNS ルックアップでは、パブリック DNS を使用してそれらのサービスのプライベートアドレスを判断し、VPN 経由でプライベートアドレスに接続します。

手順

  1. 次のコマンドを実行して出力を確認し、クラスターの DNS CR を確認します。 

    $ oc get dnses.config.openshift.io/cluster -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: config.openshift.io/v1
kind: DNS
metadata:
  creationTimestamp: "2019-10-25T18:27:09Z"
  generation: 2
  name: cluster
  resourceVersion: "37966"
  selfLink: /apis/config.openshift.io/v1/dnses/cluster
  uid: 0e714746-f755-11f9-9cb1-02ff55d8f976
spec:
  baseDomain: <base_domain>
  privateZone:
    tags:
      Name: <infrastructure_id>-int
      kubernetes.io/cluster/<infrastructure_id>: owned
  publicZone:
    id: Z2XXXXXXXXXXA4
status: {}
    Copy to Clipboard Toggle word wrap

    spec セクションには、プライベートゾーンとパブリックゾーンの両方が含まれることに注意してください。

  2. 次のコマンドを実行して、DNS CR にパッチを適用し、パブリックゾーンを削除します。 

    $ oc patch dnses.config.openshift.io/cluster --type=merge --patch='{"spec": {"publicZone": null}}'
    Copy to Clipboard Toggle word wrap

    出力例

    dns.config.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

    Ingress Operator は、IngressController オブジェクトの DNS レコード作成時に DNS CR 定義を参照します。プライベートゾーンのみ指定されている場合、プライベートレコードのみが作成されます。

    重要

    パブリックゾーンを削除しても、既存の DNS レコードは変更されません。以前に公開したパブリック DNS レコードで、パブリックに公開する必要がなくなったものは、手動で削除する必要があります。

検証

  • 次のコマンドを実行し、出力でクラスターの DNS CR を確認してパブリックゾーンが削除されたことを確認します。 

    $ oc get dnses.config.openshift.io/cluster -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: config.openshift.io/v1
kind: DNS
metadata:
  creationTimestamp: "2019-10-25T18:27:09Z"
  generation: 2
  name: cluster
  resourceVersion: "37966"
  selfLink: /apis/config.openshift.io/v1/dnses/cluster
  uid: 0e714746-f755-11f9-9cb1-02ff55d8f976
spec:
  baseDomain: <base_domain>
  privateZone:
    tags:
      Name: <infrastructure_id>-int
      kubernetes.io/cluster/<infrastructure_id>-wfpg4: owned
status: {}
    Copy to Clipboard Toggle word wrap

2.3. Ingress コントローラーをプライベートに設定する
リンクのコピー

クラスターのデプロイ後に、その Ingress コントローラーをプライベートゾーンのみを使用するように変更できます。

手順

  1. 内部エンドポイントのみを使用するようにデフォルト Ingress コントローラーを変更します。 

    $ oc replace --force --wait --filename - <<EOF
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: default
spec:
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: Internal
EOF
    Copy to Clipboard Toggle word wrap

    出力例

    ingresscontroller.operator.openshift.io "default" deleted
ingresscontroller.operator.openshift.io/default replaced
    Copy to Clipboard Toggle word wrap

    パブリック DNS エントリーが削除され、プライベートゾーンエントリーが更新されます。

2.4. API サーバーをプライベートに制限する
リンクのコピー

クラスターを Amazon Web Services (AWS) または Microsoft Azure にデプロイした後に、プライベートゾーンのみを使用するように API サーバーを再設定することができます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとして Web コンソールにアクセスできること。

手順

  1. クラウドプロバイダーの Web ポータルまたはコンソールで、次の操作を行います。

    1. 適切なロードバランサーコンポーネントを見つけて削除します。

      • AWS の場合は、外部ロードバランサーを削除します。プライベートゾーンの API DNS エントリーは、同一の設定を使用する内部ロードバランサーをすでに参照するため、内部ロードバランサーを変更する必要はありません。
      • Azure の場合は、パブリックロードバランサーの api-internal-v4 ルールを削除します。
    2. Azure の場合、Ingress Controller エンドポイントの公開スコープを Internal に設定します。詳細は、「Ingress Controller エンドポイント公開スコープを内部に設定」を参照してください。
    3. Azure パブリックロードバランサーの場合は、Ingress Controller エンドポイントの公開スコープを Internal に設定し、パブリックロードバランサーに既存の受信規則がない場合は、バックエンドアドレスプールに送信トラフィックを提供するための送信規則を明示的に作成する必要があります。詳細は、送信ルールの追加に関する Microsoft Azure のドキュメントを参照してください。
    4. パブリックゾーンの api.$clustername.$yourdomain または api.$clustername DNS エントリーを削除します。

  2. AWS クラスター: 外部ロードバランサーを削除します。

    重要

    以下の手順は、installer-provisioned infrastructure (IPI) のクラスターでのみ実行できます。user-provisioned infrastructure (UPI) のクラスターの場合は、外部ロードバランサーを手動で削除するか、無効にする必要があります。

    • クラスターがコントロールプレーンマシンセットを使用する場合は、コントロールプレーンマシンセットのカスタムリソースで、パブリックまたは外部ロードバランサーを設定する行を削除します。 

      # ...
providerSpec:
  value:
# ...
    loadBalancers:
    - name: lk4pj-ext
      1 
      
      type: network
      2 
      
    - name: lk4pj-int
      type: network
# ...
      Copy to Clipboard Toggle word wrap
      1
      -ext で終わる外部ロードバランサーの name 値を削除します。
      2
      外部ロードバランサーの type 値を削除します。

    • クラスターがコントロールプレーンマシンセットを使用しない場合は、各コントロールプレーンマシンから外部ロードバランサーを削除する必要があります。

      1. ターミナルから、次のコマンドを実行してクラスターマシンを一覧表示します。 

        $ oc get machine -n openshift-machine-api
        Copy to Clipboard Toggle word wrap

        出力例

        NAME                            STATE     TYPE        REGION      ZONE         AGE
lk4pj-master-0                  running   m4.xlarge   us-east-1   us-east-1a   17m
lk4pj-master-1                  running   m4.xlarge   us-east-1   us-east-1b   17m
lk4pj-master-2                  running   m4.xlarge   us-east-1   us-east-1a   17m
lk4pj-worker-us-east-1a-5fzfj   running   m4.xlarge   us-east-1   us-east-1a   15m
lk4pj-worker-us-east-1a-vbghs   running   m4.xlarge   us-east-1   us-east-1a   15m
lk4pj-worker-us-east-1b-zgpzg   running   m4.xlarge   us-east-1   us-east-1b   15m
        Copy to Clipboard Toggle word wrap

        コントロールプレーンマシンの名前には master が含まれています。

      2. 各コントロールプレーンマシンから外部ロードバランサーを削除します。

        1. 次のコマンドを実行して、コントロールプレーンマシンオブジェクトを編集します。 

          $ oc edit machines -n openshift-machine-api <control_plane_name>
          1
          Copy to Clipboard Toggle word wrap
          1
          変更するコントロールプレーンマシンオブジェクトの名前を指定します。

        2. 次の例でマークされている、外部ロードバランサーを説明する行を削除します。 

          # ...
providerSpec:
  value:
# ...
    loadBalancers:
    - name: lk4pj-ext
          1 
          
      type: network
          2 
          
    - name: lk4pj-int
      type: network
# ...
          Copy to Clipboard Toggle word wrap
          1
          -ext で終わる外部ロードバランサーの name 値を削除します。
          2
          外部ロードバランサーの type 値を削除します。
        3. 変更を保存して、オブジェクト仕様を終了します。
        4. コントロールプレーンマシンごとに、このプロセスを繰り返します。

2.5. Azure 上でプライベートストレージエンドポイントを設定する
リンクのコピー

Image Registry Operator を利用すると、Azure 上でプライベートエンドポイントを使用できます。これにより、OpenShift Container Platform がプライベート Azure クラスターにデプロイされている場合に、プライベートストレージアカウントのシームレスな設定が可能になります。これにより、パブリック向けのストレージエンドポイントを公開せずにイメージレジストリーをデプロイできます。

重要

Microsoft Azure Red Hat OpenShift (ARO) でプライベートストレージエンドポイントを設定しないでください。エンドポイントによって、Microsoft Azure Red Hat OpenShift クラスターが回復不能な状態になる可能性があります。

次のどちらかの方法で、Azure 上のプライベートストレージエンドポイントを使用するように Image Registry Operator を設定できます。

  • Image Registry Operator を設定して VNet 名とサブネット名を検出する
  • ユーザーが指定した Azure 仮想ネットワーク (VNet) 名とサブネット名を使用する

2.5.1. Azure 上でプライベートストレージエンドポイントを設定する場合の制限事項
リンクのコピー

Azure 上でプライベートストレージエンドポイントを設定する場合は、次の制限が適用されます。

  • プライベートストレージエンドポイントを使用するように Image Registry Operator を設定すると、ストレージアカウントへのパブリックネットワークアクセスが無効になります。したがって、OpenShift Container Platform の外部のレジストリーからイメージをプルするには、レジストリーの Operator 設定で disableRedirect: true を設定する必要があります。リダイレクトが有効になっていると、ストレージアカウントからイメージを直接プルするように、レジストリーによってクライアントがリダイレクトされますが、これは機能しません。パブリックネットワークアクセスが無効になっているためです。詳細は、「Azure でプライベートストレージエンドポイントを使用する場合にリダイレクトを無効にする」を参照してください。
  • この操作は、Image Registry Operator によって元に戻すことはできません。

次の手順では、VNet 名とサブネット名を検出するように Image Registry Operator を設定して、Azure 上でプライベートストレージエンドポイントを設定する方法を示します。

前提条件

  • Azure 上で動作するようにイメージレジストリーを設定している。

  • ネットワークが、Installer Provisioned Infrastructure インストール方法を使用してセットアップされている。

    カスタムネットワーク設定を使用するユーザーの場合は、「ユーザー指定の VNet 名とサブネット名を使用して Azure 上でプライベートストレージエンドポイントを設定する」を参照してください。

手順

  1. Image Registry Operator の config オブジェクトを編集し、networkAccess.type を Internal に設定します。 

    $ oc edit configs.imageregistry/cluster
    Copy to Clipboard Toggle word wrap 
    # ...
spec:
  # ...
   storage:
      azure:
        # ...
        networkAccess:
          type: Internal
# ...
    Copy to Clipboard Toggle word wrap

  2. オプション: 次のコマンドを入力して、Operator がプロビジョニングを完了したことを確認します。これには数分かかる場合があります。 

    $ oc get configs.imageregistry/cluster -o=jsonpath="{.spec.storage.azure.privateEndpointName}" -w
    Copy to Clipboard Toggle word wrap

  3. オプション: レジストリーがルートによって公開されており、ストレージアカウントをプライベートに設定する場合、クラスターの外部へのプルを引き続き機能させるには、リダイレクトを無効にする必要があります。次のコマンドを入力して、Image Operator 設定のリダイレクトを無効にします。 

    $ oc patch configs.imageregistry cluster --type=merge -p '{"spec":{"disableRedirect": true}}'
    Copy to Clipboard Toggle word wrap
    注記

    リダイレクトが有効になっていると、クラスターの外部からのイメージのプルが機能しなくなります。

検証

  1. 次のコマンドを実行して、レジストリーサービス名を取得します。 

    $ oc registry info --internal=true
    Copy to Clipboard Toggle word wrap

    出力例

    image-registry.openshift-image-registry.svc:5000
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行してデバッグモードに入ります。 

    $ oc debug node/<node_name>
    Copy to Clipboard Toggle word wrap

  3. 推奨される chroot コマンドを実行します。以下に例を示します。 

    $ chroot /host
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを入力して、コンテナーレジストリーにログインします。 

    $ podman login --tls-verify=false -u unused -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000
    Copy to Clipboard Toggle word wrap

    出力例

    Login Succeeded!
    Copy to Clipboard Toggle word wrap

  5. 次のコマンドを入力して、レジストリーからイメージをプルできることを確認します。 

    $ podman pull --tls-verify=false image-registry.openshift-image-registry.svc:5000/openshift/tools
    Copy to Clipboard Toggle word wrap

    出力例

    Trying to pull image-registry.openshift-image-registry.svc:5000/openshift/tools/openshift/tools...
Getting image source signatures
Copying blob 6b245f040973 done
Copying config 22667f5368 done
Writing manifest to image destination
Storing signatures
22667f53682a2920948d19c7133ab1c9c3f745805c14125859d20cede07f11f9
    Copy to Clipboard Toggle word wrap

次の手順を使用して、パブリックネットワークアクセスが無効な、Azure 上のプライベートストレージエンドポイントの背後で公開されるストレージアカウントを設定します。

前提条件

  • Azure 上で動作するようにイメージレジストリーを設定している。
  • Azure 環境で使用する VNet 名とサブネット名を把握している。
  • ネットワークが Azure の別のリソースグループに設定されている場合は、そのリソースグループの名前も把握している。

手順

  1. Image Registry Operator の config オブジェクトを編集し、VNet 名とサブネット名を使用してプライベートエンドポイントを設定します。 

    $ oc edit configs.imageregistry/cluster
    Copy to Clipboard Toggle word wrap 
    # ...
spec:
  # ...
   storage:
      azure:
        # ...
        networkAccess:
          type: Internal
          internal:
            subnetName: <subnet_name>
            vnetName: <vnet_name>
            networkResourceGroupName: <network_resource_group_name>
# ...
    Copy to Clipboard Toggle word wrap

  2. オプション: 次のコマンドを入力して、Operator がプロビジョニングを完了したことを確認します。これには数分かかる場合があります。 

    $ oc get configs.imageregistry/cluster -o=jsonpath="{.spec.storage.azure.privateEndpointName}" -w
    Copy to Clipboard Toggle word wrap
    注記

    リダイレクトが有効になっていると、クラスターの外部からのイメージのプルが機能しなくなります。

検証

  1. 次のコマンドを実行して、レジストリーサービス名を取得します。 

    $ oc registry info --internal=true
    Copy to Clipboard Toggle word wrap

    出力例

    image-registry.openshift-image-registry.svc:5000
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行してデバッグモードに入ります。 

    $ oc debug node/<node_name>
    Copy to Clipboard Toggle word wrap

  3. 推奨される chroot コマンドを実行します。以下に例を示します。 

    $ chroot /host
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを入力して、コンテナーレジストリーにログインします。 

    $ podman login --tls-verify=false -u unused -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000
    Copy to Clipboard Toggle word wrap

    出力例

    Login Succeeded!
    Copy to Clipboard Toggle word wrap

  5. 次のコマンドを入力して、レジストリーからイメージをプルできることを確認します。 

    $ podman pull --tls-verify=false image-registry.openshift-image-registry.svc:5000/openshift/tools
    Copy to Clipboard Toggle word wrap

    出力例

    Trying to pull image-registry.openshift-image-registry.svc:5000/openshift/tools/openshift/tools...
Getting image source signatures
Copying blob 6b245f040973 done
Copying config 22667f5368 done
Writing manifest to image destination
Storing signatures
22667f53682a2920948d19c7133ab1c9c3f745805c14125859d20cede07f11f9
    Copy to Clipboard Toggle word wrap

デフォルトでは、イメージレジストリーを使用する場合、リダイレクトが有効になります。リダイレクトにより、レジストリー Pod からオブジェクトストレージへのトラフィックのオフロードが可能になり、プルが高速化されます。リダイレクトが有効で、ストレージアカウントがプライベートである場合、クラスターの外部のユーザーはレジストリーからイメージをプルできません。

場合によっては、クラスターの外部のユーザーがレジストリーからイメージをプルできるように、リダイレクトを無効にする必要があります。

リダイレクトを無効にするには、次の手順を実行します。

前提条件

  • Azure 上で動作するようにイメージレジストリーを設定している。
  • ルートを設定している。

手順

  • 次のコマンドを入力して、イメージレジストリー設定のリダイレクトを無効にします。 

    $ oc patch configs.imageregistry cluster --type=merge -p '{"spec":{"disableRedirect": true}}'
    Copy to Clipboard Toggle word wrap

検証

  1. 次のコマンドを実行して、レジストリーサービス名を取得します。 

    $ oc registry info
    Copy to Clipboard Toggle word wrap

    出力例

    default-route-openshift-image-registry.<cluster_dns>
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを入力して、コンテナーレジストリーにログインします。 

    $ podman login --tls-verify=false -u unused -p $(oc whoami -t) default-route-openshift-image-registry.<cluster_dns>
    Copy to Clipboard Toggle word wrap

    出力例

    Login Succeeded!
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを入力して、レジストリーからイメージをプルできることを確認します。 

    $ podman pull --tls-verify=false default-route-openshift-image-registry.<cluster_dns>
/openshift/tools
    Copy to Clipboard Toggle word wrap

    出力例

    Trying to pull default-route-openshift-image-registry.<cluster_dns>/openshift/tools...
Getting image source signatures
Copying blob 6b245f040973 done
Copying config 22667f5368 done
Writing manifest to image destination
Storing signatures
22667f53682a2920948d19c7133ab1c9c3f745805c14125859d20cede07f11f9
    Copy to Clipboard Toggle word wrap

第3章 ベアメタルの設定
リンクのコピー

ベアメタルホストに OpenShift Container Platform をデプロイする場合、プロビジョニングの前後にホストに変更を加える必要がある場合があります。これには、ホストのハードウェア、ファームウェア、ファームウェアの詳細の検証が含まれます。また、ディスクのフォーマットや、変更可能なファームウェア設定の変更も含まれます。

3.1. ユーザー管理ロードバランサーのサービス
リンクのコピー

デフォルトのロードバランサーの代わりに、ユーザーが管理するロードバランサーを使用するように OpenShift Container Platform クラスターを設定できます。

重要

ユーザー管理ロードバランサーの設定は、ベンダーのロードバランサーによって異なります。

このセクションの情報と例は、ガイドラインのみを目的としています。ベンダーのロードバランサーに関する詳細は、ベンダーのドキュメントを参照してください。

Red Hat は、ユーザー管理ロードバランサーに対して次のサービスをサポートしています。

  • Ingress Controller
  • OpenShift API
  • OpenShift MachineConfig API

ユーザー管理ロードバランサーに対して、これらのサービスの 1 つを設定するか、すべてを設定するかを選択できます。一般的な設定オプションは、Ingress Controller サービスのみを設定することです。次の図は、各サービスの詳細を示しています。

図3.1 OpenShift Container Platform 環境で動作する Ingress Controller を示すネットワークワークフローの例

OpenShift Container Platform 環境で動作する Ingress Controller のネットワークワークフローの例を示すイメージ。
View larger image
OpenShift Container Platform 環境で動作する Ingress Controller のネットワークワークフローの例を示すイメージ。

図3.2 OpenShift Container Platform 環境で動作する OpenShift API を示すネットワークワークフローの例

OpenShift Container Platform 環境で動作する OpenShift API のネットワークワークフローの例を示すイメージ。
View larger image
OpenShift Container Platform 環境で動作する OpenShift API のネットワークワークフローの例を示すイメージ。

図3.3 OpenShift Container Platform 環境で動作する OpenShift MachineConfig API を示すネットワークワークフローの例

OpenShift Container Platform 環境で動作する OpenShift MachineConfig API のネットワークワークフローの例を示すイメージ。
View larger image
OpenShift Container Platform 環境で動作する OpenShift MachineConfig API のネットワークワークフローの例を示すイメージ。

ユーザー管理ロードバランサーでは、次の設定オプションがサポートされています。

  • ノードセレクターを使用して、Ingress Controller を特定のノードのセットにマッピングします。このセットの各ノードに静的 IP アドレスを割り当てるか、Dynamic Host Configuration Protocol (DHCP) から同じ IP アドレスを受け取るように各ノードを設定する必要があります。インフラストラクチャーノードは通常、このタイプの設定を受け取ります。

  • サブネット上のすべての IP アドレスをターゲットにします。この設定では、ロードバランサーターゲットを再設定せずにネットワーク内でノードを作成および破棄できるため、メンテナンスオーバーヘッドを削減できます。/27 や /28 などの小規模なネットワーク上に設定されたマシンを使用して Ingress Pod をデプロイする場合、ロードバランサーのターゲットを簡素化できます。

    ヒント

    マシン config プールのリソースを確認することで、ネットワーク内に存在するすべての IP アドレスをリスト表示できます。

OpenShift Container Platform クラスターのユーザー管理ロードバランサーを設定する前に、以下の情報を考慮してください。

  • フロントエンド IP アドレスの場合、フロントエンド IP アドレス、Ingress Controller のロードバランサー、および API ロードバランサーに同じ IP アドレスを使用できます。この機能は、ベンダーのドキュメントを確認してください。

  • バックエンド IP アドレスの場合、ユーザー管理ロードバランサーの有効期間中に OpenShift Container Platform コントロールプレーンノードの IP アドレスが変更されないことを確認します。次のいずれかのアクションを実行すると、これを実現できます。

    • 各コントロールプレーンノードに静的 IP アドレスを割り当てます。
    • ノードが DHCP リースを要求するたびに、DHCP から同じ IP アドレスを受信するように各ノードを設定します。ベンダーによっては、DHCP リースは IP 予約または静的 DHCP 割り当ての形式になる場合があります。
  • Ingress Controller バックエンドサービスのユーザー管理ロードバランサーで Ingress Controller を実行する各ノードを手動で定義します。たとえば、Ingress Controller が未定義のノードに移動すると、接続が停止する可能性があります。

3.1.1. ユーザー管理ロードバランサーの設定
リンクのコピー

デフォルトのロードバランサーの代わりに、ユーザーが管理するロードバランサーを使用するように OpenShift Container Platform クラスターを設定できます。

重要

ユーザー管理ロードバランサーを設定する前に、「ユーザー管理ロードバランサーのサービス」セクションを必ずお読みください。

ユーザー管理ロードバランサー用に設定するサービスに適用される次の前提条件をお読みください。

注記

クラスター上で実行される MetalLB は、ユーザー管理ロードバランサーとして機能します。

OpenShift API の前提条件

  • フロントエンド IP アドレスを定義している。

  • TCP ポート 6443 および 22623 は、ロードバランサーのフロントエンド IP アドレスで公開されている。以下の項目を確認します。

    • ポート 6443 が OpenShift API サービスにアクセスできる。
    • ポート 22623 が Ignition 起動設定をノードに提供できる。
  • フロントエンド IP アドレスとポート 6443 へは、OpenShift Container Platform クラスターの外部の場所にいるシステムのすべてのユーザーがアクセスできる。
  • フロントエンド IP アドレスとポート 22623 は、OpenShift Container Platform ノードからのみ到達できる。
  • ロードバランサーバックエンドは、ポート 6443 および 22623 の OpenShift Container Platform コントロールプレーンノードと通信できる。

Ingress Controller の前提条件

  • フロントエンド IP アドレスを定義している。
  • TCP ポート 443 および 80 はロードバランサーのフロントエンド IP アドレスで公開されている。
  • フロントエンドの IP アドレス、ポート 80、ポート 443 へは、OpenShift Container Platform クラスターの外部の場所にあるシステムの全ユーザーがアクセスできる。
  • フロントエンドの IP アドレス、ポート 80、ポート 443 は、OpenShift Container Platform クラスターで動作するすべてのノードから到達できる。
  • ロードバランサーバックエンドは、ポート 80、443、および 1936 で Ingress Controller を実行する OpenShift Container Platform ノードと通信できる。

ヘルスチェック URL 仕様の前提条件

ほとんどのロードバランサーは、サービスが使用可能か使用不可かを判断するヘルスチェック URL を指定して設定できます。OpenShift Container Platform は、OpenShift API、Machine Configuration API、および Ingress Controller バックエンドサービスのこれらのヘルスチェックを提供します。

次の例は、前にリスト表示したバックエンドサービスのヘルスチェック仕様を示しています。

Kubernetes API ヘルスチェック仕様の例

Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Copy to Clipboard Toggle word wrap

Machine Config API ヘルスチェック仕様の例

Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Copy to Clipboard Toggle word wrap

Ingress Controller のヘルスチェック仕様の例

Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10
Copy to Clipboard Toggle word wrap

手順

  1. HAProxy Ingress Controller を設定して、ポート 6443、22623、443、および 80 でロードバランサーからクラスターへのアクセスを有効化できるようにします。必要に応じて、HAProxy 設定で単一のサブネットの IP アドレスまたは複数のサブネットの IP アドレスを指定できます。

    1 つのサブネットをリストした HAProxy 設定の例

    # ...
listen my-cluster-api-6443
    bind 192.168.1.100:6443
    mode tcp
    balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /readyz
  http-check expect status 200
    server my-cluster-master-2 192.168.1.101:6443 check inter 10s rise 2 fall 2
    server my-cluster-master-0 192.168.1.102:6443 check inter 10s rise 2 fall 2
    server my-cluster-master-1 192.168.1.103:6443 check inter 10s rise 2 fall 2

listen my-cluster-machine-config-api-22623
    bind 192.168.1.100:22623
    mode tcp
    balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /healthz
  http-check expect status 200
    server my-cluster-master-2 192.168.1.101:22623 check inter 10s rise 2 fall 2
    server my-cluster-master-0 192.168.1.102:22623 check inter 10s rise 2 fall 2
    server my-cluster-master-1 192.168.1.103:22623 check inter 10s rise 2 fall 2

listen my-cluster-apps-443
    bind 192.168.1.100:443
    mode tcp
    balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /healthz/ready
  http-check expect status 200
    server my-cluster-worker-0 192.168.1.111:443 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-1 192.168.1.112:443 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-2 192.168.1.113:443 check port 1936 inter 10s rise 2 fall 2

listen my-cluster-apps-80
   bind 192.168.1.100:80
   mode tcp
   balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /healthz/ready
  http-check expect status 200
    server my-cluster-worker-0 192.168.1.111:80 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-1 192.168.1.112:80 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-2 192.168.1.113:80 check port 1936 inter 10s rise 2 fall 2
# ...
    Copy to Clipboard Toggle word wrap

    複数のサブネットをリストした HAProxy 設定の例

    # ...
listen api-server-6443
    bind *:6443
    mode tcp
      server master-00 192.168.83.89:6443 check inter 1s
      server master-01 192.168.84.90:6443 check inter 1s
      server master-02 192.168.85.99:6443 check inter 1s
      server bootstrap 192.168.80.89:6443 check inter 1s

listen machine-config-server-22623
    bind *:22623
    mode tcp
      server master-00 192.168.83.89:22623 check inter 1s
      server master-01 192.168.84.90:22623 check inter 1s
      server master-02 192.168.85.99:22623 check inter 1s
      server bootstrap 192.168.80.89:22623 check inter 1s

listen ingress-router-80
    bind *:80
    mode tcp
    balance source
      server worker-00 192.168.83.100:80 check inter 1s
      server worker-01 192.168.83.101:80 check inter 1s

listen ingress-router-443
    bind *:443
    mode tcp
    balance source
      server worker-00 192.168.83.100:443 check inter 1s
      server worker-01 192.168.83.101:443 check inter 1s

listen ironic-api-6385
    bind *:6385
    mode tcp
    balance source
      server master-00 192.168.83.89:6385 check inter 1s
      server master-01 192.168.84.90:6385 check inter 1s
      server master-02 192.168.85.99:6385 check inter 1s
      server bootstrap 192.168.80.89:6385 check inter 1s

listen inspector-api-5050
    bind *:5050
    mode tcp
    balance source
      server master-00 192.168.83.89:5050 check inter 1s
      server master-01 192.168.84.90:5050 check inter 1s
      server master-02 192.168.85.99:5050 check inter 1s
      server bootstrap 192.168.80.89:5050 check inter 1s
# ...
    Copy to Clipboard Toggle word wrap

  2. curl CLI コマンドを使用して、ユーザー管理ロードバランサーとそのリソースが動作していることを確認します。

    1. 次のコマンドを実行して応答を観察し、クラスターマシン設定 API が Kubernetes API サーバーリソースにアクセスできることを確認します。 

      $ curl https://<loadbalancer_ip_address>:6443/version --insecure
      Copy to Clipboard Toggle word wrap

      設定が正しい場合は、応答として JSON オブジェクトを受信します。 

      {
  "major": "1",
  "minor": "11+",
  "gitVersion": "v1.11.0+ad103ed",
  "gitCommit": "ad103ed",
  "gitTreeState": "clean",
  "buildDate": "2019-01-09T06:44:10Z",
  "goVersion": "go1.10.3",
  "compiler": "gc",
  "platform": "linux/amd64"
}
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して出力を確認し、クラスターマシン設定 API がマシン設定サーバーリソースからアクセスできることを確認します。 

      $ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
      Copy to Clipboard Toggle word wrap

      設定が正しい場合、コマンドの出力には次の応答が表示されます。 

      HTTP/1.1 200 OK
Content-Length: 0
      Copy to Clipboard Toggle word wrap

    3. 次のコマンドを実行して出力を確認し、コントローラーがポート 80 の Ingress Controller リソースにアクセスできることを確認します。 

      $ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>
      Copy to Clipboard Toggle word wrap

      設定が正しい場合、コマンドの出力には次の応答が表示されます。 

      HTTP/1.1 302 Found
content-length: 0
location: https://console-openshift-console.apps.ocp4.private.opequon.net/
cache-control: no-cache
      Copy to Clipboard Toggle word wrap

    4. 次のコマンドを実行して出力を確認し、コントローラーがポート 443 の Ingress Controller リソースにアクセスできることを確認します。 

      $ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

      設定が正しい場合、コマンドの出力には次の応答が表示されます。 

      HTTP/1.1 200 OK
referrer-policy: strict-origin-when-cross-origin
set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
x-content-type-options: nosniff
x-dns-prefetch-control: off
x-frame-options: DENY
x-xss-protection: 1; mode=block
date: Wed, 04 Oct 2023 16:29:38 GMT
content-type: text/html; charset=utf-8
set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
cache-control: private
      Copy to Clipboard Toggle word wrap

  3. ユーザー管理ロードバランサーのフロントエンド IP アドレスをターゲットにするようにクラスターの DNS レコードを設定します。ロードバランサー経由で、クラスター API およびアプリケーションの DNS サーバーのレコードを更新する必要があります。

    変更された DNS レコードの例

    <load_balancer_ip_address>  A  api.<cluster_name>.<base_domain>
A record pointing to Load Balancer Front End
    Copy to Clipboard Toggle word wrap 

    <load_balancer_ip_address>   A apps.<cluster_name>.<base_domain>
A record pointing to Load Balancer Front End
    Copy to Clipboard Toggle word wrap
    重要

    DNS の伝播では、各 DNS レコードが使用可能になるまでに時間がかかる場合があります。各レコードを検証する前に、各 DNS レコードが伝播されることを確認してください。

  4. OpenShift Container Platform クラスターでユーザー管理ロードバランサーを使用するには、クラスターの install-config.yaml ファイルで次の設定を指定する必要があります。 

    # ...
platform:
    loadBalancer:
      type: UserManaged
    1 
    
    apiVIPs:
    - <api_ip>
    2 
    
    ingressVIPs:
    - <ingress_ip>
    3 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    クラスターのユーザー管理ロードバランサーを指定するには、type パラメーターに UserManaged を設定します。パラメーターのデフォルトは OpenShiftManagedDefault で、これはデフォルトの内部ロードバランサーを示します。openshift-kni-infra namespace で定義されたサービスの場合、ユーザー管理ロードバランサーは coredns サービスをクラスター内の Pod にデプロイできますが、keepalived および haproxy サービスは無視します。
    2
    ユーザー管理ロードバランサーを指定する場合に必須のパラメーターです。Kubernetes API がユーザー管理ロードバランサーと通信できるように、ユーザー管理ロードバランサーのパブリック IP アドレスを指定します。
    3
    ユーザー管理ロードバランサーを指定する場合に必須のパラメーターです。ユーザー管理ロードバランサーのパブリック IP アドレスを指定して、ユーザー管理ロードバランサーがクラスターの Ingress トラフィックを管理できるようにします。

検証

  1. curl CLI コマンドを使用して、ユーザー管理ロードバランサーと DNS レコード設定が動作していることを確認します。

    1. 次のコマンドを実行して出力を確認し、クラスター API にアクセスできることを確認します。 

      $ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure
      Copy to Clipboard Toggle word wrap

      設定が正しい場合は、応答として JSON オブジェクトを受信します。 

      {
  "major": "1",
  "minor": "11+",
  "gitVersion": "v1.11.0+ad103ed",
  "gitCommit": "ad103ed",
  "gitTreeState": "clean",
  "buildDate": "2019-01-09T06:44:10Z",
  "goVersion": "go1.10.3",
  "compiler": "gc",
  "platform": "linux/amd64"
  }
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して出力を確認し、クラスターマシン設定にアクセスできることを確認します。 

      $ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
      Copy to Clipboard Toggle word wrap

      設定が正しい場合、コマンドの出力には次の応答が表示されます。 

      HTTP/1.1 200 OK
Content-Length: 0
      Copy to Clipboard Toggle word wrap

    3. 以下のコマンドを実行して出力を確認し、ポートで各クラスターアプリケーションにアクセスできることを確認します。 

      $ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
      Copy to Clipboard Toggle word wrap

      設定が正しい場合、コマンドの出力には次の応答が表示されます。 

      HTTP/1.1 302 Found
content-length: 0
location: https://console-openshift-console.apps.<cluster-name>.<base domain>/
cache-control: no-cacheHTTP/1.1 200 OK
referrer-policy: strict-origin-when-cross-origin
set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure
x-content-type-options: nosniff
x-dns-prefetch-control: off
x-frame-options: DENY
x-xss-protection: 1; mode=block
date: Tue, 17 Nov 2020 08:42:10 GMT
content-type: text/html; charset=utf-8
set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None
cache-control: private
      Copy to Clipboard Toggle word wrap

    4. 次のコマンドを実行して出力を確認し、ポート 443 で各クラスターアプリケーションにアクセスできることを確認します。 

      $ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
      Copy to Clipboard Toggle word wrap

      設定が正しい場合、コマンドの出力には次の応答が表示されます。 

      HTTP/1.1 200 OK
referrer-policy: strict-origin-when-cross-origin
set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
x-content-type-options: nosniff
x-dns-prefetch-control: off
x-frame-options: DENY
x-xss-protection: 1; mode=block
date: Wed, 04 Oct 2023 16:29:38 GMT
content-type: text/html; charset=utf-8
set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
cache-control: private
      Copy to Clipboard Toggle word wrap

3.2. Bare Metal Operator について
リンクのコピー

Bare Metal Operator (BMO) を使用して、クラスター内のベアメタルホストをプロビジョニング、管理、検査します。

BMO はこれらのタスクを完了するために次のリソースを使用します。

  • BareMetalHost
  • HostFirmwareSettings
  • FirmwareSchema
  • HostFirmwareComponents

BMO は、各ベアメタルホストを BareMetalHost カスタムリソース定義のインスタンスにマッピングすることにより、クラスター内の物理ホストのインベントリーを維持します。各 BareMetalHost リソースには、ハードウェア、ソフトウェア、およびファームウェアの詳細が含まれています。BMO は、クラスター内のベアメタルホストを継続的に検査して、各 BareMetalHost リソースが対応するホストのコンポーネントを正確に詳述していることを確認します。

BMO は、HostFirmwareSettings リソース、FirmwareSchema リソース、および HostFirmwareComponents リソースを使用して、ファームウェア仕様の詳細を指定し、ベアメタルホストのファームウェアをアップグレードまたはダウングレードします。

BMO は、Ironic API サービスを使用してクラスター内のベアメタルホストと接続します。Ironic サービスは、ホスト上のベースボード管理コントローラー (BMC) を使用して、マシンと接続します。

BMO を使用して実行できる一般的なタスクには、次のようなものがあります。

  • 特定のイメージを使用したクラスターへのベアメタルホストのプロビジョニング
  • プロビジョニング前またはプロビジョニング解除後におけるホストのディスクコンテンツのフォーマット
  • ホストのオン/オフの切り替え
  • ファームウェア設定の変更
  • ホストのハードウェア詳細の表示
  • ホストのファームウェアを特定のバージョンにアップグレードまたはダウングレードする

3.2.1. Bare Metal Operator のアーキテクチャー
リンクのコピー

Bare Metal Operator (BMO) は、次のリソースを使用して、クラスター内のベアメタルホストをプロビジョニング、管理、検査します。次の図は、これらのリソースのアーキテクチャーを示しています。

BMO アーキテクチャーの概要
View larger image
BMO アーキテクチャーの概要

BareMetalHost

BareMetalHost リソースは、物理ホストとそのプロパティーを定義します。ベアメタルホストをクラスターにプロビジョニングするときは、そのホストの BareMetalHost リソースを定義する必要があります。ホストの継続的な管理のために、BareMetalHost の情報を調べたり、この情報を更新したりできます。

BareMetalHost リソースには、次のようなプロビジョニング情報が含まれます。

  • オペレーティングシステムのブートイメージやカスタム RAM ディスクなどのデプロイメント仕様
  • プロビジョニング状態
  • ベースボード管理コントローラー (BMC) アドレス
  • 目的の電源状態

BareMetalHost リソースには、次のようなハードウェア情報が含まれます。

  • CPU 数
  • NIC の MAC アドレス
  • ホストのストレージデバイスのサイズ
  • 現在の電源状態

HostFirmwareSettings

HostFirmwareSettings リソースを使用して、ホストのファームウェア設定を取得および管理できます。ホストが Available 状態に移行すると、Ironic サービスはホストのファームウェア設定を読み取り、HostFirmwareSettings リソースを作成します。BareMetalHost リソースと HostFirmwareSettings リソースの間には 1 対 1 のマッピングがあります。

HostFirmwareSettings リソースを使用して、ホストのファームウェア仕様を調べたり、ホストのファームウェア仕様を更新したりできます。

注記

HostFirmwareSettings リソースの spec フィールドを編集するときは、ベンダーファームウェアに固有のスキーマに従う必要があります。このスキーマは、読み取り専用の FirmwareSchema リソースで定義されます。

FirmwareSchema

ファームウェア設定は、ハードウェアベンダーやホストモデルによって異なります。FirmwareSchema リソースは、各ホストモデル上の各ファームウェア設定のタイプおよび制限が含まれる読み取り専用リソースです。データは、Ironic サービスを使用して BMC から直接取得されます。FirmwareSchema リソースを使用すると、HostFirmwareSettings リソースの spec フィールドに指定できる有効な値を特定できます。

スキーマが同じであれば、FirmwareSchema リソースは多くの BareMetalHost リソースに適用できます。

HostFirmwareComponents

Metal3 は、BIOS およびベースボード管理コントローラー (BMC) ファームウェアのバージョンを記述する HostFirmwareComponents リソースを提供します。HostFirmwareComponents リソースの spec フィールドを編集することで、ホストのファームウェアを特定のバージョンにアップグレードまたはダウングレードできます。これは、特定のファームウェアバージョンに対してテストされた検証済みパターンを使用してデプロイする場合に便利です。

3.3. カスタマイズした br-ex ブリッジを含むマニフェストオブジェクトの作成
リンクのコピー

カスタマイズした br-ex ブリッジを含むマニフェストオブジェクトを作成する場合は、次のユースケースを検討してください。

  • Open vSwitch (OVS) または OVN-Kubernetes br-ex ブリッジネットワークの変更など、ブリッジにインストール後の変更を加えたい場合。configure-ovs.sh シェルスクリプトは、ブリッジへのインストール後の変更をサポートしていません。
  • ホストまたはサーバーの IP アドレスで使用可能なインターフェイスとは異なるインターフェイスにブリッジをデプロイします。
  • configure-ovs.sh シェルスクリプトでは不可能な、ブリッジの高度な設定を実行したいと考えています。これらの設定にスクリプトを使用すると、ブリッジが複数のネットワークインターフェイスに接続できず、インターフェイス間のデータ転送が促進されない可能性があります。

前提条件

  • configure-ovs の代替方法を使用して、カスタマイズされた br-ex を設定している。
  • Kubernetes NMState Operator がインストールされている。

手順

  • NodeNetworkConfigurationPolicy (NNCP) CR を作成し、カスタマイズされた br-ex ブリッジネットワーク設定を定義します。br-ex NNCP CR には、ネットワークの OVN-Kubernetes マスカレード IP アドレスとサブネットが含まれている必要があります。サンプルの NNCP CR には、ipv4.address.ip および ipv6.address.ip パラメーターにデフォルト値が含まれます。ipv4.address.ip、ipv6.address.ip、またはその両方で masquerade IP アドレスを設定できます。

    重要

    インストール後のタスクとして、カスタマイズした br-ex ブリッジのプライマリー IP アドレスを変更できません。シングルスタッククラスターネットワークをデュアルスタッククラスターネットワークに変換する場合、NNCP CR でセカンダリー IPv6 アドレスは追加または変更できますが、既存のプライマリー IP アドレスは変更できません。 

    apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: worker-0-br-ex
spec:
  nodeSelector:
    kubernetes.io/hostname: worker-0
    desiredState:
    interfaces:
    - name: enp2s0
      type: ethernet
      state: up
      ipv4:
        enabled: false
      ipv6:
        enabled: false
    - name: br-ex
      type: ovs-bridge
      state: up
      ipv4:
        enabled: false
        dhcp: false
      ipv6:
        enabled: false
        dhcp: false
      bridge:
        options:
          mcast-snooping-enable: true
        port:
        - name: enp2s0
        - name: br-ex
    - name: br-ex
      type: ovs-interface
      state: up
      copy-mac-from: enp2s0
      ipv4:
        enabled: true
        dhcp: true
        auto-route-metric: 48
        address:
        - ip: "169.254.0.2"
          prefix-length: 17
      ipv6:
        enabled: true
        dhcp: true
        auto-route-metric: 48
        address:
        - ip: "fd69::2"
        prefix-length: 112
# ...
    Copy to Clipboard Toggle word wrap

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

    metadata.name
    ポリシーの名前。
    interfaces.name
    インターフェイスの名前。
    interfaces.type
    イーサネットのタイプ。
    interfaces.state
    作成後のインターフェイスの要求された状態。
    ipv4.enabled
    この例では、IPv4 と IPv6 を無効にします。
    port.name
    ブリッジが接続されているノード NIC。
    address.ip
    デフォルトの IPv4 および IPv6 の IP アドレスを表示します。ネットワークの masquerade IPv4 および IPv6 の IP アドレスを設定するようにしてください。
    auto-route-metric
    br-ex デフォルトルートに常に最高の優先度 (最も低いメトリック値) を付与するには、パラメーターを 48 に設定します。この設定により、NetworkManager サービスによって自動的に設定される他のインターフェイスとのルーティングの競合が防止されます。

次のステップ

  • コンピュートノードをスケーリングして、クラスター内に存在する各コンピュートノードに、カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトを適用します。詳細は、関連情報 セクションの「クラスターの拡張」を参照してください。

3.4. BareMetalHost リソースについて
リンクのコピー

Metal3 で、物理ホストとそのプロパティーを定義する BareMetalHost リソースの概念が導入されました。BareMetalHost リソースには、2 つのセクションが含まれます。

  1. BareMetalHost spec
  2. BareMetalHost status

3.4.1. BareMetalHost spec
リンクのコピー

BareMetalHost リソースの spec セクションは、ホストの必要な状態を定義します。

Expand
表3.1 BareMetalHost spec
パラメーター説明

automatedCleaningMode

プロビジョニングおよびプロビジョニング解除時の自動クリーニングを有効または無効にするインターフェイス。disabled に設定すると、自動クリーニングはスキップされます。metadata に設定すると、自動消去が有効になります。デフォルト設定は metadata です。 

bmc:
  address:
  credentialsName:
  disableCertificateVerification:
Copy to Clipboard Toggle word wrap

bmc 設定には、ホスト上のベースボード管理コントローラー (BMC) の接続情報が含まれます。フィールドの詳細は以下のとおりです。

  • address: ホストの BMC コントローラーとの通信用の URL。
  • credentialsName: BMC のユーザー名およびパスワードが含まれるシークレットへの参照。
  • disableCertificateVerification: true に設定されている場合に証明書の検証を省略するブール値。

bootMACAddress

ホストのプロビジョニングに使用する NIC の MAC アドレス。

bootMode

ホストのブートモード。デフォルトは UEFI ですが、BIOS ブートの legacy または UEFISecureBoot に設定することもできます。

consumerRef

ホストを使用している別のリソースへの参照。別のリソースが現在ホストを使用していない場合は、空になることがあります。たとえば、machine-api がホストを使用している場合に、Machine リソースがホストを使用する場合があります。

description

ホストの特定に役立つ、人間が提供した文字列。

externallyProvisioned

ホストのプロビジョニングとプロビジョニング解除が外部で管理されるかどうかを示すブール値。設定される場合:

  • 電源ステータスは、オンラインフィールドを使用して引き続き管理できます。
  • ハードウェアインベントリーは監視されますが、プロビジョニング操作やプロビジョニング解除操作はホストで実行されません。

firmware

ベアメタルホストの BIOS 設定に関する情報が含まれます。現在、firmware は、iRMC、iDRAC、iLO4、および iLO5 BMC でのみサポートされます。サブフィールドは以下のとおりです。

  • simultaneousMultithreadingEnabled: 単一の物理プロセッサーコアが複数の論理プロセッサーとして表示されるのを許可します。有効な設定は true または false です。
  • sriovEnabled: SR-IOV のサポートにより、ハイパーバイザーが PCI-express デバイスの仮想インスタンスを作成できるようになり、パフォーマンスが向上する可能性があります。有効な設定は true または false です。
  • virtualizationEnabled: プラットフォームハードウェアの仮想化をサポートします。有効な設定は true または false です。 
image:
  url:
  checksum:
  checksumType:
  format:
Copy to Clipboard Toggle word wrap

image 設定には、ホストにデプロイされるイメージの詳細が保持されます。Ironic にはイメージフィールドが必要です。ただし、externallyProvisioned 設定が true に設定されていて、外部管理に電源制御が不要な場合、フィールドは空のままでもかまいません。この設定では次のフィールドがサポートされています。

  • url: ホストにデプロイするイメージの URL。
  • checksum: 実際のチェックサム、または image.url のイメージのチェックサムが含まれるファイルへの URL。
  • checksumType: チェックサムアルゴリズムを指定できます。現時点で image.checksumType は md5、sha256、および sha512 のみをサポートしています。デフォルトのチェックサムタイプは md5 です。
  • format: これはイメージのディスク形式です。raw、qcow2、vdi、vmdk、live-iso のいずれか、未設定のままにすることができます。これを raw に設定すると、そのイメージの Ironic エージェントでの raw イメージのストリーミングが有効になります。これを live-iso に設定すると、iso イメージをディスクにデプロイせずにライブブートが可能になり、checksum フィールドは無視されます。

networkData

ネットワーク設定データおよびその namespace が含まれるシークレットへの参照。したがって、ホストが起動してネットワークをセットアップする前にホストに接続することができます。

online

ホストの電源を入れる (true) かオフにする (false) かを示すブール値。この値を変更すると、物理ホストの電源状態に変更が加えられます。 

raid:
  hardwareRAIDVolumes:
  softwareRAIDVolumes:
Copy to Clipboard Toggle word wrap

(オプション) ベアメタルホストの RAID 設定に関する情報が含まれます。指定しない場合は、現在の設定を保持します。

注記

OpenShift Container Platform 4.20 は、BMC のインストールドライブ上で以下のハードウェア RAID をサポートします。

  • RAID レベル 0、1、5、6、および 10 をサポートする Fujitsu iRMC
  • ファームウェアバージョン 6.10.30.20 以降および RAID レベル 0、1、および 5 に対応した Redfish API を使用する Dell iDRAC

OpenShift Container Platform 4.20 は、インストールドライブ上のソフトウェア RAID をサポートしていません。

次の構成設定を参照してください。

  • hardwareRAIDVolumes: ハードウェア RAID の論理ドライブの一覧が含まれ、ハードウェア RAID で必要なボリューム設定を定義します。rootDeviceHints を指定しない場合、最初のボリュームがルートボリュームになります。サブフィールドは以下のとおりです。

    • level: 論理ドライブの RAID レベル。0、1、2、5、6、1+0、5+0、6+0 のレベルがサポートされます。
    • name: 文字列としてのボリュームの名前。サーバー内で一意である必要があります。指定されていない場合、ボリューム名は自動生成されます。
    • numberOfPhysicalDisks: 論理ドライブに使用する物理ドライブの数 (整数)。デフォルトは、特定の RAID レベルに必要なディスクドライブの最小数です。
    • physicalDisks: 物理ディスクドライブの名前の一覧です (文字列)。これはオプションのフィールドです。指定した場合、controller フィールドも指定する必要があります。
    • controller: (オプション) ハードウェア RAID ボリュームで使用する RAID コントローラーの名前 (文字列)。
    • rotational: true に設定すると、回転ディスクを用いるドライブのみが選択されます。false に設定すると、ソリッドステートドライブと NVMe ドライブのみが選択されます。設定されていない場合は、任意のドライブの種類を選択します (デフォルト動作)。
    • sizeGibibytes: 作成する論理ドライブのサイズ (GiB 単位の整数)。指定がない場合や 0 に設定すると、論理ドライブ用に物理ドライブの最大容量が使用されます。

  • softwareRAIDVolumes: OpenShift Container Platform 4.20 は、インストールドライブ上のソフトウェア RAID をサポートしていません。この設定には、ソフトウェア RAID の論理ディスクのリストが含まれています。rootDeviceHints を指定しない場合、最初のボリュームがルートボリュームになります。HardwareRAIDVolumes を設定すると、この項目は無効になります。ソフトウェア RAID は常に削除されます。作成されるソフトウェア RAID デバイスの数は、1 または 2 である必要があります。ソフトウェア RAID デバイスが 1 つしかない場合は、RAID-1 にする必要があります。2 つの RAID デバイスがある場合は、1 番目のデバイスを RAID-1 にする必要があります。また、2 番目のデバイスの RAID レベルは 0、1、または 1+0 に設定できます。最初の RAID デバイスはデプロイメントデバイスになりますが、ソフトウェア RAID ボリュームにすることはできません。RAID-1 を強制すると、デバイス障害が発生した場合にノードが起動しなくなるリスクが軽減されます。softwareRAIDVolume フィールドは、ソフトウェア RAID のボリュームの必要な設定を定義します。サブフィールドは以下のとおりです。

    • level: 論理ドライブの RAID レベル。0、1、1+0 のレベルがサポートされます。
    • physicalDisks: デバイスのヒントの一覧。アイテム数は、2 以上である必要があります。
    • sizeGibibytes: 作成される論理ディスクドライブのサイズ (GiB 単位の整数)。指定がない場合や 0 に設定すると、論理ドライブ用に物理ドライブの最大容量が使用されます。

hardwareRAIDVolume を空のスライスとして設定すると、ハードウェア RAID 設定を消去できます。以下に例を示します。 

spec:
   raid:
     hardwareRAIDVolume: []
Copy to Clipboard Toggle word wrap

ドライバーが RAID に対応していないことを示すエラーメッセージが表示された場合は、raid、hardwareRAIDVolumes または softwareRAIDVolumes を nil に設定します。ホストに RAID コントローラーがあることを確認する必要がある場合があります。 

rootDeviceHints:
  deviceName:
  hctl:
  model:
  vendor:
  serialNumber:
  minSizeGigabytes:
  wwn:
  wwnWithExtension:
  wwnVendorExtension:
  rotational:
Copy to Clipboard Toggle word wrap

rootDeviceHints パラメーターを使用すると、特定のデバイスへの RHCOS イメージのプロビジョニングが可能になります。これは、検出順にデバイスを検査し、検出された値をヒントの値と比較します。ヒントの値と一致する最初に検出されたデバイスが使用されます。設定では複数のヒントを組み合わせることができますが、デバイスが選択されるには、デバイスがすべてのヒントと一致する必要があります。フィールドの詳細は以下のとおりです。

  • deviceName: /dev/vda などの Linux デバイス名が含まれる文字列。ヒントは、実際の値と完全に一致する必要があります。
  • hctl: 0:0:0:0 などの SCSI バスアドレスが含まれる文字列。ヒントは、実際の値と完全に一致する必要があります。
  • model: ベンダー固有のデバイス識別子が含まれる文字列。ヒントは、実際の値のサブ文字列になります。
  • vendor: デバイスのベンダーまたは製造元の名前が含まれる文字列。ヒントは、実際の値のサブ文字列になります。
  • serialNumber: デバイスのシリアル番号が含まれる文字列。ヒントは、実際の値と完全に一致する必要があります。
  • minSizeGigabytes: デバイスの最小サイズを表す整数 (ギガバイト単位)。
  • wwn: 一意のストレージ ID が含まれる文字列。ヒントは、実際の値と完全に一致する必要があります。
  • wwnWithExtension: ベンダー拡張が追加された一意のストレージ ID が含まれる文字列。ヒントは、実際の値と完全に一致する必要があります。
  • wwnVendorExtension: 一意のベンダーストレージ ID が含まれる文字列。ヒントは、実際の値と完全に一致する必要があります。
  • rotational: デバイスが回転ディスクを用いる (true) か、そうでないか (false) を示すブール値。

3.4.2. BareMetalHost status
リンクのコピー

BareMetalHost status は、ホストの現在の状態を表し、テスト済みの認証情報、現在のハードウェアの詳細などの情報が含まれます。

Expand
表3.2 BareMetalHost status
パラメーター説明

goodCredentials

シークレットおよびその namespace の参照で、システムが動作中と検証できるベースボード管理コントローラー (BMC) 認証情報のセットが保持されています。

errorMessage

プロビジョニングバックエンドが報告する最後のエラーの詳細 (ある場合)。

errorType

ホストがエラー状態になった原因となった問題のクラスを示します。エラータイプは以下のとおりです。

  • provisioned registration error: コントローラーがプロビジョニング済みのホストを再登録できない場合に発生します。
  • registration error: コントローラーがホストのベースボード管理コントローラーに接続できない場合に発生します。
  • inspection error: ホストからハードウェア詳細の取得を試みて失敗した場合に発生します。
  • preparation error: クリーニングに失敗した場合に発生します。
  • provisioning error: コントローラーがホストのプロビジョニングまたはプロビジョニング解除に失敗した場合に発生します。
  • power management error: コントローラーがホストの電源状態を変更できない場合に発生します。
  • detach error: コントローラーがホストをプロビジョナーからデタッチできない場合に発生します。 
hardware:
  cpu
    arch:
    model:
    clockMegahertz:
    flags:
    count:
Copy to Clipboard Toggle word wrap

hardware.cpu フィールドは、システム内の CPU の詳細を示します。フィールドには以下が含まれます。

  • arch: CPU のアーキテクチャー。
  • model: CPU モデル (文字列)。
  • clockMegahertz: CPU の速度 (MHz 単位)。
  • flags: CPU フラグのリスト。たとえば、'mmx','sse','sse2','vmx' などです。
  • count: システムで利用可能な CPU の数。 
hardware:
  firmware:
Copy to Clipboard Toggle word wrap

BIOS ファームウェア情報が含まれます。たとえば、ハードウェアベンダーおよびバージョンなどです。 

hardware:
  nics:
  - ip:
    name:
    mac:
    speedGbps:
    vlans:
    vlanId:
    pxe:
Copy to Clipboard Toggle word wrap

hardware.nics フィールドには、ホストのネットワークインターフェイスの一覧が含まれます。フィールドには以下が含まれます。

  • ip: NIC の IP アドレス (検出エージェントの実行時に IP アドレスが割り当てられている場合)。
  • name: ネットワークデバイスを識別する文字列。例:nic-1
  • mac: NIC の MAC アドレス。
  • speedGbps: デバイスの速度 (Gbps 単位)。
  • vlans: この NIC で利用可能な VLAN をすべて保持するリスト。
  • vlanId: タグ付けされていない VLAN ID。
  • pxe: NIC が PXE を使用して起動できるかどうか。 
hardware:
  ramMebibytes:
Copy to Clipboard Toggle word wrap

ホストのメモリー容量 (MiB 単位)。 

hardware:
  storage:
  - name:
    rotational:
    sizeBytes:
    serialNumber:
Copy to Clipboard Toggle word wrap

hardware.storage フィールドには、ホストで利用可能なストレージデバイスの一覧が含まれます。フィールドには以下が含まれます。

  • name: ストレージデバイスを識別する文字列。たとえば、disk 1 (boot) などです。
  • rotational: ディスクが回転ディスクを用いるかどうかを示します。true または false のいずれかを返します。
  • sizeBytes: ストレージデバイスのサイズ。
  • serialNumber: デバイスのシリアル番号。 
hardware:
  systemVendor:
    manufacturer:
    productName:
    serialNumber:
Copy to Clipboard Toggle word wrap

ホストの manufacturer、productName、および serialNumber に関する情報が含まれます。

lastUpdated

ホストのステータスの最終更新時のタイムスタンプ。

operationalStatus

サーバーのステータス。ステータスは以下のいずれかになります。

  • OK: ホストの詳細がすべて認識され、正しく設定され、機能し、管理可能であることを示します。
  • discovered: ホストの詳細の一部が正常に動作していないか、欠落しているかのいずれかを意味します。たとえば、BMC アドレスは認識されているが、ログイン認証情報が認識されていない。
  • error: システムで回復不能なエラーが検出されたことを示します。詳細は、status セクションの errorMessage フィールドを参照してください。
  • delayed: 複数ホストの同時プロビジョニングを制限するために、プロビジョニングが遅延していることを示します。
  • detached: ホストが unmanaged として識別されていることを示します。

poweredOn

ホストの電源が入っているかどうかを示すブール値。 

provisioning:
  state:
  id:
  image:
  raid:
  firmware:
  rootDeviceHints:
Copy to Clipboard Toggle word wrap

provisioning フィールドには、ホストへのイメージのデプロイに関連する値が含まれます。サブフィールドには以下が含まれます。

  • state: 進行中のプロビジョニング操作の現在の状態。状態には、以下が含まれます。

    • <empty string>: 現在、プロビジョニングは行われていません。
    • unmanaged: ホストを登録するのに十分な情報が利用できません。
    • registering: エージェントはホストの BMC の詳細を確認しています。
    • match profile: エージェントは、ホストで検出されたハードウェア詳細と既知のプロファイルを比較しています。
    • available: ホストはプロビジョニングに使用できます。この状態は、以前は ready として知られていました。
    • preparing: 既存の設定は削除され、新しい設定がホストに設定されます。
    • provisioning: プロビジョナーはイメージをホストのストレージに書き込んでいます。
    • provisioned: プロビジョナーはイメージをホストのストレージに書き込みました。
    • externally provisioned: Metal3 は、ホスト上のイメージを管理しません。
    • deprovisioning: プロビジョナーは、ホストのストレージからイメージを消去しています。
    • inspecting: エージェントはホストのハードウェア情報を収集しています。
    • deleting: エージェントはクラスターから削除しています。
  • id: 基礎となるプロビジョニングツールのサービスの一意識別子。
  • image: 直近ホストにプロビジョニングされたイメージ。
  • raid: 最近設定したハードウェアまたはソフトウェア RAID ボリュームの一覧。
  • firmware: ベアメタルサーバーの BIOS 設定。
  • rootDeviceHints: 直近のプロビジョニング操作に使用されたルートデバイス選択の手順。

triedCredentials

プロビジョニングバックエンドに送信された BMC 認証情報の最後のセットを保持するシークレットおよびその namespace への参照。

3.5. BareMetalHost リソースの取得
リンクのコピー

BareMetalHost リソースには、物理ホストのプロパティーが含まれます。物理ホストのプロパティーをチェックするには、その BareMetalHost リソースを取得する必要があります。

手順

  1. BareMetalHost リソースの一覧を取得します。 

    $ oc get bmh -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap
    注記

    oc get コマンドで、bmh の長い形式として、baremetalhost を使用できます。

  2. ホストのリストを取得します。 

    $ oc get bmh -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  3. 特定のホストの BareMetalHost リソースを取得します。 

    $ oc get bmh <host_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    ここで、<host_name> はホストの名前です。

    出力例

    apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  creationTimestamp: "2022-06-16T10:48:33Z"
  finalizers:
  - baremetalhost.metal3.io
  generation: 2
  name: openshift-worker-0
  namespace: openshift-machine-api
  resourceVersion: "30099"
  uid: 1513ae9b-e092-409d-be1b-ad08edeb1271
spec:
  automatedCleaningMode: metadata
  bmc:
    address: redfish://10.46.61.19:443/redfish/v1/Systems/1
    credentialsName: openshift-worker-0-bmc-secret
    disableCertificateVerification: true
  bootMACAddress: 48:df:37:c7:f7:b0
  bootMode: UEFI
  consumerRef:
    apiVersion: machine.openshift.io/v1beta1
    kind: Machine
    name: ocp-edge-958fk-worker-0-nrfcg
    namespace: openshift-machine-api
  customDeploy:
    method: install_coreos
  online: true
  rootDeviceHints:
    deviceName: /dev/disk/by-id/scsi-<serial_number>
  userData:
    name: worker-user-data-managed
    namespace: openshift-machine-api
status:
  errorCount: 0
  errorMessage: ""
  goodCredentials:
    credentials:
      name: openshift-worker-0-bmc-secret
      namespace: openshift-machine-api
    credentialsVersion: "16120"
  hardware:
    cpu:
      arch: x86_64
      clockMegahertz: 2300
      count: 64
      flags:
      - 3dnowprefetch
      - abm
      - acpi
      - adx
      - aes
      model: Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz
    firmware:
      bios:
        date: 10/26/2020
        vendor: HPE
        version: U30
    hostname: openshift-worker-0
    nics:
    - mac: 48:df:37:c7:f7:b3
      model: 0x8086 0x1572
      name: ens1f3
    ramMebibytes: 262144
    storage:
    - hctl: "0:0:0:0"
      model: VK000960GWTTB
      name: /dev/disk/by-id/scsi-<serial_number>
      sizeBytes: 960197124096
      type: SSD
      vendor: ATA
    systemVendor:
      manufacturer: HPE
      productName: ProLiant DL380 Gen10 (868703-B21)
      serialNumber: CZ200606M3
  lastUpdated: "2022-06-16T11:41:42Z"
  operationalStatus: OK
  poweredOn: true
  provisioning:
    ID: 217baa14-cfcf-4196-b764-744e184a3413
    bootMode: UEFI
    customDeploy:
      method: install_coreos
    image:
      url: ""
    raid:
      hardwareRAIDVolumes: null
      softwareRAIDVolumes: []
    rootDeviceHints:
      deviceName: /dev/disk/by-id/scsi-<serial_number>
    state: provisioned
  triedCredentials:
    credentials:
      name: openshift-worker-0-bmc-secret
      namespace: openshift-machine-api
    credentialsVersion: "16120"
    Copy to Clipboard Toggle word wrap

3.6. BareMetalHost リソースの編集
リンクのコピー

OpenShift Container Platform クラスターをベアメタルにデプロイした後、ノードの BareMetalHost リソースを編集する必要がある場合があります。たとえば、次のような例が考えられます。

  • Assisted Installer を使用してクラスターをデプロイし、ベースボード管理コントローラー (BMC) のホスト名または IP アドレスを追加または編集する必要がある。
  • ノードをプロビジョニング解除せずに、あるクラスターから別のクラスターに移動する必要がある。

前提条件

  • ノードが Provisioned、ExternallyProvisioned、または Available 状態であることを確認する。

手順

  1. ノードのリストを取得します。 

    $ oc get bmh -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  2. ノードの BareMetalHost リソースを編集する前に、次のコマンドを実行してノードを Ironic からデタッチします。 

    $ oc annotate baremetalhost <node_name> -n openshift-machine-api 'baremetalhost.metal3.io/detached=true'
    1
    Copy to Clipboard Toggle word wrap
    1
    <node_name> はノード名に置き換えてください。

  3. 次のコマンドを実行して、BareMetalHost リソースを編集します。 

    $ oc edit bmh <node_name> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、ノードを Ironic に再アタッチします。 

    $ oc annotate baremetalhost <node_name> -n openshift-machine-api 'baremetalhost.metal3.io/detached'-
    Copy to Clipboard Toggle word wrap

3.7. BareMetalHost リソースを削除する際の遅延のトラブルシューティング
リンクのコピー

Bare Metal Operator (BMO) が BareMetalHost リソースを削除すると、Ironic がベアメタルホストのプロビジョニングを解除します。これは、たとえばマシンセットを縮小するときに発生する可能性があります。プロビジョニング解除には、"クリーニング" と呼ばれるプロセスが含まれます。このプロセスでは、次の手順が実行されます。

  • ベアメタルホストの電源をオフにする
  • ベアメタルホスト上のサービス RAM ディスクを起動する
  • すべてのディスクからパーティションメタデータを削除する
  • ベアメタルホストの電源を再度オフにする

クリーニングが成功しない場合は、BareMetalHost リソースの削除に長い時間がかかり、削除が完了しないことがあります。

重要

BareMetalHost リソースを強制的に削除するためにファイナライザーを削除しないでください。プロビジョニングバックエンドには、ホストレコードを保持する独自のデータベースがあります。ファイナライザーを削除して強制的に削除しようとしても、実行中のアクションは引き続き実行されます。後でベアメタルホストを追加しようとしたときに、予期しない問題が発生する可能性があります。

手順

  1. クリーニングプロセスが回復できる場合は、プロセスが完了するまで待ちます。
  2. クリーニングが回復できない場合は、BareMetalHost リソースを変更し、automaticCleaningMode フィールドを disabled に設定して、クリーニングプロセスを無効にします。

詳細は、「BareMetalHost リソースの編集」を参照してください。

3.8. ブータブルでない ISO をベアメタルノードにアタッチする
リンクのコピー

DataImage リソースを使用すると、ブータブルでない汎用の ISO 仮想メディアイメージを、プロビジョニングされたノードにアタッチできます。リソースを適用すると、起動後にオペレーティングシステムから ISO イメージにアクセスできるようになります。これは、オペレーティングシステムをプロビジョニングした後、ノードが初めて起動する前にノードを設定する場合に便利です。

前提条件

  • この機能をサポートするために、ノードが Redfish またはそれから派生したドライバーを使用している。
  • ノードが Provisioned または ExternallyProvisioned 状態である。
  • name が、BareMetalHost リソースで定義されているノードの名前と同じである。
  • ISO イメージへの有効な url がある。

手順

  1. DataImage リソースを作成します。 

    apiVersion: metal3.io/v1alpha1
kind: DataImage
metadata:
  name: <node_name>
    1 
    
spec:
  url: "http://dataimage.example.com/non-bootable.iso"
    2
    Copy to Clipboard Toggle word wrap
    1
    BareMetalHost リソースで定義されているノードの名前を指定します。
    2
    ISO イメージへの URL とパスを指定します。

  2. 次のコマンドを実行して、DataImage リソースをファイルに保存します。 

    $ vim <node_name>-dataimage.yaml
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、DataImage リソースを適用します。 

    $ oc apply -f <node_name>-dataimage.yaml -n <node_namespace>
    1
    Copy to Clipboard Toggle word wrap
    1
    namespace が BareMetalHost リソースの namespace と一致するように <node_namespace> を置き換えます。たとえば、openshift-machine-api です。

  4. ノードを再起動します。

    注記

    ノードを再起動するには、reboot.metal3.io アノテーションを割り当てるか、BareMetalHost リソースで online ステータスをリセットします。ベアメタルノードを強制的に再起動すると、ノードの状態がしばらくの間 NotReady に変わります。具体的には、5 分以上変わります。

  5. 次のコマンドを実行して、DataImage リソースを表示します。 

    $ oc get dataimage <node_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: v1
items:
- apiVersion: metal3.io/v1alpha1
  kind: DataImage
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"metal3.io/v1alpha1","kind":"DataImage","metadata":{"annotations":{},"name":"bmh-node-1","namespace":"openshift-machine-api"},"spec":{"url":"http://dataimage.example.com/non-bootable.iso"}}
    creationTimestamp: "2024-06-10T12:00:00Z"
    finalizers:
    - dataimage.metal3.io
    generation: 1
    name: bmh-node-1
    namespace: openshift-machine-api
    ownerReferences:
    - apiVersion: metal3.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: BareMetalHost
      name: bmh-node-1
      uid: 046cdf8e-0e97-485a-8866-e62d20e0f0b3
    resourceVersion: "21695581"
    uid: c5718f50-44b6-4a22-a6b7-71197e4b7b69
  spec:
    url: http://dataimage.example.com/non-bootable.iso
  status:
    attachedImage:
      url: http://dataimage.example.com/non-bootable.iso
    error:
      count: 0
      message: ""
    lastReconciled: "2024-06-10T12:05:00Z"
    Copy to Clipboard Toggle word wrap

3.9. HostFirmwareSettings リソースについて
リンクのコピー

HostFirmwareSettings リソースを使用して、ホストの BIOS 設定を取得および管理できます。ホストが Available 状態に移行すると、Ironic はホストの BIOS 設定を読み取り、HostFirmwareSettings リソースを作成します。リソースには、ベースボード管理コントローラー (BMC) から返される完全な BIOS 設定が含まれます。BareMetalHost リソースの firmware フィールドは、ベンダーに依存しない 3 つのフィールドを返しますが、HostFirmwareSettings リソースは、通常ホストごとにベンダー固有のフィールドの多数の BIOS 設定で構成されます。

HostFirmwareSettings リソースには、以下の 2 つのセクションが含まれます。

  1. HostFirmwareSettings spec
  2. HostFirmwareSettings status

3.9.1. HostFirmwareSettings spec
リンクのコピー

HostFirmwareSettings リソースの spec セクションは、ホストの BIOS の必要な状態を定義し、デフォルトでは空です。Ironic は spec.settings セクションの設定を使用して、ホストが Preparing 状態の場合、ベースボード管理コントローラー (BMC) を更新します。FirmwareSchema リソースを使用して、無効な名前と値のペアをホストに送信しないようにします。詳細は、「FirmwareSchema リソースについて」を参照してください。

例

spec:
  settings:
    ProcTurboMode: Disabled
1
Copy to Clipboard Toggle word wrap

1
前述の例では、spec.settings セクションには、ProcTurboMode BIOS 設定を Disabled に設定する名前/値のペアが含まれます。
注記

status セクションに一覧表示される整数パラメーターは文字列として表示されます。たとえば、"1" と表示されます。spec.settings セクションで整数を設定する場合、値は引用符なしの整数として設定する必要があります。たとえば、1 と設定します。

3.9.2. HostFirmwareSettings status
リンクのコピー

status は、ホストの BIOS の現在の状態を表します。

Expand
表3.3 HostFirmwareSettings
パラメーター説明
status:
  conditions:
  - lastTransitionTime:
    message:
    observedGeneration:
    reason:
    status:
    type:
Copy to Clipboard Toggle word wrap

conditions フィールドには、状態変更の一覧が含まれます。サブフィールドには以下が含まれます。

  • lastTransitionTime: 状態が最後に変更した時刻。
  • message: 状態変更の説明。
  • observedGeneration: status の現在の生成。metadata.generation とこのフィールドが同じでない場合には、status.conditions が古い可能性があります。
  • reason: 状態変更の理由。
  • status: 状態の変更のステータス。ステータスは True、False、または Unknown です。
  • type: 状態変更のタイプ。タイプは Valid および ChangeDetected です。 
status:
  schema:
    name:
    namespace:
    lastUpdated:
Copy to Clipboard Toggle word wrap

ファームウェア設定の FirmwareSchema。フィールドには以下が含まれます。

  • name: スキーマを参照する名前または一意の識別子。
  • namespace: スキーマが保存される namespace。
  • lastUpdated: リソースが最後に更新された時刻。 
status:
  settings:
Copy to Clipboard Toggle word wrap

settings フィールドには、ホストの現在の BIOS 設定の名前と値のペアのリストが含まれます。

3.10. HostFirmwareSettings リソースの取得
リンクのコピー

HostFirmwareSettings リソースには、物理ホストのベンダー固有の BIOS プロパティーが含まれます。物理ホストの BIOS プロパティーをチェックするには、その HostFirmwareSettings リソースを取得する必要があります。

手順

  1. HostFirmwareSettings リソースの詳細な一覧を取得します。 

    $ oc get hfs -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap
    注記

    oc get コマンドで、hfs の長い形式として、hostfirmwaresettingsを使用できます。

  2. HostFirmwareSettings リソースの一覧を取得します。 

    $ oc get hfs -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  3. 特定のホストの HostFirmwareSettings リソースを取得します。 

    $ oc get hfs <host_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    ここで、<host_name> はホストの名前です。

3.11. HostFirmwareSettings リソースの編集
リンクのコピー

プロビジョニングされたホストの HostFirmwareSettings を編集できます。

重要

読み取り専用の値を除き、ホストが プロビジョニング された状態にある場合にのみ、ホストを編集できます。externally provisioned 状態のホストは編集できません。

手順

  1. HostFirmwareSettings リソースの一覧を取得します。 

    $ oc get hfs -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  2. ホストの HostFirmwareSettings リソースを編集します。 

    $ oc edit hfs <host_name> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    ここで、<host_name> はプロビジョニングされたホストの名前です。HostFirmwareSettings リソースは、ターミナルのデフォルトエディターで開きます。

  3. spec.settings セクションに、名前と値のペアを追加します。

    例

    spec:
  settings:
    name: value
    1
    Copy to Clipboard Toggle word wrap

    1
    FirmwareSchema リソースを使用して、ホストで利用可能な設定を特定します。読み取り専用の値は設定できません。
  4. 変更を保存し、エディターを終了します。

  5. ホストのマシン名を取得します。 

     $ oc get bmh <host_name> -n openshift-machine name
    Copy to Clipboard Toggle word wrap

    ここで、<host_name> はホストの名前です。マシン名は CONSUMER フィールドの下に表示されます。

  6. マシンにアノテーションを付け、マシンセットから削除します。 

    $ oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    ここで、<machine_name> は削除するマシンの名前です。

  7. ノードのリストを取得し、ワーカーノードの数をカウントします。 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

  8. マシンセットを取得します。 

    $ oc get machinesets -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

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

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1>
    Copy to Clipboard Toggle word wrap

    ここで、<machineset_name> はマシンセットの名前で、<n-1> は減少させたワーカーノードの数です。

  10. ホストが Available の状態になったら、machineset をスケールアップして、HostFirmwareSettings リソースの変更を反映させます。 

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n>
    Copy to Clipboard Toggle word wrap

    ここで、<machineset_name> はマシンセットの名前で、<n> はワーカーノードの数です。

3.12. HostFirmware Settings リソースが有効であることの確認
リンクのコピー

ユーザーが spec.settings セクションを編集して HostFirmwareSetting (HFS) リソースに変更を加えると、Bare Metal Operator (BMO) は読み取り専用リソースである FimwareSchema リソースに対して変更を検証します。この設定が無効な場合、BMO は status.Condition 設定の Type の値を False に設定し、イベントを生成して HFS リソースに保存します。以下の手順を使用して、リソースが有効であることを確認します。

手順

  1. HostFirmwareSetting リソースの一覧を取得します。 

    $ oc get hfs -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  2. 特定のホストの HostFirmwareSettings リソースが有効であることを確認します。 

    $ oc describe hfs <host_name> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    ここで、<host_name> はホストの名前です。

    出力例

    Events:
  Type    Reason            Age    From                                    Message
  ----    ------            ----   ----                                    -------
  Normal  ValidationFailed  2m49s  metal3-hostfirmwaresettings-controller  Invalid BIOS setting: Setting ProcTurboMode is invalid, unknown enumeration value - Foo
    Copy to Clipboard Toggle word wrap

    重要

    応答が ValidationFailed を返す場合、リソース設定にエラーがあり、FirmwareSchema リソースに準拠するよう値を更新する必要があります。

3.13. FirmwareSchema リソースについて
リンクのコピー

BIOS 設定は、ハードウェアベンダーやホストモデルによって異なります。FirmwareSchema リソースは、各ホストモデル上の各 BIOS 設定のタイプおよび制限が含まれる読み取り専用リソースです。データは BMC から Ironic に直接取得されます。FirmwareSchema を使用すると、HostFirmwareSettings リソースの spec フィールドに指定できる有効な値を特定できます。FirmwareSchema リソースには、その設定および制限から派生する一意の識別子があります。同じホストモデルは同じ FirmwareSchema 識別子を使用します。HostFirmwareSettings の複数のインスタンスが同じ FirmwareSchema を使用する可能性が高いです。

Expand
表3.4 FirmwareSchema 仕様
パラメーター説明
<BIOS_setting_name>
  attribute_type:
  allowable_values:
  lower_bound:
  upper_bound:
  min_length:
  max_length:
  read_only:
  unique:
Copy to Clipboard Toggle word wrap

spec は、BIOS 設定名と設定の制限で構成される単純なマップです。フィールドには以下が含まれます。

  • attribute_type: 設定のタイプ。サポートされるタイプは以下のとおりです。

    • Enumeration
    • Integer
    • String
    • Boolean
  • allowable_values: attribute_type が Enumeration の場合の、許可される値のリスト。
  • lower_bound: attribute_type が Integer の場合に許可される最小値。
  • upper_bound: attribute_type が Integer の場合に許可される最大値。
  • min_length: attribute_type が String の場合に、値が取ることのできる最も短い文字列の長さ。
  • max_length: attribute_type が String の場合に、値が取ることのできる最も長い文字列の長さ。
  • read_only: 設定は読み取り専用で、変更することはできません。
  • unique: 設定はこのホストに固有のものです。

3.14. FirmwareSchema リソースの取得
リンクのコピー

各ベンダーの各ホストモデルの BIOS 設定は、それぞれ異なります。HostFirmwareSettings リソースの spec セクションを編集する際に、設定する名前/値のペアはそのホストのファームウェアスキーマに準拠している必要があります。有効な名前と値のペアを設定するには、ホストの FirmwareSchema を取得して確認します。

手順

  1. FirmwareSchema リソースインスタンスの一覧を取得するには、以下を実行します。 

    $ oc get firmwareschema -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  2. 特定の FirmwareSchema インスタンスを取得するには、以下を実行します。 

    $ oc get firmwareschema <instance_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    ここで、<instance_name> は、HostFirmwareSettings リソース (表 3 を参照) に記載されているスキーマインスタンスの名前です。

3.15. HostFirmwareComponents リソースについて
リンクのコピー

Metal3 は、BIOS およびベースボード管理コントローラー (BMC) ファームウェアのバージョンを記述する HostFirmwareComponents リソースを提供します。HostFirmwareComponents リソースには 2 つのセクションが含まれています。

  1. HostFirmwareComponents spec
  2. HostFirmwareComponents status

3.15.1. HostFirmwareComponents spec
リンクのコピー

HostFirmwareComponents リソースの spec セクションでは、ホストの BIOS および BMC バージョンの目的の状態を定義します。

Expand
表3.5 HostFirmwareComponents spec
パラメーター説明
updates:
  component:
  url:
Copy to Clipboard Toggle word wrap

updates 設定には、更新するコンポーネントを含めます。フィールドの詳細は以下のとおりです。

  • component: コンポーネントの名前。有効な設定は bios または bmc です。
  • url: コンポーネントのファームウェア仕様とバージョンへの URL。

3.15.2. HostFirmwareComponents status
リンクのコピー

HostFirmwareComponents リソースの status セクションは、ホストの BIOS および BMC バージョンの現在のステータスを返します。

Expand
表3.6 HostFirmwareComponents status
パラメーター説明
components:
  component:
  initialVersion:
  currentVersion:
  lastVersionFlashed:
  updatedAt:
Copy to Clipboard Toggle word wrap

components セクションには、コンポーネントのステータスが含まれています。フィールドの詳細は以下のとおりです。

  • component: ファームウェアコンポーネントの名前。bios または bmc を返します。
  • initialVersion: コンポーネントの初期ファームウェアバージョン。Ironic は、BareMetalHost リソースを作成するときにこの情報を取得します。ユーザーが変更することはできません。
  • currentVersion: コンポーネントの現在のファームウェアバージョン。この値は、Ironic がベアメタルホストのファームウェアを更新するまで、initialVersion の値と同じです。
  • lastVersionFlashed: ベアメタルホストでフラッシュされたコンポーネントの最後のファームウェアバージョン。Ironic がファームウェアを更新するまで、このフィールドは null を返します。
  • updatedAt: Ironic がベアメタルホストのファームウェアを更新したときのタイムスタンプ。 
updates:
  component:
  url:
Copy to Clipboard Toggle word wrap

updates 設定には、更新されたコンポーネントが含まれています。フィールドの詳細は以下のとおりです。

  • component: コンポーネントの名前。
  • url: コンポーネントのファームウェア仕様とバージョンへの URL。

3.16. HostFirmwareComponents リソースの取得
リンクのコピー

HostFirmwareComponents リソースには、物理ホストの BIOS およびベースボード管理コントローラー (BMC) の特定のファームウェアバージョンが含まれています。ファームウェアのバージョンとステータスを確認するには、物理ホストの HostFirmwareComponents リソースを取得する必要があります。

手順

  1. HostFirmwareComponents リソースの詳細なリストを取得します。 

    $ oc get hostfirmwarecomponents -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

  2. HostFirmwareComponents リソースのリストを取得します。 

    $ oc get hostfirmwarecomponents -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  3. 特定のホストの HostFirmwareComponents リソースを取得します。 

    $ oc get hostfirmwarecomponents <host_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    ここで、<host_name> はホストの名前です。

    出力例

    ---
apiVersion: metal3.io/v1alpha1
kind: HostFirmwareComponents
metadata:
  creationTimestamp: 2024-04-25T20:32:06Z"
  generation: 1
  name: ostest-master-2
  namespace: openshift-machine-api
  ownerReferences:
  - apiVersion: metal3.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: BareMetalHost
    name: ostest-master-2
    uid: 16022566-7850-4dc8-9e7d-f216211d4195
  resourceVersion: "2437"
  uid: 2038d63f-afc0-4413-8ffe-2f8e098d1f6c
spec:
  updates: []
status:
  components:
  - component: bios
    currentVersion: 1.0.0
    initialVersion: 1.0.0
  - component: bmc
    currentVersion: "1.00"
    initialVersion: "1.00"
  conditions:
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "True"
    type: Valid
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "False"
    type: ChangeDetected
  lastUpdated: "2024-04-25T20:32:06Z"
  updates: []
    Copy to Clipboard Toggle word wrap

3.17. HostFirmwareComponents リソースの編集
リンクのコピー

ノードの HostFirmwareComponents リソースを編集できます。

手順

  1. HostFirmwareComponents リソースの詳細なリストを取得します。 

    $ oc get hostfirmwarecomponents -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

  2. ホストの HostFirmwareComponents リソースを編集します。 

    $ oc edit <host_name> hostfirmwarecomponents -n openshift-machine-api
    1
    Copy to Clipboard Toggle word wrap
    1
    ここで、<host_name> はホストの名前です。HostFirmwareComponents リソースが、ターミナルのデフォルトのエディターで開きます。

    出力例

    ---
apiVersion: metal3.io/v1alpha1
kind: HostFirmwareComponents
metadata:
  creationTimestamp: 2024-04-25T20:32:06Z"
  generation: 1
  name: ostest-master-2
  namespace: openshift-machine-api
  ownerReferences:
  - apiVersion: metal3.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: BareMetalHost
    name: ostest-master-2
    uid: 16022566-7850-4dc8-9e7d-f216211d4195
  resourceVersion: "2437"
  uid: 2038d63f-afc0-4413-8ffe-2f8e098d1f6c
spec:
  updates:
    - name: bios
    1 
    
      url: https://myurl.with.firmware.for.bios
    2 
    
    - name: bmc
    3 
    
      url: https://myurl.with.firmware.for.bmc
    4 
    
status:
  components:
  - component: bios
    currentVersion: 1.0.0
    initialVersion: 1.0.0
  - component: bmc
    currentVersion: "1.00"
    initialVersion: "1.00"
  conditions:
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "True"
    type: Valid
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "False"
    type: ChangeDetected
  lastUpdated: "2024-04-25T20:32:06Z"
    Copy to Clipboard Toggle word wrap

    1
    BIOS のバージョンを設定するには、name 属性を bios に設定します。
    2
    BIOS のバージョンを設定するには、url 属性を BIOS のファームウェアバージョンの URL に設定します。
    3
    BMC のバージョンを設定するには、name 属性を bmc に設定します。
    4
    BMC のバージョンを設定するには、url 属性を BMC のファームウェアバージョンの URL に設定します。
  3. 変更を保存し、エディターを終了します。

  4. ホストのマシン名を取得します。 

    $ oc get bmh <host_name> -n openshift-machine name
    1
    Copy to Clipboard Toggle word wrap
    1
    ここで、<host_name> はホストの名前です。マシン名は CONSUMER フィールドの下に表示されます。

  5. マシンにアノテーションを付け、マシンセットから削除します。 

    $ oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api
    1
    Copy to Clipboard Toggle word wrap
    1
    ここで、<machine_name> は削除するマシンの名前です。

  6. ノードのリストを取得し、ワーカーノードの数をカウントします。 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

  7. マシンセットを取得します。 

    $ oc get machinesets -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

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

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1>
    1
    Copy to Clipboard Toggle word wrap
    1
    <machineset_name> はマシンセットの名前です。<n-1> は減少させたワーカーノードの数です。

  9. ホストが Available 状態になったら、マシンセットをスケールアップして、HostFirmwareComponents リソースの変更を有効にします。 

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n>
    1
    Copy to Clipboard Toggle word wrap
    1
    <machineset_name> はマシンセットの名前です。<n> はワーカーノードの数です。

第4章 OpenShift クラスターでのマルチアーキテクチャーのコンピュートマシンの設定
リンクのコピー

4.1. マルチアーキテクチャーのコンピュートマシンを含むクラスターについて
リンクのコピー

マルチアーキテクチャー計算マシンを使用する OpenShift Container Platform クラスターは、異なるアーキテクチャーのコンピュートマシンをサポートするクラスターです。

マルチアーキテクチャーコンピュートマシンの設定には、さらにいくつかの点を考慮する必要があります。

  • クラスター内に複数のアーキテクチャーを持つノードがある場合、ノードにデプロイするコンテナーイメージのアーキテクチャーは、そのノードのアーキテクチャーと一致している必要があります。Pod が適切なアーキテクチャーを持つノードに割り当てられていること、およびそれがコンテナーイメージのアーキテクチャーと一致していることを確認する必要があります。ノードへの Pod の割り当ての詳細は、ノードへの Pod の割り当て を参照してください。
  • インストーラーでプロビジョニングされるインストールでは、単一クラウドプロバイダーによって提供されるインフラストラクチャーの使用に制限されます。アーキテクチャーに関係なく、これらのクラスターに外部ノードを追加することはサポートされていません。

  • プラットフォームタイプ none でインストールされたクラスターは、Machine API を使用したコンピュートマシンの管理など、一部の機能を使用できません。この制限は、クラスターに接続されている計算マシンが、通常はこの機能をサポートするプラットフォームにインストールされている場合でも適用されます。このパラメーターは、インストール後に変更することはできません。

    重要

    仮想化またはクラウド環境で OpenShift Container Platform クラスターのインストールを試行する前に、guidelines for deploying OpenShift Container Platform on non-tested platforms にある情報を確認してください。

  • Cluster Samples Operator は、マルチアーキテクチャーのコンピュートマシンを含むクラスターではサポートされません。この機能がなくてもクラスターを作成できます。詳細は、クラスターの機能 を参照してください。
  • 単一アーキテクチャーのクラスターを、マルチアーキテクチャーのコンピュートマシンをサポートするクラスターに移行する方法は、マルチアーキテクチャーのコンピュートマシンを含むクラスターへの移行 を参照してください。

4.1.1. マルチアーキテクチャーのコンピュートマシンを使用したクラスターの設定
リンクのコピー

各種のインストールオプションとプラットフォームを使用してマルチアーキテクチャーコンピュートマシンを含むクラスターを作成するには、次の表のドキュメントを使用してください。

Expand
表4.1 マルチアーキテクチャーのコンピュートマシンを含むクラスターのインストールオプション
ドキュメントのセクションプラットフォームuser-provisioned installationinstaller-provisioned installationコントロールプレーンコンピュートノード

Azure 上でマルチアーキテクチャーのコンピュートマシンを含むクラスターを作成する

Microsoft Azure

✓

✓

aarch64 または x86_64

aarch64、x86_64

AWS 上でマルチアーキテクチャーのコンピュートマシンを含むクラスターを作成する

Amazon Web Services (AWS)

✓

✓

aarch64 または x86_64

aarch64、x86_64

Google Cloud 上でマルチアーキテクチャーのコンピュートマシンを含むクラスターを作成する

Google Cloud

 

✓

aarch64 または x86_64

aarch64、x86_64

ベアメタル、IBM Power、または IBM Z 上でマルチアーキテクチャーのコンピュートマシンを含むクラスターを作成する

ベアメタル

✓

 

aarch64 または x86_64

aarch64、x86_64

IBM Power

✓

 

x86_64 または ppc64le

x86_64、ppc64le

IBM Z

✓

 

x86_64 または s390x

x86_64、s390x

z/VM を使用した IBM Z® および IBM® LinuxONE 上でマルチアーキテクチャーのコンピュートマシンを含むクラスターを作成する

IBM Z® および IBM® LinuxONE

✓

 

x86_64

x86_64、s390x

RHEL KVM を使用した IBM Z® および IBM® LinuxONE 上でマルチアーキテクチャーのコンピュートマシンを含むクラスターを作成する

IBM Z® および IBM® LinuxONE

✓

 

x86_64

x86_64、s390x

IBM Power® 上でマルチアーキテクチャーのコンピュートマシンを含むクラスターを作成する

IBM Power®

✓

 

x86_64

x86_64、ppc64le

重要

現在、Google Cloud ではゼロからの自動スケーリングはサポートされていません。

4.2. Azure 上でマルチアーキテクチャーのコンピュートマシンを含むクラスターを作成する
リンクのコピー

マルチアーキテクチャーのコンピュートマシンを含む Azure クラスターをデプロイするには、まず、マルチアーキテクチャーインストーラーバイナリーを使用して、Azure インストーラーによってプロビジョニングされたシングルアーキテクチャーのクラスターを作成する必要があります。Azure へのインストールの詳細は、カスタマイズを使用した Azure へのクラスターのインストール を参照してください。

シングルアーキテクチャーのコンピュートマシンを含む現在のクラスターを、マルチアーキテクチャーのコンピュートマシンを含むクラスターに移行することもできます。詳細は、マルチアーキテクチャーのコンピュートマシンを備えたクラスターへの移行 を参照してください。

マルチアーキテクチャークラスターを作成した後、異なるアーキテクチャーのノードをクラスターに追加できます。

4.2.1. クラスターの互換性の確認
リンクのコピー

異なるアーキテクチャーのコンピュートノードをクラスターに追加する前に、クラスターがマルチアーキテクチャー互換であることを確認する必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. OpenShift CLI (oc) にログインします。

  2. 次のコマンドを実行すると、クラスターがアーキテクチャーペイロードを使用していることを確認できます。 

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"
    Copy to Clipboard Toggle word wrap

検証

  • 次の出力が表示された場合、クラスターはマルチアーキテクチャーペイロードを使用しています。 

    {
 "release.openshift.io/architecture": "multi",
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap

    その後、クラスターへのマルチアーキテクチャーコンピュートノードの追加を開始できます。

  • 次の出力が表示された場合、クラスターはマルチアーキテクチャーペイロードを使用していません。 

    {
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap
    重要

    クラスターを、マルチアーキテクチャーコンピュートマシンをサポートするクラスターに移行するには、マルチアーキテクチャーコンピュートマシンを含むクラスターへの移行 の手順に従ってください。

4.2.2. Azure イメージギャラリーを使用して 64 ビット ARM ブートイメージを作成する
リンクのコピー

次の手順では、64 ビット ARM ブートイメージを手動で生成する方法を説明します。

前提条件

  • Azure CLI (az) をインストールしている。
  • マルチアーキテクチャーインストーラーバイナリーを使用して、単一アーキテクチャーの Azure インストーラープロビジョニングクラスターを作成している。

手順

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

    $ az login
    Copy to Clipboard Toggle word wrap

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

    $ az storage account create -n ${STORAGE_ACCOUNT_NAME} -g ${RESOURCE_GROUP} -l westus --sku Standard_LRS
    1
    Copy to Clipboard Toggle word wrap
    1
    westus オブジェクトはリージョンの例です。

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

    $ az storage container create -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME}
    Copy to Clipboard Toggle word wrap

  4. URL と aarch64 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')
      Copy to Clipboard Toggle word wrap

    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
      Copy to Clipboard Toggle word wrap

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

    $ end=`date -u -d "30 minutes" '+%Y-%m-%dT%H:%MZ'`
    Copy to Clipboard Toggle word wrap 
    $ sas=`az storage container generate-sas -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME} --https-only --permissions dlrw --expiry $end -o tsv`
    Copy to Clipboard Toggle word wrap

  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}
    Copy to Clipboard Toggle word wrap

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

    $ az storage blob show -c ${CONTAINER_NAME} -n ${BLOB_NAME} --account-name ${STORAGE_ACCOUNT_NAME} | jq .properties.copy
    Copy to Clipboard Toggle word wrap

    出力例

    {
 "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
}
    Copy to Clipboard Toggle word wrap

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

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

    $ az sig create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME}
    Copy to Clipboard Toggle word wrap

    イメージギャラリーを使用してイメージ定義を作成します。次のコマンド例では、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
    Copy to Clipboard Toggle word wrap

  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)
    Copy to Clipboard Toggle word wrap

  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}
    Copy to Clipboard Toggle word wrap

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

    $ az sig image-version show -r $GALLERY_NAME -g $RESOURCE_GROUP -i rhcos-arm64 -e 1.0.0
    Copy to Clipboard Toggle word wrap

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

    resourceID の例

    /resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Compute/galleries/${GALLERY_NAME}/images/rhcos-arm64/versions/1.0.0
    Copy to Clipboard Toggle word wrap

4.2.3. Azure イメージギャラリーを使用して 64 ビット x86 ブートイメージを作成する
リンクのコピー

次の手順では、64 ビット x86 ブートイメージを手動で生成する方法を説明します。

前提条件

  • Azure CLI (az) をインストールしている。
  • マルチアーキテクチャーインストーラーバイナリーを使用して、単一アーキテクチャーの Azure インストーラープロビジョニングクラスターを作成している。

手順

  1. 次のコマンドを実行して、Azure アカウントにログインします。 

    $ az login
    Copy to Clipboard Toggle word wrap

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

    $ az storage account create -n ${STORAGE_ACCOUNT_NAME} -g ${RESOURCE_GROUP} -l westus --sku Standard_LRS
    1
    Copy to Clipboard Toggle word wrap
    1
    westus オブジェクトはリージョンの例です。

  3. 次のコマンドを実行して、生成したストレージアカウントを使用してストレージコンテナーを作成します。 

    $ az storage container create -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME}
    Copy to Clipboard Toggle word wrap

  4. OpenShift Container Platform インストールプログラムの JSON ファイルを使用して、URL と x86_64 VHD 名を抽出します。

    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.x86_64."rhel-coreos-extensions"."azure-disk".url')
      Copy to Clipboard Toggle word wrap

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

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

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

    $ end=`date -u -d "30 minutes" '+%Y-%m-%dT%H:%MZ'`
    Copy to Clipboard Toggle word wrap 
    $ sas=`az storage container generate-sas -n ${CONTAINER_NAME} --account-name ${STORAGE_ACCOUNT_NAME} --https-only --permissions dlrw --expiry $end -o tsv`
    Copy to Clipboard Toggle word wrap

  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}
    Copy to Clipboard Toggle word wrap

    次のコマンドを実行すると、コピープロセスのステータスを確認できます。 

    $ az storage blob show -c ${CONTAINER_NAME} -n ${BLOB_NAME} --account-name ${STORAGE_ACCOUNT_NAME} | jq .properties.copy
    Copy to Clipboard Toggle word wrap

    出力例

    {
 "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
}
    Copy to Clipboard Toggle word wrap

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

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

    $ az sig create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME}
    Copy to Clipboard Toggle word wrap

  8. 次のコマンドを実行して、イメージギャラリーを使用してイメージ定義を作成します。 

    $ az sig image-definition create --resource-group ${RESOURCE_GROUP} --gallery-name ${GALLERY_NAME} --gallery-image-definition rhcos-x86_64 --publisher RedHat --offer x86_64 --sku x86_64 --os-type linux --architecture x64 --hyper-v-generation V2
    Copy to Clipboard Toggle word wrap

    このコマンド例の rhcos-x86_64 は、イメージ定義の名前です。

  9. 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)
    Copy to Clipboard Toggle word wrap

  10. 次のコマンドを実行して、RHCOS_VHD_URL ファイル、ストレージアカウント、リソースグループ、イメージギャラリーを使用してイメージバージョンを作成します。 

    $ 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}
    Copy to Clipboard Toggle word wrap

    この例では、1.0.0 がイメージバージョンです。

  11. オプション: 次のコマンドを実行して、生成された x86_64 ブートイメージの ID にアクセスします。 

    $ az sig image-version show -r $GALLERY_NAME -g $RESOURCE_GROUP -i rhcos-x86_64 -e 1.0.0
    Copy to Clipboard Toggle word wrap

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

    resourceID の例

    /resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Compute/galleries/${GALLERY_NAME}/images/rhcos-x86_64/versions/1.0.0
    Copy to Clipboard Toggle word wrap

4.2.4. Azure クラスターにマルチアーキテクチャーコンピュートマシンセットを追加する
リンクのコピー

マルチアーキテクチャークラスターを作成した後、異なるアーキテクチャーのノードを追加できます。

マルチアーキテクチャーコンピュートマシンをマルチアーキテクチャークラスターに追加する方法には、次のものがあります。

  • 64 ビット ARM コントロールプレーンマシンを使用し、すでに 64 ビット ARM コンピュートマシンが含まれているクラスターに 64 ビット x86 コンピュートマシンを追加します。この場合、64 ビット x86 がセカンダリーアーキテクチャーと見なされます。
  • 64 ビット x86 コントロールプレーンマシンを使用し、すでに 64 ビット x86 コンピュートマシンが含まれているクラスターに 64 ビット ARM コンピュートマシンを追加します。この場合、64 ビット ARM がセカンダリーアーキテクチャーと見なされます。

Azure でカスタムコンピュートマシンセットを作成するには、「Azure でのコンピュートマシンセットの作成」を参照してください。

注記

セカンダリーアーキテクチャーノードをクラスターに追加する前に、Multiarch Tuning Operator をインストールし、ClusterPodPlacementConfig カスタムリソースをデプロイすることを推奨します。詳細は、「Multiarch Tuning Operator を使用してマルチアーキテクチャークラスター上のワークロードを管理する」を参照してください。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • 64 ビット ARM または 64 ビット x86 ブートイメージを作成した。
  • インストールプログラムを使用し、マルチアーキテクチャーインストーラーバイナリーを使用して、64 ビット ARM または 64 ビット x86 から成るシングルアーキテクチャーの Azure クラスターを作成した。

手順

  1. OpenShift CLI (oc) にログインします。

  2. YAML ファイルを作成し、設定を追加して、クラスター内の 64 ビット ARM または 64 ビット x86 コンピュートノードを制御するコンピュートマシンセットを作成します。

    Azure の 64 ビット ARM または 64 ビット x86 コンピュートノードの MachineSet オブジェクトの例

    apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
    machine.openshift.io/cluster-api-machine-role: worker
    machine.openshift.io/cluster-api-machine-type: worker
  name: <infrastructure_id>-machine-set-0
  namespace: openshift-machine-api
spec:
  replicas: 2
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-machine-set-0
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-machine-set-0
    spec:
      lifecycleHooks: {}
      metadata: {}
      providerSpec:
        value:
          acceleratedNetworking: true
          apiVersion: machine.openshift.io/v1beta1
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          image:
            offer: ""
            publisher: ""
            resourceID: /resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Compute/galleries/${GALLERY_NAME}/images/rhcos-arm64/versions/1.0.0
    1 
    
            sku: ""
            version: ""
          kind: AzureMachineProviderSpec
          location: <region>
          managedIdentity: <infrastructure_id>-identity
          networkResourceGroup: <infrastructure_id>-rg
          osDisk:
            diskSettings: {}
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
            osType: Linux
          publicIP: false
          publicLoadBalancer: <infrastructure_id>
          resourceGroup: <infrastructure_id>-rg
          subnet: <infrastructure_id>-worker-subnet
          userDataSecret:
            name: worker-user-data
          vmSize: Standard_D4ps_v5
    2 
    
          vnet: <infrastructure_id>-vnet
          zone: "<zone>"
    Copy to Clipboard Toggle word wrap

    1
    resourceID パラメーターを arm64 または amd64 ブートイメージに設定します。
    2
    vmSize パラメーターを、インストールで使用されているインスタンスタイプに設定します。インスタンスタイプの例として、Standard_D4ps_v5 または D8ps があります。

  3. 次のコマンドを実行してコンピュートマシンセットを作成します。 

    $ oc create -f <file_name>
    1
    Copy to Clipboard Toggle word wrap
    1
    <file_name> は、コンピュートマシン設定を含む YAML ファイルの名前に置き換えます。たとえば、arm64-machine-set-0.yaml、または amd64-machine-set-0.yaml です。

検証

  1. 次のコマンドを実行して、新しいマシンが実行中であることを確認します。 

    $ oc get machineset -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    出力に、作成したマシンセットが含まれている必要があります。

    出力例

    NAME                                                DESIRED  CURRENT  READY  AVAILABLE  AGE
<infrastructure_id>-machine-set-0                   2        2      2          2  10m
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行すると、ノードが準備完了状態でスケジュール可能かどうかを確認できます。 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

4.3. AWS 上でマルチアーキテクチャーのコンピュートマシンを含むクラスターを作成する
リンクのコピー

マルチアーキテクチャーのコンピュートマシンを含む AWS クラスターを作成するには、まず、マルチアーキテクチャーインストーラーバイナリーを使用して、AWS インストーラーによってプロビジョニングされたシングルアーキテクチャーのクラスターを作成する必要があります。AWS へのインストールの詳細は、カスタマイズを使用した AWS へのクラスターのインストール を参照してください。

シングルアーキテクチャーのコンピュートマシンを含む現在のクラスターを、マルチアーキテクチャーのコンピュートマシンを含むクラスターに移行することもできます。詳細は、マルチアーキテクチャーのコンピュートマシンを備えたクラスターへの移行 を参照してください。

マルチアーキテクチャークラスターを作成した後、異なるアーキテクチャーのノードをクラスターに追加できます。

4.3.1. クラスターの互換性の確認
リンクのコピー

異なるアーキテクチャーのコンピュートノードをクラスターに追加する前に、クラスターがマルチアーキテクチャー互換であることを確認する必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. OpenShift CLI (oc) にログインします。

  2. 次のコマンドを実行すると、クラスターがアーキテクチャーペイロードを使用していることを確認できます。 

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"
    Copy to Clipboard Toggle word wrap

検証

  • 次の出力が表示された場合、クラスターはマルチアーキテクチャーペイロードを使用しています。 

    {
 "release.openshift.io/architecture": "multi",
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap

    その後、クラスターへのマルチアーキテクチャーコンピュートノードの追加を開始できます。

  • 次の出力が表示された場合、クラスターはマルチアーキテクチャーペイロードを使用していません。 

    {
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap
    重要

    クラスターを、マルチアーキテクチャーコンピュートマシンをサポートするクラスターに移行するには、マルチアーキテクチャーコンピュートマシンを含むクラスターへの移行 の手順に従ってください。

4.3.2. AWS クラスターにマルチアーキテクチャーコンピュートマシンセットを追加する
リンクのコピー

マルチアーキテクチャークラスターを作成した後、異なるアーキテクチャーのノードを追加できます。

マルチアーキテクチャーコンピュートマシンをマルチアーキテクチャークラスターに追加する方法には、次のものがあります。

  • 64 ビット ARM コントロールプレーンマシンを使用し、すでに 64 ビット ARM コンピュートマシンが含まれているクラスターに 64 ビット x86 コンピュートマシンを追加します。この場合、64 ビット x86 がセカンダリーアーキテクチャーと見なされます。
  • 64 ビット x86 コントロールプレーンマシンを使用し、すでに 64 ビット x86 コンピュートマシンが含まれているクラスターに 64 ビット ARM コンピュートマシンを追加します。この場合、64 ビット ARM がセカンダリーアーキテクチャーと見なされます。
注記

セカンダリーアーキテクチャーノードをクラスターに追加する前に、Multiarch Tuning Operator をインストールし、ClusterPodPlacementConfig カスタムリソースをデプロイすることを推奨します。詳細は、「Multiarch Tuning Operator を使用してマルチアーキテクチャークラスター上のワークロードを管理する」を参照してください。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • インストールプログラムを使用し、マルチアーキテクチャーインストーラーバイナリーを使用して、64 ビット ARM または 64 ビット x86 から成るシングルアーキテクチャーの AWS クラスターを作成した。

手順

  1. OpenShift CLI (oc) にログインします。

  2. YAML ファイルを作成し、設定を追加して、クラスター内の 64 ビット ARM または 64 ビット x86 コンピュートノードを制御するコンピュートマシンセットを作成します。

    AWS の 64 ビット ARM または x86 コンピュートノードの MachineSet オブジェクトの例

    apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
    1 
    
  name: <infrastructure_id>-aws-machine-set-0
    2 
    
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
    3 
    
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<zone>
    4 
    
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
    5 
    
        machine.openshift.io/cluster-api-machine-type: <role>
    6 
    
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<zone>
    7 
    
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/<role>: ""
      providerSpec:
        value:
          ami:
            id: ami-02a574449d4f4d280
    8 
    
          apiVersion: awsproviderconfig.openshift.io/v1beta1
          blockDevices:
            - ebs:
                iops: 0
                volumeSize: 120
                volumeType: gp2
          credentialsSecret:
            name: aws-cloud-credentials
          deviceIndex: 0
          iamInstanceProfile:
            id: <infrastructure_id>-worker-profile
    9 
    
          instanceType: m6g.xlarge
    10 
    
          kind: AWSMachineProviderConfig
          placement:
            availabilityZone: us-east-1a
    11 
    
            region: <region>
    12 
    
          securityGroups:
            - filters:
                - name: tag:Name
                  values:
                    - <infrastructure_id>-node
    13 
    
          subnet:
            filters:
              - name: tag:Name
                values:
                  - <infrastructure_id>-subnet-private-<zone>
          tags:
            - name: kubernetes.io/cluster/<infrastructure_id>
    14 
    
              value: owned
            - name: <custom_tag_name>
              value: <custom_tag_value>
          userDataSecret:
            name: worker-user-data
    Copy to Clipboard Toggle word wrap

    1 2 3 9 13 14
    クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。OpenShift CLI (oc) がインストールされている場合は、以下のコマンドを実行してインフラストラクチャー ID を取得できます。 
    $ oc get -o jsonpath="{.status.infrastructureName}{'\n'}" infrastructure cluster
    Copy to Clipboard Toggle word wrap
    4 7
    インフラストラクチャー ID、ロールノードラベル、およびゾーンを指定します。
    5 6
    追加するロールノードラベルを指定します。
    8
    ノードの AWS リージョンに Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI) を指定します。RHCOS AMI はマシンのアーキテクチャーと互換性がある必要があります。 
    $ oc get configmap/coreos-bootimages \
	  -n openshift-machine-config-operator \
	  -o jsonpath='{.data.stream}' | jq \
	  -r '.architectures.<arch>.images.aws.regions."<region>".image'
    Copy to Clipboard Toggle word wrap
    10
    選択した AMI の CPU アーキテクチャーに合ったマシンタイプを指定します。詳細は、「AWS 64 ビット ARM のテスト済みインスタンスタイプ」を参照してください。
    11
    ゾーンを指定します。たとえば、us-east-1a です。選択したゾーンに必要なアーキテクチャーを備えたマシンがあることを確認してください。
    12
    リージョンを指定します。たとえば、us-east-1 などです。選択したゾーンに必要なアーキテクチャーを備えたマシンがあることを確認してください。

  3. 次のコマンドを実行してコンピュートマシンセットを作成します。 

    $ oc create -f <file_name>
    1
    Copy to Clipboard Toggle word wrap
    1
    <file_name> は、コンピュートマシン設定を含む YAML ファイルの名前に置き換えます。たとえば、aws-arm64-machine-set-0.yaml、または aws-amd64-machine-set-0.yaml です。

検証

  1. 次のコマンドを実行して、コンピュートマシンセットのリストを表示します。 

    $ oc get machineset -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    出力に、作成したマシンセットが含まれている必要があります。

    出力例

    NAME                                                DESIRED  CURRENT  READY  AVAILABLE  AGE
<infrastructure_id>-aws-machine-set-0                   2        2      2          2  10m
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行すると、ノードが準備完了状態でスケジュール可能かどうかを確認できます。 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

マルチアーキテクチャーのコンピュートマシンを含む Google Cloud クラスターを作成するには、まず、マルチアーキテクチャーインストーラーバイナリーを使用して、Google Cloud インストーラーによってプロビジョニングされたシングルアーキテクチャーのクラスターを作成する必要があります。AWS へのインストールの詳細は、カスタマイズを使用した GCP へのクラスターのインストール を参照してください。

シングルアーキテクチャーのコンピュートマシンを含む現在のクラスターを、マルチアーキテクチャーのコンピュートマシンを含むクラスターに移行することもできます。詳細は、マルチアーキテクチャーのコンピュートマシンを備えたクラスターへの移行 を参照してください。

マルチアーキテクチャークラスターを作成した後、異なるアーキテクチャーのノードをクラスターに追加できます。

注記

Google Cloud の 64 ビット ARM マシンでは、セキュアブートは現在サポートされていません。

4.4.1. クラスターの互換性の確認
リンクのコピー

異なるアーキテクチャーのコンピュートノードをクラスターに追加する前に、クラスターがマルチアーキテクチャー互換であることを確認する必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. OpenShift CLI (oc) にログインします。

  2. 次のコマンドを実行すると、クラスターがアーキテクチャーペイロードを使用していることを確認できます。 

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"
    Copy to Clipboard Toggle word wrap

検証

  • 次の出力が表示された場合、クラスターはマルチアーキテクチャーペイロードを使用しています。 

    {
 "release.openshift.io/architecture": "multi",
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap

    その後、クラスターへのマルチアーキテクチャーコンピュートノードの追加を開始できます。

  • 次の出力が表示された場合、クラスターはマルチアーキテクチャーペイロードを使用していません。 

    {
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap
    重要

    クラスターを、マルチアーキテクチャーコンピュートマシンをサポートするクラスターに移行するには、マルチアーキテクチャーコンピュートマシンを含むクラスターへの移行 の手順に従ってください。

4.4.2. Google Cloud クラスターにマルチアーキテクチャーコンピュートマシンセットを追加する
リンクのコピー

マルチアーキテクチャークラスターを作成した後、異なるアーキテクチャーのノードを追加できます。

マルチアーキテクチャーコンピュートマシンをマルチアーキテクチャークラスターに追加する方法には、次のものがあります。

  • 64 ビット ARM コントロールプレーンマシンを使用し、すでに 64 ビット ARM コンピュートマシンが含まれているクラスターに 64 ビット x86 コンピュートマシンを追加します。この場合、64 ビット x86 がセカンダリーアーキテクチャーと見なされます。
  • 64 ビット x86 コントロールプレーンマシンを使用し、すでに 64 ビット x86 コンピュートマシンが含まれているクラスターに 64 ビット ARM コンピュートマシンを追加します。この場合、64 ビット ARM がセカンダリーアーキテクチャーと見なされます。
注記

セカンダリーアーキテクチャーノードをクラスターに追加する前に、Multiarch Tuning Operator をインストールし、ClusterPodPlacementConfig カスタムリソースをデプロイすることを推奨します。詳細は、「Multiarch Tuning Operator を使用してマルチアーキテクチャークラスター上のワークロードを管理する」を参照してください。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • インストールプログラムを使用し、マルチアーキテクチャーインストーラーバイナリーを使用して、64 ビット x86 または 64 ビット ARM から成るシングルアーキテクチャーの Google Cloud クラスターを作成した。

手順

  1. OpenShift CLI (oc) にログインします。

  2. YAML ファイルを作成し、設定を追加して、クラスター内の 64 ビット ARM または 64 ビット x86 コンピュートノードを制御するコンピュートマシンセットを作成します。

    Google Cloud の 64 ビット ARM または 64 ビット x86 コンピュートノードの MachineSet オブジェクトの例

    apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
    1 
    
  name: <infrastructure_id>-w-a
  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>-w-a
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
    2 
    
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-w-a
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/<role>: ""
      providerSpec:
        value:
          apiVersion: gcpprovider.openshift.io/v1beta1
          canIPForward: false
          credentialsSecret:
            name: gcp-cloud-credentials
          deletionProtection: false
          disks:
          - autoDelete: true
            boot: true
            image: <path_to_image>
    3 
    
            labels: null
            sizeGb: 128
            type: pd-ssd
          gcpMetadata:
    4 
    
          - key: <custom_metadata_key>
            value: <custom_metadata_value>
          kind: GCPMachineProviderSpec
          machineType: n1-standard-4
    5 
    
          metadata:
            creationTimestamp: null
          networkInterfaces:
          - network: <infrastructure_id>-network
            subnetwork: <infrastructure_id>-worker-subnet
          projectID: <project_name>
    6 
    
          region: us-central1
    7 
    
          serviceAccounts:
          - email: <infrastructure_id>-w@<project_name>.iam.gserviceaccount.com
            scopes:
            - https://www.googleapis.com/auth/cloud-platform
          tags:
            - <infrastructure_id>-worker
          userDataSecret:
            name: worker-user-data
          zone: us-central1-a
    Copy to Clipboard Toggle word wrap

    1
    クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。以下のコマンドを実行してインフラストラクチャー ID を取得できます。 
    $ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
    Copy to Clipboard Toggle word wrap
    2
    追加するロールノードラベルを指定します。
    3
    現在のコンピュートマシンセットで使用されるイメージへのパスを指定します。イメージへのパスにはプロジェクトとイメージ名が必要です。

    プロジェクトとイメージ名にアクセスするには、次のコマンドを実行します。 

    $ oc get configmap/coreos-bootimages \
  -n openshift-machine-config-operator \
  -o jsonpath='{.data.stream}' | jq \
  -r '.architectures.aarch64.images.gcp'
    Copy to Clipboard Toggle word wrap

    出力例

      "gcp": {
    "release": "415.92.202309142014-0",
    "project": "rhcos-cloud",
    "name": "rhcos-415-92-202309142014-0-gcp-aarch64"
  }
    Copy to Clipboard Toggle word wrap

    出力の project パラメーターと name パラメーターを使用して、マシンセット内のイメージフィールドへのパスを作成します。イメージへのパスは次の形式に従う必要があります。 

    $ projects/<project>/global/images/<image_name>
    Copy to Clipboard Toggle word wrap
    4
    オプション: key:value のペアの形式でカスタムメタデータを指定します。ユースケースの例は、カスタムメタデータの設定 に関する Google Cloud のドキュメントを参照してください。
    5
    選択した OS イメージの CPU アーキテクチャーに合ったマシンタイプを指定します。詳細は、「64 ビット ARM インフラストラクチャー上の Google Cloud のテスト済みのインスタンスタイプ」を参照してください。
    6
    クラスターに使用する Google Cloud プロジェクトの名前を指定します。
    7
    リージョンを指定します。たとえば、us-central1 です。選択したゾーンに必要なアーキテクチャーを備えたマシンがあることを確認してください。

  3. 次のコマンドを実行してコンピュートマシンセットを作成します。 

    $ oc create -f <file_name>
    1
    Copy to Clipboard Toggle word wrap
    1
    <file_name> は、コンピュートマシン設定を含む YAML ファイルの名前に置き換えます。たとえば、gcp-arm64-machine-set-0.yaml、または gcp-amd64-machine-set-0.yaml です。

検証

  1. 次のコマンドを実行して、コンピュートマシンセットのリストを表示します。 

    $ oc get machineset -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    出力に、作成したマシンセットが含まれている必要があります。

    出力例

    NAME                                                DESIRED  CURRENT  READY  AVAILABLE  AGE
<infrastructure_id>-gcp-machine-set-0                   2        2      2          2  10m
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行すると、ノードが準備完了状態でスケジュール可能かどうかを確認できます。 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

関連情報

ベアメタル (x86_64 または aarch64)、IBM Power® (ppc64le)、または IBM Z® (s390x) 上にマルチアーキテクチャーコンピュートマシンを含むクラスターを作成するには、そのプラットフォームに既存のシングルアーキテクチャークラスターが必要です。ご使用のプラットフォームのインストール手順に従ってください。

重要

ベアメタルの installer-provisioned infrastructure および Bare Metal Operator は、クラスターの初期セットアップ中にセカンダリーアーキテクチャーノードを追加することをサポートしていません。セカンダリーアーキテクチャーノードは、初期クラスターのセットアップ後にのみ手動で追加できます。

クラスターに追加のコンピュートノードを追加する前に、クラスターをマルチアーキテクチャーペイロードを使用するクラスターにアップグレードする必要があります。マルチアーキテクチャーペイロードへの移行の詳細は、マルチアーキテクチャーコンピュートマシンを使用したクラスターへの移行 を参照してください。

次の手順では、ISO イメージまたはネットワーク PXE ブートを使用して RHCOS コンピュートマシンを作成する方法を説明します。これにより、クラスターにノードを追加し、マルチアーキテクチャーコンピュートマシンを含むクラスターをデプロイできるようになります。

注記

セカンダリーアーキテクチャーノードをクラスターに追加する前に、Multiarch Tuning Operator をインストールし、ClusterPodPlacementConfig オブジェクトをデプロイすることを推奨します。詳細は、Multiarch Tuning Operator を使用してマルチアーキテクチャークラスター上のワークロードを管理する を参照してください。

4.5.1. クラスターの互換性の確認
リンクのコピー

異なるアーキテクチャーのコンピュートノードをクラスターに追加する前に、クラスターがマルチアーキテクチャー互換であることを確認する必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. OpenShift CLI (oc) にログインします。

  2. 次のコマンドを実行すると、クラスターがアーキテクチャーペイロードを使用していることを確認できます。 

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"
    Copy to Clipboard Toggle word wrap

検証

  • 次の出力が表示された場合、クラスターはマルチアーキテクチャーペイロードを使用しています。 

    {
 "release.openshift.io/architecture": "multi",
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap

    その後、クラスターへのマルチアーキテクチャーコンピュートノードの追加を開始できます。

  • 次の出力が表示された場合、クラスターはマルチアーキテクチャーペイロードを使用していません。 

    {
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap
    重要

    クラスターを、マルチアーキテクチャーコンピュートマシンをサポートするクラスターに移行するには、マルチアーキテクチャーコンピュートマシンを含むクラスターへの移行 の手順に従ってください。

4.5.2. ISO イメージを使用した RHCOS マシンの作成
リンクのコピー

ISO イメージを使用して、ベアメタルクラスターの追加の Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートマシンを作成できます。

前提条件

  • クラスターのコンピュートマシンの Ignition 設定ファイルの URL を取得します。このファイルがインストール時に HTTP サーバーにアップロードされている必要があります。
  • OpenShift CLI (oc) がインストールされている。

手順

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

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
    Copy to Clipboard Toggle word wrap
  2. クラスターからエクスポートした worker.ign Ignition 設定ファイルを HTTP サーバーにアップロードします。これらのファイルの URL をメモします。

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

    $ curl -k http://<HTTP_server>/worker.ign
    Copy to Clipboard Toggle word wrap

  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')
    Copy to Clipboard Toggle word wrap

  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>
    1
    2
    Copy to Clipboard Toggle word wrap
    1
    core ユーザーにはインストールを実行するために必要な 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/worker.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b
    Copy to Clipboard Toggle word wrap

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

    重要

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

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

4.5.3. PXE または iPXE ブートによる RHCOS マシンの作成
リンクのコピー

PXE または iPXE ブートを使用して、ベアメタルクラスターの追加の Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートマシンを作成できます。

前提条件

  • クラスターのコンピュートマシンの Ignition 設定ファイルの URL を取得します。このファイルがインストール時に HTTP サーバーにアップロードされている必要があります。
  • クラスターのインストール時に HTTP サーバーにアップロードした RHCOS ISO イメージ、圧縮されたメタル BIOS、kernel、および initramfs ファイルの URL を取得します。
  • インストール時に OpenShift Container Platform クラスターのマシンを作成するために使用した PXE ブートインフラストラクチャーにアクセスできる必要があります。RHCOS のインストール後にマシンはローカルディスクから起動する必要があります。
  • UEFI を使用する場合、OpenShift Container Platform のインストール時に変更した grub.conf ファイルにアクセスできます。

手順

  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
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      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 
      
}
      Copy to Clipboard Toggle word wrap
      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 インフラストラクチャーを使用して、クラスターに必要なコンピュートマシンを作成します。

4.5.4. マシンの証明書署名要求の承認
リンクのコピー

マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。

前提条件

  • マシンがクラスターに追加されています。

手順

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.29.4
master-1  Ready     master  63m  v1.29.4
master-2  Ready     master  64m  v1.29.4
    Copy to Clipboard Toggle word wrap

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

    注記

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    出力例

    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
...
    Copy to Clipboard Toggle word wrap

    この例では、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 サービスアカウントによって提出されていることを確認し、ノードの ID を確認します。

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

      $ oc adm certificate approve <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      注記

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    出力例

    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
...
    Copy to Clipboard Toggle word wrap

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

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

      $ oc adm certificate approve <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.29.4
master-1  Ready     master  73m  v1.29.4
master-2  Ready     master  74m  v1.29.4
worker-0  Ready     worker  11m  v1.29.4
worker-1  Ready     worker  11m  v1.29.4
    Copy to Clipboard Toggle word wrap

    注記

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

関連情報

z/VM を使用して IBM Z® および IBM® LinuxONE (s390x) 上にマルチアーキテクチャーのコンピュートマシンを含むクラスターを作成するには、既存の単一アーキテクチャーの x86_64 クラスターが必要です。その後、s390x コンピュートマシンを OpenShift Container Platform クラスターに追加できます。

s390x ノードをクラスターに追加する前に、クラスターをマルチアーキテクチャーペイロードを使用するクラスターにアップグレードする必要があります。マルチアーキテクチャーペイロードへの移行の詳細は、マルチアーキテクチャーコンピュートマシンを使用したクラスターへの移行 を参照してください。

次の手順では、z/VM インスタンスを使用して RHCOS コンピュートマシンを作成する方法を説明します。これにより、s390x ノードをクラスターに追加し、マルチアーキテクチャーのコンピュートマシンを含むクラスターをデプロイメントできるようになります。

x86_64 上でマルチアーキテクチャーコンピュートマシンを含む IBM Z® または IBM® LinuxONE (s390x) クラスターを作成するには、IBM Z® および IBM® LinuxONE へのクラスターのインストール の手順に従ってください。その後、ベアメタル、IBM Power、または IBM Z 上でマルチアーキテクチャーコンピュートマシンを含むクラスターを作成する の説明に従って、x86_64 コンピュートマシンを追加できます。

注記

セカンダリーアーキテクチャーノードをクラスターに追加する前に、Multiarch Tuning Operator をインストールし、ClusterPodPlacementConfig オブジェクトをデプロイすることを推奨します。詳細は、Multiarch Tuning Operator を使用してマルチアーキテクチャークラスター上のワークロードを管理する を参照してください。

4.6.1. クラスターの互換性の確認
リンクのコピー

異なるアーキテクチャーのコンピュートノードをクラスターに追加する前に、クラスターがマルチアーキテクチャー互換であることを確認する必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. OpenShift CLI (oc) にログインします。

  2. 次のコマンドを実行すると、クラスターがアーキテクチャーペイロードを使用していることを確認できます。 

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"
    Copy to Clipboard Toggle word wrap

検証

  • 次の出力が表示された場合、クラスターはマルチアーキテクチャーペイロードを使用しています。 

    {
 "release.openshift.io/architecture": "multi",
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap

    その後、クラスターへのマルチアーキテクチャーコンピュートノードの追加を開始できます。

  • 次の出力が表示された場合、クラスターはマルチアーキテクチャーペイロードを使用していません。 

    {
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap
    重要

    クラスターを、マルチアーキテクチャーコンピュートマシンをサポートするクラスターに移行するには、マルチアーキテクチャーコンピュートマシンを含むクラスターへの移行 の手順に従ってください。

4.6.2. z/VM を使用した IBM Z 上での RHCOS マシンの作成
リンクのコピー

z/VM を使用した IBM Z® 上で実行される Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートマシンをさらに作成し、既存のクラスターに割り当てることができます。

前提条件

  • ノードのホスト名および逆引き参照を実行できるドメインネームサーバー (DNS) がある。
  • 作成するマシンがアクセスできるプロビジョニングマシンで稼働している HTTP または HTTPS サーバーがある。

手順

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

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
    Copy to Clipboard Toggle word wrap
  2. クラスターからエクスポートした worker.ign Ignition 設定ファイルを HTTP サーバーにアップロードします。このファイルの URL をメモします。

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

    $ curl -k http://<http_server>/worker.ign
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、RHEL ライブ kernel、initramfs、および rootfs ファイルをダウンロードします。 

    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
| jq -r '.architectures.s390x.artifacts.metal.formats.pxe.kernel.location')
    Copy to Clipboard Toggle word wrap 
    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
| jq -r '.architectures.s390x.artifacts.metal.formats.pxe.initramfs.location')
    Copy to Clipboard Toggle word wrap 
    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
| jq -r '.architectures.s390x.artifacts.metal.formats.pxe.rootfs.location')
    Copy to Clipboard Toggle word wrap
  5. ダウンロードした RHEL ライブ kernel、initramfs、および rootfs ファイルを、追加する RHCOS ゲストからアクセス可能な HTTP または HTTPS サーバーに移動します。

  6. ゲストのパラメーターファイルを作成します。次のパラメーターは仮想マシンに固有です。

    • オプション: 静的 IP アドレスを指定するには、次のエントリーをコロンで区切って ip= パラメーターを追加します。

      1. マシンの IP アドレス。
      2. 空の文字列。
      3. ゲートウェイ。
      4. ネットマスク。
      5. hostname.domainname 形式のマシンホストおよびドメイン名。この値を省略すると、RHCOS が逆引き DNS ルックアップによりホスト名を取得します。
      6. ネットワークインターフェイス名。この値を省略すると、RHCOS が利用可能なすべてのインターフェイスに IP 設定を適用します。
      7. 値 none。
    • coreos.inst.ignition_url= には、worker.ign ファイルへの URL を指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。
    • coreos.live.rootfs_url= の場合、起動している kernel および initramfs の一致する rootfs アーティファクトを指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。

    • DASD タイプのディスクへのインストールには、以下のタスクを実行します。

      1. coreos.inst.install_dev= には、/dev/dasda を指定します。
      2. rd.dasd= を使用して、RHCOS がインストールされる DASD を指定します。

      3. 必要に応じてさらにパラメーターを調整できます。

        以下はパラメーターファイルの例、additional-worker-dasd.parm です。 

        cio_ignore=all,!condev rd.neednet=1 \
console=ttysclp0 \
coreos.inst.install_dev=/dev/dasda \
coreos.inst.ignition_url=http://<http_server>/worker.ign \
coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
rd.dasd=0.0.3490 \
zfcp.allow_lun_scan=0
        Copy to Clipboard Toggle word wrap

        パラメーターファイルのすべてのオプションを 1 行で記述し、改行文字がないことを確認します。

    • FCP タイプのディスクへのインストールには、以下のタスクを実行します。

      1. rd.zfcp=<adapter>,<wwpn>,<lun> を使用して RHCOS がインストールされる FCP ディスクを指定します。マルチパスの場合、それぞれの追加のステップについてこのステップを繰り返します。

        注記

        複数のパスを使用してインストールする場合は、問題が発生する可能性があるため、後でではなくインストールの直後にマルチパスを有効にする必要があります。

      2. インストールデバイスを coreos.inst.install_dev=/dev/sda として設定します。

        注記

        追加の LUN が NPIV で設定される場合は、FCP に zfcp.allow_lun_scan=0 が必要です。CSI ドライバーを使用するために zfcp.allow_lun_scan=1 を有効にする必要がある場合などには、各ノードが別のノードのブートパーティションにアクセスできないように NPIV を設定する必要があります。

      3. 必要に応じてさらにパラメーターを調整できます。

        重要

        マルチパスを完全に有効にするには、インストール後の追加の手順が必要です。詳細は、マシン設定 の「RHCOS のカーネル引数でのマルチパスの有効化」を参照してください。

        以下は、マルチパスを使用するワーカーノードのパラメーターファイルの例 additional-worker-fcp.parm です。 

        cio_ignore=all,!condev rd.neednet=1 \
console=ttysclp0 \
coreos.inst.install_dev=/dev/sda \
coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
coreos.inst.ignition_url=http://<http_server>/worker.ign \
ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
zfcp.allow_lun_scan=0 \
rd.zfcp=0.0.1987,0x50050763070bc5e3,0x4008400B00000000 \
rd.zfcp=0.0.19C7,0x50050763070bc5e3,0x4008400B00000000 \
rd.zfcp=0.0.1987,0x50050763071bc5e3,0x4008400B00000000 \
rd.zfcp=0.0.19C7,0x50050763071bc5e3,0x4008400B00000000
        Copy to Clipboard Toggle word wrap

        パラメーターファイルのすべてのオプションを 1 行で記述し、改行文字がないことを確認します。

  7. FTP などを使用し、initramfs、kernel、パラメーターファイル、および RHCOS イメージを z/VM に転送します。FTP を使用してファイルを転送し、仮想リーダーから起動する方法の詳細は、IBM Z® でインストールを起動して z/VM に RHEL をインストールする を参照してください。

  8. ファイルを z/VM ゲスト仮想マシンの仮想リーダーに punch します。

    IBM® ドキュメントの PUNCH を参照してください。

    ヒント

    CP PUNCH コマンドを使用するか、Linux を使用している場合は、vmur コマンドを使用して 2 つの z/VM ゲスト仮想マシン間でファイルを転送できます。

  9. ブートストラップマシンで CMS にログインします。

  10. 次のコマンドを実行して、リーダーからブートストラップマシンを IPL します。 

    $ ipl c
    Copy to Clipboard Toggle word wrap

    IBM® ドキュメントの IPL を参照してください。

4.6.3. マシンの証明書署名要求の承認
リンクのコピー

マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。

前提条件

  • マシンがクラスターに追加されています。

手順

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.29.4
master-1  Ready     master  63m  v1.29.4
master-2  Ready     master  64m  v1.29.4
    Copy to Clipboard Toggle word wrap

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

    注記

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    出力例

    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
...
    Copy to Clipboard Toggle word wrap

    この例では、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 サービスアカウントによって提出されていることを確認し、ノードの ID を確認します。

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

      $ oc adm certificate approve <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      注記

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    出力例

    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
...
    Copy to Clipboard Toggle word wrap

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

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

      $ oc adm certificate approve <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.29.4
master-1  Ready     master  73m  v1.29.4
master-2  Ready     master  74m  v1.29.4
worker-0  Ready     worker  11m  v1.29.4
worker-1  Ready     worker  11m  v1.29.4
    Copy to Clipboard Toggle word wrap

    注記

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

関連情報

IBM Z® および IBM® LinuxONE (s390x) 上の LPAR にマルチアーキテクチャーコンピュートマシンを含むクラスターを作成するには、既存のシングルアーキテクチャーの x86_64 クラスターが必要です。その後、s390x コンピュートマシンを OpenShift Container Platform クラスターに追加できます。

s390x ノードをクラスターに追加する前に、クラスターをマルチアーキテクチャーペイロードを使用するクラスターにアップグレードする必要があります。マルチアーキテクチャーペイロードへの移行の詳細は、マルチアーキテクチャーコンピュートマシンを使用したクラスターへの移行 を参照してください。

以下の手順では、LPAR インスタンスを使用して RHCOS コンピュートマシンを作成する方法を説明します。これにより、s390x ノードをクラスターに追加し、マルチアーキテクチャーのコンピュートマシンを含むクラスターをデプロイメントできるようになります。

注記

x86_64 上でマルチアーキテクチャーコンピュートマシンを含む IBM Z® または IBM® LinuxONE (s390x) クラスターを作成するには、IBM Z® および IBM® LinuxONE へのクラスターのインストール の手順に従ってください。その後、ベアメタル、IBM Power、または IBM Z 上でマルチアーキテクチャーコンピュートマシンを含むクラスターを作成する の説明に従って、x86_64 コンピュートマシンを追加できます。

4.7.1. クラスターの互換性の確認
リンクのコピー

異なるアーキテクチャーのコンピュートノードをクラスターに追加する前に、クラスターがマルチアーキテクチャー互換であることを確認する必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. OpenShift CLI (oc) にログインします。

  2. 次のコマンドを実行すると、クラスターがアーキテクチャーペイロードを使用していることを確認できます。 

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"
    Copy to Clipboard Toggle word wrap

検証

  • 次の出力が表示された場合、クラスターはマルチアーキテクチャーペイロードを使用しています。 

    {
 "release.openshift.io/architecture": "multi",
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap

    その後、クラスターへのマルチアーキテクチャーコンピュートノードの追加を開始できます。

  • 次の出力が表示された場合、クラスターはマルチアーキテクチャーペイロードを使用していません。 

    {
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap
    重要

    クラスターを、マルチアーキテクチャーコンピュートマシンをサポートするクラスターに移行するには、マルチアーキテクチャーコンピュートマシンを含むクラスターへの移行 の手順に従ってください。

4.7.2. LPAR 内の IBM Z 上に RHCOS マシンを作成する
リンクのコピー

論理パーティション (LPAR) 内の IBM Z® 上で実行される Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートマシンをさらに作成し、既存のクラスターに割り当てることができます。

前提条件

  • ノードのホスト名および逆引き参照を実行できるドメインネームサーバー (DNS) がある。
  • 作成するマシンがアクセスできるプロビジョニングマシンで稼働している HTTP または HTTPS サーバーがある。

手順

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

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
    Copy to Clipboard Toggle word wrap
  2. クラスターからエクスポートした worker.ign Ignition 設定ファイルを HTTP サーバーにアップロードします。このファイルの URL をメモします。

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

    $ curl -k http://<http_server>/worker.ign
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、RHEL ライブ kernel、initramfs、および rootfs ファイルをダウンロードします。 

    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
| jq -r '.architectures.s390x.artifacts.metal.formats.pxe.kernel.location')
    Copy to Clipboard Toggle word wrap 
    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
| jq -r '.architectures.s390x.artifacts.metal.formats.pxe.initramfs.location')
    Copy to Clipboard Toggle word wrap 
    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
| jq -r '.architectures.s390x.artifacts.metal.formats.pxe.rootfs.location')
    Copy to Clipboard Toggle word wrap
  5. ダウンロードした RHEL ライブ kernel、initramfs、および rootfs ファイルを、追加する RHCOS ゲストからアクセス可能な HTTP または HTTPS サーバーに移動します。

  6. ゲストのパラメーターファイルを作成します。次のパラメーターは仮想マシンに固有です。

    • オプション: 静的 IP アドレスを指定するには、次のエントリーをコロンで区切って ip= パラメーターを追加します。

      1. マシンの IP アドレス。
      2. 空の文字列。
      3. ゲートウェイ。
      4. ネットマスク。
      5. hostname.domainname 形式のマシンホストおよびドメイン名。この値を省略すると、RHCOS が逆引き DNS ルックアップによりホスト名を取得します。
      6. ネットワークインターフェイス名。この値を省略すると、RHCOS が利用可能なすべてのインターフェイスに IP 設定を適用します。
      7. 値 none。
    • coreos.inst.ignition_url= には、worker.ign ファイルへの URL を指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。
    • coreos.live.rootfs_url= の場合、起動している kernel および initramfs の一致する rootfs アーティファクトを指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。

    • DASD タイプのディスクへのインストールには、以下のタスクを実行します。

      1. coreos.inst.install_dev= には、/dev/dasda を指定します。
      2. rd.dasd= を使用して、RHCOS がインストールされる DASD を指定します。

      3. 必要に応じてさらにパラメーターを調整できます。

        以下はパラメーターファイルの例、additional-worker-dasd.parm です。 

        cio_ignore=all,!condev rd.neednet=1 \
console=ttysclp0 \
coreos.inst.install_dev=/dev/dasda \
coreos.inst.ignition_url=http://<http_server>/worker.ign \
coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
rd.dasd=0.0.3490 \
zfcp.allow_lun_scan=0
        Copy to Clipboard Toggle word wrap

        パラメーターファイルのすべてのオプションを 1 行で記述し、改行文字がないことを確認します。

    • FCP タイプのディスクへのインストールには、以下のタスクを実行します。

      1. rd.zfcp=<adapter>,<wwpn>,<lun> を使用して RHCOS がインストールされる FCP ディスクを指定します。マルチパスの場合、それぞれの追加のステップについてこのステップを繰り返します。

        注記

        複数のパスを使用してインストールする場合は、問題が発生する可能性があるため、後でではなくインストールの直後にマルチパスを有効にする必要があります。

      2. インストールデバイスを coreos.inst.install_dev=/dev/sda として設定します。

        注記

        追加の LUN が NPIV で設定される場合は、FCP に zfcp.allow_lun_scan=0 が必要です。CSI ドライバーを使用するために zfcp.allow_lun_scan=1 を有効にする必要がある場合などには、各ノードが別のノードのブートパーティションにアクセスできないように NPIV を設定する必要があります。

      3. 必要に応じてさらにパラメーターを調整できます。

        重要

        マルチパスを完全に有効にするには、インストール後の追加の手順が必要です。詳細は、マシン設定 の「RHCOS のカーネル引数でのマルチパスの有効化」を参照してください。

        以下は、マルチパスを使用するワーカーノードのパラメーターファイルの例 additional-worker-fcp.parm です。 

        cio_ignore=all,!condev rd.neednet=1 \
console=ttysclp0 \
coreos.inst.install_dev=/dev/sda \
coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
coreos.inst.ignition_url=http://<http_server>/worker.ign \
ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
zfcp.allow_lun_scan=0 \
rd.zfcp=0.0.1987,0x50050763070bc5e3,0x4008400B00000000 \
rd.zfcp=0.0.19C7,0x50050763070bc5e3,0x4008400B00000000 \
rd.zfcp=0.0.1987,0x50050763071bc5e3,0x4008400B00000000 \
rd.zfcp=0.0.19C7,0x50050763071bc5e3,0x4008400B00000000
        Copy to Clipboard Toggle word wrap

        パラメーターファイルのすべてのオプションを 1 行で記述し、改行文字がないことを確認します。

  7. FTP などを使用し、initramfs、kernel、パラメーターファイル、および RHCOS イメージを LPAR に転送します。FTP を使用してファイルを転送し、起動する方法の詳細は、IBM Z® でインストールを起動して LPAR に RHEL をインストールする を参照してください。
  8. マシンを起動します。

4.7.3. マシンの証明書署名要求の承認
リンクのコピー

マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。

前提条件

  • マシンがクラスターに追加されています。

手順

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.29.4
master-1  Ready     master  63m  v1.29.4
master-2  Ready     master  64m  v1.29.4
    Copy to Clipboard Toggle word wrap

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

    注記

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    出力例

    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
...
    Copy to Clipboard Toggle word wrap

    この例では、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 サービスアカウントによって提出されていることを確認し、ノードの ID を確認します。

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

      $ oc adm certificate approve <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      注記

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    出力例

    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
...
    Copy to Clipboard Toggle word wrap

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

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

      $ oc adm certificate approve <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.29.4
master-1  Ready     master  73m  v1.29.4
master-2  Ready     master  74m  v1.29.4
worker-0  Ready     worker  11m  v1.29.4
worker-1  Ready     worker  11m  v1.29.4
    Copy to Clipboard Toggle word wrap

    注記

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

関連情報

RHEL KVM を使用して IBM Z® および IBM® LinuxONE (s390x) 上のマルチアーキテクチャーコンピュートマシンでクラスターを作成するには、既存の単一アーキテクチャー x86_64 クラスターが必要です。その後、s390x コンピュートマシンを OpenShift Container Platform クラスターに追加できます。

s390x ノードをクラスターに追加する前に、クラスターをマルチアーキテクチャーペイロードを使用するクラスターにアップグレードする必要があります。マルチアーキテクチャーペイロードへの移行の詳細は、マルチアーキテクチャーコンピュートマシンを使用したクラスターへの移行 を参照してください。

次の手順では、RHEL KVM インスタンスを使用して RHCOS コンピュートマシンを作成する方法を説明します。これにより、s390x ノードをクラスターに追加し、マルチアーキテクチャーのコンピュートマシンを含むクラスターをデプロイメントできるようになります。

x86_64 上でマルチアーキテクチャーコンピュートマシンを含む IBM Z® または IBM® LinuxONE (s390x) クラスターを作成するには、IBM Z® および IBM® LinuxONE へのクラスターのインストール の手順に従ってください。その後、ベアメタル、IBM Power、または IBM Z 上でマルチアーキテクチャーコンピュートマシンを含むクラスターを作成する の説明に従って、x86_64 コンピュートマシンを追加できます。

注記

セカンダリーアーキテクチャーノードをクラスターに追加する前に、Multiarch Tuning Operator をインストールし、ClusterPodPlacementConfig オブジェクトをデプロイすることを推奨します。詳細は、Multiarch Tuning Operator を使用してマルチアーキテクチャークラスター上のワークロードを管理する を参照してください。

4.8.1. クラスターの互換性の確認
リンクのコピー

異なるアーキテクチャーのコンピュートノードをクラスターに追加する前に、クラスターがマルチアーキテクチャー互換であることを確認する必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. OpenShift CLI (oc) にログインします。

  2. 次のコマンドを実行すると、クラスターがアーキテクチャーペイロードを使用していることを確認できます。 

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"
    Copy to Clipboard Toggle word wrap

検証

  • 次の出力が表示された場合、クラスターはマルチアーキテクチャーペイロードを使用しています。 

    {
 "release.openshift.io/architecture": "multi",
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap

    その後、クラスターへのマルチアーキテクチャーコンピュートノードの追加を開始できます。

  • 次の出力が表示された場合、クラスターはマルチアーキテクチャーペイロードを使用していません。 

    {
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap
    重要

    クラスターを、マルチアーキテクチャーコンピュートマシンをサポートするクラスターに移行するには、マルチアーキテクチャーコンピュートマシンを含むクラスターへの移行 の手順に従ってください。

4.8.2. virt-install を使用した RHCOS マシンの作成
リンクのコピー

virt-install を使用すると、クラスター用にさらに Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートマシンを作成できます。

前提条件

  • この手順では RHEL KVM ホストと呼ばれる、KVM を使用する RHEL 8.7 以降で実行されている少なくとも 1 つの LPAR がある。
  • KVM/QEMU ハイパーバイザーが RHEL KVM ホストにインストーされている
  • ノードのホスト名および逆引き参照を実行できるドメインネームサーバー (DNS) がある。
  • HTTP または HTTPS サーバーが設定されている。

手順

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

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
    Copy to Clipboard Toggle word wrap
  2. クラスターからエクスポートした worker.ign Ignition 設定ファイルを HTTP サーバーにアップロードします。このファイルの URL をメモします。

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

    $ curl -k http://<HTTP_server>/worker.ign
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、RHEL ライブ kernel、initramfs、および rootfs ファイルをダウンロードします。 

     $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
| jq -r '.architectures.s390x.artifacts.metal.formats.pxe.kernel.location')
    Copy to Clipboard Toggle word wrap 
    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
| jq -r '.architectures.s390x.artifacts.metal.formats.pxe.initramfs.location')
    Copy to Clipboard Toggle word wrap 
    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
| jq -r '.architectures.s390x.artifacts.metal.formats.pxe.rootfs.location')
    Copy to Clipboard Toggle word wrap
  5. virt-install を起動する前に、ダウンロードした RHEL ライブ kernel、initramfs、および rootfs ファイルを HTTP または HTTPS サーバーに移動します。

  6. RHEL kernel、initramfs、および Ignition ファイル、新規ディスクイメージ、および調整された parm 引数を使用して、新規 KVM ゲストノードを作成します。 

    $ virt-install \
   --connect qemu:///system \
   --name <vm_name> \
   --autostart \
   --os-variant rhel9.4 \
    1 
    
   --cpu host \
   --vcpus <vcpus> \
   --memory <memory_mb> \
   --disk <vm_name>.qcow2,size=<image_size> \
   --network network=<virt_network_parm> \
   --location <media_location>,kernel=<rhcos_kernel>,initrd=<rhcos_initrd> \
    2 
    
   --extra-args "rd.neednet=1" \
   --extra-args "coreos.inst.install_dev=/dev/vda" \
   --extra-args "coreos.inst.ignition_url=http://<http_server>/worker.ign " \
    3 
    
   --extra-args "coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img" \
    4 
    
   --extra-args "ip=<ip>::<gateway>:<netmask>:<hostname>::none" \
    5 
    
   --extra-args "nameserver=<dns>" \
   --extra-args "console=ttysclp0" \
   --noautoconsole \
   --wait
    Copy to Clipboard Toggle word wrap
    1
    os-variant には、RHCOS コンピュートマシンの RHEL バージョンを指定します。rhel9.4 が推奨バージョンです。オペレーティングシステムのサポートされている RHEL バージョンを照会するには、次のコマンドを実行します。 
    $ osinfo-query os -f short-id
    Copy to Clipboard Toggle word wrap
    注記

    os-variant では大文字と小文字が区別されます。

    2
    --location には、HTTP サーバーまたは HTTPS サーバーのカーネル/initrd の場所を指定します。
    3
    worker.ign 設定ファイルの場所を指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。
    4
    起動する kernel と initramfs の rootfs アーティファクトの場所を指定します。HTTP および HTTPS プロトコルのみがサポートされています。
    5
    オプション: hostname には、クライアントマシンの完全修飾ホスト名を指定します。
    注記

    HAProxy をロードバランサーとして使用している場合は、/etc/haproxy/haproxy.cfg 設定ファイル内の ingress-router-443 および ingress-router-80 の HAProxy ルールを更新します。

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

4.8.3. マシンの証明書署名要求の承認
リンクのコピー

マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。

前提条件

  • マシンがクラスターに追加されています。

手順

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.29.4
master-1  Ready     master  63m  v1.29.4
master-2  Ready     master  64m  v1.29.4
    Copy to Clipboard Toggle word wrap

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

    注記

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    出力例

    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
...
    Copy to Clipboard Toggle word wrap

    この例では、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 サービスアカウントによって提出されていることを確認し、ノードの ID を確認します。

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

      $ oc adm certificate approve <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      注記

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    出力例

    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
...
    Copy to Clipboard Toggle word wrap

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

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

      $ oc adm certificate approve <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.29.4
master-1  Ready     master  73m  v1.29.4
master-2  Ready     master  74m  v1.29.4
worker-0  Ready     worker  11m  v1.29.4
worker-1  Ready     worker  11m  v1.29.4
    Copy to Clipboard Toggle word wrap

    注記

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

関連情報

4.9. IBM Power 上でマルチアーキテクチャーのコンピュートマシンを含むクラスターを作成する
リンクのコピー

IBM Power® (ppc64le) 上でマルチアーキテクチャーのコンピュートマシンを含むクラスターを作成するには、既存の単一アーキテクチャー (x86_64) クラスターが必要です。その後、ppc64le コンピュートマシンを OpenShift Container Platform クラスターに追加できます。

重要

ppc64le ノードをクラスターに追加する前に、クラスターをマルチアーキテクチャーペイロードを使用するクラスターにアップグレードする必要があります。マルチアーキテクチャーペイロードへの移行の詳細は、マルチアーキテクチャーコンピュートマシンを使用したクラスターへの移行 を参照してください。

次の手順では、ISO イメージまたはネットワーク PXE ブートを使用して RHCOS コンピュートマシンを作成する方法を説明します。これにより、ppc64le ノードをクラスターに追加し、マルチアーキテクチャーのコンピュートマシンを含むクラスターをデプロイできるようになります。

x86_64 上でマルチアーキテクチャーのコンピュートマシンを含む IBM Power® (ppc64le) クラスターを作成するには、IBM Power® へのクラスターのインストール の手順に従ってください。その後、ベアメタル、IBM Power、または IBM Z 上でマルチアーキテクチャーコンピュートマシンを含むクラスターを作成する の説明に従って、x86_64 コンピュートマシンを追加できます。

注記

セカンダリーアーキテクチャーノードをクラスターに追加する前に、Multiarch Tuning Operator をインストールし、ClusterPodPlacementConfig オブジェクトをデプロイすることを推奨します。詳細は、Multiarch Tuning Operator を使用してマルチアーキテクチャークラスター上のワークロードを管理する を参照してください。

4.9.1. クラスターの互換性の確認
リンクのコピー

異なるアーキテクチャーのコンピュートノードをクラスターに追加する前に、クラスターがマルチアーキテクチャー互換であることを確認する必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
注記

複数のアーキテクチャーを使用する場合、OpenShift Container Platform ノードのホストは同じストレージレイヤーを共有する必要があります。同じストレージレイヤーがない場合は、nfs-provisioner などのストレージプロバイダーを使用します。

注記

コンピュートプレーンとコントロールプレーン間のネットワークホップ数をできる限り制限する必要があります。

手順

  1. OpenShift CLI (oc) にログインします。

  2. 次のコマンドを実行すると、クラスターがアーキテクチャーペイロードを使用していることを確認できます。 

    $ oc adm release info -o jsonpath="{ .metadata.metadata}"
    Copy to Clipboard Toggle word wrap

検証

  • 次の出力が表示された場合、クラスターはマルチアーキテクチャーペイロードを使用しています。 

    {
 "release.openshift.io/architecture": "multi",
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap

    その後、クラスターへのマルチアーキテクチャーコンピュートノードの追加を開始できます。

  • 次の出力が表示された場合、クラスターはマルチアーキテクチャーペイロードを使用していません。 

    {
 "url": "https://access.redhat.com/errata/<errata_version>"
}
    Copy to Clipboard Toggle word wrap
    重要

    クラスターを、マルチアーキテクチャーコンピュートマシンをサポートするクラスターに移行するには、マルチアーキテクチャーコンピュートマシンを含むクラスターへの移行 の手順に従ってください。

4.9.2. ISO イメージを使用した RHCOS マシンの作成
リンクのコピー

ISO イメージを使用して、クラスターの追加の Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートマシンを作成できます。

前提条件

  • クラスターのコンピュートマシンの Ignition 設定ファイルの URL を取得します。このファイルがインストール時に HTTP サーバーにアップロードされている必要があります。
  • OpenShift CLI (oc) がインストールされている。

手順

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

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
    Copy to Clipboard Toggle word wrap
  2. クラスターからエクスポートした worker.ign Ignition 設定ファイルを HTTP サーバーにアップロードします。これらのファイルの URL をメモします。

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

    $ curl -k http://<HTTP_server>/worker.ign
    Copy to Clipboard Toggle word wrap

  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')
    Copy to Clipboard Toggle word wrap

  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>
    1
    2
    Copy to Clipboard Toggle word wrap
    1
    core ユーザーにはインストールを実行するために必要な 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/worker.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b
    Copy to Clipboard Toggle word wrap

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

    重要

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

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

4.9.3. PXE または iPXE ブートによる RHCOS マシンの作成
リンクのコピー

PXE または iPXE ブートを使用して、ベアメタルクラスターの追加の Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートマシンを作成できます。

前提条件

  • クラスターのコンピュートマシンの Ignition 設定ファイルの URL を取得します。このファイルがインストール時に HTTP サーバーにアップロードされている必要があります。
  • クラスターのインストール時に HTTP サーバーにアップロードした RHCOS ISO イメージ、圧縮されたメタル BIOS、kernel、および initramfs ファイルの URL を取得します。
  • インストール時に OpenShift Container Platform クラスターのマシンを作成するために使用した PXE ブートインフラストラクチャーにアクセスできる必要があります。RHCOS のインストール後にマシンはローカルディスクから起動する必要があります。
  • UEFI を使用する場合、OpenShift Container Platform のインストール時に変更した grub.conf ファイルにアクセスできます。

手順

  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
      Copy to Clipboard Toggle word wrap
      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 + ppc64le) の場合: 

      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
      Copy to Clipboard Toggle word wrap
      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 インストール用シリアルコンソールの有効化」を参照してください。

      注記

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

    • ppc64le 上の 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 
      
}
      Copy to Clipboard Toggle word wrap
      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 インフラストラクチャーを使用して、クラスターに必要なコンピュートマシンを作成します。

4.9.4. マシンの証明書署名要求の承認
リンクのコピー

マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。

前提条件

  • マシンがクラスターに追加されています。

手順

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

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.29.4
master-1  Ready     master  63m  v1.29.4
master-2  Ready     master  64m  v1.29.4
    Copy to Clipboard Toggle word wrap

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

    注記

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    出力例

    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
...
    Copy to Clipboard Toggle word wrap

    この例では、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 サービスアカウントによって提出されていることを確認し、ノードの ID を確認します。

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

      $ oc adm certificate approve <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      注記

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

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    出力例

    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
...
    Copy to Clipboard Toggle word wrap

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

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

      $ oc adm certificate approve <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

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

    $ oc get nodes -o wide
    Copy to Clipboard Toggle word wrap

    出力例

    NAME               STATUS   ROLES                  AGE   VERSION   INTERNAL-IP      EXTERNAL-IP   OS-IMAGE                                                       KERNEL-VERSION                  CONTAINER-RUNTIME
worker-0-ppc64le   Ready    worker                 42d   v1.29.5   192.168.200.21   <none>        Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.ppc64le   cri-o://1.29.5-3.rhaos4.15.gitb36169e.el9
worker-1-ppc64le   Ready    worker                 42d   v1.29.5   192.168.200.20   <none>        Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.ppc64le   cri-o://1.29.5-3.rhaos4.15.gitb36169e.el9
master-0-x86       Ready    control-plane,master   75d   v1.29.5   10.248.0.38      10.248.0.38   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.29.5-3.rhaos4.15.gitb36169e.el9
master-1-x86       Ready    control-plane,master   75d   v1.29.5   10.248.0.39      10.248.0.39   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.29.5-3.rhaos4.15.gitb36169e.el9
master-2-x86       Ready    control-plane,master   75d   v1.29.5   10.248.0.40      10.248.0.40   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.29.5-3.rhaos4.15.gitb36169e.el9
worker-0-x86       Ready    worker                 75d   v1.29.5   10.248.0.43      10.248.0.43   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.29.5-3.rhaos4.15.gitb36169e.el9
worker-1-x86       Ready    worker                 75d   v1.29.5   10.248.0.44      10.248.0.44   Red Hat Enterprise Linux CoreOS 415.92.202309261919-0 (Plow)   5.14.0-284.34.1.el9_2.x86_64    cri-o://1.29.5-3.rhaos4.15.gitb36169e.el9
    Copy to Clipboard Toggle word wrap

    注記

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

関連情報

4.10. マルチアーキテクチャーコンピュートマシンを含むクラスターの管理
リンクのコピー

さまざまなアーキテクチャーのコンピュートノードを含むクラスターにワークロードをデプロイするには、クラスターの注意と監視が必要です。クラスターのノードに Pod を正常に配置するには、さらにアクションが必要な場合があります。

Multiarch Tuning Operator を使用すると、マルチアーキテクチャーコンピュートマシンを含むクラスターで、アーキテクチャーを考慮したワークロードのスケジューリングを有効にできます。Multiarch Tuning Operator は、Pod が作成時にサポートできるアーキテクチャーに基づいて、Pod 仕様に追加のスケジューラー述語を実装します。詳細は、Multiarch Tuning Operator を使用してマルチアーキテクチャークラスター上のワークロードを管理する を参照してください。

ノードアフィニティー、スケジューリング、taint、toleration の詳細は、次のドキュメントを参照してください。

4.10.1.1. マルチアーキテクチャーノードのワークロードデプロイメントのサンプル
リンクのコピー

異なるアーキテクチャーのコンピュートノードを含むクラスター上でワークロードをスケジュールする前に、次の使用例を考慮してください。

ノードアフィニティーを使用してノード上のワークロードをスケジュールする

イメージによってサポートされるアーキテクチャーを持つ一連のノード上でのみワークロードをスケジュールできるようにすることができ、Pod のテンプレート仕様で spec.affinity.nodeAffinity フィールドを設定できます。

特定のアーキテクチャーに設定された nodeAffinity を使用したデプロイメントの例

apiVersion: apps/v1
kind: Deployment
metadata: # ...
spec:
   # ...
  template:
     # ...
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values:
1 

                - amd64
                - arm64
Copy to Clipboard Toggle word wrap

1
サポートされるアーキテクチャーを指定します。有効な値には、amd64、arm64、または両方の値が含まれます。
特定のアーキテクチャー向けにすべてのノードを taint する

ノードを taint して、そのノード上でそのアーキテクチャーと互換性のないワークロードがスケジュールされるのを回避できます。クラスターが MachineSet オブジェクトを使用している場合は、サポートされていないアーキテクチャーのノードでワークロードがスケジュールされるのを回避するために、パラメーターを .spec.template.spec.taints フィールドに追加できます。

  • ノードを taint する前に、MachineSet オブジェクトをスケールダウンするか、使用可能なマシンを削除する必要があります。次のコマンドのいずれかを使用して、マシンセットをスケールダウンできます。 

    $ oc scale --replicas=0 machineset <machineset> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

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

    $ oc edit machineset <machineset> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    マシンセットのスケーリングの詳細は、「コンピュートマシンセットの変更」を参照してください。

taint セットを含む MachineSet の例

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata: # ...
spec:
  # ...
  template:
    # ...
    spec:
      # ...
      taints:
      - effect: NoSchedule
        key: multi-arch.openshift.io/arch
        value: arm64
Copy to Clipboard Toggle word wrap

次のコマンドを実行して、特定のノードに taint を設定することもできます。 

$ oc adm taint nodes <node-name> multi-arch.openshift.io/arch=arm64:NoSchedule
Copy to Clipboard Toggle word wrap
デフォルト許容範囲の作成

次のコマンドを実行して、namespace にアノテーションを付けて、すべてのワークロードが同じデフォルトの許容範囲を取得できるようにすることができます。 

$ oc annotate namespace my-namespace \
  'scheduler.alpha.kubernetes.io/defaultTolerations'='[{"operator": "Exists", "effect": "NoSchedule", "key": "multi-arch.openshift.io/arch"}]'
Copy to Clipboard Toggle word wrap
ワークロードにおけるアーキテクチャーの taint を許容する

taint が定義されたノードでは、そのノード上でワークロードはスケジュールされません。ただし、Pod の仕様で toleration を設定することで、スケジュールを許可できます。

許容を備えた導入例

apiVersion: apps/v1
kind: Deployment
metadata: # ...
spec:
  # ...
  template:
    # ...
    spec:
      tolerations:
      - key: "multi-arch.openshift.io/arch"
        value: "arm64"
        operator: "Equal"
        effect: "NoSchedule"
Copy to Clipboard Toggle word wrap

このデプロイメント例は、multi-arch.openshift.io/arch=arm64 taint が指定されたノードでも許可できます。

taint および許容でのノードアフィニティーの使用

スケジューラーが Pod をスケジュールするためにノードのセットを計算する場合は、ノードアフィニティーによってセットが制限される一方で、許容によってセットが拡大する可能性があります。特定のアーキテクチャーのノードに taint を設定する場合、Pod のスケジュールには次の例の許容が必要です。

ノードアフィニティーと許容セットを使用したデプロイメントの例。

apiVersion: apps/v1
kind: Deployment
metadata: # ...
spec:
  # ...
  template:
    # ...
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values:
                - amd64
                - arm64
      tolerations:
      - key: "multi-arch.openshift.io/arch"
        value: "arm64"
        operator: "Equal"
        effect: "NoSchedule"
Copy to Clipboard Toggle word wrap

関連情報

4.10.2. Red Hat Enterprise Linux CoreOS (RHCOS) カーネルでの 64k ページの有効化
リンクのコピー

クラスター内の 64 ビット ARM コンピュートマシン上の Red Hat Enterprise Linux CoreOS (RHCOS) カーネルで 64k メモリーページを有効にすることができます。64k ページサイズのカーネル仕様は、大規模な GPU または高メモリーのワークロードに使用できます。これは、マシン設定プールを使用してカーネルを更新する Machine Config Operator (MCO) を使用して行われます。64k ページサイズを有効にするには、ARM64 専用のマシン設定プールをカーネルで有効にする必要があります。

重要

64k ページの使用は、64 ビット ARM マシンにインストールされた 64 ビット ARM アーキテクチャーのコンピュートノードまたはクラスターに限定されます。64 ビット x86 マシンを使用してマシン設定プールに 64k ページのカーネルを設定すると、マシン設定プールと MCO がデグレード状態になります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • サポート対象のいずれかのプラットフォームで、異なるアーキテクチャーのコンピュートノードを含むクラスターを作成している。

手順

  1. 64k ページサイズのカーネルを実行するノードにラベルを付けます。 

    $ oc label node <node_name> <label>
    Copy to Clipboard Toggle word wrap

    コマンドの例

    $ oc label node worker-arm64-01 node-role.kubernetes.io/worker-64k-pages=
    Copy to Clipboard Toggle word wrap

  2. ARM64 アーキテクチャーを使用するワーカーロールと worker-64k-pages ロールを含むマシン設定プールを作成します。 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: worker-64k-pages
spec:
  machineConfigSelector:
    matchExpressions:
      - key: machineconfiguration.openshift.io/role
        operator: In
        values:
        - worker
        - worker-64k-pages
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker-64k-pages: ""
      kubernetes.io/arch: arm64
    Copy to Clipboard Toggle word wrap

  3. コンピュートノード上にマシン設定を作成し、64k-pages パラメーターを使用して 64k-pages を有効にします。 

    $ oc create -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

    MachineConfig の例

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: "worker-64k-pages"
    1 
    
  name: 99-worker-64kpages
spec:
  kernelType: 64k-pages
    2
    Copy to Clipboard Toggle word wrap

    1
    カスタムマシン設定プールの machineconfiguration.openshift.io/role ラベルの値を指定します。MachineConfig の例では、worker-64k-pages ラベルを使用して、worker-64k-pages プールで 64k ページを有効にしています。
    2
    必要なカーネルタイプを指定します。有効な値は 64k-pages と default です。
    注記

    64k-pages タイプは、64 ビット ARM アーキテクチャーベースのコンピュートノードでのみサポートされます。realtime タイプは、64 ビット x86 アーキテクチャーベースのコンピュートノードでのみサポートされます。

検証

  • 新しい worker-64k-pages マシン設定プールを表示するには、次のコマンドを実行します。 

    $ oc get mcp
    Copy to Clipboard Toggle word wrap

    出力例

    NAME     CONFIG                                                                UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-9d55ac9a91127c36314e1efe7d77fbf8                      True      False      False      3              3                   3                     0                      361d
worker   rendered-worker-e7b61751c4a5b7ff995d64b967c421ff                      True      False      False      7              7                   7                     0                      361d
worker-64k-pages  rendered-worker-64k-pages-e7b61751c4a5b7ff995d64b967c421ff   True      False      False      2              2                   2                     0                      35m
    Copy to Clipboard Toggle word wrap

マルチアーキテクチャーコンピュートマシンを持つ OpenShift Container Platform 4.16 クラスターでは、クラスター内のイメージストリームはマニフェストリストを自動的にインポートしません。マニフェストリストをインポートするには、デフォルトの importMode オプションを PreserveOriginal オプションに手動で変更する必要があります。

前提条件

  • OpenShift Container Platform CLI (oc) をインストールしている。

手順

  • 次のコマンド例は、ImageStream cli-artifacts にパッチを適用して、cli-artifacts:latest イメージストリームタグがマニフェストリストとしてインポートされるようにする方法を示しています。 

    $ oc patch is/cli-artifacts -n openshift -p '{"spec":{"tags":[{"name":"latest","importPolicy":{"importMode":"PreserveOriginal"}}]}}'
    Copy to Clipboard Toggle word wrap

検証

  • イメージストリームタグを調べて、マニフェストリストが正しくインポートされたことを確認できます。次のコマンドは、特定のタグの個々のアーキテクチャーマニフェストを一覧表示します。 

    $ oc get istag cli-artifacts:latest -n openshift -oyaml
    Copy to Clipboard Toggle word wrap

    dockerImageManifests オブジェクトが存在する場合、マニフェストリストのインポートは成功しています。

    dockerImageManifests オブジェクトの出力例

    dockerImageManifests:
  - architecture: amd64
    digest: sha256:16d4c96c52923a9968fbfa69425ec703aff711f1db822e4e9788bf5d2bee5d77
    manifestSize: 1252
    mediaType: application/vnd.docker.distribution.manifest.v2+json
    os: linux
  - architecture: arm64
    digest: sha256:6ec8ad0d897bcdf727531f7d0b716931728999492709d19d8b09f0d90d57f626
    manifestSize: 1252
    mediaType: application/vnd.docker.distribution.manifest.v2+json
    os: linux
  - architecture: ppc64le
    digest: sha256:65949e3a80349cdc42acd8c5b34cde6ebc3241eae8daaeea458498fedb359a6a
    manifestSize: 1252
    mediaType: application/vnd.docker.distribution.manifest.v2+json
    os: linux
  - architecture: s390x
    digest: sha256:75f4fa21224b5d5d511bea8f92dfa8e1c00231e5c81ab95e83c3013d245d1719
    manifestSize: 1252
    mediaType: application/vnd.docker.distribution.manifest.v2+json
    os: linux
    Copy to Clipboard Toggle word wrap

Multiarch Tuning Operator は、マルチアーキテクチャークラスター内およびマルチアーキテクチャー環境に移行するシングルアーキテクチャークラスター内のワークロード管理を最適化します。

アーキテクチャーを考慮したワークロードスケジューリングにより、スケジューラーは Pod イメージのアーキテクチャーに一致するノードに Pod を配置できます。

スケジューラーは、新しい Pod のノードへの配置を決定する際に、デフォルトでは Pod のコンテナーイメージのアーキテクチャーを考慮しません。

アーキテクチャーを考慮したワークロードのスケジューリングを有効にするには、ClusterPodPlacementConfig オブジェクトを作成する必要があります。ClusterPodPlacementConfig オブジェクトを作成すると、Multiarch Tuning Operator は、アーキテクチャーを考慮したワークロードスケジューリングをサポートするために必要なオペランドをデプロイします。ClusterPodPlacementConfig オブジェクトの nodeAffinityScoring プラグインを使用して、ノードアーキテクチャーのクラスター全体のスコアを設定することもできます。nodeAffinityScoring プラグインを有効にすると、スケジューラーによって、互換性のあるアーキテクチャーを持つノードがフィルタリングされてから、スコアが最も高いノードに Pod が配置されます。

Pod が作成されると、オペランドは次のアクションを実行します。

  1. Pod のスケジュールを防止するスケジューリングゲート multiarch.openshift.io/scheduling-gate を追加します。
  2. kubernetes.io/arch ラベルでサポートされているアーキテクチャー値を含むスケジューリング述語を計算します。
  3. スケジューリング述語を Pod 仕様の nodeAffinity 要件として統合します。
  4. Pod からスケジューリングゲートを削除します。
重要

オペランドの次の動作に注意してください。

  • nodeSelector フィールドがすでにワークロードの kubernetes.io/arch ラベルで設定されている場合、オペランドはそのワークロードの nodeAffinity フィールドを更新しません。
  • nodeSelector フィールドがワークロードの kubernetes.io/arch ラベルで設定されていない場合、オペランドはそのワークロードの nodeAffinity フィールドを更新します。ただし nodeAffinity フィールドでは、オペランドは kubernetes.io/arch ラベルで設定されていないノードセレクター条件のみ更新します。
  • nodeName フィールドがすでに設定されている場合、Multiarch Tuning Operator は Pod を処理しません。
  • Pod が DaemonSet によって所有されている場合、オペランドは nodeAffinity フィールドを更新しません。
  • kubernetes.io/arch ラベルに nodeSelector または nodeAffinity と preferredAffinity の両方のフィールドが設定されている場合、オペランドは nodeAffinity フィールドを更新しません。
  • kubernetes.io/arch ラベルに nodeSelector または nodeAffinity フィールドのみが設定され、nodeAffinityScoring プラグインが無効になっている場合、オペランドは nodeAffinity フィールドを更新しません。
  • nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution フィールドに、kubernetes.io/arch ラベルに基づいてノードにスコアを割り当てる条件がすでに含まれている場合、オペランドは nodeAffinityScoring プラグイン内の設定を無視します。

4.11.1. CLI を使用した Multiarch Tuning Operator のインストール
リンクのコピー

OpenShift CLI (oc) を使用して、Multiarch Tuning Operator をインストールできます。

前提条件

  • oc がインストールされている。
  • cluster-admin 権限を持つユーザーとして oc にログインしている。

手順

  1. 次のコマンドを実行して、openshift-multiarch-tuning-operator という名前の新しいプロジェクトを作成します。 

    $ oc create ns openshift-multiarch-tuning-operator
    Copy to Clipboard Toggle word wrap

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

    1. OperatorGroup オブジェクトを作成するための設定を含む YAML ファイルを作成します。

      OperatorGroup オブジェクトを作成するための YAML 設定の例

      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-multiarch-tuning-operator
  namespace: openshift-multiarch-tuning-operator
spec: {}
      Copy to Clipboard Toggle word wrap

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

      $ oc create -f <file_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      <file_name> は、OperatorGroup オブジェクトの設定を含む YAML ファイルの名前に置き換えます。

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

    1. Subscription オブジェクトを作成するための設定を含む YAML ファイルを作成します。

      Subscription オブジェクトを作成するための YAML 設定の例

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-multiarch-tuning-operator
  namespace: openshift-multiarch-tuning-operator
spec:
  channel: stable
  name: multiarch-tuning-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic
  startingCSV: multiarch-tuning-operator.<version>
      Copy to Clipboard Toggle word wrap

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

      $ oc create -f <file_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      <file_name> は、Subscription オブジェクトの設定を含む YAML ファイルの名前に置き換えます。
注記

Subscription オブジェクトと OperatorGroup オブジェクトの設定の詳細は、「CLI を使用した OperatorHub からのインストール」を参照してください。

検証

  1. Multiarch Tuning Operator がインストールされていることを確認するには、次のコマンドを実行します。 

    $ oc get csv -n openshift-multiarch-tuning-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                   DISPLAY                     VERSION       REPLACES                            PHASE
multiarch-tuning-operator.<version>   Multiarch Tuning Operator   <version>     multiarch-tuning-operator.1.0.0      Succeeded
    Copy to Clipboard Toggle word wrap

    Operator が Succeeded フェーズにある場合、インストールは成功しています。

  2. オプション: OperatorGroup オブジェクトが作成されたことを確認するには、次のコマンドを実行します。 

    $ oc get operatorgroup -n openshift-multiarch-tuning-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                        AGE
openshift-multiarch-tuning-operator-q8zbb   133m
    Copy to Clipboard Toggle word wrap

  3. オプション: Subscription オブジェクトが作成されたことを確認するには、次のコマンドを実行します。 

    $ oc get subscription -n openshift-multiarch-tuning-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                        PACKAGE                     SOURCE                  CHANNEL
multiarch-tuning-operator   multiarch-tuning-operator   redhat-operators        stable
    Copy to Clipboard Toggle word wrap

4.11.2. Web コンソールを使用した Multiarch Tuning Operator のインストール
リンクのコピー

OpenShift Container Platform Web コンソールを使用して、Multiarch Tuning Operator をインストールできます。

前提条件

  • cluster-admin 権限でクラスターにアクセスできる。
  • OpenShift Container Platform Web コンソールにアクセスできる。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. Operators → OperatorHub に移動します。
  3. 検索フィールドに Multiarch Tuning Operator と入力します。
  4. Multiarch Tuning Operator をクリックします。
  5. Version リストから Multiarch Tuning Operator のバージョンを選択します。
  6. Install をクリックします。

  7. Operator Installation ページで次のオプションを設定します。

    1. Update Channel を stable に設定します。
    2. Installation Mode を All namespaces on the cluster に設定します。

    3. Installed Namespace を、Operator recommended Namespace か Select a Namespace に設定します。

      推奨される Operator namespace は openshift-multiarch-tuning-operator です。openshift-multiarch-tuning-operator namespace が存在しない場合は、Operator のインストール中に作成されます。

      Select a namespace を選択した場合は、Select Project リストから Operator の namespace を選択する必要があります。

    4. Update approval で Automatic または Manual を選択します。

      Automatic 更新を選択すると、Operator Lifecycle Manager (OLM) が管理者の介入なしで Multiarch Tuning Operator の実行中のインスタンスを自動的に更新します。

      Manual 更新を選択すると、OLM は更新要求を作成します。クラスター管理者は、Multiarch Tuning Operator を新しいバージョンに更新するために、更新要求を手動で承認する必要があります。

  8. オプション: Enable Operator recommended cluster monitoring on this Namespace チェックボックスを選択します。
  9. Install をクリックします。

検証

  1. Operators → Installed Operators に移動します。
  2. Multiarch Tuning Operator が、openshift-multiarch-tuning-operator namespace の Status フィールドに Succeeded としてリストされていることを確認します。

4.11.3. Multiarch Tuning Operator Pod ラベルとアーキテクチャーサポートの概要
リンクのコピー

Multiarch Tuning Operator をインストールした後、クラスター内のワークロードに対するマルチアーキテクチャーのサポートを確認できます。Pod ラベルを使用して、アーキテクチャーの互換性に基づき Pod を識別および管理できます。これらのラベルは、アーキテクチャーサポートに関する情報を提供するために、新しく作成された Pod に自動的に設定されます。

次の表は、Pod の作成時に Multiarch Tuning Operator が追加するラベルを説明しています。

Expand
表4.2 Pod 作成時に Multiarch Tuning Operator が追加する Pod ラベル
ラベル説明

multiarch.openshift.io/multi-arch: ""

Pod は複数のアーキテクチャーをサポートします。

multiarch.openshift.io/single-arch: ""

Pod は単一のアーキテクチャーのみサポートします。

multiarch.openshift.io/arm64: ""

Pod は arm64 アーキテクチャーをサポートします。

multiarch.openshift.io/amd64: ""

Pod は amd64 アーキテクチャーをサポートします。

multiarch.openshift.io/ppc64le: ""

Pod は ppc64le アーキテクチャーをサポートします。

multiarch.openshift.io/s390x: ""

Pod は s390x アーキテクチャーをサポートします。

multirach.openshift.io/node-affinity: set

Operator は、アーキテクチャーのノードアフィニティー要件を設定しました。

multirach.openshift.io/node-affinity: not-set

Operator はノードアフィニティー要件を設定しませんでした。たとえば、Pod にすでにアーキテクチャーのノードアフィニティーがある場合、Multiarch Tuning Operator はこのラベルを Pod に追加します。

multiarch.openshift.io/scheduling-gate: gated

Pod にはゲートがあります。

multiarch.openshift.io/scheduling-gate: removed

Pod ゲートが削除されました。

multiarch.openshift.io/inspection-error: ""

ノードアフィニティー要件のビルド時にエラーが発生しました。

multiarch.openshift.io/preferred-node-affinity: set

Operator が Pod のアーキテクチャー優先設定を指定しました。

multiarch.openshift.io/preferred-node-affinity: not-set

ユーザーがすでに preferredDuringSchedulingIgnoredDuringExecution ノードアフィニティーでアーキテクチャー優先設定を指定していたため、Operator が Pod でアーキテクチャー優先設定を指定しませんでした。

4.11.4. ClusterPodPlacementConfig オブジェクトの作成
リンクのコピー

Multiarch Tuning Operator をインストールしたら、ClusterPodPlacementConfig オブジェクトを作成する必要があります。このオブジェクトを作成すると、Multiarch Tuning Operator が、アーキテクチャーを考慮したワークロードスケジューリングを可能にするオペランドをデプロイします。

注記

ClusterPodPlacementConfig オブジェクトのインスタンスは 1 つだけ作成できます。

ClusterPodPlacementConfig オブジェクトの設定例

apiVersion: multiarch.openshift.io/v1beta1
kind: ClusterPodPlacementConfig
metadata:
  name: cluster
1 

spec:
  logVerbosityLevel: Normal
2 

  namespaceSelector:
3 

    matchExpressions:
      - key: multiarch.openshift.io/exclude-pod-placement
        operator: DoesNotExist
  plugins:
4 

    nodeAffinityScoring:
5 

      enabled: true
6 

      platforms:
7 

        - architecture: amd64
8 

          weight: 100
9 

        - architecture: arm64
          weight: 50
Copy to Clipboard Toggle word wrap

1
このフィールドの値を cluster に設定する必要があります。
2
オプション: フィールドの値を Normal、Debug、Trace、または TraceAll に設定できます。デフォルトでは、値は Normal に設定されています。
3
オプション: namespaceSelector を設定すると、Multiarch Tuning Operator の Pod 配置オペランドによって Pod の nodeAffinity を処理する必要がある namespace を選択できます。デフォルトではすべての namespace が考慮されます。
4
オプション: アーキテクチャーを考慮したワークロードスケジューリング用のプラグインのリストを含めます。
5
オプション: このプラグインを使用すると、Pod 配置用のアーキテクチャー優先設定を指定できます。有効にすると、スケジューラーによって、まず Pod の要件を満たさないノードが除外されます。次に、nodeAffinityScoring.platforms フィールドで定義されたアーキテクチャースコアに基づいて、残りのノードに優先順位が付けられます。
6
オプション: nodeAffinityScoring プラグインを有効にするには、このフィールドを true に設定します。デフォルト値は false です。
7
オプション: アーキテクチャーとそれに対応するスコアのリストを定義します。
8
スコアを割り当てるノードアーキテクチャーを指定します。スケジューラーは、設定したアーキテクチャースコアと Pod 仕様で定義されたスケジューリング要件に基づいて、Pod を配置するノードを優先順位付けします。許可される値は、arm64、amd64、ppc64le、または s390x です。
9
アーキテクチャーにスコアを割り当てます。このフィールドの値は、1 (最低優先度) から 100 (最高優先度) の範囲で設定する必要があります。スケジューラーは、このスコアを使用して Pod を配置するノードを優先順位付けし、スコアが高いアーキテクチャーのノードを優先します。

この例では、operator フィールドの値が DoesNotExist に設定されています。したがって、key フィールドの値 (multiarch.openshift.io/exclude-pod-placement) が namespace のラベルとして設定されている場合、オペランドはその namespace 内の Pod の nodeAffinity を処理しません。代わりに、オペランドはこのラベルを含まない namespace 内の Pod の nodeAffinity を処理します。

オペランドで特定の namespace 内の Pod の nodeAffinity のみを処理する場合は、次のように namespaceSelector を設定できます。 

namespaceSelector:
  matchExpressions:
    - key: multiarch.openshift.io/include-pod-placement
      operator: Exists
Copy to Clipboard Toggle word wrap

この例では、operator フィールドの値が Exists に設定されています。したがって、オペランドは、multiarch.openshift.io/include-pod-placement ラベルを含む namespace 内の Pod の nodeAffinity のみを処理します。

重要

この Operator は、kube- で始まる namespace 内の Pod を除外します。また、コントロールプレーンノードでスケジュールされることが予想される Pod も除外されます。

4.11.4.1. CLI を使用した ClusterPodPlacementConfig オブジェクトの作成
リンクのコピー

アーキテクチャーを考慮したワークロードのスケジューリングを可能にする Pod 配置オペランドをデプロイするには、OpenShift CLI (oc) を使用して ClusterPodPlacementConfig オブジェクトを作成します。

前提条件

  • oc がインストールされている。
  • cluster-admin 権限を持つユーザーとして oc にログインしている。
  • Multiarch Tuning Operator がインストールされている。

手順

  1. ClusterPodPlacementConfig オブジェクトの YAML ファイルを作成します。

    ClusterPodPlacementConfig オブジェクトの設定例

    apiVersion: multiarch.openshift.io/v1beta1
kind: ClusterPodPlacementConfig
metadata:
  name: cluster
spec:
  logVerbosityLevel: Normal
  namespaceSelector:
    matchExpressions:
      - key: multiarch.openshift.io/exclude-pod-placement
        operator: DoesNotExist
  plugins:
    nodeAffinityScoring:
      enabled: true
      platforms:
        - architecture: amd64
          weight: 100
        - architecture: arm64
          weight: 50
    Copy to Clipboard Toggle word wrap

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

    $ oc create -f <file_name>
    1
    Copy to Clipboard Toggle word wrap
    1
    <file_name> は、ClusterPodPlacementConfig オブジェクトの YAML ファイルの名前に置き換えます。

検証

  • ClusterPodPlacementConfig オブジェクトが作成されたことを確認するには、次のコマンドを実行します。 

    $ oc get clusterpodplacementconfig
    Copy to Clipboard Toggle word wrap

    出力例

    NAME      AGE
cluster   29s
    Copy to Clipboard Toggle word wrap

4.11.4.2. Web コンソールを使用した ClusterPodPlacementConfig オブジェクトの作成
リンクのコピー

アーキテクチャーを考慮したワークロードのスケジューリングを可能にする Pod 配置オペランドをデプロイするには、OpenShift Container Platform Web コンソールを使用して ClusterPodPlacementConfig オブジェクトを作成します。

前提条件

  • cluster-admin 権限でクラスターにアクセスできる。
  • OpenShift Container Platform Web コンソールにアクセスできる。
  • Multiarch Tuning Operator がインストールされている。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. Operators → Installed Operators に移動します。
  3. Installed Operators ページで、Multiarch Tuning Operator をクリックします。
  4. Cluster Pod Placement Config タブをクリックします。
  5. Form view または YAML view のいずれかを選択します。
  6. ClusterPodPlacementConfig オブジェクトのパラメーターを設定します。
  7. Create をクリックします。

  8. オプション: ClusterPodPlacementConfig オブジェクトを編集する場合は、次の操作を実行します。

    1. Cluster Pod Placement Config タブをクリックします。
    2. オプションメニューから Edit ClusterPodPlacementConfig を選択します。
    3. YAML をクリックし、ClusterPodPlacementConfig オブジェクトのパラメーターを編集します。
    4. Save をクリックします。

検証

  • Cluster Pod Placement Config ページで、ClusterPodPlacementConfig オブジェクトが Ready 状態であることを確認します。

4.11.5. CLI を使用した ClusterPodPlacementConfig オブジェクトの削除
リンクのコピー

ClusterPodPlacementConfig オブジェクトのインスタンスは 1 つだけ作成できます。このオブジェクトを再作成する場合は、まず既存のインスタンスを削除する必要があります。

OpenShift CLI (oc) を使用してこのオブジェクトを削除できます。

前提条件

  • oc がインストールされている。
  • cluster-admin 権限を持つユーザーとして oc にログインしている。

手順

  1. OpenShift CLI (oc) にログインします。

  2. 次のコマンドを実行して ClusterPodPlacementConfig オブジェクトを削除します。 

    $ oc delete clusterpodplacementconfig cluster
    Copy to Clipboard Toggle word wrap

検証

  • ClusterPodPlacementConfig オブジェクトが削除されたことを確認するには、次のコマンドを実行します。 

    $ oc get clusterpodplacementconfig
    Copy to Clipboard Toggle word wrap

    出力例

    No resources found
    Copy to Clipboard Toggle word wrap

4.11.6. Web コンソールを使用した ClusterPodPlacementConfig オブジェクトの削除
リンクのコピー

ClusterPodPlacementConfig オブジェクトのインスタンスは 1 つだけ作成できます。このオブジェクトを再作成する場合は、まず既存のインスタンスを削除する必要があります。

OpenShift Container Platform Web コンソールを使用してこのオブジェクトを削除できます。

前提条件

  • cluster-admin 権限でクラスターにアクセスできる。
  • OpenShift Container Platform Web コンソールにアクセスできる。
  • ClusterPodPlacementConfig オブジェクトを作成した。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. Operators → Installed Operators に移動します。
  3. Installed Operators ページで、Multiarch Tuning Operator をクリックします。
  4. Cluster Pod Placement Config タブをクリックします。
  5. オプションメニューから Delete ClusterPodPlacementConfig を選択します。
  6. Delete をクリックします。

検証

  • Cluster Pod Placement Config ページで、ClusterPodPlacementConfig オブジェクトが削除されていることを確認します。

4.11.7. CLI を使用した Multiarch Tuning Operator のアンインストール
リンクのコピー

OpenShift CLI (oc) を使用して、Multiarch Tuning Operator をアンインストールできます。

前提条件

  • oc がインストールされている。
  • cluster-admin 権限を持つユーザーとして oc にログインしている。

  • ClusterPodPlacementConfig オブジェクトを削除した。

    重要

    Multiarch Tuning Operator をアンインストールする前に、ClusterPodPlacementConfig オブジェクトを削除する必要があります。ClusterPodPlacementConfig オブジェクトを削除せずに Operator をアンインストールすると、予期しない動作が発生する可能性があります。

手順

  1. 次のコマンドを実行して、Multiarch Tuning Operator の Subscription オブジェクト名を取得します。 

    $ oc get subscription.operators.coreos.com -n <namespace>
    1
    Copy to Clipboard Toggle word wrap
    1
    <namespace> は、Multiarch Tuning Operator をアンインストールする namespace の名前に置き換えます。

    出力例

    NAME                                  PACKAGE                     SOURCE             CHANNEL
openshift-multiarch-tuning-operator   multiarch-tuning-operator   redhat-operators   stable
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、Multiarch Tuning Operator の currentCSV 値を取得します。 

    $ oc get subscription.operators.coreos.com <subscription_name> -n <namespace> -o yaml | grep currentCSV
    1
    Copy to Clipboard Toggle word wrap
    1
    <subscription_name> を Subscription オブジェクト名に置き換えます。たとえば、openshift-multiarch-tuning-operator です。<namespace> は、Multiarch Tuning Operator をアンインストールする namespace の名前に置き換えます。

    出力例

    currentCSV: multiarch-tuning-operator.<version>
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、Subscription オブジェクトを削除します。 

    $ oc delete subscription.operators.coreos.com <subscription_name> -n <namespace>
    1
    Copy to Clipboard Toggle word wrap
    1
    <subscription_name> を Subscription オブジェクト名に置き換えます。<namespace> は、Multiarch Tuning Operator をアンインストールする namespace の名前に置き換えます。

    出力例

    subscription.operators.coreos.com "openshift-multiarch-tuning-operator" deleted
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、currentCSV 値を使用してターゲット namespace 内の Multiarch Tuning Operator の CSV を削除します。 

    $ oc delete clusterserviceversion <currentCSV_value> -n <namespace>
    1
    Copy to Clipboard Toggle word wrap
    1
    <currentCSV> は、Multiarch Tuning Operator の currentCSV 値に置き換えます。たとえば、multiarch-tuning-operator.<version> です。<namespace> は、Multiarch Tuning Operator をアンインストールする namespace の名前に置き換えます。

    出力例

    clusterserviceversion.operators.coreos.com "multiarch-tuning-operator.<version>" deleted
    Copy to Clipboard Toggle word wrap

検証

  • Multiarch Tuning Operator がアンインストールされたことを確認するには、次のコマンドを実行します。 

    $ oc get csv -n <namespace>
    1
    Copy to Clipboard Toggle word wrap
    1
    <namespace> は、Multiarch Tuning Operator をアンインストールした namespace の名前に置き換えます。

    出力例

    No resources found in openshift-multiarch-tuning-operator namespace.
    Copy to Clipboard Toggle word wrap

4.11.8. Web コンソールを使用した Multiarch Tuning Operator のアンインストール
リンクのコピー

OpenShift Container Platform Web コンソールを使用して、Multiarch Tuning Operator をアンインストールできます。

前提条件

  • cluster-admin 権限でクラスターにアクセスできます。

  • ClusterPodPlacementConfig オブジェクトを削除した。

    重要

    Multiarch Tuning Operator をアンインストールする前に、ClusterPodPlacementConfig オブジェクトを削除する必要があります。ClusterPodPlacementConfig オブジェクトを削除せずに Operator をアンインストールすると、予期しない動作が発生する可能性があります。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. Operators → OperatorHub に移動します。
  3. 検索フィールドに Multiarch Tuning Operator と入力します。
  4. Multiarch Tuning Operator をクリックします。
  5. Details タブをクリックします。
  6. Actions メニューから、Uninstall Operator を選択します。
  7. プロンプトが表示されたら、Uninstall をクリックします。

検証

  1. Operators → Installed Operators に移動します。
  2. Installed Operator ページで、Multiarch Tuning Operator がリストされていないことを確認します。

4.12. Multiarch Tuning Operator のリリースノート
リンクのコピー

Multiarch Tuning Operator は、マルチアーキテクチャークラスター内およびマルチアーキテクチャー環境に移行するシングルアーキテクチャークラスター内のワークロード管理を最適化します。

これらのリリースノートでは、Multiarch Tuning Operator の開発を追跡します。

詳細は、Multiarch Tuning Operator を使用してマルチアーキテクチャークラスター上のワークロードを管理する を参照してください。

4.12.1. Multiarch Tuning Operator 1.1.1 のリリースノート
リンクのコピー

発行日: 2025 年 5 月 27 日

4.12.1.1. バグ修正
リンクのコピー

  • 以前は、Pod 配置オペランドが、プルシークレットのホスト名にワイルドカードエントリーを使用してレジストリーを認証することをサポートしていませんでした。そのため、イメージをプルするときの Kubelet の動作に一貫性がありませんでした。Kubelet はワイルドカードエントリーをサポートしていましたが、オペランドにはホスト名の正確なマッチが必要であったためです。その結果、レジストリーがワイルドカードホスト名を使用する場合にイメージのプルが予期せず失敗する可能性がありました。

    このリリースでは、Pod 配置オペランドはワイルドカードホスト名を含むプルシークレットをサポートしています。これにより、イメージ認証とプルの一貫性と信頼性が確保されます。

  • 以前は、すべての再試行の実行後にイメージ検査が失敗し、nodeAffinityScoring プラグインが有効である場合、Pod 配置オペランドによって誤った nodeAffinityScoring ラベルが適用されていました。

    このリリースでは、イメージ検査が失敗した場合でも、オペランドは nodeAffinityScoring ラベルを正しく設定します。このラベルは、スケジュールの正確性と一貫性を確保するために、必要なアフィニティープロセスとは別に適用されます。

4.12.2. Multiarch Tuning Operator 1.1.0 のリリースノート
リンクのコピー

発行日: 2025 年 3 月 18 日

4.12.2.1. 新機能および機能拡張
リンクのコピー
  • Multiarch Tuning Operator は、ROSA with Hosted Control Plane (HCP) やその他の HCP 環境など、マネージドサービスでサポートされるようになりました。
  • このリリースでは、ClusterPodPlacementConfig オブジェクトの新しい plugins フィールドを使用して、アーキテクチャーを考慮したワークロードスケジューリングを設定できます。plugins.nodeAffinityScoring フィールドを使用して、Pod 配置用のアーキテクチャー優先設定を指定できます。nodeAffinityScoring プラグインを有効にすると、スケジューラーによって、まず Pod の要件を満たさないノードが除外されます。次に、nodeAffinityScoring.platforms フィールドで定義されたアーキテクチャースコアに基づいて、残りのノードに優先順位が付けられます。
4.12.2.2. バグ修正
リンクのコピー
  • このリリースでは、Multiarch Tuning Operator は、デーモンセットによって管理される Pod の nodeAffinity フィールドを更新しません。(OCPBUGS-45885)

4.12.3. Multiarch Tuning Operator 1.0.0 のリリースノート
リンクのコピー

発行日: 2024 年 10 月 31 日

4.12.3.1. 新機能および機能拡張
リンクのコピー
  • このリリースでは、Multiarch Tuning Operator はカスタムネットワークシナリオとクラスター全体のカスタムレジストリー設定をサポートします。
  • このリリースでは、Multiarch Tuning Operator が新しく作成された Pod に追加する Pod ラベルを使用して、アーキテクチャーの互換性に基づき Pod を識別できます。
  • このリリースでは、Cluster Monitoring Operator に登録されているメトリクスとアラートを使用して、Multiarch Tuning Operator の動作を監視できます。

第5章 インストール後のクラスタータスク
リンクのコピー

OpenShift Container Platform のインストール後に、クラスターをさらに拡張し、要件に合わせてカスタマイズできます。

5.1. 利用可能なクラスターのカスタマイズ
リンクのコピー

OpenShift Container Platform クラスターのデプロイ後は、大半のクラスター設定およびカスタマイズが終了していることになります。数多くの 設定リソース が利用可能です。

注記

クラスターを IBM Z® にインストールする場合は、すべての特長および機能が利用可能である訳ではありません。

イメージレジストリー、ネットワーク設定、イメージビルドの動作およびアイデンティティープロバイダーなどのクラスターの主要な機能を設定するために設定リソースを変更します。

これらのリソースを使用して制御する設定の現在の記述は、oc explain コマンドを使用します (例: oc explain builds --api-version=config.openshift.io/v1)。

5.1.1. クラスター設定リソース
リンクのコピー

すべてのクラスター設定リソースは、グローバルスコープであり (namespace に属さない)、cluster という名前が付けられます。

Expand
リソース名説明

apiserver.config.openshift.io

証明書および認証局 などの API サーバー設定を提供します。

authentication.config.openshift.io

クラスターの アイデンティティープロバイダー および認証設定を制御します。

build.config.openshift.io

クラスター上のすべてのビルドの、デフォルトおよび強制された 設定 を制御します。

console.config.openshift.io

ログアウト動作 を含む Web コンソールインターフェイスの動作を設定します。

featuregate.config.openshift.io

FeatureGates を有効にして、テクノロジープレビュー機能を使用できるようにします。

image.config.openshift.io

特定の イメージレジストリー が処理される方法を設定します (allowed、disallowed、insecure、CA の詳細)。

ingress.config.openshift.io

ルートのデフォルトドメインなどの ルーティング に関連する設定の詳細。

oauth.config.openshift.io

内部 OAuth サーバー フローに関連するアイデンティティープロバイダーと他の動作を設定します。

project.config.openshift.io

プロジェクトテンプレートを含む プロジェクトの作成方法 を設定します。

proxy.config.openshift.io

外部ネットワークアクセスを必要とするコンポーネントで使用されるプロキシーを定義します。注: すべてのコンポーネントがこの値を使用する訳ではありません。

scheduler.config.openshift.io

プロファイルやデフォルトのノードセレクターなどの スケジューラー の動作を設定します。

5.1.2. Operator 設定リソース
リンクのコピー

これらの設定リソースは、cluster という名前のクラスタースコープのインスタンスです。これは、特定の Operator によって所有される特定コンポーネントの動作を制御します。

Expand
リソース名説明

consoles.operator.openshift.io

ブランドのカスタマイズなどのコンソールの外観の制御

config.imageregistry.operator.openshift.io

パブリックルーティング、ログレベル、プロキシー設定、リソース制約、レプリカ数、ストレージタイプなどの OpenShift イメージレジストリー設定 を設定します。

config.samples.operator.openshift.io

Samples Operator を設定して、クラスターにインストールされるイメージストリームとテンプレートのサンプルを制御します。

5.1.3. 追加の設定リソース
リンクのコピー

これらの設定リソースは、特定コンポーネントの単一インスタンスを表します。場合によっては、リソースの複数のインスタンスを作成して、複数のインスタンスを要求できます。他の場合には、Operator は特定の namespace の特定のリソースインスタンス名のみを使用できます。追加のリソースインスタンスの作成方法や作成するタイミングの詳細は、コンポーネント固有のドキュメントを参照してください。

Expand
リソース名インスタンス名Namespace説明

alertmanager.monitoring.coreos.com

main

openshift-monitoring

Alertmanager のデプロイメントパラメーターを制御します。

ingresscontroller.operator.openshift.io

default

openshift-ingress-operator

ドメイン、レプリカ数、証明書、およびコントローラーの配置など、Ingress Operator の動作を設定します。

5.1.4. 情報リソース
リンクのコピー

これらのリソースを使用して、クラスターに関する情報を取得します。設定によっては、これらのリソースの直接編集が必要になる場合があります。

Expand
リソース名インスタンス名説明

clusterversion.config.openshift.io

version

OpenShift Container Platform 4.16 では、実稼働クラスターの ClusterVersion リソースをカスタマイズすることはできません。代わりに、クラスターを更新する ためのプロセスを実行します。

dns.config.openshift.io

cluster

クラスターの DNS 設定を変更することはできません。DNS Operator のステータスを確認 できます。

infrastructure.config.openshift.io

cluster

クラスターはそのクラウドプロバイダーとの対話を可能にする設定の詳細。

network.config.openshift.io

cluster

インストール後にクラスターのネットワークを変更することはできません。ネットワークをカスタマイズするには、インストール時にネットワークをカスタマイズする プロセスを実行します。

5.2. ワーカーノードの追加
リンクのコピー

OpenShift Container Platform クラスターをデプロイしたら、ワーカーノードを追加してクラスターリソースをスケーリングできます。インストール方法とクラスターの環境に応じて、ワーカーノードを追加するさまざまな方法があります。

5.2.1. installer-provisioned infrastructure へのワーカーノードの追加
リンクのコピー

installer-provisioned infrastructure クラスターの場合、MachineSet オブジェクトを手動または自動でスケーリングして、利用可能なベアメタルホストの数に一致させることができます。

ベアメタルホストを追加するには、すべてのネットワーク前提条件を設定し、関連する baremetalhost オブジェクトを設定してから、クラスターにワーカーノードをプロビジョニングする必要があります。手動で、または Web コンソールを使用して、ベアメタルホストを追加できます。

5.2.2. user-provisioned infrastructure クラスターへのワーカーノードの追加
リンクのコピー

user-provisioned infrastructure クラスターの場合、RHEL または RHCOS ISO イメージを使用し、クラスター Ignition 設定ファイルを使用してこれをクラスターに接続することで、ワーカーノードを追加できます。RHEL ワーカーノードの場合、次の例では、Ansible Playbook を使用してクラスターにワーカーノードを追加します。RHCOS ワーカーノードの場合、次の例では、ISO イメージとネットワークブートを使用してワーカーノードをクラスターに追加します。

5.2.3. Assisted Installer によって管理されるクラスターへのワーカーノードの追加
リンクのコピー

Assisted Installer によって管理されるクラスターの場合、Red Hat OpenShift Cluster Manager コンソール、Assisted Installer REST API を使用してワーカーノードを追加するか、ISO イメージとクラスター Ignition 設定ファイルを使用してワーカーノードを手動で追加することができます。

Kubernetes のマルチクラスターエンジンによって管理されるクラスターの場合、専用のマルチクラスターエンジンコンソールを使用してワーカーノードを追加することができます。

5.3. ワーカーノードの調整
リンクのコピー

デプロイメント時にワーカーノードのサイズを誤って設定した場合には、1 つ以上の新規コンピュートマシンセットを作成してそれらをスケールアップしてから、元のコンピュートマシンセットを削除する前にスケールダウンしてこれらのワーカーノードを調整します。

5.3.1. コンピュートマシンセットとマシン設定プールの相違点について
リンクのコピー

MachineSet オブジェクトは、クラウドまたはマシンプロバイダーに関する OpenShift Container Platform ノードを記述します。

MachineConfigPool オブジェクトにより、MachineConfigController コンポーネントがアップグレードのコンテキストでマシンのステータスを定義し、提供できるようになります。

MachineConfigPool オブジェクトにより、ユーザーはマシン設定プールの OpenShift Container Platform ノードにアップグレードをデプロイメントする方法を設定できます。

NodeSelector オブジェクトは MachineSet オブジェクトへの参照に置き換えることができます。

5.3.2. コンピュートマシンセットの手動スケーリング
リンクのコピー

コンピュートマシンセットのマシンのインスタンスを追加したり、削除したりする必要がある場合、コンピュートマシンセットを手動でスケーリングできます。

このガイダンスは、完全に自動化された installer-provisioned infrastructure のインストールに関連します。user-provisioned infrastructure のカスタマイズされたインストールにはコンピュートマシンセットがありません。

前提条件

  • OpenShift Container Platform クラスターおよび oc コマンドラインをインストールすること。
  • cluster-admin パーミッションを持つユーザーとして、oc にログインする。

手順

  1. 次のコマンドを実行して、クラスター内のコンピュートマシンセットを表示します。 

    $ oc get machinesets.machine.openshift.io -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

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

  2. 次のコマンドを実行して、クラスター内のコンピュートマシンを表示します。 

    $ oc get machines.machine.openshift.io -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、削除するコンピュートマシンに注釈を設定します。 

    $ oc annotate machines.machine.openshift.io/<machine_name> -n openshift-machine-api machine.openshift.io/delete-machine="true"
    Copy to Clipboard Toggle word wrap

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

    $ oc scale --replicas=2 machinesets.machine.openshift.io <machineset> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

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

    $ oc edit machinesets.machine.openshift.io <machineset> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap
    ヒント

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

    apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  replicas: 2
    Copy to Clipboard Toggle word wrap

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

    重要

    デフォルトでは、マシンコントローラーは、成功するまでマシンによってサポートされるノードを drain しようとします。場合によっては、drain 操作が成功しない可能性があります。たとえば、Pod Disruption Budget が間違っている場合などです。drain 操作が失敗した場合、マシンコントローラーはマシンの削除を続行できません。

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

検証

  • 次のコマンドを実行して、目的のマシンが削除されたことを確認します。 

    $ oc get machines.machine.openshift.io
    Copy to Clipboard Toggle word wrap

5.3.3. コンピュートマシンセットの削除ポリシー
リンクのコピー

Random、Newest、および Oldest は 3 つのサポートされる削除オプションです。デフォルトは Random です。これは、コンピュートマシンセットのスケールダウン時にランダムなマシンが選択され、削除されることを意味します。削除ポリシーは、特定のコンピュートマシンセットを変更し、ユースケースに基づいて設定できます。 

spec:
  deletePolicy: <delete_policy>
  replicas: <desired_replica_count>
Copy to Clipboard Toggle word wrap

削除に関する特定のマシンの優先順位は、削除ポリシーに関係なく、関連するマシンにアノテーション machine.openshift.io/delete-machine=true を追加して設定できます。

重要

デフォルトで、OpenShift Container Platform ルーター Pod はワーカーにデプロイされます。ルーターは Web コンソールなどの一部のクラスターリソースにアクセスすることが必要であるため、ルーター Pod をまず再配置しない限り、ワーカーのコンピュートマシンセットを 0 にスケーリングできません。

注記

カスタムのコンピュートマシンセットは、サービスを特定のノードサービスで実行し、それらのサービスがワーカーのコンピュートマシンセットのスケールダウン時にコントローラーによって無視されるようにする必要があるユースケースで使用できます。これにより、サービスの中断が回避されます。

5.3.4. クラスタースコープのデフォルトノードセレクターの作成
リンクのコピー

クラスター内の作成されたすべての Pod を特定のノードに制限するために、デフォルトのクラスタースコープのノードセレクターをノード上のラベルと共に Pod で使用することができます。

クラスタースコープのノードセレクターを使用する場合、クラスターで Pod を作成すると、OpenShift Container Platform はデフォルトのノードセレクターを Pod に追加し、一致するラベルのあるノードで Pod をスケジュールします。

スケジューラー Operator カスタムリソース (CR) を編集して、クラスタースコープのノードセレクターを設定します。ラベルをノード、コンピュートマシンセット、またはマシン設定に追加します。コンピュートマシンセットにラベルを追加すると、ノードまたはマシンが停止した場合に、新規ノードにそのラベルが追加されます。ノードまたはマシン設定に追加されるラベルは、ノードまたはマシンが停止すると維持されません。

注記

Pod にキーと値のペアを追加できます。ただし、デフォルトキーの異なる値を追加することはできません。

手順

デフォルトのクラスタースコープのセレクターを追加するには、以下を実行します。

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

    $ oc edit scheduler cluster
    Copy to Clipboard Toggle word wrap

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

    apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  name: cluster
...
spec:
  defaultNodeSelector: type=user-node,region=east
    1 
    
  mastersSchedulable: false
    Copy to Clipboard Toggle word wrap

    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
        Copy to Clipboard Toggle word wrap
        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
        Copy to Clipboard Toggle word wrap
        ヒント

        あるいは、以下の 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"
        Copy to Clipboard Toggle word wrap

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

        以下に例を示します。 

        $ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api
        Copy to Clipboard Toggle word wrap

        MachineSet オブジェクトの例

        apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
  ...
spec:
  ...
  template:
    metadata:
  ...
    spec:
      metadata:
        labels:
          region: east
          type: user-node
  ...
        Copy to Clipboard Toggle word wrap

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

        以下に例を示します。 

        $ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api
        Copy to Clipboard Toggle word wrap 
        $ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api
        Copy to Clipboard Toggle word wrap

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

        $ oc get nodes -l <key>=<value>
        Copy to Clipboard Toggle word wrap

        以下に例を示します。 

        $ oc get nodes -l type=user-node
        Copy to Clipboard Toggle word wrap

        出力例

        NAME                                       STATUS   ROLES    AGE   VERSION
ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.29.4
        Copy to Clipboard Toggle word wrap

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

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

        $ oc label nodes <name> <key>=<value>
        Copy to Clipboard Toggle word wrap

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

        $ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 type=user-node region=east
        Copy to Clipboard Toggle word wrap
        ヒント

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

        kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    type: "user-node"
    region: "east"
        Copy to Clipboard Toggle word wrap

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

        $ oc get nodes -l <key>=<value>,<key>=<value>
        Copy to Clipboard Toggle word wrap

        以下に例を示します。 

        $ oc get nodes -l type=user-node,region=east
        Copy to Clipboard Toggle word wrap

        出力例

        NAME                                       STATUS   ROLES    AGE   VERSION
ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.29.4
        Copy to Clipboard Toggle word wrap

クラスター管理者が遅延テストを実行してプラットフォームを検証した際に、遅延が大きい場合でも安定性を確保するために、クラスターの動作を調整する必要性が判明することがあります。クラスター管理者が変更する必要があるのは、ファイルに記録されている 1 つのパラメーターだけです。このパラメーターは、監視プロセスがステータスを読み取り、クラスターの健全性を解釈する方法に影響を与える 4 つのパラメーターを制御するものです。1 つのパラメーターのみを変更し、サポートしやすく簡単な方法でクラスターをチューニングできます。

Kubelet プロセスは、クラスターの健全性を監視する上での出発点です。Kubelet は、OpenShift Container Platform クラスター内のすべてのノードのステータス値を設定します。Kubernetes コントローラーマネージャー (kube controller) は、デフォルトで 10 秒ごとにステータス値を読み取ります。ノードのステータス値を読み取ることができない場合、設定期間が経過すると、kube controller とそのノードとの接続が失われます。デフォルトの動作は次のとおりです。

  1. コントロールプレーン上のノードコントローラーが、ノードの健全性を Unhealthy に更新し、ノードの Ready 状態を `Unknown` とマークします。
  2. この操作に応じて、スケジューラーはそのノードへの Pod のスケジューリングを停止します。
  3. ノードライフサイクルコントローラーが、NoExecute effect を持つ node.kubernetes.io/unreachable taint をノードに追加し、デフォルトでノード上のすべての Pod を 5 分後に退避するようにスケジュールします。

この動作は、ネットワークが遅延の問題を起こしやすい場合、特にネットワークエッジにノードがある場合に問題が発生する可能性があります。場合によっては、ネットワークの遅延が原因で、Kubernetes コントローラーマネージャーが正常なノードから更新を受信できないことがあります。Kubelet は、ノードが正常であっても、ノードから Pod を削除します。

この問題を回避するには、ワーカーレイテンシープロファイル を使用して、Kubelet と Kubernetes コントローラーマネージャーがアクションを実行する前にステータスの更新を待機する頻度を調整できます。これらの調整により、コントロールプレーンとワーカーノード間のネットワーク遅延が最適でない場合に、クラスターが適切に動作するようになります。

これらのワーカーレイテンシープロファイルには、3 つのパラメーターセットが含まれています。パラメーターは、遅延の増加に対するクラスターの反応を制御するように、慎重に調整された値で事前定義されています。試験により手作業で最良の値を見つける必要はありません。

クラスターのインストール時、またはクラスターネットワークのレイテンシーの増加に気付いたときはいつでも、ワーカーレイテンシープロファイルを設定できます。

5.4.1. ワーカーレイテンシープロファイルについて
リンクのコピー

ワーカーレイテンシープロファイルは、4 つの異なるカテゴリーからなる慎重に調整されたパラメーターです。これらの値を実装する 4 つのパラメーターは、node-status-update-frequency、node-monitor-grace-period、default-not-ready-toleration-seconds、および default-unreachable-toleration-seconds です。これらのパラメーターにより、遅延の問題に対するクラスターの反応を制御できる値を使用できます。手作業で最適な値を決定する必要はありません。

重要

これらのパラメーターの手動設定はサポートされていません。パラメーター設定が正しくないと、クラスターの安定性に悪影響が及びます。

すべてのワーカーレイテンシープロファイルは、次のパラメーターを設定します。

node-status-update-frequency
kubelet がノードのステータスを API サーバーにポストする頻度を指定します。
node-monitor-grace-period
Kubernetes コントローラーマネージャーが、ノードを異常とマークし、node.kubernetes.io/not-ready または node.kubernetes.io/unreachable taint をノードに追加する前に、kubelet からの更新を待機する時間を秒単位で指定します。
default-not-ready-toleration-seconds
ノードを異常とマークした後、Kube API Server Operator がそのノードから Pod を削除するまでに待機する時間を秒単位で指定します。
default-unreachable-toleration-seconds
ノードを到達不能とマークした後、Kube API Server Operator がそのノードから Pod を削除するまでに待機する時間を秒単位で指定します。

次の Operator は、ワーカーレイテンシープロファイルの変更を監視し、それに応じて対応します。

  • Machine Config Operator (MCO) は、ワーカーノードの node-status-update-frequency パラメーターを更新します。
  • Kubernetes コントローラーマネージャーは、コントロールプレーンノードの node-monitor-grace-period パラメーターを更新します。
  • Kubernetes API Server Operator は、コントロールプレーンノードの default-not-ready-toleration-seconds および default-unreachable-toleration-seconds パラメーターを更新します。

ほとんどの場合はデフォルト設定が機能しますが、OpenShift Container Platform は、ネットワークで通常よりも高いレイテンシーが発生している状況に対して、他に 2 つのワーカーレイテンシープロファイルを提供します。次のセクションでは、3 つのワーカーレイテンシープロファイルを説明します。

デフォルトのワーカーレイテンシープロファイル

Default プロファイルを使用すると、各 Kubelet が 10 秒ごとにステータスを更新します (node-status-update-frequency)。Kube Controller Manager は、5 秒ごとに Kubelet のステータスをチェックします。

Kubernetes Controller Manager は、Kubelet からのステータス更新を 40 秒 (node-monitor-grace-period) 待機した後、Kubelet が正常ではないと判断します。ステータスが提供されない場合、Kubernetes コントローラーマネージャーは、ノードに node.kubernetes.io/not-ready または node.kubernetes.io/unreachable taint のマークを付け、そのノードの Pod を削除します。

Pod が NoExecute taint を持つノード上にある場合、Pod は tolerationSeconds に従って実行されます。ノードに taint がない場合、そのノードは 300 秒以内に削除されます (Kube API Server の default-not-ready-toleration-seconds および default-unreachable-toleration-seconds 設定)。

Expand
プロファイルコンポーネントパラメーター値

デフォルト

kubelet

node-status-update-frequency

10s

Kubelet コントローラーマネージャー

node-monitor-grace-period

40s

Kubernetes API Server Operator

default-not-ready-toleration-seconds

300s

Kubernetes API Server Operator

default-unreachable-toleration-seconds

300s

中規模のワーカーレイテンシープロファイル

ネットワークレイテンシーが通常よりもわずかに高い場合は、MediumUpdateAverageReaction プロファイルを使用します。

MediumUpdateAverageReaction プロファイルは、kubelet の更新の頻度を 20 秒に減らし、Kubernetes コントローラーマネージャーがそれらの更新を待機する期間を 2 分に変更します。そのノード上の Pod の Pod 排除期間は 60 秒に短縮されます。Pod に tolerationSeconds パラメーターがある場合、エビクションはそのパラメーターで指定された期間待機します。

Kubernetes コントローラーマネージャーは、ノードが異常であると判断するまでに 2 分間待機します。別の 1 分間でエビクションプロセスが開始されます。

Expand
プロファイルコンポーネントパラメーター値

MediumUpdateAverageReaction

kubelet

node-status-update-frequency

20s

Kubelet コントローラーマネージャー

node-monitor-grace-period

2m

Kubernetes API Server Operator

default-not-ready-toleration-seconds

60s

Kubernetes API Server Operator

default-unreachable-toleration-seconds

60s

ワーカーの低レイテンシープロファイル

ネットワーク遅延が非常に高い場合は、LowUpdateSlowReaction プロファイルを使用します。

LowUpdateSlowReaction プロファイルは、kubelet の更新頻度を 1 分に減らし、Kubernetes コントローラーマネージャーがそれらの更新を待機する時間を 5 分に変更します。そのノード上の Pod の Pod 排除期間は 60 秒に短縮されます。Pod に tolerationSeconds パラメーターがある場合、エビクションはそのパラメーターで指定された期間待機します。

Kubernetes コントローラーマネージャーは、ノードが異常であると判断するまでに 5 分間待機します。別の 1 分間でエビクションプロセスが開始されます。

Expand
プロファイルコンポーネントパラメーター値

LowUpdateSlowReaction

kubelet

node-status-update-frequency

1m

Kubelet コントローラーマネージャー

node-monitor-grace-period

5m

Kubernetes API Server Operator

default-not-ready-toleration-seconds

60s

Kubernetes API Server Operator

default-unreachable-toleration-seconds

60s

注記

レイテンシープロファイルは、カスタムのマシン設定プールをサポートしていません。デフォルトのワーカーマシン設定プールのみをサポートしていします。

5.4.2. ワーカーレイテンシープロファイルの使用と変更
リンクのコピー

ネットワークの遅延に対処するためにワーカー遅延プロファイルを変更するには、node.config オブジェクトを編集してプロファイルの名前を追加します。遅延が増加または減少したときに、いつでもプロファイルを変更できます。

ワーカーレイテンシープロファイルは、一度に 1 つずつ移行する必要があります。たとえば、Default プロファイルから LowUpdateSlowReaction ワーカーレイテンシープロファイルに直接移行することはできません。まず Default ワーカーレイテンシープロファイルから MediumUpdateAverageReaction プロファイルに移行し、次に LowUpdateSlowReaction プロファイルに移行する必要があります。同様に、Default プロファイルに戻る場合は、まずロープロファイルからミディアムプロファイルに移行し、次に Default に移行する必要があります。

注記

OpenShift Container Platform クラスターのインストール時にワーカーレイテンシープロファイルを設定することもできます。

手順

デフォルトのワーカーレイテンシープロファイルから移動するには、以下を実行します。

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

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

      $ oc edit nodes.config/cluster
      Copy to Clipboard Toggle word wrap

    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 
      

# ...
      Copy to Clipboard Toggle word wrap

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

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

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

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

      $ oc edit nodes.config/cluster
      Copy to Clipboard Toggle word wrap

    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 
      

# ...
      Copy to Clipboard Toggle word wrap

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

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

検証

  • 全ノードが Ready 状態に戻ると、以下のコマンドを使用して Kubernetes Controller Manager を確認し、これが適用されていることを確認できます。 

    $ oc get KubeControllerManager -o yaml | grep -i workerlatency -A 5 -B 5
    Copy to Clipboard Toggle word wrap

    出力例

    # ...
    - lastTransitionTime: "2022-07-11T19:47:10Z"
      reason: ProfileUpdated
      status: "False"
      type: WorkerLatencyProfileProgressing
    - lastTransitionTime: "2022-07-11T19:47:10Z"
    1 
    
      message: all static pod revision(s) have updated latency profile
      reason: ProfileUpdated
      status: "True"
      type: WorkerLatencyProfileComplete
    - lastTransitionTime: "2022-07-11T19:20:11Z"
      reason: AsExpected
      status: "False"
      type: WorkerLatencyProfileDegraded
    - lastTransitionTime: "2022-07-11T19:20:36Z"
      status: "False"
# ...
    Copy to Clipboard Toggle word wrap

    1
    プロファイルが適用され、アクティブであることを指定します。

ミディアムプロファイルからデフォルト、またはデフォルトからミディアムに変更する場合、node.config オブジェクトを編集し、spec.workerLatencyProfile パラメーターを適切な値に設定します。

5.5. コントロールプレーンマシンの管理
リンクのコピー

コントロールプレーンマシンセット は、コンピュートマシンセットがコンピュートマシンに提供するものと同様の管理機能をコントロールプレーンマシンに提供します。クラスター上のコントロールプレーンマシンセットの可用性と初期ステータスは、クラウドプロバイダーと、インストールした OpenShift Container Platform のバージョンによって異なります。詳細は、コントロールプレーンマシンセットの概要 を参照してください。

5.6. 実稼働環境用のインフラストラクチャーマシンセットの作成
リンクのコピー

コンピュートマシンセットを作成して、デフォルトのルーター、統合コンテナーイメージレジストリー、およびクラスターメトリクスおよびモニタリングのコンポーネントなどのインフラストラクチャーコンポーネントのみをホストするマシンを作成できます。これらのインフラストラクチャーマシンは、環境の実行に必要なサブスクリプションの合計数にカウントされません。

インフラストラクチャーノードおよびインフラストラクチャーノードで実行できるコンポーネントの情報は、Creating infrastructure machine setsを参照してください。

インフラストラクチャーノードを作成するには、マシンセットを使用する か ノードにラベルを割り当てる か、マシン設定プールを使用します。

これらの手順で使用できるサンプルマシンセットについては、さまざまなクラウド用のマシンセットの作成 を参照してください。

特定のノードセレクターをすべてのインフラストラクチャーコンポーネントに適用すると、OpenShift Container Platform は そのラベルを持つノードでそれらのワークロードをスケジュール します。

5.6.1. コンピュートマシンセットの作成
リンクのコピー

インストールプログラムによって作成されるコンピュートセットセットに加えて、独自のマシンセットを作成して、選択した特定のワークロードのマシンコンピューティングリソースを動的に管理できます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしている。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin パーミッションを持つユーザーとして、oc にログインする。

手順

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

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

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

    1. クラスター内のコンピュートマシンセットをリスト表示するには、次のコマンドを実行します。 

      $ oc get machinesets -n openshift-machine-api
      Copy to Clipboard Toggle word wrap

      出力例

      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
      Copy to Clipboard Toggle word wrap

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

      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml
      Copy to Clipboard Toggle word wrap

      出力例

      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 
      
        ...
      Copy to Clipboard Toggle word wrap

      1
      クラスターインフラストラクチャー ID。
      2
      デフォルトのノードラベル。
      注記

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

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

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

    $ oc create -f <file_name>.yaml
    Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを実行して、コンピュートマシンセットのリストを表示します。 

    $ oc get machineset -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    出力例

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

    新しいコンピュートマシンセットが利用可能になると、DESIRED と CURRENT の値が一致します。コンピュートマシンセットが使用できない場合は、数分待ってからコマンドを再実行してください。

5.6.2. インフラストラクチャーノードの作成
リンクのコピー

重要

installer-provisioned infrastructure 環境またはコントロールプレーンノードが Machine API によって管理されるクラスターの場合は、「インフラストラクチャーマシンセットの作成」を参照してください。

クラスターの要件によっては、インフラストラクチャー (infra) ノードをプロビジョニングする必要があります。インストールプログラムによってプロビジョニングされるのは、コントロールプレーンとワーカーノードだけです。ワーカーノードは、ラベル付けによってインフラストラクチャーノードとして指定できます。その後、taint と toleration を使用して、適切なワークロードをインフラストラクチャーノードに移動できます。詳細は、「インフラストラクチャーマシンセットへのリソースの移動」を参照してください。

必要に応じて、クラスター全体のデフォルトのノードセレクターを作成できます。デフォルトのノードセレクターは、すべての namespace で作成された Pod に適用され、Pod の既存のノードセレクターと重なります。これにより、Pod のセレクターがさらに制約されます。

重要

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

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

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

手順

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

    $ oc label node <node-name> node-role.kubernetes.io/infra=""
    Copy to Clipboard Toggle word wrap

  2. 該当するノードに infra ロールがあるかどうかを確認します。 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

  3. オプション: クラスター全体のデフォルトのノードセレクターを作成します。

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

      $ oc edit scheduler cluster
      Copy to Clipboard Toggle word wrap

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

      apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  name: cluster
spec:
  defaultNodeSelector: node-role.kubernetes.io/infra=""
      1 
      
# ...
      Copy to Clipboard Toggle word wrap
      1
      この例のノードセレクターは、デフォルトでインフラストラクチャーノードに Pod をデプロイします。
    3. 変更を適用するためにファイルを保存します。

これで、インフラストラクチャーリソースを新しいインフラストラクチャーノードに移動できるようになりました。また、新しいインフラストラクチャーノード上の不要なワークロードやノードに属さないワークロードを削除してください。「OpenShift Container Platform インフラストラクチャーコンポーネント」で、インフラストラクチャーノードでの使用がサポートされているワークロードのリストを参照してください。

5.6.3. インフラストラクチャーマシンのマシン設定プール作成
リンクのコピー

インフラストラクチャーマシンに専用の設定が必要な場合は、infra プールを作成する必要があります。

重要

カスタムマシン設定プールを作成すると、デフォルトのワーカープール設定がオーバーライドされます (デフォルトのワーカープール設定が同じファイルまたはユニットを参照する場合)。

手順

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

    $ oc label node <node_name> <label>
    Copy to Clipboard Toggle word wrap 
    $ oc label node ci-ln-n8mqwr2-f76d1-xscn2-worker-c-6fmtx node-role.kubernetes.io/infra=
    Copy to Clipboard Toggle word wrap

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

    $ cat infra.mcp.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    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
    Copy to Clipboard Toggle word wrap

    1
    ワーカーロールおよびカスタムロールを追加します。
    2
    ノードに追加したラベルを nodeSelector として追加します。
    注記

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

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

    $ oc create -f infra.mcp.yaml
    Copy to Clipboard Toggle word wrap

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

    $ oc get machineconfig
    Copy to Clipboard Toggle word wrap

    出力例

    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
    Copy to Clipboard Toggle word wrap

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

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

    注記

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

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

      $ cat infra.mc.yaml
      Copy to Clipboard Toggle word wrap

      出力例

      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
      Copy to Clipboard Toggle word wrap

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

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

      $ oc create -f infra.mc.yaml
      Copy to Clipboard Toggle word wrap

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

    $ oc get mcp
    Copy to Clipboard Toggle word wrap

    出力例

    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
    Copy to Clipboard Toggle word wrap

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

5.7. マシンセットリソースのインフラストラクチャーノードへの割り当て
リンクのコピー

インフラストラクチャーマシンセットの作成後、worker および infra ロールが新規の infra ノードに適用されます。infra ロールが割り当てられたノードは、worker ロールも適用されている場合でも、環境を実行するために必要なサブスクリプションの合計数にはカウントされません。

ただし、infra ノードに worker ロールが割り当てられている場合は、ユーザーのワークロードが誤って infra ノードに割り当てられる可能性があります。これを回避するには、taint を、制御する必要のある Pod の infra ノードおよび toleration に適用できます。

infra および worker ロールが割り当てられているインフラストラクチャーノードがある場合、ユーザーのワークロードがそのノードに割り当てられないようにノードを設定する必要があります。

重要

インフラストラクチャーノード用に作成した infra,worker ラベルを両方とも保持し、ユーザーのワークロードがスケジュールされるノードを taint および toleration を使用して管理することを推奨します。ノードから worker ラベルを削除する場合には、カスタムプールを作成して管理する必要があります。master または worker 以外のラベルが割り当てられたノードは、カスタムプールなしには MCO で認識されません。worker ラベルを維持すると、カスタムラベルを選択するカスタムプールが存在しない場合に、ノードをデフォルトのワーカーマシン設定プールで管理できます。infra ラベルは、サブスクリプションの合計数にカウントされないクラスターと通信します。

前提条件

  • 追加の MachineSet を OpenShift Container Platform クラスターに設定します。

手順

  1. インフラストラクチャーノードに taint を追加して、そのノードにユーザーのワークロードがスケジュールされないようにします。

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

      $ oc describe nodes <node_name>
      Copy to Clipboard Toggle word wrap

      出力例

      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=reserved:NoSchedule
 ...
      Copy to Clipboard Toggle word wrap

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

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

      $ oc adm taint nodes <node_name> <key>=<value>:<effect>
      Copy to Clipboard Toggle word wrap

      以下に例を示します。 

      $ oc adm taint nodes node1 node-role.kubernetes.io/infra=reserved:NoSchedule
      Copy to Clipboard Toggle word wrap
      ヒント

      または、Pod 仕様を編集して taint を追加することもできます。 

      apiVersion: v1
kind: Node
metadata:
  name: node1
# ...
spec:
  taints:
    - key: node-role.kubernetes.io/infra
      value: reserved
      effect: NoSchedule
# ...
      Copy to Clipboard Toggle word wrap

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

      インフラストラクチャーノードに NoSchedule taint を追加した場合、そのノードに設定されたデーモンによって制御されるすべての Pod は、misscheduled とマークされます。Red Hat ナレッジベースソリューション add toleration on misscheduled DNS pods に示されているように、Pod を削除するか、Pod に toleration を追加する必要があります。Operator によって管理されるデーモンセットオブジェクトには toleration を追加できないことに注意してください。

      注記

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

  2. インフラストラクチャーノードにスケジュールする Pod (ルーター、レジストリー、モニタリングワークロードなど) に toleration を追加します。前の例を参考にして、Pod オブジェクト仕様に次の toleration を追加します。 

    apiVersion: v1
kind: Pod
metadata:
  annotations:

# ...
spec:
# ...
  tolerations:
    - key: node-role.kubernetes.io/infra
    1 
    
      value: reserved
    2 
    
      effect: NoSchedule
    3 
    
      operator: Equal
    4
    Copy to Clipboard Toggle word wrap
    1
    ノードに追加したキーを指定します。
    2
    ノードに追加したキーと値のペア taint の値を指定します。
    3
    ノードに追加した effect を指定します。
    4
    Equal 演算子を指定して、キー node-role.kubernetes.io/infra を持つ taint がノードに存在することを必須にします。

    この toleration は、oc adm taint コマンドで作成された taint と一致します。この toleration を持つ Pod は、インフラストラクチャーノードにスケジュールできます。

    注記

    OLM によってインストールされた Operator の Pod は、必ずしもインフラストラクチャーノードに移動できません。Operator Pod を移動する機能は、各 Operator の設定によって異なります。

  3. スケジューラーを使用して、Pod をインフラストラクチャーノードにスケジュールします。詳細は、「スケジューラーによる Pod 配置の制御」のドキュメントを参照してください。
  4. 新しいインフラストラクチャーノード上の不要なワークロードやノードに属さないワークロードを削除します。「OpenShift Container Platform インフラストラクチャーコンポーネント」で、インフラストラクチャーノードでの使用がサポートされているワークロードのリストを参照してください。

5.8. リソースのインフラストラクチャーマシンセットへの移行
リンクのコピー

インフラストラクチャーリソースの一部はデフォルトでクラスターにデプロイされます。それらは、作成したインフラストラクチャーマシンセットに移行できます。

5.8.1. ルーターの移動
リンクのコピー

ルーター Pod を異なるコンピュートマシンセットにデプロイできます。デフォルトで、この Pod はワーカーノードにデプロイされます。

前提条件

  • 追加のコンピュートマシンセットを OpenShift Container Platform クラスターに設定します。

手順

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

    $ oc get ingresscontroller default -n openshift-ingress-operator -o yaml
    Copy to Clipboard Toggle word wrap

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

    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
    Copy to Clipboard Toggle word wrap

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

    $ oc edit ingresscontroller default -n openshift-ingress-operator
    Copy to Clipboard Toggle word wrap 
    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  creationTimestamp: "2025-03-26T21:15:43Z"
  finalizers:
  - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller
  generation: 1
  name: default
# ...
spec:
  nodePlacement:
    nodeSelector:
    1 
    
      matchLabels:
        node-role.kubernetes.io/infra: ""
    tolerations:
    - effect: NoSchedule
      key: node-role.kubernetes.io/infra
      value: reserved
# ...
    Copy to Clipboard Toggle word wrap
    1
    適切な値が設定された nodeSelector パラメーターを、移動する必要のあるコンポーネントに追加します。上記の形式で nodeSelector パラメーターを使用することも、ノードに指定された値に基づいて <key>: <value> ペアを使用することもできます。インフラストラクチャーノードに taint を追加した場合は、一致する toleration も追加します。

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

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

      $ oc get pod -n openshift-ingress -o wide
      Copy to Clipboard Toggle word wrap

      出力例

      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>
      Copy to Clipboard Toggle word wrap

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

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

      $ oc get node <node_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      Pod のリストより取得した <node_name> を指定します。

      出力例

      NAME                          STATUS  ROLES         AGE   VERSION
ip-10-0-217-226.ec2.internal  Ready   infra,worker  17h   v1.29.4
      Copy to Clipboard Toggle word wrap

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

5.8.2. デフォルトレジストリーの移行
リンクのコピー

レジストリー Operator を、その Pod を複数の異なるノードにデプロイするように設定します。

前提条件

  • 追加のコンピュートマシンセットを OpenShift Container Platform クラスターに設定します。

手順

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

    $ oc get configs.imageregistry.operator.openshift.io/cluster -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    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:
...
    Copy to Clipboard Toggle word wrap

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

    $ oc edit configs.imageregistry.operator.openshift.io/cluster
    Copy to Clipboard Toggle word wrap 
    apiVersion: imageregistry.operator.openshift.io/v1
kind: Config
metadata:
  name: cluster
# ...
spec:
  logLevel: Normal
  managementState: Managed
  nodeSelector:
    1 
    
    node-role.kubernetes.io/infra: ""
  tolerations:
  - effect: NoSchedule
    key: node-role.kubernetes.io/infra
    value: reserved
    Copy to Clipboard Toggle word wrap
    1
    適切な値が設定された nodeSelector パラメーターを、移動する必要のあるコンポーネントに追加します。上記の形式で nodeSelector パラメーターを使用することも、ノードに指定された値に基づいて <key>: <value> ペアを使用することもできます。インフラストラクチャーノードに taint を追加した場合は、一致する toleration も追加します。

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

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

      $ oc get pods -o wide -n openshift-image-registry
      Copy to Clipboard Toggle word wrap

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

      $ oc describe node <node_name>
      Copy to Clipboard Toggle word wrap

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

5.8.3. モニタリングソリューションの移動
リンクのコピー

監視スタックには、Prometheus、Thanos Querier、Alertmanager などの複数のコンポーネントが含まれています。Cluster Monitoring Operator は、このスタックを管理します。モニタリングスタックをインフラストラクチャーノードに再デプロイするために、カスタム config map を作成して適用できます。

前提条件

  • cluster-admin クラスターロールを持つユーザーとしてクラスターにアクセスできる。
  • cluster-monitoring-config ConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. cluster-monitoring-config config map を編集し、nodeSelector を変更して infra ラベルを使用します。 

    $ oc edit configmap cluster-monitoring-config -n openshift-monitoring
    Copy to Clipboard Toggle word wrap 
    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
    prometheusK8s:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
    prometheusOperator:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
    metricsServer:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
    kubeStateMetrics:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
    telemeterClient:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
    openshiftStateMetrics:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
    thanosQuerier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
    monitoringPlugin:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
    Copy to Clipboard Toggle word wrap
    1
    適切な値が設定された nodeSelector パラメーターを、移動する必要のあるコンポーネントに追加します。上記の形式で nodeSelector パラメーターを使用することも、ノードに指定された値に基づいて <key>: <value> ペアを使用することもできます。インフラストラクチャーノードに taint を追加した場合は、一致する toleration も追加します。

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

    $ watch 'oc get pod -n openshift-monitoring -o wide'
    Copy to Clipboard Toggle word wrap

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

    $ oc delete pod -n openshift-monitoring <pod>
    Copy to Clipboard Toggle word wrap

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

5.8.4. ロギングリソースの移動
リンクのコピー

ロギングリソースの移動の詳細は、以下を参照してください。

5.9. クラスターへの自動スケーリングの適用
リンクのコピー

自動スケーリングの OpenShift Container Platform クラスターへの適用には、クラスターへの Cluster Autoscaler のデプロイと各マシンタイプの Machine Autoscaler のデプロイが必要です。

詳細は、OpenShift Container Platform クラスターへの自動スケーリングの適用 を参照してください。

5.10. Linux cgroup の設定
リンクのコピー

OpenShift Container Platform 4.14 以降、OpenShift Container Platform はクラスター内で Linux コントロールグループバージョン 2 (cgroup v2) を使用します。OpenShift Container Platform 4.13 以前で cgroup v1 を使用している場合、OpenShift Container Platform 4.14 以降に移行しても、cgroup 設定はバージョン 2 に自動的に更新されません。OpenShift Container Platform 4.14 以降の新規インストールでは、デフォルトで cgroup v2 が使用されます。ただし、インストール時に Linux コントロールグループバージョン 1 (cgroup v1) を有効にできます。

cgroup v2 は、Linux cgroup API の現行バージョンです。cgroup v2 では、統一された階層、安全なサブツリー委譲、Pressure Stall Information 等の新機能、および強化されたリソース管理および分離など、cgroup v1 に対していくつかの改善が行われています。ただし、cgroup v2 には、cgroup v1 とは異なる CPU、メモリー、および I/O 管理特性があります。したがって、一部のワークロードでは、cgroup v2 を実行するクラスター上のメモリーまたは CPU 使用率にわずかな違いが発生する可能性があります。

必要に応じて、cgroup v1 と cgroup v2 の間で変更できます。OpenShift Container Platform で cgroup v1 を有効にすると、クラスター内のすべての cgroup v2 コントローラーと階層が無効になります。

重要

cgroup v1 は非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、この製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。

OpenShift Container Platform で非推奨となったか、削除された主な機能の最新の一覧は、OpenShift Container Platform リリースノートの 非推奨および削除された機能 セクションを参照してください。

前提条件

  • OpenShift Container Platform クラスター (バージョン 4.12 以降) が実行中。
  • 管理者権限を持つユーザーとしてクラスターにログインしている。

手順

  1. ノードに、必要な cgroup バージョンを設定します。

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

      $ oc edit nodes.config/cluster
      Copy to Clipboard Toggle word wrap

    2. Add spec.cgroupMode: "v1":

      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:
  cgroupMode: "v1"
      1 
      
...
      Copy to Clipboard Toggle word wrap

      1
      cgroup v1 を有効にします。

検証

  1. マシン設定をチェックして、新しいマシン設定が追加されたことを確認します。 

    $ oc get mc
    Copy to Clipboard Toggle word wrap

    出力例

    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
97-master-generated-kubelet                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-worker-generated-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-23d4317815a5f854bd3553d689cfe2e9   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             10s
    1 
    
rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
rendered-worker-dcc7f1b92892d34db74d6832bcc9ccd4   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             10s
    Copy to Clipboard Toggle word wrap

    1
    予想どおり、新しいマシン設定が作成されます。

  2. 新しい kernelArguments が新しいマシン設定に追加されたことを確認します。 

    $ oc describe mc <name>
    Copy to Clipboard Toggle word wrap

    cgroup v1 の出力例

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 05-worker-kernelarg-selinuxpermissive
spec:
  kernelArguments:
    systemd.unified_cgroup_hierarchy=0
    1 
    
    systemd.legacy_systemd_cgroup_controller=1
    2 
    
    psi=0
    Copy to Clipboard Toggle word wrap

    1
    cgroup v2 を無効にします。
    2
    systemd で cgroup v1 を有効にします。

  3. ノードをチェックして、ノードのスケジューリングが無効になっていることを確認します。これは、変更が適用されていることを示しています。 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                       STATUS                     ROLES    AGE   VERSION
ci-ln-fm1qnwt-72292-99kt6-master-0         Ready,SchedulingDisabled   master   58m   v1.29.4
ci-ln-fm1qnwt-72292-99kt6-master-1         Ready                      master   58m   v1.29.4
ci-ln-fm1qnwt-72292-99kt6-master-2         Ready                      master   58m   v1.29.4
ci-ln-fm1qnwt-72292-99kt6-worker-a-h5gt4   Ready,SchedulingDisabled   worker   48m   v1.29.4
ci-ln-fm1qnwt-72292-99kt6-worker-b-7vtmd   Ready                      worker   48m   v1.29.4
ci-ln-fm1qnwt-72292-99kt6-worker-c-rhzkv   Ready                      worker   48m   v1.29.4
    Copy to Clipboard Toggle word wrap

  4. ノードが Ready 状態に戻ったら、そのノードのデバッグセッションを開始します。 

    $ oc debug node/<node_name>
    Copy to Clipboard Toggle word wrap

  5. /host をデバッグシェル内のルートディレクトリーとして設定します。 

    sh-4.4# chroot /host
    Copy to Clipboard Toggle word wrap

  6. sys/fs/cgroup/cgroup2fs ファイルがノードに存在することを確認します。このファイルは cgroup v1 によって作成されます。 

    $ stat -c %T -f /sys/fs/cgroup
    Copy to Clipboard Toggle word wrap

    出力例

    cgroup2fs
    Copy to Clipboard Toggle word wrap

5.11. FeatureGate の使用によるテクノロジープレビュー機能の有効化
リンクのコピー

FeatureGate カスタムリソース (CR) を編集して、クラスターのすべてのノードに対して現在のテクノロジープレビュー機能のサブセットをオンにすることができます。

5.11.1. フィーチャーゲートについて
リンクのコピー

FeatureGate カスタムリソース (CR) を使用して、クラスター内の特定の機能セットを有効にすることができます。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。

FeatureGate CR を使用して、以下の機能セットをアクティブにすることができます。

  • TechPreviewNoUpgrade: この機能セットは、現在のテクノロジープレビュー機能のサブセットです。この機能セットを使用すると、テストクラスターでこれらのテクノロジープレビュー機能を有効にすることができます。そこでは、これらの機能を完全にテストできますが、運用クラスターでは機能を無効にしたままにできます。

    警告

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

    この機能セットにより、以下のテクノロジープレビュー機能が有効になります。

    • 外部クラウドプロバイダー。vSphere、AWS、Azure、GCP 上にあるクラスターの外部クラウドプロバイダーのサポートを有効にします。OpenStack のサポートは GA です。これは内部機能であり、ほとんどのユーザーは操作する必要はありません。(ExternalCloudProvider)
    • OpenShift Builds の共有リソース CSI ドライバー。Container Storage Interface (CSI) を有効にします。(CSIDriverSharedResource)
    • ノード上のスワップメモリー。ノードごとに OpenShift Container Platform ワークロードのスワップメモリーの使用を有効にします。(NodeSwap)
    • OpenStack Machine API プロバイダー。このゲートは効果がなく、今後のリリースでこの機能セットから削除される予定です。(MachineAPIProviderOpenStack)
    • Insights Operator。InsightsDataGather CRD を有効にし、ユーザーがいくつかの Insights データ収集オプションを設定できるようにします。この機能セットにより、DataGather CRD も有効になり、ユーザーがオンデマンドで Insights データ収集を実行できるようになります。(InsightsConfigAPI)
    • Retroactive デフォルトストレージクラス。PVC 作成時にデフォルトのストレージクラスがない場合に、OpenShift Container Platform は PVC に対してデフォルトのストレージクラスを遡及的に割り当てることができます。(RetroactiveDefaultStorageClass)
    • 動的リソース割り当て API。Pod とコンテナー間でリソースを要求および共有するための新しい API が有効になります。これは内部機能であり、ほとんどのユーザーは操作する必要はありません。(DynamicResourceAllocation)
    • Pod セキュリティーアドミッションの適用。Pod セキュリティーアドミッションの制限付き強制モードを有効にします。警告をログに記録するだけでなく、Pod のセキュリティー基準に違反している場合、Pod は拒否されます。(OpenShiftPodSecurityAdmission)
    • StatefulSet Pod の可用性アップグレードの制限。ユーザーは、更新中に使用できないステートフルセット Pod の最大数を定義できるため、アプリケーションのダウンタイムが削減されます。(MaxUnavailableStatefulSet)
    • MatchConditions は、この Webhook にリクエストを送信するために満たす必要がある条件のリストです。Match Conditions は、ルール、namespaceSelector、および objectSelector ですでに一致しているリクエストをフィルター処理します。matchConditions の空のリストは、すべてのリクエストに一致します。(admissionWebhookMatchConditions)
    • gcpLabelsTags
    • vSphereStaticIPs
    • routeExternalCertificate
    • automatedEtcdBackup
    • gcpClusterHostedDNS
    • vSphereControlPlaneMachineset
    • dnsNameResolver
    • machineConfigNodes
    • metricsServer
    • installAlternateInfrastructureAWS
    • sdnLiveMigration
    • mixedCPUsAllocation
    • managedBootImages
    • onClusterBuild
    • signatureStores
    • DisableKubeletCloudCredentialProviders
    • BareMetalLoadBalancer
    • ClusterAPIInstallAWS
    • ClusterAPIInstallNutanix
    • ClusterAPIInstallOpenStack
    • ClusterAPIInstallVSphere
    • HardwareSpeed
    • KMSv1
    • NetworkDiagnosticsConfig
    • VSphereDriverConfiguration
    • ExternalOIDC
    • ChunkSizeMiB
    • ClusterAPIInstallGCP
    • ClusterAPIInstallPowerVS
    • EtcdBackendQuota
    • 例
    • ImagePolicy
    • InsightsConfig
    • InsightsOnDemandDataGather
    • MetricsCollectionProfiles
    • NewOLM
    • NodeDisruptionPolicy
    • PinnedImages
    • PlatformOperators
    • ServiceAccountTokenNodeBinding
    • ServiceAccountTokenNodeBindingValidation
    • ServiceAccountTokenPodNodeInfo
    • TranslateStreamCloseWebsocketRequests
    • UpgradeStatus
    • VSphereMultiVCenters
    • VolumeGroupSnapshot

5.11.2. Web コンソールを使用した機能セットの有効化
リンクのコピー

FeatureGate カスタムリソース (CR) を編集して、OpenShift Container Platform Web コンソールを使用してクラスター内のすべてのノードの機能セットを有効にすることができます。

手順

機能セットを有効にするには、以下を実行します。

  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
    Copy to Clipboard Toggle word wrap

    1
    FeatureGate CR の名前は cluster である必要があります。
    2
    有効にする機能セットを追加します。
    • TechPreviewNoUpgrade は、特定のテクノロジープレビュー機能を有効にします。

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

検証

ノードが準備完了状態に戻った後、ノード上の kubelet.conf ファイルを確認することで、フィーチャーゲートが有効になっていることを確認できます。

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

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

    sh-4.2# chroot /host
    Copy to Clipboard Toggle word wrap

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

    sh-4.2# cat /etc/kubernetes/kubelet.conf
    Copy to Clipboard Toggle word wrap

    出力例

    # ...
featureGates:
  InsightsOperatorPullingSCA: true,
  LegacyNodeRoleBehavior: false
# ...
    Copy to Clipboard Toggle word wrap

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

    注記

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

5.11.3. CLI を使用した機能セットの有効化
リンクのコピー

FeatureGate カスタムリソース (CR) を編集し、OpenShift CLI (oc) を使用してクラスター内のすべてのノードの機能セットを有効にすることができます。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

機能セットを有効にするには、以下を実行します。

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

    $ oc edit featuregate cluster
    Copy to Clipboard Toggle word wrap
    警告

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

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

    apiVersion: config.openshift.io/v1
kind: FeatureGate
metadata:
  name: cluster
    1 
    
# ...
spec:
  featureSet: TechPreviewNoUpgrade
    2
    Copy to Clipboard Toggle word wrap

    1
    FeatureGate CR の名前は cluster である必要があります。
    2
    有効にする機能セットを追加します。
    • TechPreviewNoUpgrade は、特定のテクノロジープレビュー機能を有効にします。

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

検証

ノードが準備完了状態に戻った後、ノード上の kubelet.conf ファイルを確認することで、フィーチャーゲートが有効になっていることを確認できます。

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

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

    sh-4.2# chroot /host
    Copy to Clipboard Toggle word wrap

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

    sh-4.2# cat /etc/kubernetes/kubelet.conf
    Copy to Clipboard Toggle word wrap

    出力例

    # ...
featureGates:
  InsightsOperatorPullingSCA: true,
  LegacyNodeRoleBehavior: false
# ...
    Copy to Clipboard Toggle word wrap

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

    注記

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

5.12. etcd タスク
リンクのコピー

etcd のバックアップ、etcd 暗号化の有効化または無効化、または etcd データのデフラグを行います。

5.12.1. etcd 暗号化について
リンクのコピー

デフォルトで、etcd データは OpenShift Container Platform で暗号化されません。クラスターの etcd 暗号化を有効にして、データセキュリティーのレイヤーを追加で提供することができます。たとえば、etcd バックアップが正しくない公開先に公開される場合に機密データが失われないように保護することができます。

etcd の暗号化を有効にすると、以下の OpenShift API サーバーおよび Kubernetes API サーバーリソースが暗号化されます。

  • シークレット
  • config map
  • ルート
  • OAuth アクセストークン
  • OAuth 認証トークン

etcd 暗号を有効にすると、暗号化キーが作成されます。etcd バックアップから復元するには、これらのキーが必要です。

注記

etcd 暗号化は、キーではなく、値のみを暗号化します。リソースの種類、namespace、およびオブジェクト名は暗号化されません。

バックアップ中に etcd 暗号化が有効になっている場合は、static_kuberesources_<datetimestamp>.tar.gz ファイルに etcd スナップショットの暗号化キーが含まれています。セキュリティー上の理由から、このファイルは etcd スナップショットとは別に保存してください。ただし、このファイルは、それぞれの etcd スナップショットから etcd の以前の状態を復元するために必要です。

5.12.2. サポートされている暗号化の種類
リンクのコピー

以下の暗号化タイプは、OpenShift Container Platform で etcd データを暗号化するためにサポートされています。

AES-CBC
暗号化を実行するために、PKCS#7 パディングと 32 バイトの鍵を含む AES-CBC を使用します。暗号化キーは毎週ローテーションされます。
AES-GCM
AES-GCM とランダムナンスおよび 32 バイトキーを使用して暗号化を実行します。暗号化キーは毎週ローテーションされます。

5.12.3. etcd 暗号化の有効化
リンクのコピー

etcd 暗号化を有効にして、クラスターで機密性の高いリソースを暗号化できます。

警告

初期暗号化プロセスが完了するまで、etcd リソースをバックアップしないでください。暗号化プロセスが完了しない場合、バックアップは一部のみ暗号化される可能性があります。

etcd 暗号化を有効にすると、いくつかの変更が発生する可能性があります。

  • etcd 暗号化は、いくつかのリソースのメモリー消費に影響を与える可能性があります。
  • リーダーがバックアップを提供する必要があるため、バックアップのパフォーマンスに一時的な影響が生じる場合があります。
  • ディスク I/O は、バックアップ状態を受け取るノードに影響を与える可能性があります。

etcd データベースは、AES-GCM または AES-CBC 暗号化で暗号化できます。

注記

etcd データベースをある暗号化タイプから別の暗号化タイプに移行するには、API サーバーの spec.encryption.type フィールドを変更します。etcd データの新しい暗号化タイプへの移行は自動的に行われます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

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

    $ oc edit apiserver
    Copy to Clipboard Toggle word wrap

  2. spec.encryption.type フィールドを aesgcm または aescbc に設定します。 

    spec:
  encryption:
    type: aesgcm
    1
    Copy to Clipboard Toggle word wrap
    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"}'
      Copy to Clipboard Toggle word wrap

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

      EncryptionCompleted
All resources encrypted: routes.route.openshift.io
      Copy to Clipboard Toggle word wrap

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

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

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

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

      EncryptionCompleted
All resources encrypted: secrets, configmaps
      Copy to Clipboard Toggle word wrap

      出力に 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"}'
      Copy to Clipboard Toggle word wrap

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

      EncryptionCompleted
All resources encrypted: oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io
      Copy to Clipboard Toggle word wrap

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

5.12.4. etcd 暗号化の無効化
リンクのコピー

クラスターで etcd データの暗号化を無効にできます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

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

    $ oc edit apiserver
    Copy to Clipboard Toggle word wrap

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

    spec:
  encryption:
    type: identity
    1
    Copy to Clipboard Toggle word wrap
    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"}'
      Copy to Clipboard Toggle word wrap

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

      DecryptionCompleted
Encryption mode set to identity and everything is decrypted
      Copy to Clipboard Toggle word wrap

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

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

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

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

      DecryptionCompleted
Encryption mode set to identity and everything is decrypted
      Copy to Clipboard Toggle word wrap

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

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

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

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

      DecryptionCompleted
Encryption mode set to identity and everything is decrypted
      Copy to Clipboard Toggle word wrap

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

5.12.5. etcd データのバックアップ
リンクのコピー

以下の手順に従って、etcd スナップショットを作成し、静的 Pod のリソースをバックアップして etcd データをバックアップします。このバックアップは保存でき、etcd を復元する必要がある場合に後で使用することができます。

重要

単一のコントロールプレーンホストからのバックアップのみを保存します。クラスター内の各コントロールプレーンホストからのバックアップは取得しないでください。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

  • クラスター全体のプロキシーが有効になっているかどうかを確認している。

    ヒント

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

手順

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

    $ oc debug --as-root node/<node_name>
    Copy to Clipboard Toggle word wrap

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

    sh-4.4# chroot /host
    Copy to Clipboard Toggle word wrap

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

    $ export HTTP_PROXY=http://<your_proxy.example.com>:8080
    Copy to Clipboard Toggle word wrap 
    $ export HTTPS_PROXY=https://<your_proxy.example.com>:8080
    Copy to Clipboard Toggle word wrap 
    $ export NO_PROXY=<example.com>
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    スクリプトの出力例

    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
    Copy to Clipboard Toggle word wrap

    この例では、コントロールプレーンホストの /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、およびオブジェクト名は暗号化されません。

5.12.6. etcd データのデフラグ
リンクのコピー

大規模で密度の高いクラスターの場合、キースペースが大きくなりすぎてスペースのクォータを超えると、etcd のパフォーマンスが低下する可能性があります。定期的に etcd をメンテナンスしてデフラグし、データストアの領域を解放してください。Prometheus で etcd メトリクスを監視し、必要に応じてデフラグしてください。そうしないと、etcd がクラスター全体のアラームを発し、クラスターがキーの読み取りと削除しか受け付けないメンテナンスモードになる可能性があります。

以下の主要なメトリクスを監視してください。

  • etcd_server_quota_backend_bytes。これは現在のクォータ制限です。
  • etcd_mvcc_db_total_size_in_use_in_bytes。履歴圧縮後の実際のデータベース使用量を示します。
  • etcd_mvcc_db_total_size_in_bytes。デフラグ待ちの空き領域を含むデータベースのサイズを示します。

etcd データをデフラグし、etcd 履歴の圧縮などのディスクの断片化を引き起こすイベント後にディスク領域を回収します。

履歴の圧縮は 5 分ごとに自動的に行われ、これによりバックエンドデータベースにギャップが生じます。この断片化された領域は etcd が使用できますが、ホストファイルシステムでは利用できません。ホストファイルシステムでこの領域を使用できるようにするには、etcd をデフラグする必要があります。

デフラグは自動的に行われますが、手動でトリガーすることもできます。

注記

etcd Operator はクラスター情報を使用してユーザーの最も効率的な操作を決定するため、ほとんどの場合、自動デフラグが適しています。

5.12.6.1. 自動デフラグ
リンクのコピー

etcd Operator はディスクを自動的にデフラグします。手動による介入は必要ありません。

以下のログのいずれかを表示して、デフラグプロセスが成功したことを確認します。

  • etcd ログ
  • cluster-etcd-operator Pod
  • Operator ステータスのエラーログ
警告

自動デフラグにより、Kubernetes コントローラーマネージャーなどのさまざまな OpenShift コアコンポーネントでリーダー選出の失敗が発生し、失敗したコンポーネントの再起動がトリガーされる可能性があります。再起動は無害であり、次に実行中のインスタンスへのフェイルオーバーをトリガーするか、再起動後にコンポーネントが再び作業を再開します。

デフラグ成功時のログ出力例

etcd member has been defragmented: <member_name>, memberID: <member_id>
Copy to Clipboard Toggle word wrap

デフラグ失敗時のログ出力例

failed defrag on member: <member_name>, memberID: <member_id>: <error_message>
Copy to Clipboard Toggle word wrap

5.12.6.2. 手動デフラグ
リンクのコピー

Prometheus アラートは、手動でのデフラグを使用する必要がある場合を示します。アラートは次の 2 つの場合に表示されます。

  • etcd が使用可能なスペースの 50% 以上を 10 分を超過して使用する場合
  • etcd が合計データベースサイズの 50% 未満を 10 分を超過してアクティブに使用している場合

また、デフラグによって解放される etcd データベースのサイズ (MB 単位) を確認することで、デフラグが必要かどうかを判断することもできます。これは (etcd_mvcc_db_total_size_in_bytes - etcd_mvcc_db_total_size_in_use_in_bytes)/1024/1024 という PromQL 式を使用して確認できます。

警告

etcd のデフラグはプロセスを阻止するアクションです。etcd メンバーはデフラグが完了するまで応答しません。このため、各 Pod のデフラグアクションごとに少なくとも 1 分間待機し、クラスターが回復できるようにします。

以下の手順に従って、各 etcd メンバーで etcd データをデフラグします。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

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

    1. etcd Pod のリストを取得します。 

      $ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide
      Copy to Clipboard Toggle word wrap

      出力例

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

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

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w table
      Copy to Clipboard Toggle word wrap

      出力例

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

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

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

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

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com
      Copy to Clipboard Toggle word wrap

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

      sh-4.4# unset ETCDCTL_ENDPOINTS
      Copy to Clipboard Toggle word wrap

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

      sh-4.4# etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag
      Copy to Clipboard Toggle word wrap

      出力例

      Finished defragmenting etcd member[https://localhost:2379]
      Copy to Clipboard Toggle word wrap

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

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

      sh-4.4# etcdctl endpoint status -w table --cluster
      Copy to Clipboard Toggle word wrap

      出力例

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

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

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

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

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

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

      sh-4.4# etcdctl alarm list
      Copy to Clipboard Toggle word wrap

      出力例

      memberID:12345678912345678912 alarm:NOSPACE
      Copy to Clipboard Toggle word wrap

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

      sh-4.4# etcdctl alarm disarm
      Copy to Clipboard Toggle word wrap

5.12.7. クラスターの直前の状態への復元
リンクのコピー

保存された etcd のバックアップを使用して、クラスターの以前の状態を復元したり、大多数のコントロールプレーンホストが失われたクラスターを復元したりできます。

注記

クラスターがコントロールプレーンマシンセットを使用している場合は、「コントロールプレーンマシンセットのトラブルシューティング」の「劣化した etcd Operator のリカバリー」で etcd のリカバリー手順を参照してください。

重要

クラスターを復元する際に、同じ z-stream リリースから取得した etcd バックアップを使用する必要があります。たとえば、OpenShift Container Platform 4.7.2 クラスターは、4.7.2 から取得した etcd バックアップを使用する必要があります。

前提条件

  • インストール時に使用したものと同様、証明書ベースの kubeconfig ファイルを介して、cluster-admin ロールを持つユーザーとしてクラスターにアクセスします。
  • リカバリーホストとして使用する正常なコントロールプレーンホストがあること。
  • コントロールプレーンホストへの SSH アクセス。
  • etcd スナップショットと静的 Pod のリソースの両方を含むバックアップディレクトリー (同じバックアップから取られるもの)。ディレクトリー内のファイル名は、snapshot_<datetimestamp>.db および static_kuberesources_<datetimestamp>.tar.gz の形式にする必要があります。
  • ノードはアクセス可能またはブート可能である。
重要

非リカバリーコントロールプレーンノードの場合は、SSH 接続を確立したり、静的 Pod を停止したりする必要はありません。他のリカバリー以外のコントロールプレーンマシンを 1 つずつ削除し、再作成します。

手順

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

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

    Kubernetes API サーバーは復元プロセスの開始後にアクセスできなくなるため、oc debug メソッドを使用してコントロールプレーンノードにアクセスすることはできません。このため、別のターミナルで各コントロールプレーンホストへの 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
      Copy to Clipboard Toggle word wrap

    3. 次のコマンドを実行して、etcd Pod が停止していることを確認します。 

      $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"
      Copy to Clipboard Toggle word wrap

      このコマンドの出力が空でない場合は、数分待ってからもう一度確認してください。

    4. 以下のコマンドを実行して、既存の kube-apiserver ファイルを kubelet マニフェストディレクトリーから移動します。 

      $ sudo mv -v /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
      Copy to Clipboard Toggle word wrap

    5. 以下のコマンドを実行して、kube-apiserver コンテナーが停止していることを確認します。 

      $ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"
      Copy to Clipboard Toggle word wrap

      このコマンドの出力が空でない場合は、数分待ってからもう一度確認してください。

    6. 次のコマンドを実行して、既存の kube-controller-manager ファイルを kubelet マニフェストディレクトリーから移動します。 

      $ sudo mv -v /etc/kubernetes/manifests/kube-controller-manager-pod.yaml /tmp
      Copy to Clipboard Toggle word wrap

    7. 以下のコマンドを実行して、kube-controller-manager コンテナーが停止していることを確認します。 

      $ sudo crictl ps | grep kube-controller-manager | egrep -v "operator|guard"
      Copy to Clipboard Toggle word wrap

      このコマンドの出力が空でない場合は、数分待ってからもう一度確認してください。

    8. 次のコマンドを実行して、既存の kube-scheduler ファイルを kubelet マニフェストディレクトリーから移動します。 

      $ sudo mv -v /etc/kubernetes/manifests/kube-scheduler-pod.yaml /tmp
      Copy to Clipboard Toggle word wrap

    9. 以下のコマンドを実行して、kube-scheduler コンテナーが停止していることを確認します。 

      $ sudo crictl ps | grep kube-scheduler | egrep -v "operator|guard"
      Copy to Clipboard Toggle word wrap

      このコマンドの出力が空でない場合は、数分待ってからもう一度確認してください。

    10. 次の例を使用して、etcd データディレクトリーを別の場所に移動します。 

      $ sudo mv -v /var/lib/etcd/ /tmp
      Copy to Clipboard Toggle word wrap

    11. /etc/kubernetes/manifests/keepalived.yaml ファイルが存在する場合は、以下の手順を実行します。これらの手順は、API IP アドレスがリカバリーホストでリッスンしていることを確認するために必要です。

      1. 次のコマンドを実行して、/etc/kubernetes/manifests/keepalived.yaml ファイルを kubelet マニフェストディレクトリーから移動します。 

        $ sudo mv -v /etc/kubernetes/manifests/keepalived.yaml /home/core/
        Copy to Clipboard Toggle word wrap
        注記

        このファイルは、手順の完了後に元の場所に復元する必要があります。

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

        $ sudo crictl ps --name keepalived
        Copy to Clipboard Toggle word wrap

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

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

        $ ip -o address | egrep '<api_vip>|<ingress_vip>'
        Copy to Clipboard Toggle word wrap

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

        $ sudo ip address del <reported_vip> dev <reported_vip_device>
        Copy to Clipboard Toggle word wrap
    12. リカバリーホストではない他のコントロールプレーンホストでこの手順を繰り返します。
  5. リカバリーコントロールプレーンホストにアクセスします。

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

    $ ip -o address | grep <api_vip>
    Copy to Clipboard Toggle word wrap

    仮想 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
    Copy to Clipboard Toggle word wrap

    スクリプトの出力例

    ...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
    Copy to Clipboard Toggle word wrap

    cluster-restore.sh スクリプトは、etcd、kube-apiserver、kube-controller-manager、および kube-scheduler Pod が停止され、復元プロセスの最後に開始されたことを示す必要があります。

    注記

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

  9. ノードをチェックして、Ready 状態であることを確認します。ノードを確認するには、bastion ホストまたはリカバリーホストのいずれかを使用できます。

    • リカバリーホストを使用する場合は、次のコマンドを実行します。 

      $ export KUBECONFIG=/etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost-recovery.kubeconfig
      Copy to Clipboard Toggle word wrap 
      $ oc get nodes -w
      Copy to Clipboard Toggle word wrap

    • bastion ホストを使用する場合は、以下の手順を実行します。

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

        $ oc get nodes -w
        Copy to Clipboard Toggle word wrap

        出力例

        NAME                STATUS  ROLES          AGE     VERSION
host-172-25-75-28   Ready   master         3d20h   v1.29.4
host-172-25-75-38   Ready   infra,worker   3d20h   v1.29.4
host-172-25-75-40   Ready   master         3d20h   v1.29.4
host-172-25-75-65   Ready   master         3d20h   v1.29.4
host-172-25-75-74   Ready   infra,worker   3d20h   v1.29.4
host-172-25-75-79   Ready   worker         3d20h   v1.29.4
host-172-25-75-86   Ready   worker         3d20h   v1.29.4
host-172-25-75-98   Ready   infra,worker   3d20h   v1.29.4
        Copy to Clipboard Toggle word wrap

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

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

        $  ssh -i <ssh-key-path> core@<master-hostname>
        Copy to Clipboard Toggle word wrap

        サンプル 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
        Copy to Clipboard Toggle word wrap

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

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

      $ sudo systemctl restart kubelet.service
      Copy to Clipboard Toggle word wrap
    2. 他のすべてのコントロールプレーンホストでこの手順を繰り返します。

  11. 保留中の証明書署名要求 (CSR) を承認します。

    注記

    単一ノードクラスターや 3 つのスケジュール可能なコントロールプレーンノードで構成されるクラスターなど、ワーカーノードを持たないクラスターには、承認する保留中の CSR はありません。この手順にリストされているすべてのコマンドをスキップできます。

    1. 次のコマンドを実行して、現在の CSR のリストを取得します。 

      $ oc get csr
      Copy to Clipboard Toggle word wrap

      出力例

      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 
      
...
      Copy to Clipboard Toggle word wrap

      1 1 2
      kubelet 提供エンドポイントのノードによって要求される、保留中の kubelet 提供 CSR。
      3 4
      node-bootstrapper ノードのブートストラップ認証情報を使用して要求される、保留中の kubelet クライアント CSR。

    2. 以下のコマンドを実行して CSR の詳細をレビューし、これが有効であることを確認します。 

      $ oc describe csr <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      <csr_name> は、現行の CSR のリストからの CSR の名前です。

    3. 次のコマンドを実行して、それぞれの有効な node-bootstrapper CSR を承認します。 

      $ oc adm certificate approve <csr_name>
      Copy to Clipboard Toggle word wrap

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

      $ oc adm certificate approve <csr_name>
      Copy to Clipboard Toggle word wrap

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

    1. リカバリーホストから、次のコマンドを入力して、etcd コンテナーが実行されていることを確認します。 

      $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"
      Copy to Clipboard Toggle word wrap

      出力例

      3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0
      Copy to Clipboard Toggle word wrap

    2. リカバリーホストから、次のコマンドを入力して、etcd Pod が実行されていることを確認します。 

      $ oc -n openshift-etcd get pods -l k8s-app=etcd
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                                             READY   STATUS      RESTARTS   AGE
etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s
      Copy to Clipboard Toggle word wrap

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

  13. OVNKubernetes ネットワークプラグインを使用している場合は、ovnkube-controlplane Pod を再起動する必要があります。

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

      $ oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-control-plane
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、すべての ovnkube-controlplane Pod が再デプロイされたことを確認します。 

      $ oc -n openshift-ovn-kubernetes get pod -l app=ovnkube-control-plane
      Copy to Clipboard Toggle word wrap

  14. OVN-Kubernetes ネットワークプラグインを使用している場合は、すべてのノードで Open Virtual Network (OVN) Kubernetes Pod を 1 つずつ再起動します。次の手順を使用して、各ノードで OVN-Kubernetes Pod を再起動します。

    重要

    OVN-Kubernetes Pod は次の順序で再起動してください。

    1. リカバリーコントロールプレーンホスト
    2. 他のコントロールプレーンホスト (利用可能な場合)
    3. 他のノード
    注記

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

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

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

      $ sudo rm -f /var/lib/ovn-ic/etc/*.db
      Copy to Clipboard Toggle word wrap

    2. OpenVSwitch サービスを再起動します。Secure Shell (SSH) を使用してノードにアクセスし、次のコマンドを実行します。 

      $ sudo systemctl restart ovs-vswitchd ovsdb-server
      Copy to Clipboard Toggle word wrap

    3. 次のコマンドを実行して、ノード上の ovnkube-node Pod を削除します。<node> は、再起動するノードの名前に置き換えます。 

      $ oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-node --field-selector=spec.nodeName==<node>
      Copy to Clipboard Toggle word wrap

    4. 次のコマンドを実行して、Pod のステータスを確認します。 

      $ oc get po -n openshift-ovn-kubernetes
      Copy to Clipboard Toggle word wrap

      1. OVN Pod のステータスが Terminating である場合は、次のコマンドを実行して、OVN Pod を実行しているノードを削除します。&lt ;node& gt; を、削除するノードの名前に置き換えます。 

        $ oc delete node <node>
        Copy to Clipboard Toggle word wrap

      2. 次のコマンドを実行して、SSH を使用して Terminating ステータスの OVN Pod ノードにログインします。 

        $ ssh -i <ssh-key-path> core@<node>
        Copy to Clipboard Toggle word wrap

      3. 次のコマンドを実行して、すべての PEM ファイルを /var/lib/kubelet/pki ディレクトリーから移動します。 

        $ sudo mv /var/lib/kubelet/pki/* /tmp
        Copy to Clipboard Toggle word wrap

      4. 次のコマンドを実行して、kubelet サービスを無効にします。 

        $ sudo systemctl restart kubelet.service
        Copy to Clipboard Toggle word wrap

      5. 次のコマンドを実行して、リカバリー etcd マシンに戻ります。 

        $ oc get csr
        Copy to Clipboard Toggle word wrap

        出力例

        NAME        AGE    SIGNERNAME                         REQUESTOR                     CONDITION
csr-<uuid>   8m3s   kubernetes.io/kubelet-serving     system:node:<node_name>       Pending
        Copy to Clipboard Toggle word wrap

      6. 以下のコマンドを実行して、すべての新規 CSR を承認します。ここで、csr-<uuid > は CSR の名前に置き換えてください。 

        oc adm certificate approve csr-<uuid>
        Copy to Clipboard Toggle word wrap

      7. 次のコマンドを実行して、ノードが復旧していることを確認します。 

        $ oc get nodes
        Copy to Clipboard Toggle word wrap

    5. 以下を使用して、ovnkube-node Pod が再度実行されていることを確認します。 

      $ oc -n openshift-ovn-kubernetes get pod -l app=ovnkube-node --field-selector=spec.nodeName==<node>
      Copy to Clipboard Toggle word wrap
      注記

      Pod が再起動するまでに数分かかる場合があります。

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

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

      警告

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

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

      警告

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

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

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

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

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        出力例

        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
        Copy to Clipboard Toggle word wrap

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

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

        $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0
        1
        Copy to Clipboard Toggle word wrap
        1
        失われたコントロールプレーンホストのコントロールプレーンマシンの名前を指定します。

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

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

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        出力例

        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
        Copy to Clipboard Toggle word wrap

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

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

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

  16. 次のコマンドを実行して、クォーラムガードをオフにします。 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
    Copy to Clipboard Toggle word wrap

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

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

    $ export KUBECONFIG=/etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost-recovery.kubeconfig
    Copy to Clipboard Toggle word wrap

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

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

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    forceRedeploymentReason 値は一意である必要があります。そのため、タイムスタンプが付加されます。

    etcd の再デプロイメントが開始します。

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

  19. 次のコマンドを実行して、クォーラムガードをオンに戻します。 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
    Copy to Clipboard Toggle word wrap

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

    $ oc get etcd/cluster -oyaml
    Copy to Clipboard Toggle word wrap

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

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

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

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

    AllNodesAtLatestRevision
3 nodes are at revision 7
    1
    Copy to Clipboard Toggle word wrap
    1
    この例では、最新のリビジョン番号は 7 です。

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

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

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

    1. kube-apiserver の新規ロールアウトを強制します。 

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

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

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

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

      AllNodesAtLatestRevision
3 nodes are at revision 7
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

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

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

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

      AllNodesAtLatestRevision
3 nodes are at revision 7
      1
      Copy to Clipboard Toggle word wrap
      1
      この例では、最新のリビジョン番号は 7 です。

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

    3. 以下のコマンドを実行して kube-scheduler の新規ロールアウトを強制的に実行します。 

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

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

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

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

      AllNodesAtLatestRevision
3 nodes are at revision 7
      1
      Copy to Clipboard Toggle word wrap
      1
      この例では、最新のリビジョン番号は 7 です。

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

  23. 次のコマンドを実行して、プラットフォーム Operator をモニターします。 

    $ oc adm wait-for-stable-cluster
    Copy to Clipboard Toggle word wrap

    このプロセスには最大 15 分かかる場合があります。

  24. リカバリー手順の後にすべてのワークロードが通常の操作に戻るようにするには、すべてのコントロールプレーンノードを再起動します。

    注記

    前の手順が完了したら、すべてのサービスが復元された状態に戻るまで数分間待つ必要がある場合があります。たとえば、oc login を使用した認証は、OAuth サーバー Pod が再起動するまですぐに機能しない可能性があります。

    即時認証に system:admin kubeconfig ファイルを使用することを検討してください。この方法は、OAuth トークンではなく SSL/TLS クライアント証明書に基づいて認証を行います。以下のコマンドを実行し、このファイルを使用して認証できます。 

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig
    Copy to Clipboard Toggle word wrap

    以下のコマンドを実行て、認証済みユーザー名を表示します。 

    $ oc whoami
    Copy to Clipboard Toggle word wrap
  25. ローリング方式ですべてのワーカーノードを再起動します。

5.12.8. 永続ストレージの状態復元に関する問題および回避策
リンクのコピー

OpenShift Container Platform クラスターがいずれかの形式の永続ストレージを使用する場合に、クラスターの状態は通常 etcd 外に保存されます。etcd バックアップから復元する場合には、OpenShift Container Platform のワークロードのステータスも復元されます。ただし、etcd スナップショットが古い場合には、ステータスは無効または期限切れの可能性があります。

重要

永続ボリューム (PV) の内容は etcd スナップショットには含まれません。etcd スナップショットから OpenShift Container Platform クラスターを復元する時に、重要ではないワークロードから重要なデータにアクセスしたり、その逆ができたりする場合があります。

以下は、古いステータスを生成するシナリオ例です。

  • MySQL データベースが PV オブジェクトでバックアップされる Pod で実行されている。etcd スナップショットから OpenShift Container Platform を復元すると、Pod の起動を繰り返し試行しても、ボリュームをストレージプロバイダーに戻したり、実行中の MySQL Pod が生成したりされるわけではありません。この Pod は、ストレージプロバイダーでボリュームを復元し、次に PV を編集して新規ボリュームを参照するように手動で復元する必要があります。
  • Pod P1 は、ノード X に割り当てられているボリューム A を使用している。別の Pod がノード Y にある同じボリュームを使用している場合に etcd スナップショットが作成された場合に、etcd の復元が実行されると、ボリュームがノード Y に割り当てられていることが原因で Pod P1 が正常に起動できなくなる可能性があります。OpenShift Container Platform はこの割り当てを認識せず、ボリュームが自動的に切り離されるわけではありません。これが生じる場合には、ボリュームをノード Y から手動で切り離し、ノード X に割り当ててることで Pod P1 を起動できるようにします。
  • クラウドプロバイダーまたはストレージプロバイダーの認証情報が etcd スナップショットの作成後に更新された。これが原因で、プロバイダーの認証情報に依存する CSI ドライバーまたは Operator が機能しなくなります。これらのドライバーまたは Operator で必要な認証情報を手動で更新する必要がある場合があります。

  • デバイスが etcd スナップショットの作成後に OpenShift Container Platform ノードから削除されたか、名前が変更された。ローカルストレージ Operator で、/dev/disk/by-id または /dev ディレクトリーから管理する各 PV のシンボリックリンクが作成されます。この状況では、ローカル PV が存在しないデバイスを参照してしまう可能性があります。

    この問題を修正するには、管理者は以下を行う必要があります。

    1. デバイスが無効な PV を手動で削除します。
    2. 各ノードからシンボリックリンクを削除します。
    3. LocalVolume または LocalVolumeSet オブジェクトを削除します (ストレージ → 永続ストレージの設定 → ローカルボリュームを使用した永続ストレージ → ローカルストレージ Operator のリソースの削除 を参照)。

5.13. Pod Disruption Budget
リンクのコピー

Pod Disruption Budget を理解して設定します。

5.13.1. 起動している必要がある Pod の数を Pod Disruption Budget を使用して指定する方法について
リンクのコピー

Pod Disruption Budget を使用すると、メンテナンスのためにノードの drain (Pod の退避) を実行するなど、運用中の Pod に対して安全上の制約を指定できます。

PodDisruptionBudget は、同時に起動している必要のあるレプリカの最小数またはパーセンテージを指定する API オブジェクトです。これらをプロジェクトに設定することは、ノードのメンテナンス (クラスターのスケールダウンまたはクラスターのアップグレードなどの実行) 時に役立ち、この設定は (ノードの障害時ではなく) 自発的な退避の場合にのみ許可されます。

PodDisruptionBudget オブジェクトの設定は、次の主要な部分で構成されます。

  • 一連の Pod に対するラベルのクエリー機能であるラベルセレクター。

  • 同時に利用可能にする必要のある Pod の最小数を指定する可用性レベル。

    • minAvailable は、中断時にも常に利用可能である必要のある Pod 数です。
    • maxUnavailable は、中断時に利用不可にできる Pod 数です。
注記

Available は、Ready=True の状態にある Pod 数を指します。Ready=True は、要求に対応でき、一致するすべてのサービスの負荷分散プールに追加する必要がある Pod を指します。

maxUnavailable の 0% または 0 あるいは minAvailable の 100%、ないしはレプリカ数に等しい値は許可されますが、これによりノードがドレイン (解放) されないようにブロックされる可能性があります。

警告

OpenShift Container Platform のすべてのマシン設定プールにおける maxUnavailable のデフォルト設定は 1 です。この値を変更せず、一度に 1 つのコントロールプレーンノードを更新することを推奨します。コントロールプレーンプールのこの値を 3 に変更しないでください。

次のコマンドで、すべてのプロジェクトの Pod Disruption Budget を確認できます。 

$ oc get poddisruptionbudget --all-namespaces
Copy to Clipboard Toggle word wrap
注記

次の例には、OpenShift Container Platform on AWS に固有の値がいくつか含まれています。

出力例

NAMESPACE                              NAME                                    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
openshift-apiserver                    openshift-apiserver-pdb                 N/A             1                 1                     121m
openshift-cloud-controller-manager     aws-cloud-controller-manager            1               N/A               1                     125m
openshift-cloud-credential-operator    pod-identity-webhook                    1               N/A               1                     117m
openshift-cluster-csi-drivers          aws-ebs-csi-driver-controller-pdb       N/A             1                 1                     121m
openshift-cluster-storage-operator     csi-snapshot-controller-pdb             N/A             1                 1                     122m
openshift-cluster-storage-operator     csi-snapshot-webhook-pdb                N/A             1                 1                     122m
openshift-console                      console                                 N/A             1                 1                     116m
#...
Copy to Clipboard Toggle word wrap

PodDisruptionBudget は、最低でも minAvailable Pod がシステムで実行されている場合は正常であるとみなされます。この制限を超えるすべての Pod は退避の対象となります。

注記

Pod の優先度とプリエンプションの設定によっては、Pod Disruption Budget の要件にもかかわらず、優先度の低い Pod が削除される可能性があります。

5.13.2. 起動している必要がある Pod の数を Pod Disruption Budget を使用して指定する
リンクのコピー

同時に起動している必要のあるレプリカの最小数またはパーセンテージは、PodDisruptionBudget オブジェクトを使用して指定します。

手順

Pod Disruption Budget を設定するには、次の手順を実行します。

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

    apiVersion: policy/v1
    1 
    
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  minAvailable: 2
    2 
    
  selector:
    3 
    
    matchLabels:
      name: my-pod
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
    1
    PodDisruptionBudget は policy/v1 API グループの一部です。
    2
    同時に利用不可にできる Pod の最大数。これには、整数またはパーセンテージ (例: 20%) を指定する文字列を使用できます。
    3
    一連のリソースに対するラベルのクエリー。matchLabels と matchExpressions の結果は論理的に結合されます。プロジェクト内のすべての Pod を選択するには、このパラメーターを空白のままにします (例: selector {})。

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

    $ oc create -f </path/to/file> -n <project_name>
    Copy to Clipboard Toggle word wrap

<