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

インストール後の設定

OpenShift Container Platform 4.20

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 を使用すると、ノードとカスタムリソースを設定できます。

  • クラスター機能の設定: 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 を設定できます。

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

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

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

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 Platform では、内部および外部 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. 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. クラウドプロバイダーの 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.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 get imagestream -n openshift
    Copy to Clipboard Toggle word wrap

    出力例

    NAME   IMAGE REPOSITORY                                                 TAGS     UPDATED
cli    image-registry.openshift-image-registry.svc:5000/openshift/cli   latest   8 hours ago
...
    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 get imagestream -n openshift
    Copy to Clipboard Toggle word wrap

    出力例

    NAME   IMAGE REPOSITORY                                                 TAGS     UPDATED
cli    image-registry.openshift-image-registry.svc:5000/openshift/cli   latest   8 hours ago
...
    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 get imagestream -n openshift
    Copy to Clipboard Toggle word wrap

    出力例

    NAME   IMAGE REPOSITORY                                           TAGS     UPDATED
cli    default-route-openshift-image-registry.<cluster_dns>/cli   latest   8 hours ago
...
    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 クラスターでのマルチアーキテクチャーのコンピュートマシンの設定
リンクのコピー

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

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

注記

クラスター内に複数のアーキテクチャーを持つノードがある場合、イメージのアーキテクチャーはノードのアーキテクチャーと一致している必要があります。Pod が適切なアーキテクチャーを持つノードに割り当てられていること、およびそれがイメージアーキテクチャーと一致していることを確認する必要があります。ノードへの Pod の割り当ての詳細は、ノードへの Pod の割り当て を参照してください。

重要

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

シングルアーキテクチャーのクラスターを、マルチアーキテクチャーのコンピュートマシンをサポートするクラスターに移行する方法は、マルチアーキテクチャーのコンピュートマシンを含むクラスターへの移行 を参照してください。

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

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

Expand
表3.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

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

Google Cloud Platform (GCP)

 

✓

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 Platform (GCP) ではサポートされていません。

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

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

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

3.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
    重要

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

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

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

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

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

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

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

3.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
    重要

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

3.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 Platform (GCP) クラスターを作成するには、まず、マルチアーキテクチャーインストーラーバイナリーを使用して、単一アーキテクチャーの GCP インストーラーによってプロビジョニングされたクラスターを作成する必要があります。AWS へのンストールの詳細は、カスタマイズを使用した GCP へのクラスターのインストール を参照してください。

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

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

注記

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

3.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
    重要

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

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

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

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

  • 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 シングルアーキテクチャー GCP クラスターを作成した。

手順

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

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

    GCP の 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 のペアの形式でカスタムメタデータを指定します。ユースケースの例は、カスタムメタデータの設定 について GCP のドキュメントを参照してください。
    5
    選択した OS イメージの CPU アーキテクチャーに合ったマシンタイプを指定します。詳細は、「64 ビット ARM インフラストラクチャー上の GCP のテスト済みのインスタンスタイプ」を参照してください。
    6
    クラスターに使用する GCP プロジェクトの名前を指定します。
    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 を使用してマルチアーキテクチャークラスター上のワークロードを管理する を参照してください。

3.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
    重要

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

3.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/bootstrap.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b
    Copy to Clipboard Toggle word wrap

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

    重要

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

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

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

3.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.33.4
master-1  Ready     master  63m  v1.33.4
master-2  Ready     master  64m  v1.33.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.33.4
master-1  Ready     master  73m  v1.33.4
master-2  Ready     master  74m  v1.33.4
worker-0  Ready     worker  11m  v1.33.4
worker-1  Ready     worker  11m  v1.33.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 を使用してマルチアーキテクチャークラスター上のワークロードを管理する を参照してください。

3.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
    重要

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

3.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 を参照してください。

3.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.33.4
master-1  Ready     master  63m  v1.33.4
master-2  Ready     master  64m  v1.33.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.33.4
master-1  Ready     master  73m  v1.33.4
master-2  Ready     master  74m  v1.33.4
worker-0  Ready     worker  11m  v1.33.4
worker-1  Ready     worker  11m  v1.33.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 コンピュートマシンを追加できます。

3.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
    重要

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

3.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. マシンを起動します。

3.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.33.4
master-1  Ready     master  63m  v1.33.4
master-2  Ready     master  64m  v1.33.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.33.4
master-1  Ready     master  73m  v1.33.4
master-2  Ready     master  74m  v1.33.4
worker-0  Ready     worker  11m  v1.33.4
worker-1  Ready     worker  11m  v1.33.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 を使用してマルチアーキテクチャークラスター上のワークロードを管理する を参照してください。

3.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
    重要

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

3.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. 継続してクラスター用の追加のコンピュートマシンを作成します。

3.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.33.4
master-1  Ready     master  63m  v1.33.4
master-2  Ready     master  64m  v1.33.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.33.4
master-1  Ready     master  73m  v1.33.4
master-2  Ready     master  74m  v1.33.4
worker-0  Ready     worker  11m  v1.33.4
worker-1  Ready     worker  11m  v1.33.4
    Copy to Clipboard Toggle word wrap

    注記

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

関連情報

3.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 を使用してマルチアーキテクチャークラスター上のワークロードを管理する を参照してください。

3.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
    重要

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

3.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/bootstrap.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b
    Copy to Clipboard Toggle word wrap

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

    重要

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

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

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

3.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.33.4
master-1  Ready     master  63m  v1.33.4
master-2  Ready     master  64m  v1.33.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.33.4   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.33.4-3.rhaos4.15.gitb36169e.el9
worker-1-ppc64le   Ready    worker                 42d   v1.33.4   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.33.4-3.rhaos4.15.gitb36169e.el9
master-0-x86       Ready    control-plane,master   75d   v1.33.4   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.33.4-3.rhaos4.15.gitb36169e.el9
master-1-x86       Ready    control-plane,master   75d   v1.33.4   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.33.4-3.rhaos4.15.gitb36169e.el9
master-2-x86       Ready    control-plane,master   75d   v1.33.4   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.33.4-3.rhaos4.15.gitb36169e.el9
worker-0-x86       Ready    worker                 75d   v1.33.4   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.33.4-3.rhaos4.15.gitb36169e.el9
worker-1-x86       Ready    worker                 75d   v1.33.4   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.33.4-3.rhaos4.15.gitb36169e.el9
    Copy to Clipboard Toggle word wrap

    注記

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

関連情報

3.10. マルチアーキテクチャーコンピュートマシンを含むクラスターの管理
リンクのコピー

複数のアーキテクチャーを使用するノードを含むクラスターを管理するには、クラスターを監視してワークロードを管理するときに、ノードアーキテクチャーを考慮する必要があります。そのため、クラスターリソースの要件と動作を設定するとき、またはマルチアーキテクチャークラスターでワークロードをスケジュールするときには、追加事項を考慮する必要があります。

異なるアーキテクチャーを使用するコンピュートノードを含むクラスターにワークロードをデプロイする場合は、基盤となるノードのアーキテクチャーに Pod アーキテクチャーを合わせる必要があります。ワークロードによっては、基盤となるノードのアーキテクチャーに応じて、特定のリソースに対する追加の設定が必要になる場合もあります。

Multiarch Tuning Operator を使用すると、マルチアーキテクチャーコンピュートマシンを含むクラスターで、アーキテクチャーを考慮したワークロードのスケジューリングを有効にできます。Multiarch Tuning Operator は、Pod が作成時にサポートできるアーキテクチャーに基づいて、Pod 仕様に追加のスケジューラー述語を実装します。

3.10.1.1. マルチアーキテクチャーノードのワークロードデプロイメントのサンプル
リンクのコピー

アーキテクチャーに基づいて適切なノードにワークロードをスケジュールする方法は、他のノード特性に基づいてスケジュールする方法と同じです。ワークロードのスケジュール方法を決定するときは、次の選択肢を考慮してください。

nodeAffinity を使用して特定のアーキテクチャーのノードをスケジュールする

イメージによってサポートされるアーキテクチャーを持つ一連のノード上でのみワークロードをスケジュールできるようにすることができ、Pod のテンプレート仕様で spec.affinity.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 オブジェクトをスケールダウンするか、既存の使用可能なマシンを削除する必要があります。詳細は、コンピュートマシンセットの変更 を参照してください。 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata: # ...
spec:
  # ...
  template:
    # ...
    spec:
      # ...
      taints:
      - effect: NoSchedule
        key: multiarch.openshift.io/arch
        value: arm64
Copy to Clipboard Toggle word wrap

次のコマンドを実行して、特定のノードに taint を設定することもできます。 

$ oc adm taint nodes <node-name> multiarch.openshift.io/arch=arm64:NoSchedule
Copy to Clipboard Toggle word wrap
namespace にデフォルトの toleration を作成する

ノードまたはマシンセットに taint を付与すると、スケジュールできるワークロードが、その taint を許容するワークロードだけになります。次のコマンドを実行すると、namespace にアノテーションを付けて、すべてのワークロードに同じデフォルトの toleration を適用できます。 

$ oc annotate namespace my-namespace \
  'scheduler.alpha.kubernetes.io/defaultTolerations'='[{"operator": "Exists", "effect": "NoSchedule", "key": "multiarch.openshift.io/arch"}]'
Copy to Clipboard Toggle word wrap
ワークロードでアーキテクチャーの taint を許容する

ノードまたはマシンセットに taint を付与すると、スケジュールできるワークロードが、その taint を許容するワークロードだけになります。toleration を使用してワークロードを設定すると、特定のアーキテクチャー taint を持つノードでワークロードをスケジュールできます。 

apiVersion: apps/v1
kind: Deployment
metadata: # ...
spec:
  # ...
  template:
    # ...
    spec:
      tolerations:
      - key: "multiarch.openshift.io/arch"
        value: "arm64"
        operator: "Equal"
        effect: "NoSchedule"
Copy to Clipboard Toggle word wrap

このサンプルのデプロイメントは、multiarch.openshift.io/arch=arm64 が指定されているノードおよびマシンセットでスケジュールできます。

ノードアフィニティーを taint と toleration とともに使用する

Pod をスケジュールするためのノードセットがスケジューラーによって計算されるとき、そのノードセットは toleration によって拡張される一方で、ノードアフィニティーによって制限されます。特定のアーキテクチャーを持つノードに taint を設定する場合は、そこにスケジュールするワークロードに toleration を追加する必要もあります。 

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: "multiarch.openshift.io/arch"
        value: "arm64"
        operator: "Equal"
        effect: "NoSchedule"
Copy to Clipboard Toggle word wrap

関連情報

3.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.20 クラスターでは、クラスター内のイメージストリームによってマニフェストリストが自動的にインポートされません。マニフェストリストをインポートするには、デフォルトの 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 プラグイン内の設定を無視します。

3.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 を使用してソフトウェアカタログからインストールする」を参照してください。

検証

  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

3.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. Ecosystem → Software Catalog に移動します。
  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. Ecosystem → Installed Operators に移動します。
  2. Multiarch Tuning Operator が、openshift-multiarch-tuning-operator namespace の Status フィールドに Succeeded としてリストされていることを確認します。

3.11.3. Multiarch Tuning Operator Pod ラベルとアーキテクチャーサポートの概要
リンクのコピー

Multiarch Tuning Operator をインストールした後、クラスター内のワークロードに対するマルチアーキテクチャーのサポートを確認できます。Pod ラベルを使用して、アーキテクチャーの互換性に基づき Pod を識別および管理できます。これらのラベルは、アーキテクチャーサポートに関する情報を提供するために、新しく作成された Pod に自動的に設定されます。

次の表は、Pod の作成時に Multiarch Tuning Operator が追加するラベルを説明しています。

Expand
表3.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 でアーキテクチャー優先設定を指定しませんでした。

3.11.4. ClusterPodPlacementConfig オブジェクトの作成
リンクのコピー

Multiarch Tuning Operator をインストールした後、ClusterPodPlacementConfig オブジェクトを作成する必要があります。このオブジェクトは、Operator にオペランドをデプロイするように指示します。これにより、クラスター全体でアーキテクチャーを考慮したワークロードのスケジューリングが可能になります。

ClusterPodPlacementConfig オブジェクトは、次の 2 つのオプションプラグインをサポートしています。

  • ノードアフィニティースコアリング プラグインは、ユーザーが指定したアーキテクチャーに対して、重み付けされたアフィニティーを使用して緩やかな優先設定を指定するために、Pod にパッチを適用します。Pod は、重みが大きいアーキテクチャーを実行しているノードにスケジュールされる可能性が高くなります。
  • exec フォーマットエラーモニター プラグインは、Pod がノードのアーキテクチャーと互換性のないバイナリーを実行しようとしたときに発生する ENOEXEC エラーを検出します。有効にすると、このプラグインにより、影響を受ける Pod のイベントストリームにイベントが生成されます。過去 6 時間以内に 1 つ以上の ENOEXEC エラーが検出されると、ExecFormatErrorsDetected Prometheus アラートがトリガーされます。このエラーは、不正なアーキテクチャーノードセレクター、アーキテクチャーを考慮したワークロードスケジューリングに影響する無効なイメージメタデータ、イメージ内の不正なバイナリー、または実行時に注入された互換性のないバイナリーによって発生する可能性があります。
注記

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
    execFormatErrorMonitor:
      enabled: true
10
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 を配置するノードを優先順位付けし、スコアが高いアーキテクチャーのノードを優先します。
10
オプション: execFormatErrorMonitor プラグインを有効にするには、このフィールドを true に設定します。有効にすると、このプラグインにより ENOEXEC エラーが検出されます。このエラーは、Pod がノードのアーキテクチャーと互換性のないバイナリーを実行したときに発生します。このプラグインは、影響を受ける Pod でイベントを生成し、過去 6 時間以内に 1 つ以上のエラーが見つかった場合は、ExecFormatErrorsDetected Prometheus アラートをトリガーします。

この例では、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 も除外されます。

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

3.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. Ecosystem → 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 状態であることを確認します。

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

3.11.6. Web コンソールを使用した ClusterPodPlacementConfig オブジェクトの削除
リンクのコピー

ClusterPodPlacementConfig オブジェクトのインスタンスは 1 つだけ作成できます。このオブジェクトを再作成する場合は、まず既存のインスタンスを削除する必要があります。

OpenShift Container Platform Web コンソールを使用してこのオブジェクトを削除できます。

前提条件

  • cluster-admin 権限でクラスターにアクセスできる。
  • OpenShift Container Platform Web コンソールにアクセスできる。
  • ClusterPodPlacementConfig オブジェクトを作成した。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. Ecosystem → Installed Operators に移動します。
  3. Installed Operators ページで、Multiarch Tuning Operator をクリックします。
  4. Cluster Pod Placement Config タブをクリックします。
  5. オプションメニューから Delete ClusterPodPlacementConfig を選択します。
  6. Delete をクリックします。

検証

  • Cluster Pod Placement Config ページで、ClusterPodPlacementConfig オブジェクトが削除されていることを確認します。

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

3.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. Ecosystem → Software Catalog に移動します。
  3. 検索フィールドに Multiarch Tuning Operator と入力します。
  4. Multiarch Tuning Operator をクリックします。
  5. Details タブをクリックします。
  6. Actions メニューから、Uninstall Operator を選択します。
  7. プロンプトが表示されたら、Uninstall をクリックします。

検証

  1. Ecosystem → Installed Operators に移動します。
  2. Installed Operator ページで、Multiarch Tuning Operator がリストされていないことを確認します。

3.12. Multiarch Tuning Operator のリリースノート
リンクのコピー

Multiarch Tuning Operator は、マルチアーキテクチャークラスター内およびマルチアーキテクチャー環境に移行するシングルアーキテクチャークラスター内のワークロード管理を最適化します。

これらのリリースノートでは、Multiarch Tuning Operator の開発を追跡します。

詳細は、Multiarch Tuning Operator を使用してマルチアーキテクチャークラスター上のワークロードを管理する を参照してください。

3.12.1. Multiarch Tuning Operator 1.2.0 のリリースノート
リンクのコピー

発行日: 2025 年 10 月 22 日

3.12.1.1. 新機能および機能拡張
リンクのコピー
  • このリリースでは、Multiarch Tuning Operator の exec フォーマットエラーモニター プラグインを有効にできます。このプラグインは、Pod がノードのアーキテクチャーと互換性のないバイナリーを実行しようとしたときに発生する ENOEXEC エラーを検出します。このプラグインを有効にするには、ClusterPodPlacementConfig オブジェクトで plugins.execFormatErrorMonitor.enabled パラメーターを true に設定します。詳細は、ClusterPodPlacementConfig オブジェクトの作成 を参照してください。
3.12.1.2. バグ修正
リンクのコピー
  • 以前は、Multiarch Tuning Operator は Operator バンドルイメージインスペクターを不適切に処理し、それを単一のアーキテクチャーに制限していたため、Operator のインストール時に OLM が失敗する可能性がありました。この更新により、MTO はバンドルイメージをすべてのアーキテクチャーに対応するように設定するようになりました。これにより、Multiarch Tuning Operator がデプロイされている場合も、Operator をシングルアーキテクチャーのクラスターに正常にインストールできるようになりました。(MULTIARCH-5546)
  • 以前は、クラスターのグローバルプルシークレットが変更されると、古い認証情報が Multiarch Tuning Operator キャッシュに残る可能性がありました。この更新により、クラスターのグローバルプルシークレットが変更されるたびにキャッシュがクリアされるようになりました。(MULTIARCH-5538)
  • 以前は、イメージ参照にタグとダイジェストの両方が含まれている場合、Multiarch Tuning Operator が Pod の処理に失敗していました。この更新により、両方とも存在する場合に、イメージインスペクターによってダイジェストが優先されるようになりました。(MULTIARCH-5584)
  • 以前は、ワークロードイメージでレジストリー URL が指定されていない場合、Multiarch Tuning Operator が config.openshift.io/Image カスタムリソースの .spec.registrySources.containerRuntimeSearchRegistries フィールドを考慮していませんでした。この更新により、Operator がこのケースを処理できるようになり、明示的なレジストリー URL のないワークロードイメージを正常にプルできるようになりました。(MULTIARCH-5611)
  • 以前は、ClusterPodPlacementConfig オブジェクトが作成後 1 秒以内に削除された場合、一部のファイナライザーが時間内に削除されず、特定のリソースが残っていました。この更新により、ClusterPodPlacementConfig オブジェクトが削除されると、すべてのファイナライザーが適切に削除されるようになりました。(MULTIARCH-5372)

3.12.2. Multiarch Tuning Operator 1.1.1 のリリースノート
リンクのコピー

発行日: 2025 年 5 月 27 日

3.12.2.1. バグ修正
リンクのコピー

  • 以前は、Pod 配置オペランドが、プルシークレットのホスト名にワイルドカードエントリーを使用してレジストリーを認証することをサポートしていませんでした。そのため、イメージをプルするときの Kubelet の動作に一貫性がありませんでした。Kubelet はワイルドカードエントリーをサポートしていましたが、オペランドにはホスト名の正確なマッチが必要であったためです。その結果、レジストリーがワイルドカードホスト名を使用する場合にイメージのプルが予期せず失敗する可能性がありました。

    このリリースでは、Pod 配置オペランドはワイルドカードホスト名を含むプルシークレットをサポートしています。これにより、イメージ認証とプルの一貫性と信頼性が確保されます。

  • 以前は、すべての再試行の実行後にイメージ検査が失敗し、nodeAffinityScoring プラグインが有効である場合、Pod 配置オペランドによって誤った nodeAffinityScoring ラベルが適用されていました。

    このリリースでは、イメージ検査が失敗した場合でも、オペランドは nodeAffinityScoring ラベルを正しく設定します。このラベルは、スケジュールの正確性と一貫性を確保するために、必要なアフィニティープロセスとは別に適用されます。

3.12.3. Multiarch Tuning Operator 1.1.0 のリリースノート
リンクのコピー

発行日: 2024 年 3 月 18 日

3.12.3.1. 新機能および機能拡張
リンクのコピー
  • Multiarch Tuning Operator は、ROSA with Hosted Control Plane (HCP) やその他の HCP 環境など、マネージドサービスでサポートされるようになりました。
  • このリリースでは、ClusterPodPlacementConfig オブジェクトの新しい plugins フィールドを使用して、アーキテクチャーを考慮したワークロードスケジューリングを設定できます。plugins.nodeAffinityScoring フィールドを使用して、Pod 配置用のアーキテクチャー優先設定を指定できます。nodeAffinityScoring プラグインを有効にすると、スケジューラーによって、まず Pod の要件を満たさないノードが除外されます。次に、nodeAffinityScoring.platforms フィールドで定義されたアーキテクチャースコアに基づいて、残りのノードに優先順位が付けられます。
3.12.3.1.1. バグ修正
リンクのコピー
  • このリリースでは、Multiarch Tuning Operator は、デーモンセットによって管理される Pod の nodeAffinity フィールドを更新しません。(OCPBUGS-45885)

3.12.4. Multiarch Tuning Operator 1.0.0 のリリースノート
リンクのコピー

発行日: 2024 年 10 月 31 日

3.12.4.1. 新機能および機能拡張
リンクのコピー
  • このリリースでは、Multiarch Tuning Operator はカスタムネットワークシナリオとクラスター全体のカスタムレジストリー設定をサポートします。
  • このリリースでは、Multiarch Tuning Operator が新しく作成された Pod に追加する Pod ラベルを使用して、アーキテクチャーの互換性に基づき Pod を識別できます。
  • このリリースでは、Cluster Monitoring Operator に登録されているメトリクスとアラートを使用して、Multiarch Tuning Operator の動作を監視できます。

第4章 インストール後のクラスタータスク
リンクのコピー

OpenShift Container Platform のインストール後に、クラスターをさらに拡張し、要件に合わせてカスタマイズできます。

4.1. 利用可能なクラスターのカスタマイズ
リンクのコピー

OpenShift Container Platform クラスターのデプロイ後は、大半のクラスター設定およびカスタマイズが終了していることになります。数多くの 設定リソース が利用可能です。

注記

クラスターを IBM Z® にインストールする場合は、すべての特長および機能が利用可能である訳ではありません。

イメージレジストリー、ネットワーク設定、イメージビルドの動作およびアイデンティティープロバイダーなどのクラスターの主要な機能を設定するために設定リソースを変更します。

これらのリソースを使用して制御する設定の現在の記述は、oc explain コマンドを使用します (例: oc explain builds --api-version=config.openshift.io/v1)。

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

プロファイルやデフォルトのノードセレクターなどの スケジューラー の動作を設定します。

4.1.2. Operator 設定リソース
リンクのコピー

これらの設定リソースは、cluster という名前のクラスタースコープのインスタンスです。これは、特定の Operator によって所有される特定コンポーネントの動作を制御します。

Expand
リソース名説明

consoles.operator.openshift.io

ブランドのカスタマイズなどのコンソールの外観の制御

config.imageregistry.operator.openshift.io

パブリックルーティング、ログレベル、プロキシー設定、リソース制約、レプリカ数、ストレージタイプなどの OpenShift イメージレジストリー設定 を指定します。

config.samples.operator.openshift.io

Samples Operator を設定して、クラスターにインストールされるイメージストリームとテンプレートのサンプルを制御します。

4.1.3. 追加の設定リソース
リンクのコピー

これらの設定リソースは、特定コンポーネントの単一インスタンスを表します。場合によっては、リソースの複数のインスタンスを作成して、複数のインスタンスを要求できます。他の場合には、Operator は特定の namespace の特定のリソースインスタンス名のみを使用できます。追加のリソースインスタンスの作成方法や作成するタイミングの詳細は、コンポーネント固有のドキュメントを参照してください。

Expand
リソース名インスタンス名Namespace説明

alertmanager.monitoring.coreos.com

main

openshift-monitoring

Alertmanager のデプロイメントパラメーターを制御します。

ingresscontroller.operator.openshift.io

default

openshift-ingress-operator

ドメイン、レプリカ数、証明書、およびコントローラーの配置など、Ingress Operator の動作を設定します。

4.1.4. 情報リソース
リンクのコピー

これらのリソースを使用して、クラスターに関する情報を取得します。設定によっては、これらのリソースの直接編集が必要になる場合があります。

Expand
リソース名インスタンス名説明

clusterversion.config.openshift.io

version

OpenShift Container Platform 4.20 では、実稼働クラスターの ClusterVersion リソースをカスタマイズすることはできません。代わりに、クラスターを更新 するプロセスを実行してください。

dns.config.openshift.io

cluster

クラスターの DNS 設定を変更することはできません。DNS Operator のステータスを確認 できます。

infrastructure.config.openshift.io

cluster

クラスターはそのクラウドプロバイダーとの対話を可能にする設定の詳細。

network.config.openshift.io

cluster

インストール後にクラスターのネットワークを変更することはできません。ネットワークをカスタマイズするには、インストール時にネットワークをカスタマイズする プロセスを実行します。

4.2. ワーカーノードの追加
リンクのコピー

OpenShift Container Platform クラスターをデプロイしたら、ワーカーノードを追加してクラスターリソースをスケーリングできます。インストール方法とクラスターの環境に応じて、ワーカーノードを追加するさまざまな方法があります。

4.2.1. オンプレミスクラスターにワーカーノードを追加する
リンクのコピー

オンプレミスクラスターの場合、OpenShift Container Platform CLI (oc) を使用してワーカーノードを追加し、ISO イメージを生成できます。その後、このイメージを使用して、ターゲットクラスター内の 1 つ以上のノードを起動できます。このプロセスは、クラスターのインストール方法に関係なく使用できます。

静的ネットワーク設定などのより複雑な設定で各ノードをカスタマイズしながら一度に 1 つ以上のノードを追加することも、各ノードの MAC アドレスのみを指定することもできます。ISO 生成中に指定されなかった設定は、ターゲットクラスターから取得され、新しいノードに適用されます。

ISO イメージの起動時にも事前検証チェックが実行され、各ノードの起動を試みる前に障害の原因となる問題が通知されます。

オンプレミスクラスターにワーカーノードを追加する

4.2.2. installer-provisioned infrastructure へのワーカーノードの追加
リンクのコピー

installer-provisioned infrastructure クラスターの場合、MachineSet オブジェクトを手動または自動でスケーリングして、利用可能なベアメタルホストの数に一致させることができます。

ベアメタルホストを追加するには、すべてのネットワーク前提条件を設定し、関連する baremetalhost オブジェクトを設定してから、クラスターにワーカーノードをプロビジョニングする必要があります。手動で、または Web コンソールを使用して、ベアメタルホストを追加できます。

4.2.3. user-provisioned infrastructure クラスターへのワーカーノードの追加
リンクのコピー

user-provisioned infrastructure クラスターの場合、RHEL または RHCOS ISO イメージを使用し、クラスター Ignition 設定ファイルを使用してこれをクラスターに接続することで、ワーカーノードを追加できます。RHEL ワーカーノードの場合、次の例では、Ansible Playbook を使用してクラスターにワーカーノードを追加します。RHCOS ワーカーノードの場合、次の例では、ISO イメージとネットワークブートを使用してワーカーノードをクラスターに追加します。

4.2.4. Assisted Installer によって管理されるクラスターへのワーカーノードの追加
リンクのコピー

Assisted Installer によって管理されるクラスターの場合、Red Hat OpenShift Cluster Manager コンソール、Assisted Installer REST API を使用してワーカーノードを追加するか、ISO イメージとクラスター Ignition 設定ファイルを使用してワーカーノードを手動で追加することができます。

Kubernetes のマルチクラスターエンジンによって管理されるクラスターの場合、専用のマルチクラスターエンジンコンソールを使用してワーカーノードを追加することができます。

4.3. ワーカーノードの調整
リンクのコピー

デプロイメント時にワーカーノードのサイズを誤って設定した場合には、1 つ以上の新規コンピュートマシンセットを作成してそれらをスケールアップしてから、元のコンピュートマシンセットを削除する前にスケールダウンしてこれらのワーカーノードを調整します。

4.3.1. コンピュートマシンセットとマシン設定プールの相違点について
リンクのコピー

MachineSet オブジェクトは、クラウドまたはマシンプロバイダーに関する OpenShift Container Platform ノードを記述します。

MachineConfigPool オブジェクトにより、MachineConfigController コンポーネントがアップグレードのコンテキストでマシンのステータスを定義し、提供できるようになります。

MachineConfigPool オブジェクトにより、ユーザーはマシン設定プールの OpenShift Container Platform ノードにアップグレードをデプロイメントする方法を設定できます。

NodeSelector オブジェクトは MachineSet オブジェクトへの参照に置き換えることができます。

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

4.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 にスケーリングできません。

注記

カスタムのコンピュートマシンセットは、サービスを特定のノードサービスで実行し、それらのサービスがワーカーのコンピュートマシンセットのスケールダウン時にコントローラーによって無視されるようにする必要があるユースケースで使用できます。これにより、サービスの中断が回避されます。

4.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.33.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.33.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 つのパラメーターセットが含まれています。パラメーターは、遅延の増加に対するクラスターの反応を制御するように、慎重に調整された値で事前定義されています。試験により手作業で最良の値を見つける必要はありません。

クラスターのインストール時、またはクラスターネットワークのレイテンシーの増加に気付いたときはいつでも、ワーカーレイテンシープロファイルを設定できます。

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

注記

レイテンシープロファイルは、カスタムのマシン設定プールをサポートしていません。デフォルトのワーカーマシン設定プールのみをサポートしていします。

4.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 パラメーターを適切な値に設定します。

4.5. コントロールプレーンマシンの管理
リンクのコピー

コントロールプレーンマシンセット は、コンピュートマシンセットがコンピュートマシンに提供するものと同様の管理機能をコントロールプレーンマシンに提供します。クラスター上のコントロールプレーンマシンセットの可用性と初期ステータスは、クラウドプロバイダーと、インストールした OpenShift Container Platform のバージョンによって異なります。詳細は、コントロールプレーンマシンセットのスタートガイド を参照してください。

4.5.1. クラスターへのコントロールプレーンノードの追加
リンクのコピー

ベアメタルインフラストラクチャーにクラスターをインストールする場合、クラスターのコントロールプレーンノードを最大 4 つまたは 5 つまで手動でスケーリングできます。この手順の例では、新しいコントロールプレーンノードとして node-5 を使用します。

前提条件

  • 少なくとも 3 つのコントロールプレーンノードを持つ正常なクラスターをインストールした。
  • インストール後のタスクとしてクラスターに追加するコントロールプレーンノードを 1 つ作成した。

手順

  1. 次のコマンドを入力して、新しいコントロールプレーンノードの保留中の証明書署名要求 (CSR) を取得します。 

    $ oc get csr | grep Pending
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを入力して、コントロールプレーンノードの保留中の 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
    重要

    インストールを完了するには、CSR を承認する必要があります。

  3. 次のコマンドを入力して、コントロールプレーンノードが Ready ステータスになっていることを確認します。 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap
    注記

    installer-provisioned infrastructure では、etcd Operator が Machine API を利用してコントロールプレーンを管理し、etcd クォーラムを確保します。Machine API は Machine CR を使用して、基盤となるコントロールプレーンノードを表現および管理します。

  4. BareMetalHost および Machine CR を作成し、それらをコントロールプレーンノードの Node CR にリンクします。

    1. 次の例に示すように、一意の .metadata.name 値を持つ BareMetalHost CR を作成します。 

      apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: node-5
  namespace: openshift-machine-api
spec:
  automatedCleaningMode: metadata
  bootMACAddress: 00:00:00:00:00:02
  bootMode: UEFI
  customDeploy:
    method: install_coreos
  externallyProvisioned: true
  online: true
  userData:
    name: master-user-data-managed
    namespace: openshift-machine-api
# ...
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを入力して、BareMetalHost CR を適用します。 

      $ oc apply -f <filename>
      1
      Copy to Clipboard Toggle word wrap
      1
      <filename> は BareMetalHost CR の名前に置き換えます。

    3. 次の例に示すように、一意の .metadata.name 値を使用して Machine CR を作成します。 

      apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  annotations:
    machine.openshift.io/instance-state: externally provisioned
    metal3.io/BareMetalHost: openshift-machine-api/node-5
  finalizers:
  - machine.machine.openshift.io
  labels:
    machine.openshift.io/cluster-api-cluster: <cluster_name>
      1 
      
    machine.openshift.io/cluster-api-machine-role: master
    machine.openshift.io/cluster-api-machine-type: master
  name: node-5
  namespace: openshift-machine-api
spec:
  metadata: {}
  providerSpec:
    value:
      apiVersion: baremetal.cluster.k8s.io/v1alpha1
      customDeploy:
        method: install_coreos
      hostSelector: {}
      image:
        checksum: ""
        url: ""
      kind: BareMetalMachineProviderSpec
      metadata:
        creationTimestamp: null
      userData:
        name: master-user-data-managed
# ...
      Copy to Clipboard Toggle word wrap
      1
      <cluster_name> は、特定のクラスターの名前に置き換えます (例: test-day2-1-6qv96)。

    4. 次のコマンドを実行してクラスター名を取得します。 

      $ oc get infrastructure cluster -o=jsonpath='{.status.infrastructureName}{"\n"}'
      Copy to Clipboard Toggle word wrap

    5. 次のコマンドを入力して、Machine CR を適用します。 

      $ oc apply -f <filename>
      1
      Copy to Clipboard Toggle word wrap
      1
      <filename> は Machine CR の名前に置き換えます。

    6. link-machine-and-node.sh スクリプトを実行して、BareMetalHost、Machine、および Node オブジェクトをリンクします。

      1. 次の link-machine-and-node.sh スクリプトをローカルマシンにコピーします。 

        #!/bin/bash

# Credit goes to
# https://bugzilla.redhat.com/show_bug.cgi?id=1801238.
# This script will link Machine object
# and Node object. This is needed
# in order to have IP address of
# the Node present in the status of the Machine.

set -e

machine="$1"
node="$2"

if [ -z "$machine" ] || [ -z "$node" ]; then
    echo "Usage: $0 MACHINE NODE"
    exit 1
fi

node_name=$(echo "${node}" | cut -f2 -d':')

oc proxy &
proxy_pid=$!
function kill_proxy {
    kill $proxy_pid
}
trap kill_proxy EXIT SIGINT

HOST_PROXY_API_PATH="http://localhost:8001/apis/metal3.io/v1alpha1/namespaces/openshift-machine-api/baremetalhosts"

function print_nics() {
    local ips
    local eob
    declare -a ips

    readarray -t ips < <(echo "${1}" \
                         | jq '.[] | select(. | .type == "InternalIP") | .address' \
                         | sed 's/"//g')

    eob=','
    for (( i=0; i<${#ips[@]}; i++ )); do
        if [ $((i+1)) -eq ${#ips[@]} ]; then
            eob=""
        fi
        cat <<- EOF
          {
            "ip": "${ips[$i]}",
            "mac": "00:00:00:00:00:00",
            "model": "unknown",
            "speedGbps": 10,
            "vlanId": 0,
            "pxe": true,
            "name": "eth1"
          }${eob}
EOF
    done
}

function wait_for_json() {
    local name
    local url
    local curl_opts
    local timeout

    local start_time
    local curr_time
    local time_diff

    name="$1"
    url="$2"
    timeout="$3"
    shift 3
    curl_opts="$@"
    echo -n "Waiting for $name to respond"
    start_time=$(date +%s)
    until curl -g -X GET "$url" "${curl_opts[@]}" 2> /dev/null | jq '.' 2> /dev/null > /dev/null; do
        echo -n "."
        curr_time=$(date +%s)
        time_diff=$((curr_time - start_time))
        if [[ $time_diff -gt $timeout ]]; then
            printf '\nTimed out waiting for %s' "${name}"
            return 1
        fi
        sleep 5
    done
    echo " Success!"
    return 0
}
wait_for_json oc_proxy "${HOST_PROXY_API_PATH}" 10 -H "Accept: application/json" -H "Content-Type: application/json"

addresses=$(oc get node -n openshift-machine-api "${node_name}" -o json | jq -c '.status.addresses')

machine_data=$(oc get machines.machine.openshift.io -n openshift-machine-api -o json "${machine}")
host=$(echo "$machine_data" | jq '.metadata.annotations["metal3.io/BareMetalHost"]' | cut -f2 -d/ | sed 's/"//g')

if [ -z "$host" ]; then
    echo "Machine $machine is not linked to a host yet." 1>&2
    exit 1
fi

# The address structure on the host doesn't match the node, so extract
# the values we want into separate variables so we can build the patch
# we need.
hostname=$(echo "${addresses}" | jq '.[] | select(. | .type == "Hostname") | .address' | sed 's/"//g')

set +e
read -r -d '' host_patch << EOF
{
  "status": {
    "hardware": {
      "hostname": "${hostname}",
      "nics": [
$(print_nics "${addresses}")
      ],
      "systemVendor": {
        "manufacturer": "Red Hat",
        "productName": "product name",
        "serialNumber": ""
      },
      "firmware": {
        "bios": {
          "date": "04/01/2014",
          "vendor": "SeaBIOS",
          "version": "1.11.0-2.el7"
        }
      },
      "ramMebibytes": 0,
      "storage": [],
      "cpu": {
        "arch": "x86_64",
        "model": "Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz",
        "clockMegahertz": 2199.998,
        "count": 4,
        "flags": []
      }
    }
  }
}
EOF
set -e

echo "PATCHING HOST"
echo "${host_patch}" | jq .

curl -s \
     -X PATCH \
     "${HOST_PROXY_API_PATH}/${host}/status" \
     -H "Content-type: application/merge-patch+json" \
     -d "${host_patch}"

oc get baremetalhost -n openshift-machine-api -o yaml "${host}"
        Copy to Clipboard Toggle word wrap

      2. 次のコマンドを入力して、スクリプトを実行可能にします。 

        $ chmod +x link-machine-and-node.sh
        Copy to Clipboard Toggle word wrap

      3. 次のコマンドを入力して、スクリプトを実行します。 

        $ bash link-machine-and-node.sh node-5 node-5
        Copy to Clipboard Toggle word wrap
        注記

        最初の node-5 インスタンスはマシンを表し、2 番目のインスタンスはノードを表します。

検証

  1. 既存のコントロールプレーンノードの 1 つを実行して、etcd のメンバーを確認します。

    1. 次のコマンドを入力して、コントロールプレーンノードへのリモートシェルセッションを開きます。 

      $ oc rsh -n openshift-etcd etcd-node-0
      Copy to Clipboard Toggle word wrap

    2. etcd のメンバーをリスト表示します。 

      # etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

  2. 次のコマンドを入力して、etcd Operator の設定プロセスが完了するまで確認を続けます。期待される出力では、PROGRESSING 列に False と表示されます。 

    $ oc get clusteroperator etcd
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、etcd の健全性を確認します。

    1. コントロールプレーンノードへのリモートシェルセッションを開きます。 

      $ oc rsh -n openshift-etcd etcd-node-0
      Copy to Clipboard Toggle word wrap

    2. エンドポイントの健全性を確認します。期待される出力では、エンドポイントに対して is healthy と表示されます。 

      # etcdctl endpoint health
      Copy to Clipboard Toggle word wrap

  4. 次のコマンドを入力して、すべてのノードが準備完了状態であることを確認します。期待される出力では、各ノードエントリーの横に Ready ステータスが表示されます。 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

  5. 次のコマンドを入力して、クラスター Operator がすべて利用可能であることを確認します。期待される出力では、各 Operator がリストされ、リストされた各 Operator の横に利用可能な状態を示す True が表示されます。 

    $ oc get ClusterOperators
    Copy to Clipboard Toggle word wrap

  6. 次のコマンドを入力して、クラスターのバージョンが正しいことを確認します。 

    $ oc get ClusterVersion
    Copy to Clipboard Toggle word wrap

    出力例

    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   OpenShift Container Platform.5    True        False         5h57m   Cluster version is OpenShift Container Platform.5
    Copy to Clipboard Toggle word wrap

4.6. 実稼働環境用のインフラストラクチャーマシンセットの作成
リンクのコピー

コンピュートマシンセットを作成して、デフォルトのルーター、統合コンテナーイメージレジストリー、およびクラスターメトリクスおよびモニタリングのコンポーネントなどのインフラストラクチャーコンポーネントのみをホストするマシンを作成できます。これらのインフラストラクチャーマシンは、環境の実行に必要なサブスクリプションの合計数にカウントされません。

実稼働デプロイメントでは、インフラストラクチャーコンポーネントを保持するために 3 つ以上のコンピュートマシンセットをデプロイすることが推奨されます。OpenShift Logging と Red Hat OpenShift Service Mesh の両方が Elasticsearch をデプロイします。これには、3 つのインスタンスを異なるノードにインストールする必要があります。これらの各ノードは、高可用性のために異なるアベイラビリティーゾーンにデプロイできます。このような設定では、各アベイラビリティーゾーンに 1 つずつ、3 つの異なるコンピュートマシンセットが必要です。複数のアベイラビリティーゾーンを持たないグローバル Azure リージョンでは、アベイラビリティーセットを使用して高可用性を確保できます。

インフラストラクチャーノードおよびインフラストラクチャーノードで実行できるコンポーネントの情報は、Creating infrastructure machine sets を参照してください。

インフラストラクチャーノードを作成するには、マシンセットを使用する か ノードにラベルを割り当てる か、マシン設定プールを使用します。

これらの手順で使用できるサンプルマシンセットについては、さまざまなクラウドのマシンセットの作成 を参照してください。

特定のノードセレクターをすべてのインフラストラクチャーコンポーネントに適用すると、OpenShift Container Platform は そのラベルを持つノードでそれらのワークロードをスケジュール します。

4.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 の値が一致します。コンピュートマシンセットが使用できない場合は、数分待ってからコマンドを再実行してください。

4.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 インフラストラクチャーコンポーネント」で、インフラストラクチャーノードでの使用がサポートされているワークロードのリストを参照してください。

4.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.5.0             31d
00-worker                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             31d
01-master-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             31d
01-master-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             31d
01-worker-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             31d
01-worker-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             31d
99-master-1ae2a1e0-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             31d
99-master-ssh                                                                                          3.2.0             31d
99-worker-1ae64748-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             31d
99-worker-ssh                                                                                          3.2.0             31d
rendered-infra-4e48906dca84ee702959c71a53ee80e7             365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             23m
rendered-master-072d4b2da7f88162636902b074e9e28e            5b6fb8349a29735e48446d435962dec4547d3090   3.5.0             31d
rendered-master-3e88ec72aed3886dec061df60d16d1af            02c07496ba0417b3e12b78fb32baf6293d314f79   3.5.0             31d
rendered-master-419bee7de96134963a15fdf9dd473b25            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             17d
rendered-master-53f5c91c7661708adce18739cc0f40fb            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             13d
rendered-master-a6a357ec18e5bce7f5ac426fc7c5ffcd            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             7d3h
rendered-master-dc7f874ec77fc4b969674204332da037            5b6fb8349a29735e48446d435962dec4547d3090   3.5.0             31d
rendered-worker-1a75960c52ad18ff5dfa6674eb7e533d            5b6fb8349a29735e48446d435962dec4547d3090   3.5.0             31d
rendered-worker-2640531be11ba43c61d72e82dc634ce6            5b6fb8349a29735e48446d435962dec4547d3090   3.5.0             31d
rendered-worker-4e48906dca84ee702959c71a53ee80e7            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             7d3h
rendered-worker-4f110718fe88e5f349987854a1147755            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.0             17d
rendered-worker-afc758e194d6188677eb837842d3b379            02c07496ba0417b3e12b78fb32baf6293d314f79   3.5.0             31d
rendered-worker-daa08cc1e8f5fcdeba24de60cd955cc3            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.5.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.5.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 ノードに変更されました。

4.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 インフラストラクチャーコンポーネント」で、インフラストラクチャーノードでの使用がサポートされているワークロードのリストを参照してください。

4.8. リソースのインフラストラクチャーマシンセットへの移行
リンクのコピー

インフラストラクチャーリソースの一部はデフォルトでクラスターにデプロイされます。それらは、作成したインフラストラクチャーマシンセットに移行できます。

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

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

4.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 リストにあることを確認します。

4.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 ノードに再作成されます。

4.9. Cluster Autoscaler について
リンクのコピー

Cluster Autoscaler は、現行のデプロイメントのニーズに合わせて OpenShift Container Platform クラスターのサイズを調整します。これは、Kubernetes 形式の宣言引数を使用して、特定のクラウドプロバイダーのオブジェクトに依存しないインフラストラクチャー管理を提供します。Cluster Autoscaler には cluster スコープがあり、特定の namespace には関連付けられていません。

Cluster Autoscaler は、リソース不足のために現在のワーカーノードのいずれにもスケジュールできない Pod がある場合や、デプロイメントのニーズを満たすために別のノードが必要な場合に、クラスターのサイズを拡大します。Cluster Autoscaler は、指定される制限を超えてクラスターリソースを拡大することはありません。

Cluster Autoscaler は、コントロールプレーンノードを管理しない場合でも、クラスター内のすべてのノードのメモリー、CPU、および GPU の合計を計算します。これらの値は、単一マシン指向ではありません。これらは、クラスター全体での全リソースの集約です。たとえば、最大メモリーリソースの制限を設定する場合、Cluster Autoscaler は現在のメモリー使用量を計算する際にクラスター内のすべてのノードを含めます。この計算は、Cluster Autoscaler にワーカーリソースを追加する容量があるかどうかを判別するために使用されます。

重要

作成する ClusterAutoscaler リソース定義の maxNodesTotal 値が、クラスター内のマシンの想定される合計数に対応するのに十分な大きさの値であることを確認します。この値は、コントロールプレーンマシンの数とスケーリングする可能性のあるコンピュートマシンの数に対応できる値である必要があります。

4.9.1. 自動ノード削除
リンクのコピー

クラスターオートスケーラーは 10 秒ごとにクラスター内の不要なノードをチェックし、そのノードを削除します。クラスターオートスケーラーは、次の条件が当てはまる場合に、ノードを削除対象とみなします。

  • ノード使用率が、クラスターの ノード使用率 レベルのしきい値を下回っている。ノード使用率レベルとは、要求されたリソースの合計をノードに割り当てられたリソースで除算したものです。ClusterAutoscaler カスタムリソースで値が指定されいない場合、クラスターオートスケーラーはデフォルト値の 0.5 を使用します。これは 50% の使用率に相当します。
  • クラスターオートスケーラーが、ノード上で実行されているすべての Pod を他のノードに移動できる。Kubernetes スケジューラーは、ノード上の Pod のスケジュールを担当します。
  • クラスターオートスケーラーに、スケールダウンを無効にするアノテーションがない。

ノードに次のタイプの Pod が存在する場合、クラスターオートスケーラーはノードを削除しません。

  • 制限のある Pod Disruption Budget を持つ Pod。
  • デフォルトでノードで実行されない kube-system Pod。
  • PDB を持たないか、制限が厳しい PDB を持つ kube-system Pod。
  • デプロイメント、レプリカセット、またはステートフルセットなどのコントローラーオブジェクトによってサポートされない Pod。
  • ローカルストレージを持つ Pod。
  • リソース不足、互換性のないノードセレクターまたはアフィニティー、アンチアフィニティーの一致などの理由で、他の場所に移動できない Pod。
  • それらに "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" アノテーションがない場合、"cluster-autoscaler.kubernetes.io/safe-to-evict": "false" アノテーションを持つ Pod。

たとえば、CPU の上限を 64 コアに設定し、それぞれ 8 コアのマシンのみを作成するようにクラスターオートスケーラーを設定したとします。クラスターが 30 コアで起動した場合、クラスターオートスケーラーはさらに最大 4 ノードを追加して 32 コアを増やし、合計 62 コアにすることができます。

4.9.2. 制限事項
リンクのコピー

クラスターオートスケーラーを設定する場合は、使用に関する追加の制限が適用されます。

  • 自動スケーリングされたノードグループにあるノードを直接変更しないようにしてください。同じノードグループ内のすべてのノードには同じ容量およびラベルがあり、同じシステム Pod を実行します。
  • Pod の要求を指定します。
  • Pod がすぐに削除されるのを防ぐ必要がある場合、適切な PDB を設定します。
  • クラウドプロバイダーのクォータが、設定する最大のノードプールに対応できる十分な大きさであることを確認します。
  • クラウドプロバイダーで提供されるものなどの、追加のノードグループの Autoscaler を実行しないようにしてください。
注記

クラスターオートスケーラーが自動スケーリング対象のノードグループにノードを追加するのは、その追加によって Pod がスケジュール可能になる場合に限られます。利用可能なノードタイプが Pod 要求の要件を満たすことができない場合、またはその要件を満たすことができるノードグループが最大サイズに達している場合、クラスターオートスケーラーはスケールアップできません。

4.9.3. 他のスケジュール機能との連携
リンクのコピー

Horizontal Pod Autoscaler (HPA) とクラスターオートスケーラーは、異なる方法でクラスターリソースを変更します。HPA は、現在の CPU 負荷に基づいてデプロイメント、またはレプリカセットのレプリカ数を変更します。負荷が増大すると、HPA はクラスターで利用できるリソース量に関係なく、新規レプリカを作成します。リソースが不足している場合、クラスターオートスケーラーは、HPA によって作成された Pod が実行できるようにリソースを追加します。負荷が減少する場合、HPA は一部のレプリカを停止します。この動作によってノードの使用率が低下するか、ノードが完全に空になった場合、クラスターオートスケーラーは不要なノードを削除します。

クラスターオートスケーラーは Pod の優先度を考慮します。Pod の優先度とプリエンプション機能を使用すると、クラスターに十分なリソースがない場合に優先度に基づいて Pod をスケジュールできますが、クラスターオートスケーラーにより、クラスターにすべての Pod を実行するためのリソースが確保されます。両方の機能の意図を反映するために、クラスターオートスケーラーには、優先度のカットオフ機能が搭載されています。このカットオフ機能を使用すると、"ベストエフォート" の Pod をスケジュールできます。この Pod は、クラスターオートスケーラーによるリソースの増加を引き起こすことなく、予備のリソースが利用可能な場合にのみ実行されます。

カットオフ値よりも低い優先度を持つ Pod は、クラスターのスケールアップを引き起さず、クラスターのスケールダウンを妨げることもありません。これらの Pod を実行するために新規ノードは追加されず、これらの Pod を実行しているノードはリソースを解放するために削除される可能性があります。

4.9.4. Cluster Autoscaler リソース定義
リンクのコピー

次の ClusterAutoscaler リソース定義に、Cluster Autoscaler のパラメーターとサンプル値を示します。

注記

既存の Cluster Autoscaler の設定を変更すると、Cluster Autoscaler が再起動します。 

apiVersion: "autoscaling.openshift.io/v1"
kind: "ClusterAutoscaler"
metadata:
  name: "default"
spec:
  podPriorityThreshold: -10
1 

  resourceLimits:
    maxNodesTotal: 24
2 

    cores:
      min: 8
3 

      max: 128
4 

    memory:
      min: 4
5 

      max: 256
6 

    gpus:
    - type: <gpu_type>
7 

      min: 0
8 

      max: 16
9 

  logVerbosity: 4
10 

  scaleDown:
11 

    enabled: true
12 

    delayAfterAdd: 10m
13 

    delayAfterDelete: 5m
14 

    delayAfterFailure: 30s
15 

    unneededTime: 5m
16 

    utilizationThreshold: "0.4"
17 

  scaleUp:
18 

    newPodScaleUpDelay: "10s"
19 

  expanders: ["Random"]
20
Copy to Clipboard Toggle word wrap
1
Cluster Autoscaler に追加のノードをデプロイさせるために Pod が超えている必要のある優先順位を指定します。32 ビットの整数値を入力します。podPriorityThreshold 値は、各 Pod に割り当てる PriorityClass の値と比較されます。
2
デプロイするノードの最大数を指定します。この値は、Autoscaler が制御するマシンだけでなく、クラスターにデプロイされるマシンの合計数です。この値は、すべてのコントロールプレーンおよびコンピュートマシン、および MachineAutoscaler リソースに指定するレプリカの合計数に対応するのに十分な大きさの値であることを確認します。
3
クラスターにデプロイするコアの最小数を指定します。
4
クラスターにデプロイするコアの最大数を指定します。
5
クラスターのメモリーの最小量 (GiB 単位) を指定します。
6
クラスターのメモリーの最大量 (GiB 単位) を指定します。
7
オプション: GPU 対応ノードをデプロイするように Cluster Autoscaler を設定するには、type 値を指定します。この値は、そのタイプの GPU 対応ノードを管理するマシンセット内の spec.template.spec.metadata.labels[cluster-api/accelerator] ラベルの値と一致する必要があります。たとえば、この値は、Nvidia T4 GPU を表す場合は nvidia-t4、A10G GPU を表す場合は nvidia-a10g になります。詳細は、「Cluster Autoscaler 用の GPU マシンセットのラベル付け」を参照してください。
8
クラスターにデプロイする指定タイプの GPU の最小数を指定します。
9
クラスターにデプロイする指定タイプの GPU の最大数を指定します。
10
ロギングの詳細レベルを 0 から 10 の間で指定します。次のログレベルのしきい値は、ガイダンスとして提供されています。
  • 1: (デフォルト) 変更に関する基本情報。
  • 4: 一般的な問題をトラブルシューティングするためのデバッグレベルの詳細度。
  • 9: 広範なプロトコルレベルのデバッグ情報。

値を指定しない場合は、デフォルト値の 1 が使用されます。

11
このセクションでは、有効な ParseDuration 期間 ( ns、us、ms、s、m、および h を含む) を使用して各アクションに、待機する期間を指定できます。
12
Cluster Autoscaler が不必要なノードを削除できるかどうかを指定します。
13
オプション: ノードが最後に 追加 されてからノードを削除するまで待機する期間を指定します。値を指定しない場合、デフォルト値の 10m が使用されます。
14
オプション: ノードが最後に 削除 されてからノードを削除するまで待機する期間を指定します。値を指定しない場合、デフォルト値の 0s が使用されます。
15
オプション: スケールダウンが失敗してからノードを削除するまで待機する期間を指定します。値を指定しない場合、デフォルト値の 3m が使用されます。
16
オプション: 不要なノードが削除の対象となるまでの期間を指定します。値を指定しない場合、デフォルト値の 10m が使用されます。
17
オプション: node utilization level を指定します。この使用率レベルを下回るノードは、削除の対象となります。

ノード使用率は、要求されたリソースをそのノードに割り当てられたリソースで割ったもので、"0" より大きく "1" より小さい値でなければなりません。値を指定しない場合、Cluster Autoscaler は 50% の使用率に対応するデフォルト値 "0.5" を使用します。この値は文字列として表現する必要があります。

18
このセクションでは、新たに保留中となった Pod を認識するまでの待機期間を、有効な ParseDuration 間隔 (ns、us、ms、s、m、h など) を使用して指定できます。
19
オプション: 新しいノードを追加する前に、スケジュール不可能な新しい Pod を無視する期間を指定します。値を指定しない場合、デフォルト値の 0s が使用されます。
20
オプション: クラスターオートスケーラーで使用するエクスパンダーを指定します。次の値が有効です。
  • LeastWaste : スケーリング後にアイドル CPU を最小限に抑えるマシンセットを選択します。複数のマシンセットで同じ量のアイドル CPU が生成される場合、選択によって未使用のメモリーが最小限に抑えられます。
  • Priority: ユーザーが割り当てた優先度が最も高いマシンセットを選択します。このエクスパンダーを使用するには、マシンセットの優先順位を定義する config map を作成する必要があります。詳細は、「クラスターオートスケーラーの優先度エクスパンダーの設定」を参照してください。
  • Random: (デフォルト) マシンセットをランダムに選択します。

値を指定しない場合は、デフォルト値 Random が使用されます。

[LeastWaste, Priority] 形式を使用して複数のエクスパンダーを指定できます。クラスターオートスケーラーは、指定された順序に従って各エクスパンダーを適用します。

[LeastWaste, Priority] の例では、クラスターオートスケーラーは最初に LeastWaste 基準に従って評価します。複数のマシンセットが LeastWaste 基準を同等に満たしている場合、クラスターオートスケーラーは Priority 基準に従って評価します。複数のマシンセットが指定されたエクスパンダーのすべてを同等に満たす場合、クラスターオートスケーラーはランダムに 1 つを選択して使用します。

注記

スケーリング操作の実行時に、Cluster Autoscaler は、デプロイするコアの最小および最大数、またはクラスター内のメモリー量などの ClusterAutoscaler リソース定義に設定された範囲内に残ります。ただし、Cluster Autoscaler はそれらの範囲内に留まるようクラスターの現在の値を修正しません。

Cluster Autoscaler がノードを管理しない場合でも、最小および最大の CPU、メモリー、および GPU の値は、クラスター内のすべてのノードのこれらのリソースを計算することによって決定されます。たとえば、Cluster Autoscaler がコントロールプレーンノードを管理しない場合でも、コントロールプレーンノードはクラスターのメモリーの合計に考慮されます。

4.9.5. Cluster Autoscaler のデプロイ
リンクのコピー

Cluster Autoscaler をデプロイするには、ClusterAutoscaler リソースのインスタンスを作成します。

手順

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

  2. 以下のコマンドを実行して、クラスター内にカスタムリソースを作成します。 

    $ oc create -f <filename>.yaml
    1
    Copy to Clipboard Toggle word wrap
    1
    <filename> はカスタムリソースファイルの名前です。

4.10. クラスターへの自動スケーリングの適用
リンクのコピー

自動スケーリングの OpenShift Container Platform クラスターへの適用には、クラスターへの Cluster Autoscaler のデプロイと各マシンタイプの Machine Autoscaler のデプロイが必要です。

詳細は、OpenShift Container Platform クラスターへの自動スケーリングの適用 を参照してください。

4.11. FeatureGate の使用によるテクノロジープレビュー機能の有効化
リンクのコピー

FeatureGate カスタムリソース (CR) を編集して、クラスターのすべてのノードに対して現在のテクノロジープレビュー機能のサブセットをオンにすることができます。

4.11.1. フィーチャーゲートについて
リンクのコピー

FeatureGate カスタムリソース (CR) を使用して、クラスター内の特定の機能セットを有効にすることができます。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。

FeatureGate CR を使用して、以下の機能セットをアクティブにすることができます。

  • TechPreviewNoUpgrade: この機能セットは、現在のテクノロジープレビュー機能のサブセットです。この機能セットを使用すると、テストクラスターでこれらのテクノロジープレビュー機能を有効にすることができます。そこでは、これらの機能を完全にテストできますが、運用クラスターでは機能を無効にしたままにできます。

    警告

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

    この機能セットにより、以下のテクノロジープレビュー機能が有効になります。

    • AdditionalRoutingCapabilities
    • AdminNetworkPolicy
    • AlibabaPlatform
    • AutomatedEtcdBackup
    • AWSClusterHostedDNS
    • AWSServiceLBNetworkSecurityGroup
    • AzureMultiDisk
    • AzureWorkloadIdentity
    • BootcNodeManagement
    • BuildCSIVolumes
    • ClusterMonitoringConfig
    • ClusterVersionOperatorConfiguration
    • ConsolePluginContentSecurityPolicy
    • CPMSMachineNamePrefix
    • DNSNameResolver
    • DynamicResourceAllocation
    • DyanmicServiceEndpointIBMCloud
    • EtcdBackendQuota
    • Example
    • ExternalOIDC
    • ExternalOIDCWithUIDAndExtraClaimMappings
    • GatewayAPI
    • GatewayAPIController
    • GCPClusterHostedDNSInstall
    • GCPCustomAPIEndpoints
    • HighlyAvailableArbiter
    • ImageModeStatusReporting
    • ImageStreamImportMode
    • ImageVolume
    • IngressControllerDynamicConfigurationManager
    • IngressControllerLBSubnetsAWS
    • InsightsConfig
    • InsightsConfigAPI
    • InsightsOnDemandDataGather
    • IrreconcilableMachineConfig
    • KMSEncryptionProvider
    • KMSv1
    • MachineAPIMigration
    • MachineConfigNodes
    • ManagedBootImages
    • ManagedBootImagesAWS
    • ManagedBootImagesAzure
    • ManagedBootImagesvSphere
    • MaxUnavailableStatefulSet
    • MetricsCollectionProfiles
    • MinimumKubeletVersion
    • MixedCPUsAllocation
    • MultiDiskSetup
    • MutatingAdmissionPolicy
    • NetworkDiagnosticsConfig
    • NetworkLiveMigration
    • NetworkSegmentation
    • NewOLM
    • NewOLMCatalogdAPIV1Metas
    • NewOLMOwnSingleNamespace
    • NewOLMPreflightPermissionChecks
    • NewOLMWebhookProviderOpenshiftServiceCA
    • NodeSwap
    • NoRegistryClusterOperations
    • NutanixMultiSubnets
    • OpenShiftPodSecurityAdmission
    • OVNObservability
    • PinnedImages
    • PreconfiguredUDNAddresses
    • ProcMountType
    • RouteAdvertisements
    • RouteExternalCertificate
    • SELinuxMount
    • ServiceAccountTokenNodeBinding
    • SetEIPForNLBIngressController
    • SignatureStores
    • SigstoreImageVerification
    • SigstoreImageVerificationPKI
    • TranslateStreamCloseWebsocketRequests
    • UserNamespacesPodSecurityStandards
    • UserNamespacesSupport
    • VolumeAttributesClass
    • VolumeGroupSnapshot
    • VSphereConfigurableMaxAllowedBlockVolumesPerNode
    • VSphereHostVMGroupZonal
    • VSphereMixedNodeEnv
    • VSphereMultiDisk
    • VSphereMultiNetworks
    • VSphereMultiVCenters
    • TwoNodeOpenShiftClusterWithFencing

4.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 のバージョンによって異なります。

4.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 のバージョンによって異なります。

4.12. etcd タスク
リンクのコピー

etcd のバックアップ、etcd 暗号化の有効化または無効化、または etcd データのデフラグを行います。

注記

ベアメタルクラスターをデプロイした場合は、インストール後のタスクの一環として、クラスターを最大 5 ノードまでスケーリングできます。詳細は、etcd のノードスケーリング を参照してください。

4.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 の以前の状態を復元するために必要です。

4.12.2. サポートされている暗号化の種類
リンクのコピー

以下の暗号化タイプは、OpenShift Container Platform で etcd データを暗号化するためにサポートされています。

AES-CBC
暗号化を実行するために、PKCS#7 パディングと 32 バイトの鍵を含む AES-CBC を使用します。暗号化キーは毎週ローテーションされます。
AES-GCM
AES-GCM とランダムナンスおよび 32 バイトキーを使用して暗号化を実行します。暗号化キーは毎週ローテーションされます。

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

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

4.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、およびオブジェクト名は暗号化されません。

4.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 はクラスター情報を使用してユーザーの最も効率的な操作を決定するため、ほとんどの場合、自動デフラグが適しています。

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

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

4.12.7. 複数のノードの以前のクラスター状態への復元
リンクのコピー

保存された etcd のバックアップを使用して、クラスターの以前の状態を復元したり、大多数のコントロールプレーンホストが失われたクラスターを復元したりできます。

高可用性 (HA) クラスターの場合、3 ノードの HA クラスターでは、クラスターの分割を回避するために、2 つのホストで etcd をシャットダウンする必要があります。4 ノードおよび 5 ノードの HA クラスターでは、3 つのホストをシャットダウンする必要があります。クォーラムにはノードの単純過半数が必要です。3 ノードの HA クラスターのクォーラムに必要なノードの最小数は 2 です。4 ノードおよび 5 ノードの HA クラスターでは、クォーラムに必要なノードの最小数は 3 です。リカバリーホスト上のバックアップから新しいクラスターを起動すると、他の etcd メンバーがクォーラムを形成してサービスを継続できる可能性があります。

注記

クラスターがコントロールプレーンマシンセットを使用している場合は、「コントロールプレーンマシンセットのトラブルシューティング」の「劣化した etcd Operator のリカバリー」で etcd のリカバリー手順を参照してください。シングルノード上の OpenShift Container Platform は、「シングルノードで以前のクラスター状態に復元する」を参照してください。

重要

クラスターを復元する際に、同じ z-stream リリースから取得した etcd バックアップを使用する必要があります。たとえば、OpenShift Container Platform 4.20.2 クラスターは、4.20.2 から取得した etcd バックアップを使用する必要があります。

前提条件

  • インストール時に使用したものと同様、証明書ベースの kubeconfig ファイルを介して、cluster-admin ロールを持つユーザーとしてクラスターにアクセスします。
  • リカバリーホストとして使用する正常なコントロールプレーンホストがあること。
  • コントロールプレーンホストへの SSH アクセス権がある。
  • etcd スナップショットと静的 Pod のリソースの両方を含むバックアップディレクトリー (同じバックアップから取られるもの)。ディレクトリー内のファイル名は、snapshot_<datetimestamp>.db および static_kuberesources_<datetimestamp>.tar.gz の形式にする必要があります。
  • ノードはアクセス可能またはブート可能である。
重要

非リカバリーコントロールプレーンノードの場合は、SSH 接続を確立したり、静的 Pod を停止したりする必要はありません。他のリカバリー以外のコントロールプレーンマシンを 1 つずつ削除し、再作成します。

手順

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

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

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

    重要

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

  3. SSH を使用して各コントロールプレーンノードに接続し、次のコマンドを実行して etcd を無効にします。 

    $ sudo -E /usr/local/bin/disable-etcd.sh
    Copy to Clipboard Toggle word wrap

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

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

  5. SSH を使用してリカバリーホストに接続し、次のコマンドを実行して以前のバックアップからクラスターを復元します。 

    $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/<etcd-backup-directory>
    Copy to Clipboard Toggle word wrap
  6. SSH セッションを終了します。

  7. API が応答したら、次のコマンドを実行して etcd Operator のクォーラムガードをオフにします。 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
    Copy to Clipboard Toggle word wrap

  8. 次のコマンドを実行して、コントロールプレーンの回復の進行状況を監視します。 

    $ oc adm wait-for-stable-cluster
    Copy to Clipboard Toggle word wrap
    注記

    コントロールプレーンが回復するまでに最大 15 分かかります。

  9. 回復したら、次のコマンドを実行してクォーラムガードを有効にします。 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
    Copy to Clipboard Toggle word wrap

トラブルシューティング

etcd 静的 Pod のロールアウトが進行していない場合は、次のコマンドを実行して、cluster-etcd-operator から強制的に再デプロイを実行できます。 

$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$(date --rfc-3339=ns )"'"}}' --type=merge
Copy to Clipboard Toggle word wrap

4.12.8. 永続ストレージの状態復元に関する問題および回避策
リンクのコピー

OpenShift Container Platform クラスターがいずれかの形式の永続ストレージを使用する場合に、クラスターの状態は通常 etcd 外に保存されます。たとえば、Pod で実行されている Elasticsearch クラスター、または StatefulSet オブジェクトで実行されているデータベースなどである可能性があります。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 のリソースの削除 を参照)。

4.13. Pod Disruption Budget
リンクのコピー

Pod Disruption Budget を理解して設定します。

4.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 が削除される可能性があります。

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

4.13.3. 正常でない Pod のエビクションポリシーの指定
リンクのコピー

Pod Disruption Budget (PDB) を使用して、同時に使用可能にする必要がある Pod の数を指定する場合、異常な Pod をエビクション対象として考慮する基準も定義できます。

以下のポリシーから選択できます。

IfHealthyBudget
正常ではない実行中の Pod は、保護されたアプリケーションが停止されない場合に限り退避できます。
AlwaysAllow

まだ正常ではない実行中の Pod は、Pod Disruption Budget の基準が満たされているかどうかに関係なく削除される可能性があります。このポリシーは、Pod が CrashLoopBackOff 状態でスタックしているアプリケーションや Ready ステータスの報告に失敗しているアプリケーションなど、正常に動作しないアプリケーションを退避するために使用できます。

注記

ノードドレイン中に誤動作するアプリケーションのエビクションをサポートするには、PodDisruptionBudget オブジェクトの unhealthyPodEvictionPolicy フィールドを AlwaysAllow に設定することを推奨します。デフォルトの動作では、ドレインを続行する前に、アプリケーション Pod が正常になるまで待機します。

手順

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

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

    apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      name: my-pod
  unhealthyPodEvictionPolicy: AlwaysAllow
    1
    Copy to Clipboard Toggle word wrap

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

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

    $ oc create -f pod-disruption-budget.yaml
    Copy to Clipboard Toggle word wrap

PDB で正常でない Pod のエビクションポリシーが AlwaysAllow に設定されている場合、ノードをドレイン (解放)、この PDB が保護する正常に動作しないアプリケーションの Pod を退避できます。

第5章 インストール後のノードタスク
リンクのコピー

OpenShift Container Platform のインストール後に、特定のノードタスクでクラスターをさらに拡張し、要件に合わせてカスタマイズできます。

5.1. RHCOS コンピュートマシンの OpenShift Container Platform クラスターへの追加
リンクのコピー

ベアメタルの OpenShift Container Platform クラスターに Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートマシンを追加することができます。

ベアメタルインフラストラクチャーにインストールされているクラスターにコンピュートマシンを追加する前に、それが使用する RHCOS マシンを作成する必要があります。ISO イメージまたはネットワーク PXE ブートを使用してマシンを作成できます。

5.1.1. 前提条件
リンクのコピー

  • クラスターをベアメタルにインストールしている。
  • クラスターの作成に使用したインストールメディアおよび Red Hat Enterprise Linux CoreOS (RHCOS) イメージがある。これらのファイルがない場合は、インストール手順 に従って取得する必要があります。

5.1.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/bootstrap.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b
    Copy to Clipboard Toggle word wrap

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

    重要

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

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

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

5.1.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.33.4
master-1  Ready     master  63m  v1.33.4
master-2  Ready     master  64m  v1.33.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.33.4
master-1  Ready     master  73m  v1.33.4
master-2  Ready     master  74m  v1.33.4
worker-0  Ready     worker  11m  v1.33.4
worker-1  Ready     worker  11m  v1.33.4
    Copy to Clipboard Toggle word wrap

    注記

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

関連情報

5.1.5. AWS でのカスタム /var パーティションを持つ新規 RHCOS ワーカーノードの追加
リンクのコピー

OpenShift Container Platform は、ブートストラップ時に処理されるマシン設定を使用したインストール時のデバイスのパーティション設定をサポートします。ただし、/var パーティション設定を使用する場合は、デバイス名はインストール時に決定する必要があり、変更することはできません。デバイス命名スキーマが異なる場合は、異なるインスタンスタイプをノードとして追加することはできません。たとえば、/var パーティションを m4.large インスタンスのデフォルトの AWS デバイス名 dev/xvdb で設定した場合、m5.large インスタンスはデフォルトで /dev/nvme1n1 デバイスを使用するため、AWS m5.large インスタンスを直接追加することはできません。異なる命名スキーマにより、デバイスはパーティション設定に失敗する可能性があります。

本セクションの手順では、インストール時に設定したものとは異なるデバイス名を使用するインスタンスと共に、新規の Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートノードを追加する方法を説明します。カスタムユーザーデータシークレットを作成し、新規コンピュートマシンセットを設定します。これらの手順は AWS クラスターに固有のものです。この原則は、他のクラウドデプロイメントにも適用されます。ただし、デバイスの命名スキーマは他のデプロイメントでは異なり、ケースごとに決定する必要があります。

手順

  1. コマンドラインで、openshift-machine-api namespace に移動します。 

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

  2. worker-user-data シークレットから新規シークレットを作成します。

    1. シークレットの userData セクションをテキストファイルにエクスポートします。 

      $ oc get secret worker-user-data --template='{{index .data.userData | base64decode}}' | jq > userData.txt
      Copy to Clipboard Toggle word wrap

    2. テキストファイルを編集して、新規ノードに使用するパーティションの storage、filesystems、および systemd スタンザを追加します。必要に応じて Ignition 設定パラメーター を指定できます。

      注記

      ignition スタンザの値は変更しないでください。 

      {
  "ignition": {
    "config": {
      "merge": [
        {
          "source": "https:...."
        }
      ]
    },
    "security": {
      "tls": {
        "certificateAuthorities": [
          {
            "source": "data:text/plain;charset=utf-8;base64,.....=="
          }
        ]
      }
    },
    "version": "3.2.0"
  },
  "storage": {
    "disks": [
      {
        "device": "/dev/nvme1n1",
      1 
      
        "partitions": [
          {
            "label": "var",
            "sizeMiB": 50000,
      2 
      
            "startMiB": 0
      3 
      
          }
        ]
      }
    ],
    "filesystems": [
      {
        "device": "/dev/disk/by-partlabel/var",
      4 
      
        "format": "xfs",
      5 
      
        "path": "/var"
      6 
      
      }
    ]
  },
  "systemd": {
    "units": [
      7 
      
      {
        "contents": "[Unit]\nBefore=local-fs.target\n[Mount]\nWhere=/var\nWhat=/dev/disk/by-partlabel/var\nOptions=defaults,pquota\n[Install]\nWantedBy=local-fs.target\n",
        "enabled": true,
        "name": "var.mount"
      }
    ]
  }
}
      Copy to Clipboard Toggle word wrap
      1
      AWS ブロックデバイスへの絶対パスを指定します。
      2
      データパーティションのサイズをメビバイト単位で指定します。
      3
      メビバイト単位でパーティションの開始点を指定します。データパーティションをブートディスクに追加する場合は、最小値の 25000 MB (メビバイト) が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。
      4
      /var パーティションへの絶対パスを指定します。
      5
      ファイルシステムのフォーマットを指定します。
      6
      Ignition がルートファイルシステムがマウントされる場所に対して相対的な場所で実行される、ファイルシステムのマウントポイントを指定します。これは実際のルートにマウントする場所と同じである必要はありませんが、同じにすることが推奨されます。
      7
      /dev/disk/by-partlabel/var デバイスを /var パーティションにマウントする systemd マウントユニットを定義します。

    3. disableTemplating セクションを work-user-data シークレットからテキストファイルに展開します。 

      $ oc get secret worker-user-data --template='{{index .data.disableTemplating | base64decode}}' | jq > disableTemplating.txt
      Copy to Clipboard Toggle word wrap

    4. 2 つのテキストファイルから新しいユーザーデータのシークレットファイルを作成します。このユーザーデータのシークレットは、userData.txt ファイルの追加のノードパーティション情報を新規作成されたノードに渡します。 

      $ oc create secret generic worker-user-data-x5 --from-file=userData=userData.txt --from-file=disableTemplating=disableTemplating.txt
      Copy to Clipboard Toggle word wrap

  3. 新規ノードの新規コンピュートマシンセットを作成します。

    1. AWS 向けに設定される新規のコンピュートマシンセット YAML ファイルを、以下のように作成します。必要なパーティションおよび新規に作成されたユーザーデータシークレットを追加します。

      ヒント

      既存のコンピュートマシンセットをテンプレートとして使用し、新規ノード用に必要に応じてパラメーターを変更します。 

      apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: auto-52-92tf4
  name: worker-us-east-2-nvme1n1
      1 
      
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: auto-52-92tf4
      machine.openshift.io/cluster-api-machineset: auto-52-92tf4-worker-us-east-2b
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: auto-52-92tf4
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: auto-52-92tf4-worker-us-east-2b
    spec:
      metadata: {}
      providerSpec:
        value:
          ami:
            id: ami-0c2dbd95931a
          apiVersion: awsproviderconfig.openshift.io/v1beta1
          blockDevices:
          - DeviceName: /dev/nvme1n1
      2 
      
            ebs:
              encrypted: true
              iops: 0
              volumeSize: 120
              volumeType: gp2
          - DeviceName: /dev/nvme1n2
      3 
      
            ebs:
              encrypted: true
              iops: 0
              volumeSize: 50
              volumeType: gp2
          credentialsSecret:
            name: aws-cloud-credentials
          deviceIndex: 0
          iamInstanceProfile:
            id: auto-52-92tf4-worker-profile
          instanceType: m6i.large
          kind: AWSMachineProviderConfig
          metadata:
            creationTimestamp: null
          placement:
            availabilityZone: us-east-2b
            region: us-east-2
          securityGroups:
          - filters:
            - name: tag:Name
              values:
              - auto-52-92tf4-worker-sg
          subnet:
            id: subnet-07a90e5db1
          tags:
          - name: kubernetes.io/cluster/auto-52-92tf4
            value: owned
          userDataSecret:
            name: worker-user-data-x5
      4
      Copy to Clipboard Toggle word wrap
      1
      新規ノードの名前を指定します。
      2
      AWS ブロックデバイスへの絶対パスを指定します (ここでは暗号化された EBS ボリューム)。
      3
      オプション: 追加の EBS ボリュームを指定します。
      4
      ユーザーデータシークレットファイルを指定します。

    2. コンピュートマシンセットを作成します。 

      $ oc create -f <file-name>.yaml
      Copy to Clipboard Toggle word wrap

      マシンが利用可能になるまでに少し時間がかかる場合があります。

  4. 新しいパーティションとノードが作成されたことを確認します。

    1. コンピュートマシンセットが作成されていることを確認します。 

      $ oc get machineset
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                                               DESIRED   CURRENT   READY   AVAILABLE   AGE
ci-ln-2675bt2-76ef8-bdgsc-worker-us-east-1a        1         1         1       1           124m
ci-ln-2675bt2-76ef8-bdgsc-worker-us-east-1b        2         2         2       2           124m
worker-us-east-2-nvme1n1                           1         1         1       1           2m35s
      1
      Copy to Clipboard Toggle word wrap

      1
      これが新しいコンピュートマシンセットです。

    2. 新規ノードが作成されていることを確認します。 

      $ oc get nodes
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                           STATUS   ROLES    AGE     VERSION
ip-10-0-128-78.ec2.internal    Ready    worker   117m    v1.33.4
ip-10-0-146-113.ec2.internal   Ready    master   127m    v1.33.4
ip-10-0-153-35.ec2.internal    Ready    worker   118m    v1.33.4
ip-10-0-176-58.ec2.internal    Ready    master   126m    v1.33.4
ip-10-0-217-135.ec2.internal   Ready    worker   2m57s   v1.33.4
      1 
      
ip-10-0-225-248.ec2.internal   Ready    master   127m    v1.33.4
ip-10-0-245-59.ec2.internal    Ready    worker   116m    v1.33.4
      Copy to Clipboard Toggle word wrap

      1
      これは新しいノードです。

    3. カスタム /var パーティションが新しいノードに作成されていることを確認します。 

      $ oc debug node/<node-name> -- chroot /host lsblk
      Copy to Clipboard Toggle word wrap

      以下に例を示します。 

      $ oc debug node/ip-10-0-217-135.ec2.internal -- chroot /host lsblk
      Copy to Clipboard Toggle word wrap

      出力例

      NAME        MAJ:MIN  RM  SIZE RO TYPE MOUNTPOINT
nvme0n1     202:0    0   120G  0 disk
|-nvme0n1p1 202:1    0     1M  0 part
|-nvme0n1p2 202:2    0   127M  0 part
|-nvme0n1p3 202:3    0   384M  0 part /boot
`-nvme0n1p4 202:4    0 119.5G  0 part /sysroot
nvme1n1     202:16   0    50G  0 disk
`-nvme1n1p1 202:17   0  48.8G  0 part /var
      1
      Copy to Clipboard Toggle word wrap

      1
      nvme1n1 デバイスが /var パーティションにマウントされます。

5.2. マシンヘルスチェックのデプロイ
リンクのコピー

マシンヘルスチェックについて確認し、これをデプロイします。

重要

高度なマシン管理およびスケーリング機能は、Machine API が動作しているクラスターでのみ使用できます。user-provisioned infrastructure を持つクラスターでは、Machine API を使用するために追加の検証と設定が必要です。

インフラストラクチャープラットフォームタイプが none のクラスターでは、Machine API を使用できません。この制限は、クラスターに接続されている計算マシンが、この機能をサポートするプラットフォームにインストールされている場合でも適用されます。このパラメーターは、インストール後に変更することはできません。

クラスターのプラットフォームタイプを表示するには、以下のコマンドを実行します。 

$ oc get infrastructure cluster -o jsonpath='{.status.platform}'
Copy to Clipboard Toggle word wrap

5.2.1. マシンのヘルスチェック
リンクのコピー

注記

マシンのヘルスチェックは、コンピュートマシンセットまたはコントロールプレーンマシンセットにより管理されるマシンにのみ適用できます。

マシンの正常性を監視するには、リソースを作成し、コントローラーの設定を定義します。5 分間 NotReady ステータスにすることや、node-problem-detector に永続的な条件を表示すること、および監視する一連のマシンのラベルなど、チェックする条件を設定します。

MachineHealthCheck リソースを監視するコントローラーは定義済みのステータスをチェックします。マシンがヘルスチェックに失敗した場合、このマシンは自動的に検出され、その代わりとなるマシンが作成されます。マシンが削除されると、machine deleted イベントが表示されます。

マシンの削除による破壊的な影響を制限するために、コントローラーは 1 度に 1 つのノードのみを drain し、これを削除します。マシンのターゲットプールで許可される maxUnhealthy しきい値を上回る数の正常でないマシンがある場合、修復が停止するため、手動による介入が可能になります。

注記

タイムアウトについて注意深い検討が必要であり、ワークロードと要件を考慮してください。

  • タイムアウトの時間が長くなると、正常でないマシンのワークロードのダウンタイムが長くなる可能性があります。
  • タイムアウトが短すぎると、修復ループが生じる可能性があります。たとえば、NotReady ステータスを確認するためのタイムアウトは、マシンが起動プロセスを完了できるように十分な時間を設定する必要があります。

チェックを停止するには、リソースを削除します。

5.2.1.1. マシンヘルスチェックのデプロイ時の制限
リンクのコピー

マシンヘルスチェックをデプロイする前に考慮すべき制限事項があります。

  • マシンセットが所有するマシンのみがマシンヘルスチェックによって修復されます。
  • マシンのノードがクラスターから削除される場合、マシンヘルスチェックはマシンが正常ではないとみなし、すぐにこれを修復します。
  • nodeStartupTimeout の後にマシンの対応するノードがクラスターに加わらない場合、マシンは修復されます。
  • Machine リソースフェーズが Failed の場合、マシンはすぐに修復されます。

5.2.2. サンプル MachineHealthCheck リソース
リンクのコピー

ベアメタルを除くすべてのクラウドベースのインストールタイプの MachineHealthCheck リソースは、以下の YAML ファイルのようになります。 

apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: example
1 

  namespace: openshift-machine-api
spec:
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-machine-role: <role>
2 

      machine.openshift.io/cluster-api-machine-type: <role>
3 

      machine.openshift.io/cluster-api-machineset: <cluster_name>-<label>-<zone>
4 

  unhealthyConditions:
  - type:    "Ready"
    timeout: "300s"
5 

    status: "False"
  - type:    "Ready"
    timeout: "300s"
6 

    status: "Unknown"
  maxUnhealthy: "40%"
7 

  nodeStartupTimeout: "10m"
8
Copy to Clipboard Toggle word wrap
1
デプロイするマシンヘルスチェックの名前を指定します。
2 3
チェックする必要のあるマシンプールのラベルを指定します。
4
追跡するマシンセットを <cluster_name>-<label>-<zone> 形式で指定します。たとえば、prod-node-us-east-1a とします。
5 6
ノードの状態のタイムアウト期間を指定します。タイムアウト期間の条件が満たされると、マシンは修正されます。タイムアウトの時間が長くなると、正常でないマシンのワークロードのダウンタイムが長くなる可能性があります。
7
ターゲットプールで同時に修復できるマシンの数を指定します。これはパーセンテージまたは整数として設定できます。正常でないマシンの数が maxUnhealthy で設定された制限を超える場合、修復は実行されません。
8
マシンが正常でないと判別される前に、ノードがクラスターに参加するまでマシンヘルスチェックが待機する必要のあるタイムアウト期間を指定します。
注記

matchLabels はあくまでもサンプルであるため、特定のニーズに応じてマシングループをマッピングする必要があります。

5.2.2.1. マシンヘルスチェックによる修復の一時停止 (short-circuiting)
リンクのコピー

一時停止 (short-circuiting) が実行されることにより、マシンのヘルスチェックはクラスターが正常な場合にのみマシンを修復するようになります。一時停止 (short-circuiting) は、MachineHealthCheck リソースの maxUnhealthy フィールドで設定されます。

ユーザーがマシンの修復前に maxUnhealthy フィールドの値を定義する場合、MachineHealthCheck は maxUnhealthy の値を、正常でないと判別するターゲットプール内のマシン数と比較します。正常でないマシンの数が maxUnhealthy の制限を超える場合、修復は実行されません。

重要

maxUnhealthy が設定されていない場合、値は 100% にデフォルト設定され、マシンはクラスターの状態に関係なく修復されます。

適切な maxUnhealthy 値は、デプロイするクラスターの規模や、MachineHealthCheck が対応するマシンの数によって異なります。たとえば、maxUnhealthy 値を使用して複数のアベイラビリティーゾーン間で複数のマシンセットに対応でき、ゾーン全体が失われると、maxUnhealthy の設定によりクラスター内で追加の修復を防ぐことができます。複数のアベイラビリティーゾーンを持たないグローバル Azure リージョンでは、アベイラビリティーセットを使用して高可用性を確保できます。

重要

コントロールプレーンの MachineHealthCheck リソースを設定する場合は、maxUnhealthy の値を 1 に設定します。

この設定により、複数のコントロールプレーンマシンが異常であると思われる場合に、マシンのヘルスチェックがアクションを実行しないことが保証されます。複数の異常なコントロールプレーンマシンは、etcd クラスターが劣化していること、または障害が発生したマシンを置き換えるためのスケーリング操作が進行中であることを示している可能性があります。

etcd クラスターが劣化している場合は、手動での介入が必要になる場合があります。スケーリング操作が進行中の場合は、マシンのヘルスチェックで完了できるようにする必要があります。

maxUnhealthy フィールドは整数またはパーセンテージのいずれかに設定できます。maxUnhealthy の値によって、修復の実装が異なります。

5.2.2.1.1. 絶対値を使用した maxUnhealthy の設定
リンクのコピー

maxUnhealthy が 2 に設定される場合:

  • 2 つ以下のノードが正常でない場合に、修復が実行されます。
  • 3 つ以上のノードが正常でない場合は、修復は実行されません。

これらの値は、マシンヘルスチェックによってチェックされるマシン数と別個の値です。

5.2.2.1.2. パーセンテージを使用した maxUnhealthy の設定
リンクのコピー

maxUnhealthy が 40% に設定され、25 のマシンがチェックされる場合:

  • 10 以下のノードが正常でない場合に、修復が実行されます。
  • 11 以上のノードが正常でない場合は、修復は実行されません。

maxUnhealthy が 40% に設定され、6 マシンがチェックされる場合:

  • 2 つ以下のノードが正常でない場合に、修復が実行されます。
  • 3 つ以上のノードが正常でない場合は、修復は実行されません。
注記

チェックされる maxUnhealthy マシンの割合が整数ではない場合、マシンの許可される数は切り捨てられます。

5.2.3. マシンヘルスチェックリソースの作成
リンクのコピー

クラスター内のマシンセットの MachineHealthCheck リソースを作成できます。

注記

マシンのヘルスチェックは、コンピュートマシンセットまたはコントロールプレーンマシンセットにより管理されるマシンにのみ適用できます。

前提条件

  • oc コマンドラインインターフェイスをインストールします。

手順

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

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

    $ oc apply -f healthcheck.yml
    Copy to Clipboard Toggle word wrap

5.2.4. コンピュートマシンセットの手動スケーリング
リンクのコピー

コンピュートマシンセットのマシンのインスタンスを追加したり、削除したりする必要がある場合、コンピュートマシンセットを手動でスケーリングできます。

このガイダンスは、完全に自動化された 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.2.5. コンピュートマシンセットとマシン設定プールの相違点について
リンクのコピー

MachineSet オブジェクトは、クラウドまたはマシンプロバイダーに関する OpenShift Container Platform ノードを記述します。

MachineConfigPool オブジェクトにより、MachineConfigController コンポーネントがアップグレードのコンテキストでマシンのステータスを定義し、提供できるようになります。

MachineConfigPool オブジェクトにより、ユーザーはマシン設定プールの OpenShift Container Platform ノードにアップグレードをデプロイメントする方法を設定できます。

NodeSelector オブジェクトは MachineSet オブジェクトへの参照に置き換えることができます。

5.3. ノードホストに関する推奨プラクティス
リンクのコピー

OpenShift Container Platform ノードの設定ファイルには、重要なオプションが含まれています。たとえば、podsPerCore および maxPods の 2 つのパラメーターはノードにスケジュールできる Pod の最大数を制御します。

両方のオプションが使用されている場合、2 つの値の低い方の値により、ノード上の Pod 数が制限されます。これらの値を超えると、以下の状態が生じる可能性があります。

  • CPU 使用率の増大。
  • Pod のスケジューリングの速度が遅くなる。
  • (ノードのメモリー量によって) メモリー不足のシナリオが生じる可能性。
  • IP アドレスのプールを消費する。
  • リソースのオーバーコミット、およびこれによるアプリケーションのパフォーマンスの低下。
重要

Kubernetes では、単一コンテナーを保持する Pod は実際には 2 つのコンテナーを使用します。2 つ目のコンテナーは実際のコンテナーの起動前にネットワークを設定するために使用されます。そのため、10 の Pod を使用するシステムでは、実際には 20 のコンテナーが実行されていることになります。

注記

クラウドプロバイダーからのディスク IOPS スロットリングは CRI-O および kubelet に影響を与える可能性があります。ノード上に多数の I/O 集約型 Pod が実行されている場合、それらはオーバーロードする可能性があります。ノード上のディスク I/O を監視し、ワークロード用に十分なスループットを持つボリュームを使用することが推奨されます。

podsPerCore パラメーターは、ノードのプロセッサーコアの数に基づいて、ノードが実行できる Pod の数を設定します。たとえば、4 プロセッサーコアを搭載したノードで podsPerCore が 10 に設定される場合、このノードで許可される Pod の最大数は 40 になります。 

kubeletConfig:
  podsPerCore: 10
Copy to Clipboard Toggle word wrap

podsPerCore を 0 に設定すると、この制限が無効になります。デフォルトは 0 です。podsPerCore パラメーターの値は、maxPods パラメーターの値を超えることはできません。

maxPods パラメーターは、ノードのプロパティーに関係なく、ノードが実行できる Pod の数を固定値に設定します。 

 kubeletConfig:
    maxPods: 250
Copy to Clipboard Toggle word wrap

5.3.1. Kubelet パラメーターを編集するための KubeletConfig CR の作成
リンクのコピー

kubelet 設定は、現時点で Ignition 設定としてシリアル化されているため、直接編集することができます。ただし、新規の kubelet-config-controller も Machine Config Controller (MCC) に追加されます。これにより、KubeletConfig カスタムリソース (CR) を使用して kubelet パラメーターを編集できます。

注記

kubeletConfig オブジェクトのフィールドはアップストリーム Kubernetes から kubelet に直接渡されるため、kubelet はそれらの値を直接検証します。kubeletConfig オブジェクトに無効な値があると、クラスターノードを利用できなくなる可能性があります。有効な値は、Kubernetes ドキュメント を参照してください。

以下のガイダンスを参照してください。

  • 既存の KubeletConfig CR を編集して既存の設定を編集するか、変更ごとに新規 CR を作成する代わりに新規の設定を追加する必要があります。CR を作成するのは、別のマシン設定プールを変更する場合、または一時的な変更を目的とした変更の場合のみにして、変更を元に戻すことができるようにすることを推奨します。
  • マシン設定プールごとに、そのプールに加える設定変更をすべて含めて、KubeletConfig CR を 1 つ作成します。
  • 必要に応じて、クラスターごとに 10 個を上限として、複数の KubeletConfig CR を作成します。最初の KubeletConfig CR について、Machine Config Operator (MCO) は kubelet で追加されたマシン設定を作成します。それぞれの後続の CR で、コントローラーは数字の接尾辞が付いた別の kubelet マシン設定を作成します。たとえば、kubelet マシン設定があり、その接尾辞が -2 の場合に、次の kubelet マシン設定には -3 が付けられます。
注記

kubelet またはコンテナーのランタイム設定をカスタムマシン設定プールに適用する場合、machineConfigSelector のカスタムロールは、カスタムマシン設定プールの名前と一致する必要があります。

たとえば、次のカスタムマシン設定プールの名前は infra であるため、カスタムロールも infra にする必要があります。 

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: infra
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,infra]}
# ...
Copy to Clipboard Toggle word wrap

マシン設定を削除する場合は、制限を超えないようにそれらを逆の順序で削除する必要があります。たとえば、kubelet-3 マシン設定を、kubelet-2 マシン設定を削除する前に削除する必要があります。

注記

接尾辞が kubelet-9 のマシン設定があり、別の KubeletConfig CR を作成する場合には、kubelet マシン設定が 10 未満の場合でも新規マシン設定は作成されません。

KubeletConfig CR の例

$ oc get kubeletconfig
Copy to Clipboard Toggle word wrap 

NAME                      AGE
set-kubelet-config        15m
Copy to Clipboard Toggle word wrap

KubeletConfig マシン設定を示す例

$ oc get mc | grep kubelet
Copy to Clipboard Toggle word wrap 

...
99-worker-generated-kubelet-1                  b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.5.0             26m
...
Copy to Clipboard Toggle word wrap

次の手順は、ノードあたりの Pod の最大数、ノードあたりの PID の最大数、およびワーカーノード上のコンテナーログの最大サイズを設定する方法を示した例です。

前提条件

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

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

      $ oc describe machineconfigpool <name>
      Copy to Clipboard Toggle word wrap

      以下に例を示します。 

      $ oc describe machineconfigpool worker
      Copy to Clipboard Toggle word wrap

      出力例

      apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: 2019-02-08T14:52:39Z
  generation: 1
  labels:
    custom-kubelet: set-kubelet-config
      1
      Copy to Clipboard Toggle word wrap

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

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

      $ oc label machineconfigpool worker custom-kubelet=set-kubelet-config
      Copy to Clipboard Toggle word wrap

手順

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

    $ oc get machineconfig
    Copy to Clipboard Toggle word wrap

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

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

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

    以下に例を示します。 

    $ oc describe node ci-ln-5grqprb-f76d1-ncnqq-worker-a-mdv94
    Copy to Clipboard Toggle word wrap

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

    出力例

    Allocatable:
 attachable-volumes-aws-ebs:  25
 cpu:                         3500m
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      15341844Ki
 pods:                        250
    Copy to Clipboard Toggle word wrap

  3. 必要に応じてワーカーノードを設定します。

    1. kubelet 設定を含む次のような YAML ファイルを作成します。

      重要

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

      apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-kubelet-config
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: set-kubelet-config
      1 
      
  kubeletConfig:
      2 
      
      podPidsLimit: 8192
      containerLogMaxSize: 50Mi
      maxPods: 500
      Copy to Clipboard Toggle word wrap
      1
      Machine Config Pool からラベルを入力します。
      2
      kubelet 設定を追加します。以下に例を示します。
      • podPidsLimit を使用して、任意の Pod 内の PID の最大数を設定します。
      • containerLogMaxSize を使用して、コンテナーログファイルがローテーションされる前の最大サイズを設定します。

      • maxPods を使用して、ノードあたりの Pod の最大数を設定します。

        注記

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

        apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-kubelet-config
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: set-kubelet-config
  kubeletConfig:
    maxPods: <pod_count>
    kubeAPIBurst: <burst_rate>
    kubeAPIQPS: <QPS>
        Copy to Clipboard Toggle word wrap

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

      $ oc label machineconfigpool worker custom-kubelet=set-kubelet-config
      Copy to Clipboard Toggle word wrap

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

      $ oc create -f change-maxPods-cr.yaml
      Copy to Clipboard Toggle word wrap

検証

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

    $ oc get kubeletconfig
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                      AGE
set-kubelet-config        15m
    Copy to Clipboard Toggle word wrap

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

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

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

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

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

       ...
Allocatable:
  attachable-volumes-gce-pd:  127
  cpu:                        3500m
  ephemeral-storage:          123201474766
  hugepages-1Gi:              0
  hugepages-2Mi:              0
  memory:                     14225400Ki
  pods:                       500
      1 
      
 ...
      Copy to Clipboard Toggle word wrap
      1
      この例では、pods パラメーターは KubeletConfig オブジェクトに設定した値を報告するはずです。

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

    $ oc get kubeletconfigs set-kubelet-config -o yaml
    Copy to Clipboard Toggle word wrap

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

    spec:
  kubeletConfig:
    containerLogMaxSize: 50Mi
    maxPods: 500
    podPidsLimit: 8192
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: set-kubelet-config
status:
  conditions:
  - lastTransitionTime: "2021-06-30T17:04:07Z"
    message: Success
    status: "True"
    type: Success
    Copy to Clipboard Toggle word wrap

5.3.2. 利用不可のワーカーノードの数の変更
リンクのコピー

デフォルトでは、kubelet 関連の設定を利用可能なワーカーノードに適用する場合に 1 つのマシンのみを利用不可の状態にすることが許可されます。大規模なクラスターの場合、設定の変更が反映されるまでに長い時間がかかる可能性があります。プロセスのスピードを上げるためにマシン数の調整をいつでも実行することができます。

手順

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

    $ oc edit machineconfigpool worker
    Copy to Clipboard Toggle word wrap

  2. maxUnavailable フィールドを追加して、値を設定します。 

    spec:
  maxUnavailable: <node_count>
    Copy to Clipboard Toggle word wrap
    重要

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

5.3.3. コントロールプレーンノードのサイジング
リンクのコピー

コントロールプレーンノードのリソース要件は、クラスター内のノードとオブジェクトの数とタイプによって異なります。次のコントロールプレーンノードサイズの推奨事項は、コントロールプレーン密度に焦点を当てたテストまたは クラスター密度 の結果に基づいています。このテストでは、指定された数の namespace にわたって次のオブジェクトを作成します。

  • 1 イメージストリーム
  • 1 ビルド
  • 5 つのデプロイメント、sleep 状態の 2 つの Pod レプリカ、4 つのシークレット、4 つの config map、およびそれぞれ 1 つの下位 API ボリュームのマウント
  • 5 つのサービス。それぞれが以前のデプロイメントの 1 つの TCP/8080 および TCP/8443 ポートを指します。
  • 以前のサービスの最初を指す 1 つのルート
  • 2048 個のランダムな文字列文字を含む 10 個のシークレット
  • 2048 個のランダムな文字列文字を含む 10 個の config map
Expand
ワーカーノードの数クラスター密度 (namespace)CPU コア数メモリー (GB)

24

500

4

16

120

1000

8

32

252

4000

16、ただし OVN-Kubernetes ネットワークプラグインを使用する場合は 24

64、ただし OVN-Kubernetes ネットワークプラグインを使用する場合は 128

501、ただし OVN-Kubernetes ネットワークプラグインではテストされていません

4000

16

96

上の表のデータは、r5.4xlarge インスタンスをコントロールプレーンノードとして使用し、m5.2xlarge インスタンスをワーカーノードとして使用する、AWS 上で実行される OpenShift Container Platform をベースとしています。

3 つのコントロールプレーンノードを持つ大規模で高密度なクラスターでは、いずれかのノードが停止、再起動、または障害が発生すると、CPU とメモリーの使用量が急増します。障害は、電源、ネットワーク、または基礎となるインフラストラクチャーの予期しない問題、またはコストを節約するためにシャットダウンした後にクラスターが再起動する意図的なケースが原因である可能性があります。残りの 2 つのコントロールプレーンノードは、高可用性を維持するために負荷を処理する必要があります。これにより、リソースの使用量が増えます。この動作はアップグレード時にも予想されます。オペレーティングシステムの更新とコントロールプレーン Operator の更新を適用するために、コントロールプレーンノードに cordon (スケジューリング対象からの除外) と drain (Pod の退避) が実行され、ノードが順次再起動されるためです。障害が繰り返し発生しないようにするには、コントロールプレーンノードでの全体的な CPU およびメモリーリソース使用状況を、利用可能な容量の最大 60% に維持し、使用量の急増に対応できるようにします。リソース不足による潜在的なダウンタイムを回避するために、コントロールプレーンノードの CPU およびメモリーを適宜増やします。

重要

ノードのサイジングは、クラスター内のノードおよびオブジェクトの数によって異なります。また、オブジェクトがそのクラスター上でアクティブに作成されるかどうかによっても異なります。オブジェクトの作成中は、オブジェクトが Running フェーズにあるときと比較して、コントロールプレーンのリソース使用状況がより活発になります。

Operator Lifecycle Manager (OLM) はコントロールプレーンノードで実行されます。OLM のメモリーフットプリントは、クラスターで OLM が管理する必要がある namespaces とユーザーがインストールした Operator の数によって異なります。OOM による強制終了を防ぐには、コントロールプレーンノードのサイズを適切に設定する必要があります。以下のデータポイントは、クラスター最大のテストの結果に基づいています。

Expand
namespace 数アイドル状態の OLM メモリー (GB)ユーザー Operator が 5 つインストールされている OLM メモリー (GB)

500

0.823

1.7

1000

1.2

2.5

1500

1.7

3.2

2000

2

4.4

3000

2.7

5.6

4000

3.8

7.6

5000

4.2

9.02

6000

5.8

11.3

7000

6.6

12.9

8000

6.9

14.8

9000

8

17.7

10,000

9.9

21.6

重要

実行中の OpenShift Container Platform 4.20 クラスターでコントロールプレーンノードのサイズを変更できるのは、以下の構成の場合に限られます。

  • ユーザーがプロビジョニングしたインストール方法でインストールされたクラスター。
  • installer-provisioned infrastructure インストール方法でインストールされた AWS クラスター。
  • コントロールプレーンマシンセットを使用してコントロールプレーンマシンを管理するクラスター。

他のすべての構成では、インストール時に合計ノード数を見積もり、推奨されるコントロールプレーンノードサイズを使用する必要があります。

注記

OpenShift Container Platform 4.20 では、OpenShift Container Platform 3.11 以前のバージョンと比較して、CPU コアの半分 (500 ミリコア) がデフォルトでシステムによって予約されるようになりました。サイズはこれを考慮に入れて決定されます。

5.3.4. CPU マネージャーの設定
リンクのコピー

CPU マネージャーを設定するには、KubeletConfig カスタムリソース (CR) を作成し、それを目的のノードセットに適用します。

手順

  1. 次のコマンドを実行してノードにラベルを付けます。 

    # oc label node perf-node.example.com cpumanager=true
    Copy to Clipboard Toggle word wrap

  2. すべてのコンピュートノードに対して CPU マネージャーを有効にするには、次のコマンドを実行して CR を編集します。 

    # oc edit machineconfigpool worker
    Copy to Clipboard Toggle word wrap

  3. custom-kubelet: cpumanager-enabled ラベルを metadata.labels セクションに追加します。 

    metadata:
  creationTimestamp: 2020-xx-xxx
  generation: 3
  labels:
    custom-kubelet: cpumanager-enabled
    Copy to Clipboard Toggle word wrap

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

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: cpumanager-enabled
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: cpumanager-enabled
  kubeletConfig:
     cpuManagerPolicy: static
    1 
    
     cpuManagerReconcilePeriod: 5s
    2
    Copy to Clipboard Toggle word wrap
    1
    ポリシーを指定します。
    • noneこのポリシーは、既存のデフォルト CPU アフィニティースキームを明示的に有効にし、スケジューラーが自動的に実行するもの以外のアフィニティーを提供しません。これはデフォルトポリシーになります。
    • staticこのポリシーは、整数の CPU 要求を持つ保証された Pod 内のコンテナーを許可します。また、ノードの排他的 CPU へのアクセスも制限します。static の場合は、小文字の s を使用する必要があります。
    2
    オプション。CPU マネージャーの調整頻度を指定します。デフォルトは 5s です。

  5. 次のコマンドを実行して、動的 kubelet 設定を作成します。 

    # oc create -f cpumanager-kubeletconfig.yaml
    Copy to Clipboard Toggle word wrap

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

  6. 次のコマンドを実行して、マージされた kubelet 設定を確認します。 

    # oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7
    Copy to Clipboard Toggle word wrap

    出力例

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

  7. 次のコマンドを実行して、更新された kubelet.conf ファイルをコンピュートノードで確認します。 

    # oc debug node/perf-node.example.com
sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager
    Copy to Clipboard Toggle word wrap

    出力例

    cpuManagerPolicy: static
    1 
    
cpuManagerReconcilePeriod: 5s
    2
    Copy to Clipboard Toggle word wrap

    1
    cpuManagerPolicy は、KubeletConfig CR の作成時に定義されます。
    2
    cpuManagerReconcilePeriod は、KubeletConfig CR の作成時に定義されます。

  8. 次のコマンドを実行してプロジェクトを作成します。 

    $ oc new-project <project_name>
    Copy to Clipboard Toggle word wrap

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

    # cat cpumanager-pod.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: v1
kind: Pod
metadata:
  generateName: cpumanager-
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: cpumanager
    image: gcr.io/google_containers/pause:3.2
    resources:
      requests:
        cpu: 1
        memory: "1G"
      limits:
        cpu: 1
        memory: "1G"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
  nodeSelector:
    cpumanager: "true"
    Copy to Clipboard Toggle word wrap

  10. Pod を作成します。 

    # oc create -f cpumanager-pod.yaml
    Copy to Clipboard Toggle word wrap

検証

  1. 次のコマンドを実行して、ラベルを付けたノードに Pod がスケジュールされていることを確認します。 

    # oc describe pod cpumanager
    Copy to Clipboard Toggle word wrap

    出力例

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

  2. 次のコマンドを実行して、CPU が Pod 専用として割り当てられていることを確認します。 

    # oc describe node --selector='cpumanager=true' | grep -i cpumanager- -B2
    Copy to Clipboard Toggle word wrap

    出力例

    NAMESPACE    NAME                CPU Requests  CPU Limits  Memory Requests  Memory Limits  Age
cpuman       cpumanager-mlrrz    1 (28%)       1 (28%)     1G (13%)         1G (13%)       27m
    Copy to Clipboard Toggle word wrap

  3. cgroups が正しく設定されていることを確認します。次のコマンドを実行して、pause プロセスのプロセス ID (PID) を取得します。 

    # oc debug node/perf-node.example.com
    Copy to Clipboard Toggle word wrap 
    sh-4.2# systemctl status | grep -B5 pause
    Copy to Clipboard Toggle word wrap
    注記

    出力で複数の pause プロセスエントリーが返される場合は、正しい一時停止プロセスを特定する必要があります。

    出力例

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

  4. 次のコマンドを実行して、サービス品質 (QoS) 層 (Guaranteed) の Pod が kubepods.slice サブディレクトリー内に配置されていることを確認します。 

    # cd /sys/fs/cgroup/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope
    Copy to Clipboard Toggle word wrap 
    # for i in `ls cpuset.cpus cgroup.procs` ; do echo -n "$i "; cat $i ; done
    Copy to Clipboard Toggle word wrap
    注記

    他の QoS 階層の Pod は、親 kubepods の子である cgroups に配置されます。

    出力例

    cpuset.cpus 1
tasks 32706
    Copy to Clipboard Toggle word wrap

  5. 次のコマンドを実行して、タスクに許可されている CPU リストを確認します。 

    # grep ^Cpus_allowed_list /proc/32706/status
    Copy to Clipboard Toggle word wrap

    出力例

     Cpus_allowed_list:    1
    Copy to Clipboard Toggle word wrap

  6. システム上の別の Pod が、Guaranteed Pod に割り当てられたコアで実行できないことを確認します。たとえば、besteffort QoS 階層の Pod を検証するには、次のコマンドを実行します。 

    # cat /sys/fs/cgroup/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus
    Copy to Clipboard Toggle word wrap 
    # oc describe node perf-node.example.com
    Copy to Clipboard Toggle word wrap

    出力例

    ...
Capacity:
 attachable-volumes-aws-ebs:  39
 cpu:                         2
 ephemeral-storage:           124768236Ki
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      8162900Ki
 pods:                        250
Allocatable:
 attachable-volumes-aws-ebs:  39
 cpu:                         1500m
 ephemeral-storage:           124768236Ki
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      7548500Ki
 pods:                        250
-------                               ----                           ------------  ----------  ---------------  -------------  ---
  default                                 cpumanager-6cqz7               1 (66%)       1 (66%)     1G (12%)         1G (12%)       29m

Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource                    Requests          Limits
  --------                    --------          ------
  cpu                         1440m (96%)       1 (66%)
    Copy to Clipboard Toggle word wrap

    この仮想マシンには、2 つの CPU コアがあります。system-reserved 設定は 500 ミリコアを予約し、Node Allocatable の量になるようにノードの全容量からコアの半分を引きます。ここで Allocatable CPU は 1500 ミリコアであることを確認できます。これは、それぞれがコアを 1 つ受け入れるので、CPU マネージャー Pod の 1 つを実行できることを意味します。1 つのコア全体は 1000 ミリコアに相当します。2 つ目の Pod をスケジュールしようとする場合、システムは Pod を受け入れますが、これがスケジュールされることはありません。 

    NAME                    READY   STATUS    RESTARTS   AGE
cpumanager-6cqz7        1/1     Running   0          33m
cpumanager-7qc2t        0/1     Pending   0          11s
    Copy to Clipboard Toggle word wrap

5.4. Huge Page
リンクのコピー

Huge Page を理解し、これを設定します。

5.4.1. Huge Page の機能
リンクのコピー

メモリーは Page と呼ばれるブロックで管理されます。多くのシステムでは、1 ページは 4Ki です。メモリー 1Mi は 256 ページに、メモリー 1Gi は 256,000 ページに相当します。CPU には、内蔵のメモリー管理ユニットがあり、ハードウェアでこのようなページリストを管理します。トランスレーションルックアサイドバッファー (TLB: Translation Lookaside Buffer) は、仮想から物理へのページマッピングの小規模なハードウェアキャッシュのことです。ハードウェアの指示で渡された仮想アドレスが TLB にあれば、マッピングをすばやく決定できます。そうでない場合には、TLB ミスが発生し、システムは速度が遅く、ソフトウェアベースのアドレス変換にフォールバックされ、パフォーマンスの問題が発生します。TLB のサイズは固定されているので、TLB ミスの発生率を減らすには Page サイズを大きくする必要があります。

Huge Page とは、4Ki より大きいメモリーページのことです。x86_64 アーキテクチャーでは、2Mi と 1Gi の 2 つが一般的な Huge Page サイズです。別のアーキテクチャーではサイズは異なります。Huge Page を使用するには、アプリケーションが認識できるようにコードを書き込む必要があります。Transparent Huge Page (THP) は、アプリケーションによる認識なしに、Huge Page の管理を自動化しようとしますが、制約があります。特に、ページサイズは 2Mi に制限されます。THP では、THP のデフラグが原因で、メモリー使用率が高くなり、断片化が起こり、パフォーマンスの低下につながり、メモリーページがロックされてしまう可能性があります。このような理由から、アプリケーションは THP ではなく、事前割り当て済みの Huge Page を使用するように設計 (また推奨) される場合があります。

5.4.2. Huge Page がアプリケーションによって消費される仕組み
リンクのコピー

ノードは、Huge Page の容量をレポートできるように Huge Page を事前に割り当てる必要があります。ノードは、単一サイズの Huge Page のみを事前に割り当てることができます。

Huge Page は、リソース名の hugepages-<size> を使用してコンテナーレベルのリソース要件で消費可能です。この場合、サイズは特定のノードでサポートされる整数値を使用した最もコンパクトなバイナリー表記です。たとえば、ノードが 2048KiB ページサイズをサポートする場合、これはスケジュール可能なリソース hugepages-2Mi を公開します。CPU やメモリーとは異なり、Huge Page はオーバーコミットをサポートしません。 

apiVersion: v1
kind: Pod
metadata:
  generateName: hugepages-volume-
spec:
  containers:
  - securityContext:
      privileged: true
    image: rhel7:latest
    command:
    - sleep
    - inf
    name: example
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        hugepages-2Mi: 100Mi
1 

        memory: "1Gi"
        cpu: "1"
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
Copy to Clipboard Toggle word wrap
1
hugepages のメモリー量は、実際に割り当てる量に指定します。この値は、ページサイズで乗算した hugepages のメモリー量に指定しないでください。たとえば、Huge Page サイズが 2MB と仮定し、アプリケーションに Huge Page でバックアップする RAM 100 MB を使用する場合には、Huge Page は 50 に指定します。OpenShift Container Platform により、計算処理が実行されます。上記の例にあるように、100MB を直接指定できます。

指定されたサイズの Huge Page の割り当て

プラットフォームによっては、複数の Huge Page サイズをサポートするものもあります。特定のサイズの Huge Page を割り当てるには、Huge Page の起動コマンドパラメーターの前に、Huge Page サイズの選択パラメーター hugepagesz=<size> を指定してください。<size> の値は、バイトで指定する必要があります。その際、オプションでスケール接尾辞 [kKmMgG] を指定できます。デフォルトの Huge Page サイズは、default_hugepagesz=<size> の起動パラメーターで定義できます。

Huge page の要件

  • Huge Page 要求は制限と同じでなければなりません。制限が指定されているにもかかわらず、要求が指定されていない場合には、これがデフォルトになります。
  • Huge Page は、Pod のスコープで分割されます。コンテナーの分割は、今後のバージョンで予定されています。
  • Huge Page がサポートする EmptyDir ボリュームは、Pod 要求よりも多くの Huge Page メモリーを消費することはできません。
  • shmget() で SHM_HUGETLB を使用して Huge Page を消費するアプリケーションは、proc/sys/vm/hugetlb_shm_group に一致する補助グループで実行する必要があります。

5.4.3. 起動時の Huge Page 設定
リンクのコピー

ノードは、OpenShift Container Platform クラスターで使用される Huge Page を事前に割り当てる必要があります。Huge Page を予約する方法は、ブート時とランタイム時に実行する 2 つの方法があります。ブート時の予約は、メモリーが大幅に断片化されていないために成功する可能性が高くなります。Node Tuning Operator は、現時点で特定のノードでの Huge Page のブート時の割り当てをサポートします。

手順

ノードの再起動を最小限にするには、以下の手順の順序に従う必要があります。

  1. ラベルを使用して同じ Huge Page 設定を必要とするすべてのノードにラベルを付けます。 

    $ oc label node <node_using_hugepages> node-role.kubernetes.io/worker-hp=
    Copy to Clipboard Toggle word wrap

  2. 以下の内容でファイルを作成し、これに hugepages-tuned-boottime.yaml という名前を付けます。 

    apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: hugepages
    1 
    
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
    2 
    
  - data: |
      [main]
      summary=Boot time configuration for hugepages
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_hugepages=hugepagesz=2M hugepages=50
    3 
    
    name: openshift-node-hugepages

  recommend:
  - machineConfigLabels:
    4 
    
      machineconfiguration.openshift.io/role: "worker-hp"
    priority: 30
    profile: openshift-node-hugepages
    Copy to Clipboard Toggle word wrap
    1
    チューニングされたリソースの name を hugepages に設定します。
    2
    Huge Page を割り当てる profile セクションを設定します。
    3
    一部のプラットフォームではさまざまなサイズの Huge Page をサポートするため、パラメーターの順序に注意してください。
    4
    マシン設定プールベースのマッチングを有効にします。

  3. チューニングされた hugepages オブジェクトの作成 

    $ oc create -f hugepages-tuned-boottime.yaml
    Copy to Clipboard Toggle word wrap

  4. 以下の内容でファイルを作成し、これに hugepages-mcp.yaml という名前を付けます。 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: worker-hp
  labels:
    worker-hp: ""
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,worker-hp]}
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker-hp: ""
    Copy to Clipboard Toggle word wrap

  5. マシン設定プールを作成します。 

    $ oc create -f hugepages-mcp.yaml
    Copy to Clipboard Toggle word wrap

断片化されていないメモリーが十分にある場合、worker-hp マシン設定プールのすべてのノードには 50 2Mi の Huge Page が割り当てられているはずです。 

$ oc get node <node_using_hugepages> -o jsonpath="{.status.allocatable.hugepages-2Mi}"
100Mi
Copy to Clipboard Toggle word wrap
注記

TuneD ブートローダープラグインは、Red Hat Enterprise Linux CoreOS (RHCOS) ワーカーノードのみサポートします。

5.5. デバイスプラグインについて
リンクのコピー

デバイスプラグインは、クラスター間でハードウェアデバイスを使用する際の一貫した移植可能なソリューションを提供します。デバイスプラグインは、拡張メカニズムを通じてこれらのデバイスをサポートし (これにより、コンテナーがこれらのデバイスを利用できるようになります)、デバイスのヘルスチェックを実施し、それらを安全に共有します。

重要

OpenShift Container Platform はデバイスのプラグイン API をサポートしますが、デバイスプラグインコンテナーは個別のベンダーによりサポートされます。

デバイスプラグインは、特定のハードウェアリソースの管理を行う、ノード上で実行される gRPC サービスです (kubelet の外部にあります)。デバイスプラグインは以下のリモートプロシージャーコール (RPC) をサポートしている必要があります。 

service DevicePlugin {
      // GetDevicePluginOptions returns options to be communicated with Device
      // Manager
      rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}

      // ListAndWatch returns a stream of List of Devices
      // Whenever a Device state change or a Device disappears, ListAndWatch
      // returns the new list
      rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}

      // Allocate is called during container creation so that the Device
      // Plug-in can run device specific operations and instruct Kubelet
      // of the steps to make the Device available in the container
      rpc Allocate(AllocateRequest) returns (AllocateResponse) {}

      // PreStartcontainer is called, if indicated by Device Plug-in during
      // registration phase, before each container start. Device plug-in
      // can run device specific operations such as resetting the device
      // before making devices available to the container
      rpc PreStartcontainer(PreStartcontainerRequest) returns (PreStartcontainerResponse) {}
}
Copy to Clipboard Toggle word wrap

5.5.1. デバイスプラグインの例
リンクのコピー

注記

デバイスプラグイン参照の実装を容易にするために、vendor/k8s.io/kubernetes/pkg/kubelet/cm/deviceplugin/device_plugin_stub.go という Device Manager コードのスタブデバイスプラグインを使用できます。

5.5.2. デバイスプラグインのデプロイ方法
リンクのコピー

  • デーモンセットは、デバイスプラグインのデプロイメントに推奨される方法です。
  • 起動時にデバイスプラグインは、Device Manager から RPC を送信するためにノードの /var/lib/kubelet/device-plugin/ での UNIX ドメインソケットの作成を試行します。
  • デバイスプラグインは、ソケットの作成のほかにもハードウェアリソース、ホストファイルシステムへのアクセスを管理する必要があるため、特権付きセキュリティーコンテキストで実行される必要があります。
  • デプロイメント手順の詳細は、それぞれのデバイスプラグインの実装で確認できます。

5.5.3. Device Manager について
リンクのコピー

Device Manager は、特殊なノードのハードウェアリソースを、デバイスプラグインとして知られるプラグインを使用して公開するメカニズムを提供します。

特殊なハードウェアは、アップストリームのコード変更なしに公開できます。

重要

OpenShift Container Platform はデバイスのプラグイン API をサポートしますが、デバイスプラグインコンテナーは個別のベンダーによりサポートされます。

Device Manager はデバイスを 拡張リソース として公開します。ユーザー Pod は、他の 拡張リソース を要求するために使用されるのと同じ 制限/要求 メカニズムを使用して Device Manager で公開されるデバイスを消費できます。

使用開始時に、デバイスプラグインは /var/lib/kubelet/device-plugins/kubelet.sock の Register を起動して Device Manager に自己登録し、Device Manager の要求を提供するために /var/lib/kubelet/device-plugins/<plugin>.sock で gRPC サービスを起動します。

Device Manager は、新規登録要求の処理時にデバイスプラグインサービスで ListAndWatch リモートプロシージャーコール (RPC) を起動します。応答として Device Manager は gRPC ストリームでプラグインから デバイス オブジェクトの一覧を取得します。Device Manager はプラグインからの新規の更新の有無についてストリームを監視します。プラグイン側では、プラグインはストリームを開いた状態にし、デバイスの状態に変更があった場合には常に新規デバイスの一覧が同じストリーム接続で Device Manager に送信されます。

新しい Pod の受付リクエストの処理中に、Kubelet が要求された Extended Resources をデバイス割り当てのためにデバイスマネージャーに渡します。Device Manager はそのデータベースにチェックインして対応するプラグインが存在するかどうかを確認します。プラグインが存在し、ローカルキャッシュと共に割り当て可能な空きデバイスがある場合、Allocate RPC がその特定デバイスのプラグインで起動します。

さらにデバイスプラグインは、ドライバーのインストール、デバイスの初期化、およびデバイスのリセットなどの他のいくつかのデバイス固有の操作も実行できます。これらの機能は実装ごとに異なります。

5.5.4. Device Manager の有効化
リンクのコピー

Device Manager を有効にし、デバイスプラグインを実装してアップストリームのコード変更なしに特殊なハードウェアを公開できるようにします。

Device Manager は、特殊なノードのハードウェアリソースを、デバイスプラグインとして知られるプラグインを使用して公開するメカニズムを提供します。

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

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

      # oc describe machineconfig <name>
      Copy to Clipboard Toggle word wrap

      以下に例を示します。 

      # oc describe machineconfig 00-worker
      Copy to Clipboard Toggle word wrap

      出力例

      Name:         00-worker
Namespace:
Labels:       machineconfiguration.openshift.io/role=worker
      1
      Copy to Clipboard Toggle word wrap

      1
      Device Manager に必要なラベル。

手順

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

    Device Manager CR の設定例

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

    1
    CR に名前を割り当てます。
    2
    Machine Config Pool からラベルを入力します。
    3
    DevicePlugins を 'true` に設定します。

  2. Device Manager を作成します。 

    $ oc create -f devicemgr.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    kubeletconfig.machineconfiguration.openshift.io/devicemgr created
    Copy to Clipboard Toggle word wrap

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

5.6. taint および toleration
リンクのコピー

taint および toleration を理解し、これらを使用します。

5.6.1. taint および toleration について
リンクのコピー

taint により、ノードは Pod に一致する toleration がない場合に Pod のスケジュールを拒否することができます。

taint は Node 仕様 (NodeSpec) でノードに適用され、toleration は Pod 仕様 (PodSpec) で Pod に適用されます。taint をノードに適用する場合、スケジューラーは Pod が taint を容認しない限り、Pod をそのノードに配置できません。

ノード仕様の taint の例

apiVersion: v1
kind: Node
metadata:
  name: my-node
#...
spec:
  taints:
  - effect: NoExecute
    key: key1
    value: value1
#...
Copy to Clipboard Toggle word wrap

Pod 仕様での toleration の例

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
#...
spec:
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoExecute"
    tolerationSeconds: 3600
#...
Copy to Clipboard Toggle word wrap

taint および toleration は、key、value、および effect で構成されます。

Expand
表5.1 taint および toleration コンポーネント
パラメーター説明

key

key には、253 文字までの文字列を使用できます。キーは文字または数字で開始する必要があり、文字、数字、ハイフン、ドットおよびアンダースコアを含めることができます。

value

value には、63 文字までの文字列を使用できます。値は文字または数字で開始する必要があり、文字、数字、ハイフン、ドットおよびアンダースコアを含めることができます。

effect

effect は以下のいずれかにすることができます。

Expand

NoSchedule [1]

  • taint に一致しない新規 Pod はノードにスケジュールされません。
  • ノードの既存 Pod はそのままになります。

PreferNoSchedule

  • taint に一致しない新規 Pod はノードにスケジュールされる可能性がありますが、スケジューラーはスケジュールしないようにします。
  • ノードの既存 Pod はそのままになります。

NoExecute

  • taint に一致しない新規 Pod はノードにスケジュールできません。
  • 一致する toleration を持たないノードの既存 Pod は削除されます。

operator

Expand

Equal

key/value/effect パラメーターは一致する必要があります。これがデフォルトです。

Exists

key/effect パラメーターは一致する必要があります。いずれかに一致する value パラメーターを空のままにする必要があります。

  1. NoSchedule taint をコントロールプレーンノードに追加すると、ノードには、デフォルトで追加される node-role.kubernetes.io/master=:NoSchedule taint が必要です。

    以下に例を示します。 

    apiVersion: v1
kind: Node
metadata:
  annotations:
    machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
    machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
  name: my-node
#...
spec:
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
#...
    Copy to Clipboard Toggle word wrap

toleration は taint と一致します。

  • operator パラメーターが Equal に設定されている場合:

    • key パラメーターが同じである。
    • value パラメーターが同じである。
    • effect パラメーターが同じである。

  • operator パラメーターが Exists に設定されている場合:

    • key パラメーターが同じである。
    • effect パラメーターが同じである。

以下の taint は OpenShift Container Platform に組み込まれています。

  • node.kubernetes.io/not-ready: ノードは準備状態にありません。これはノード条件 Ready=False に対応します。
  • node.kubernetes.io/unreachable: ノードはノードコントローラーから到達不能です。これはノード条件 Ready=Unknown に対応します。
  • node.kubernetes.io/memory-pressure: ノードにはメモリー不足の問題が発生しています。これはノード条件 MemoryPressure=True に対応します。
  • node.kubernetes.io/disk-pressure: ノードにはディスク不足の問題が発生しています。これはノード条件 DiskPressure=True に対応します。
  • node.kubernetes.io/network-unavailable: ノードのネットワークは使用できません。
  • node.kubernetes.io/unschedulable: ノードはスケジュールが行えません。
  • node.cloudprovider.kubernetes.io/uninitialized: ノードコントローラーが外部のクラウドプロバイダーを使用して起動すると、この taint はノード上に設定され、使用不可能とマークされます。cloud-controller-manager のコントローラーがこのノードを初期化した後に、kubelet がこの taint を削除します。

  • node.kubernetes.io/pid-pressure: ノードが pid 不足の状態です。これはノード条件 PIDPressure=True に対応します。

    重要

    OpenShift Container Platform では、デフォルトの pid.available evictionHard は設定されません。

5.6.2. taint および toleration の追加
リンクのコピー

toleration を Pod に、taint をノードに追加することで、ノードはノード上でスケジュールする必要のある (またはスケジュールすべきでない) Pod を制御できます。既存の Pod およびノードの場合、最初に toleration を Pod に追加してから taint をノードに追加して、toleration を追加する前に Pod がノードから削除されないようにする必要があります。

手順

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

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

    apiVersion: v1
kind: Pod
metadata:
  name: my-pod
#...
spec:
  tolerations:
  - key: "key1"
    1 
    
    value: "value1"
    operator: "Equal"
    effect: "NoExecute"
    tolerationSeconds: 3600
    2 
    
#...
    Copy to Clipboard Toggle word wrap

    1
    taint および toleration コンポーネント の表で説明されている toleration パラメーターです。
    2
    tolerationSeconds パラメーターは、退避する前に Pod をどの程度の期間ノードにバインドさせるかを指定します。

    以下に例を示します。

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

    apiVersion: v1
kind: Pod
metadata:
  name: my-pod
#...
spec:
   tolerations:
    - key: "key1"
      operator: "Exists"
    1 
    
      effect: "NoExecute"
      tolerationSeconds: 3600
#...
    Copy to Clipboard Toggle word wrap

    1
    Exists Operator は value を取りません。

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

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

    $ oc adm taint nodes <node_name> <key>=<value>:<effect>
    Copy to Clipboard Toggle word wrap