第10章 シングルノード OpenShift クラスター用のワーカーノード


10.1. シングルノード OpenShift クラスターへのワーカーノードの追加

クラスターの容量を増やす必要がある場合は、シングルノードの OpenShift クラスターにワーカーノードを追加できます。

シングルノードクラスターは、単一ホストへのデプロイメントに必要なホスト要件を軽減します。これは、制約のある環境またはネットワークエッジでのデプロイメントに役立ちます。ただし、通信やネットワークエッジのシナリオなどでは、クラスターに容量を追加する必要がある場合があります。これらのシナリオでは、ワーカーノードを単一ノードクラスターに追加できます。

注記

マルチノードクラスターとは異なり、ワーカーノードを追加した後でも、デフォルトではすべての ingress トラフィックが単一のコントロールプレーンノードにルーティングされます。

単一ノードクラスターにワーカーノードを追加するには、いくつかの方法があります。Red Hat OpenShift Cluster Manager を使用するか、Assisted Installer REST API を直接使用して、クラスターにワーカーノードを手動で追加できます。

重要

ワーカーノードを追加してもクラスターコントロールプレーンは拡張されず、クラスターに高可用性は提供されません。単一ノードの OpenShift クラスターの場合、高可用性は別のサイトにフェイルオーバーすることによって処理されます。単一ノードの OpenShift クラスターにワーカーノードを追加する場合は、テスト済みの最大 2 つのワーカーノードを推奨します。推奨されるワーカーノードの数を超えると、クラスター障害など、パフォーマンスが全体的に低下する可能性があります。

注記

ワーカーノードを追加するには、OpenShift Cluster Manager へのアクセス権が必要です。この方法は、エージェントベースのインストーラーを使用して切断された環境にクラスターをインストールする場合にはサポートされません。

10.1.1. 単一ノードの OpenShift ワーカーノードをインストールするための要件

シングルノードの OpenShift ワーカーノードをインストールする前に満たすべき要件を理解するために、以下の情報を確認してください。

単一ノードの OpenShift ワーカーノードをインストールするには、次の要件に対応する必要があります。

  • 管理ホスト: ISO を準備し、インストールを監視するためのコンピューターが必要です。
  • 実稼働環境グレードサーバー: 単一ノードの OpenShift ワーカーノードをインストールするには、OpenShift Container Platform サービスと実稼働環境ワークロードを実行するのに十分なリソースを備えたサーバーが必要です。

    Expand
    表10.1 最小リソース要件
    プロファイル仮想 CPUメモリーストレージ

    最低限

    2 vCPU コア

    8GB の RAM

    100GB

    注記

    1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。有効にした場合には、次の式を使用して対応する比率を計算します。

    (コアあたりのスレッド数 x コア数) x ソケット数 = 仮想 CPU 数

    仮想メディアを使用して起動する場合は、サーバーには Baseboard Management Controller (BMC) が必要です。

  • ネットワーク: ワーカーノードサーバーは、ルーティング可能なネットワークに接続されていない場合、インターネットまたはローカルレジストリーにアクセスできる必要があります。ワーカーノードサーバーには、DHCP 予約または静的 IP アドレスが必要であり、単一ノードの OpenShift クラスター Kubernetes API、ingress ルート、およびクラスターノードのドメイン名にアクセスできる必要があります。単一ノードの OpenShift クラスターの次の完全修飾ドメイン名 (FQDN) のそれぞれに IP アドレスを解決するように DNS を設定する必要があります。

    Expand
    表10.2 必要な DNS レコード
    使用法FQDN説明

    Kubernetes API

    api.<cluster_name>.<base_domain>

    DNS A/AAAA または CNAME レコードを追加します。このレコードは、クラスター外のクライアントで解決できる必要があります。

    内部 API

    api-int.<cluster_name>.<base_domain>

    ISO を手動で作成する場合は、DNS A/AAAA または CNAME レコードを追加します。このレコードは、クラスター内のノードにより解決可能である必要があります。

    Ingress ルート

    *.apps.<cluster_name>.<base_domain>

    ノードをターゲットにするワイルドカード DNS A/AAAA または CNAME レコードを追加します。このレコードは、クラスター外のクライアントで解決できる必要があります。

    永続的な IP アドレスがない場合は、apiserveretcd の間の通信で失敗する可能性があります。

10.1.2. Assisted Installer および OpenShift Cluster Manager を使用したワーカーノードの追加

Assisted Installer を使用すると、OpenShift Cluster Manager で作成されたシングルノードの OpenShift クラスターにワーカーノードを追加できます。この方法は、コマンドラインコマンドを使用する代替手段を提供します。

重要

単一ノードの OpenShift クラスターへのワーカーノードの追加は、OpenShift Container Platform バージョン 4.11 以降を実行しているクラスターに対してのみサポートされます。

前提条件

  • Assisted Installer を使用してインストールされた単一ノードの OpenShift クラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • ワーカーノードを追加するクラスターに必要なすべての DNS レコードが存在することを確認してください。

手順

  1. OpenShift Cluster Manager にログインし、ワーカーノードを追加するシングルノードクラスターをクリックします。
  2. Add hosts をクリックし、新しいワーカーノードの検出 ISO をダウンロードして、必要に応じて SSH 公開キーを追加し、クラスター全体のプロキシー設定を設定します。
  3. 検出 ISO を使用してターゲットホストを起動し、ホストがコンソールで検出されるまで待ちます。ホストが検出されたら、インストールを開始します。
  4. インストールが進行するにつれて、インストールはワーカーノードの保留中の証明書署名要求 (CSR) を生成します。プロンプトが表示されたら、保留中の CSR を承認してインストールを完了します。

    ワーカーノードが正常にインストールされると、クラスター Web コンソールにワーカーノードとして一覧表示されます。

    重要

    新しいワーカーノードは、元のクラスターと同じ方法で暗号化されます。

10.1.3. Assisted Installer API を使用したワーカーノードの追加

Assisted InstallerREST API に対してコマンドラインコマンドを記述することで、ワーカーノードをクラスターに追加できます。この方法は、Web コンソールを使用する代替手段を提供します。

ワーカーノードを追加する前に、OpenShift Cluster Manager にログインし、API に対して認証する必要があります。認証後、Assisted Installer REST API を使用してノードを追加できます。

10.1.3.1. Assisted Installer REST API に対する認証

Assisted Installer REST API を使用する前に、生成した JSON Web トークン (JWT) を使用して API に対して認証する必要があります。

前提条件

  • クラスター作成権限を持つユーザーで OpenShift Cluster Manager にログインする。
  • jq をインストールします。

手順

  1. OpenShift Cluster Manager にログインし、API トークンをコピーします。
  2. 次のコマンドを実行して、コピーした API トークンを使用して $OFFLINE_TOKEN 変数を設定します。

    $ export OFFLINE_TOKEN=<copied_api_token>
  3. 以前に設定した $OFFLINE_TOKEN 変数を使用して、$JWT_TOKEN 変数を設定します。

    $ export JWT_TOKEN=$(
      curl \
      --silent \
      --header "Accept: application/json" \
      --header "Content-Type: application/x-www-form-urlencoded" \
      --data-urlencode "grant_type=refresh_token" \
      --data-urlencode "client_id=cloud-services" \
      --data-urlencode "refresh_token=${OFFLINE_TOKEN}" \
      "https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token" \
      | jq --raw-output ".access_token"
    )
    注記

    JWT トークンは 15 分間のみ有効です。

検証

  • オプション: 次のコマンドを実行して、API にアクセスできることを確認します。

    $ curl -s https://api.openshift.com/api/assisted-install/v2/component-versions -H "Authorization: Bearer ${JWT_TOKEN}" | jq

    出力例

    {
        "release_tag": "v2.5.1",
        "versions":
        {
            "assisted-installer": "registry.redhat.io/rhai-tech-preview/assisted-installer-rhel8:v1.0.0-175",
            "assisted-installer-controller": "registry.redhat.io/rhai-tech-preview/assisted-installer-reporter-rhel8:v1.0.0-223",
            "assisted-installer-service": "quay.io/app-sre/assisted-service:ac87f93",
            "discovery-agent": "registry.redhat.io/rhai-tech-preview/assisted-installer-agent-rhel8:v1.0.0-156"
        }
    }

10.1.3.2. Assisted Installer REST API を使用したワーカーノードの追加

Assisted InstallerREST API に対してコマンドラインコマンドを記述することで、ワーカーノードをクラスターに追加できます。この方法は、Web コンソールを使用する代替手段を提供します。

前提条件

  • OpenShift Cluster Manager CLI (ocm) をインストールしている。
  • クラスター作成権限を持つユーザーで OpenShift Cluster Manager にログインする。
  • jq をインストールします。
  • ワーカーノードを追加するクラスターに必要なすべての DNS レコードが存在することを確認してください。

手順

  1. Assisted Installer REST API に対して認証し、セッションの JSON Web トークン (JWT) を生成します。生成された JWT トークンは 15 分間のみ有効です。
  2. 次のコマンドを実行して、$API_URL 変数を設定します。

    $ export API_URL=<api_url>

    <api_url> を Assisted Installer API の URL に置き換えます (例: https://api.openshift.com)。

  3. 次のコマンドを実行して、単一ノードの OpenShift クラスターをインポートします。

    1. $OPENSHIFT_CLUSTER_ID 変数を設定します。クラスターにログインし、次のコマンドを実行します。

      $ export OPENSHIFT_CLUSTER_ID=$(oc get clusterversion -o jsonpath='{.items[].spec.clusterID}')
    2. クラスターのインポートに使用される $CLUSTER_REQUEST 変数を設定します。

      $ export CLUSTER_REQUEST=$(jq --null-input --arg openshift_cluster_id "$OPENSHIFT_CLUSTER_ID" '{
        "api_vip_dnsname": "<api_vip>",
        "openshift_cluster_id": $openshift_cluster_id,
        "name": "<openshift_cluster_name>"
      }')

      各項目の説明:

      <api_vip>
      クラスターの API サーバーのホスト名を指定します。これは、API サーバーの DNS ドメイン、またはワーカーノードが到達できる単一ノードの IP アドレスになります。たとえば、api.compute-1.example.com です。
      <openshift_cluster_name>
      クラスターのプレーンテキスト名を指定します。クラスター名は、Day 1 クラスターのインストール中に設定されたクラスター名と一致する必要があります。
    3. クラスターをインポートし、$CLUSTER_ID 変数を設定します。以下のコマンドを実行します。

      $ CLUSTER_ID=$(curl "$API_URL/api/assisted-install/v2/clusters/import" -H "Authorization: Bearer ${JWT_TOKEN}" -H 'accept: application/json' -H 'Content-Type: application/json' \
        -d "$CLUSTER_REQUEST" | tee /dev/stderr | jq -r '.id')
  4. 次のコマンドを実行して、クラスターの InfraEnv リソースを生成し、$INFRA_ENV_ID 変数を設定します。

    1. Red Hat OpenShift Cluster Manager からプルシークレット をダウンロードします。
    2. $INFRA_ENV_REQUEST 変数を設定します。

      export INFRA_ENV_REQUEST=$(jq --null-input \
          --slurpfile pull_secret <path_to_pull_secret_file> \//
          --arg ssh_pub_key "$(cat <path_to_ssh_pub_key>)" \//
          --arg cluster_id "$CLUSTER_ID" '{
        "name": "<infraenv_name>",
        "pull_secret": $pull_secret[0] | tojson,
        "cluster_id": $cluster_id,
        "ssh_authorized_key": $ssh_pub_key,
        "image_type": "<iso_image_type>"
      }')

      各項目の説明:

      <path_to_pull_secret_file>
      Red Hat OpenShift Cluster Manager からダウンロードしたプルシークレット を含むローカルファイルへのパスを指定します。
      <path_to_ssh_pub_key>
      ホストへのアクセスに必要な公開 SSH 鍵へのパスを指定します。この値を設定しないと、検出モードでホストにアクセスできません。
      <infraenv_name>
      InfraEnv リソースのプレーンテキスト名を指定します。
      <iso_image_type>
      ISO イメージの種類を指定します。full-iso または minimal-iso のいずれかです。
    3. $INFRA_ENV_REQUEST/v2/infra-envs API に送信し、$INFRA_ENV_ID 変数を設定します。

      $ INFRA_ENV_ID=$(curl "$API_URL/api/assisted-install/v2/infra-envs" -H "Authorization: Bearer ${JWT_TOKEN}" -H 'accept: application/json' -H 'Content-Type: application/json' -d "$INFRA_ENV_REQUEST" | tee /dev/stderr | jq -r '.id')
  5. 次のコマンドを実行して、クラスターワーカーノードの検出 ISO の URL を取得します。

    $ curl -s "$API_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID" -H "Authorization: Bearer ${JWT_TOKEN}" | jq -r '.download_url'

    出力例

    https://api.openshift.com/api/assisted-images/images/41b91e72-c33e-42ee-b80f-b5c5bbf6431a?arch=x86_64&image_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2NTYwMjYzNzEsInN1YiI6IjQxYjkxZTcyLWMzM2UtNDJlZS1iODBmLWI1YzViYmY2NDMxYSJ9.1EX_VGaMNejMhrAvVRBS7PDPIQtbOOc8LtG8OukE1a4&type=minimal-iso&version=$VERSION

  6. ISO をダウンロードします。

    $ curl -L -s '<iso_url>' --output rhcos-live-minimal.iso

    <iso_url> を前の手順の ISO の URL に置き換えます。

  7. ダウンロードした rhcos-live-minimal.iso から新しいワーカーホストを起動します。
  8. インストールされていない クラスター内のホストのリストを取得します。新しいホストが表示されるまで、次のコマンドを実行し続けます。

    $ curl -s "$API_URL/api/assisted-install/v2/clusters/$CLUSTER_ID" -H "Authorization: Bearer ${JWT_TOKEN}" | jq -r '.hosts[] | select(.status != "installed").id'

    出力例

    2294ba03-c264-4f11-ac08-2f1bb2f8c296

  9. 新しいワーカーノードの $HOST_ID 変数を設定します。次に例を示します。

    $ HOST_ID=<host_id>

    <host_id> を前の手順のホスト ID に置き換えます。

  10. 以下のコマンドを実行して、ホストがインストールできる状態であることを確認します。

    注記

    完全な jq 式を含むコマンド全体をコピーしてください。

    $ curl -s $API_URL/api/assisted-install/v2/clusters/$CLUSTER_ID -H "Authorization: Bearer ${JWT_TOKEN}" | jq '
    def host_name($host):
        if (.suggested_hostname // "") == "" then
            if (.inventory // "") == "" then
                "Unknown hostname, please wait"
            else
                .inventory | fromjson | .hostname
            end
        else
            .suggested_hostname
        end;
    
    def is_notable($validation):
        ["failure", "pending", "error"] | any(. == $validation.status);
    
    def notable_validations($validations_info):
        [
            $validations_info // "{}"
            | fromjson
            | to_entries[].value[]
            | select(is_notable(.))
        ];
    
    {
        "Hosts validations": {
            "Hosts": [
                .hosts[]
                | select(.status != "installed")
                | {
                    "id": .id,
                    "name": host_name(.),
                    "status": .status,
                    "notable_validations": notable_validations(.validations_info)
                }
            ]
        },
        "Cluster validations info": {
            "notable_validations": notable_validations(.validations_info)
        }
    }
    ' -r

    出力例

    {
      "Hosts validations": {
        "Hosts": [
          {
            "id": "97ec378c-3568-460c-bc22-df54534ff08f",
            "name": "localhost.localdomain",
            "status": "insufficient",
            "notable_validations": [
              {
                "id": "ntp-synced",
                "status": "failure",
                "message": "Host couldn't synchronize with any NTP server"
              },
              {
                "id": "api-domain-name-resolved-correctly",
                "status": "error",
                "message": "Parse error for domain name resolutions result"
              },
              {
                "id": "api-int-domain-name-resolved-correctly",
                "status": "error",
                "message": "Parse error for domain name resolutions result"
              },
              {
                "id": "apps-domain-name-resolved-correctly",
                "status": "error",
                "message": "Parse error for domain name resolutions result"
              }
            ]
          }
        ]
      },
      "Cluster validations info": {
        "notable_validations": []
      }
    }

  11. 前のコマンドでホストの準備ができていることが示されたら、次のコマンドを実行し、/v2/infra-envs/{infra_env_id}/hosts/{host_id}/actions/install API を使用してインストールを開始します。

    $ curl -X POST -s "$API_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts/$HOST_ID/actions/install"  -H "Authorization: Bearer ${JWT_TOKEN}"
  12. インストールが進行するにつれて、インストールはワーカーノードの保留中の証明書署名要求 (CSR) を生成します。

    重要

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

    次の API 呼び出しを実行し続けて、クラスターのインストールを監視します。

    $ curl -s "$API_URL/api/assisted-install/v2/clusters/$CLUSTER_ID" -H "Authorization: Bearer ${JWT_TOKEN}" | jq '{
        "Cluster day-2 hosts":
            [
                .hosts[]
                | select(.status != "installed")
                | {id, requested_hostname, status, status_info, progress, status_updated_at, updated_at, infra_env_id, cluster_id, created_at}
            ]
    }'

    出力例

    {
      "Cluster day-2 hosts": [
        {
          "id": "a1c52dde-3432-4f59-b2ae-0a530c851480",
          "requested_hostname": "control-plane-1",
          "status": "added-to-existing-cluster",
          "status_info": "Host has rebooted and no further updates will be posted. Please check console for progress and to possibly approve pending CSRs",
          "progress": {
            "current_stage": "Done",
            "installation_percentage": 100,
            "stage_started_at": "2022-07-08T10:56:20.476Z",
            "stage_updated_at": "2022-07-08T10:56:20.476Z"
          },
          "status_updated_at": "2022-07-08T10:56:20.476Z",
          "updated_at": "2022-07-08T10:57:15.306369Z",
          "infra_env_id": "b74ec0c3-d5b5-4717-a866-5b6854791bd3",
          "cluster_id": "8f721322-419d-4eed-aa5b-61b50ea586ae",
          "created_at": "2022-07-06T22:54:57.161614Z"
        }
      ]
    }

  13. オプション: 次のコマンドを実行して、クラスターのすべてのイベントを表示します。

    $ curl -s "$API_URL/api/assisted-install/v2/events?cluster_id=$CLUSTER_ID" -H "Authorization: Bearer ${JWT_TOKEN}" | jq -c '.[] | {severity, message, event_time, host_id}'

    出力例

    {"severity":"info","message":"Host compute-0: updated status from insufficient to known (Host is ready to be installed)","event_time":"2022-07-08T11:21:46.346Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Host compute-0: updated status from known to installing (Installation is in progress)","event_time":"2022-07-08T11:28:28.647Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Host compute-0: updated status from installing to installing-in-progress (Starting installation)","event_time":"2022-07-08T11:28:52.068Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Uploaded logs for host compute-0 cluster 8f721322-419d-4eed-aa5b-61b50ea586ae","event_time":"2022-07-08T11:29:47.802Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Host compute-0: updated status from installing-in-progress to added-to-existing-cluster (Host has rebooted and no further updates will be posted. Please check console for progress and to possibly approve pending CSRs)","event_time":"2022-07-08T11:29:48.259Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Host: compute-0, reached installation stage Rebooting","event_time":"2022-07-08T11:29:48.261Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}

  14. クラスターにログインし、保留中の CSR を承認してインストールを完了します。

検証

  • 新しいワーカーノードが Ready のステータスで、クラスターに正常に追加されたことを確認します。

    $ oc get nodes

    出力例

    NAME                           STATUS   ROLES           AGE   VERSION
    control-plane-1.example.com    Ready    master,worker   56m   v1.29.4
    compute-1.example.com          Ready    worker          11m   v1.29.4

10.1.4. 単一ノードの OpenShift クラスターへのワーカーノードの手動での追加

Red Hat Enterprise Linux CoreOS (RHCOS) ISO からワーカーノードを起動し、クラスターの worker.ign ファイルを使用して新しいワーカーノードをクラスターに参加させることにより、単一ノードの OpenShift クラスターにワーカーノードを手動で追加できます。

前提条件

  • ベアメタルに単一ノードの OpenShift クラスターをインストールします。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • ワーカーノードを追加するクラスターに必要なすべての DNS レコードが存在することを確認してください。

手順

  1. OpenShift Container Platform バージョンを設定します。

    $ OCP_VERSION=<ocp_version>

    <ocp_version> は、現在のバージョン (latest-4.16 など) に置き換えます。

  2. ホストアーキテクチャーを設定します。

    $ ARCH=<architecture>

    <architecture> をターゲットホストアーキテクチャー (aarch64x86_64 など) に置き換えます。

  3. 次のコマンドを実行して、実行中の単一ノードクラスターから worker.ign データを取得します。

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
  4. ネットワークからアクセスできる Web サーバーで worker.ign ファイルをホストします。
  5. OpenShift Container Platform インストーラーをダウンロードし、以下のコマンドを入力して使用できるようにします。

    $ curl -k https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$OCP_VERSION/openshift-install-linux.tar.gz > openshift-install-linux.tar.gz
    $ tar zxvf openshift-install-linux.tar.gz
    $ chmod +x openshift-install
  6. RHCOS ISO URL を取得します。

    $ ISO_URL=$(./openshift-install coreos print-stream-json | grep location | grep $ARCH | grep iso | cut -d\" -f4)
  7. RHCOS ISO をダウンロードします。

    $ curl -L $ISO_URL -o rhcos-live.iso
  8. RHCOS ISO とホストされている worker.ign ファイルを使用して、ワーカーノードをインストールします。

    1. RHCOS ISO と任意のインストール方法を使用して、ターゲットホストを起動します。
    2. ターゲットホストが RHCOS ISO から起動したら、ターゲットホストでコンソールを開きます。
    3. ローカルネットワークで DHCP が有効になっていない場合は、RHCOS インストールを実行する前に、新しいホスト名で Ignition ファイルを作成し、ワーカーノードの静的 IP アドレスを設定する必要があります。以下の手順を実行します。

      1. 静的 IP を使用してワーカーホストネットワーク接続を設定します。ターゲットホストコンソールで次のコマンドを実行します。

        $ nmcli con mod <network_interface> ipv4.method manual /
        ipv4.addresses <static_ip> ipv4.gateway <network_gateway> ipv4.dns <dns_server> /
        802-3-ethernet.mtu 9000

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

        <static_ip>
        ホストの静的 IP アドレスと CIDR を指定します (例: 10.1.101.50/24)。
        <network_gateway>
        ネットワークゲートウェイを指定します。たとえば、10.1.101.1 などです。
      2. 変更したネットワークインターフェイスを有効にします。

        $ nmcli con up <network_interface>
      3. 新しい Ignition ファイル new-worker.ign を作成します。このファイルには、元の worker.ign への参照と、coreos-installer プログラムが新しいワーカーホストの /etc/hostname ファイルに入力するために使用する追加の命令を含めます。以下に例を示します。

        {
          "ignition":{
            "version":"3.2.0",
            "config":{
              "merge":[
                {
                  "source":"<hosted_worker_ign_file>"
                }
              ]
            }
          },
          "storage":{
            "files":[
              {
                "path":"/etc/hostname",
                "contents":{
                  "source":"data:,<new_fqdn>"
                },
                "mode":420,
                "overwrite":true,
                "path":"/etc/hostname"
              }
            ]
          }
        }

        各項目の説明:

        <hosted_worker_ign_file>
        元の worker.ign ファイルへのローカルアクセス可能な URL を指定します。たとえば、http://webserver.example.com/worker.ign などです。
        <new_fqdn>
        ワーカーノードに設定する新しい FQDN を指定します。たとえば、new-worker.example.com です。
      4. ネットワークからアクセスできる Web サーバーで new-worker.ign ファイルをホストします。
      5. 次の coreos-installer コマンドを実行して、ignition-url とハードディスクの詳細を渡します。

        $ sudo coreos-installer install --copy-network /
        --ignition-url=<new_worker_ign_file> <hard_disk> --insecure-ignition

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

        <new_worker_ign_file>
        ホストされている new-worker.ign ファイルへのローカルでアクセス可能な URL を指定します (例: http://webserver.example.com/new-worker.ign)。
        <hard_disk>
        RHCOS をインストールするハードディスクを指定します (例: /dev/sda)。
    4. DHCP が有効になっているネットワークでは、静的 IP を設定する必要はありません。ターゲットホストコンソールから次の coreos-installer コマンドを実行して、システムをインストールします。

      $ coreos-installer install --ignition-url=<hosted_worker_ign_file> <hard_disk>
    5. DHCP を手動で有効にするには、次の NMStateConfig CR を単一ノードの OpenShift クラスターに適用します。

      apiVersion: agent-install.openshift.io/v1
      kind: NMStateConfig
      metadata:
        name: nmstateconfig-dhcp
        namespace: example-sno
        labels:
          nmstate_config_cluster_name: <nmstate_config_cluster_label>
      spec:
        config:
          interfaces:
            - name: eth0
              type: ethernet
              state: up
              ipv4:
                enabled: true
                dhcp: true
              ipv6:
                enabled: false
        interfaces:
          - name: "eth0"
            macAddress: "AA:BB:CC:DD:EE:11"
      重要

      NMStateConfig CR は、静的 IP アドレスを持つワーカーノードのデプロイメントを正常に実行する場合、およびシングルノードの OpenShift が静的 IP アドレスでデプロイされている場合に動的 IP アドレスを持つワーカーノードを追加する場合に必要です。クラスターネットワーク DHCP は、これらのネットワーク設定を新しいワーカーノードに自動的に設定しません。

  9. インストールが進行するにつれて、インストールはワーカーノードの保留中の証明書署名要求 (CSR) を生成します。プロンプトが表示されたら、保留中の CSR を承認してインストールを完了します。
  10. インストールが完了したら、ホストを再起動します。ホストは、新しいワーカーノードとしてクラスターに参加します。

検証

  • 新しいワーカーノードが Ready のステータスで、クラスターに正常に追加されたことを確認します。

    $ oc get nodes

    出力例

    NAME                           STATUS   ROLES           AGE   VERSION
    control-plane-1.example.com    Ready    master,worker   56m   v1.29.4
    compute-1.example.com          Ready    worker          11m   v1.29.4

10.1.5. マシンの証明書署名要求の承認

クラスターにマシンを追加するには、各マシン用に生成された証明書署名要求 (CSR) のステータスを確認します。手動承認が必要な場合は、まずクライアントからのリクエストを承認し、次にサーバーからのリクエストを承認してください。

前提条件

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

手順

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

    $ oc get nodes

    出力例

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

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

    注記

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

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

    $ oc get csr

    出力例

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

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

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

    注記

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

    注記

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

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

      $ oc adm certificate approve <csr_name>

      各項目の説明:

      <csr_name>
      現在登録されている CSR のリストから、CSR の名前を指定します。
    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

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

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

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

    $ oc get csr

    出力例

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

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

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

      $ oc adm certificate approve <csr_name>

      各項目の説明:

      <csr_name>
      現在登録されている CSR のリストから、CSR の名前を指定します。
    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
  6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。

    $ oc get nodes

    出力例

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

    注記

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

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る