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

10.1. 単一ノードの OpenShift クラスターへのワーカーノードの追加

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

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

重要

ワーカーノードを追加してもクラスターコントロールプレーンは拡張されず、クラスターに高可用性は提供されません。単一ノードの OpenShift クラスターの場合、高可用性は別のサイトにフェイルオーバーすることによって処理されます。多数のワーカーノードを単一ノードクラスターに追加することは推奨しません。

注記

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

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

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

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

    表10.1 最小リソース要件

    プロファイルvCPUメモリーストレージ

    最低限

    2 vCPU コア

    8GB の RAM

    100GB

    注記

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

    (コアあたりのスレッド数×コア)×ソケット= vCPU

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

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

    表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 を使用して、Red Hat 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 Installer REST API を使用して、単一ノードの OpenShift クラスターにワーカーノードを追加できます。ワーカーノードを追加する前に、OpenShift Cluster Manager にログインし、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 Installer REST API を使用して、クラスターにワーカーノードを追加できます。

前提条件

  • 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> 1
    1
    <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>", 1
        "openshift_cluster_id": $openshift_cluster_id,
        "name": "<openshift_cluster_name>" 2
      }')
      1
      <api_vip> をクラスターの API サーバーのホスト名に置き換えます。これは、API サーバーの DNS ドメイン、またはワーカーノードが到達できる単一ノードの IP アドレスになります。たとえば、api.compute-1.example.com です。
      2
      <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. console.redhat.com の Red Hat OpenShift Cluster Manager からプルシークレットファイルをダウンロードします。
    2. $INFRA_ENV_REQUEST 変数を設定します。

      export INFRA_ENV_REQUEST=$(jq --null-input \
          --slurpfile pull_secret <path_to_pull_secret_file> \1
          --arg ssh_pub_key "$(cat <path_to_ssh_pub_key>)" \2
          --arg cluster_id "$CLUSTER_ID" '{
        "name": "<infraenv_name>", 3
        "pull_secret": $pull_secret[0] | tojson,
        "cluster_id": $cluster_id,
        "ssh_authorized_key": $ssh_pub_key,
        "image_type": "<iso_image_type>" 4
      }')
      1
      <path_to_pull_secret_file> を、console.redhat.com の Red Hat OpenShift Cluster Manager からダウンロードしたプルシークレットを含むローカルファイルへのパスに置き換えます。
      2
      <path_to_ssh_pub_key> を、ホストへのアクセスに必要な公開 SSH キーへのパスに置き換えます。この値を設定しないと、検出モードでホストにアクセスできません。
      3
      <infraenv_name>InfraEnv リソースのプレーンテキスト名に置き換えます。
      4
      <iso_image_type>full-iso または minimal-iso のいずれかの 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=4.12

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

    $ curl -L -s '<iso_url>' --output rhcos-live-minimal.iso 1
    1
    <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> 1
    1
    <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.25.0
    compute-1.example.com          Ready    worker          11m   v1.25.0

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> 1
    1
    <ocp_version> を現在のバージョン (latest-4.12 など) に置き換えます。
  2. ホストアーキテクチャーを設定します。

    $ ARCH=<architecture> 1
    1
    <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>" 1
                }
              ]
            }
          },
          "storage":{
            "files":[
              {
                "path":"/etc/hostname",
                "contents":{
                  "source":"data:,<new_fqdn>" 2
                },
                "mode":420,
                "overwrite":true,
                "path":"/etc/hostname"
              }
            ]
          }
        }
        1
        <hosted_worker_ign_file> は、元の worker.ign ファイルのローカルでアクセス可能な URL です。たとえば、http://webserver.example.com/worker.ign です。
        2
        <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"
      重要

      単一ノードの OpenShift が静的 IP アドレスでデプロイされた場合に、静的 IP アドレスを使用してワーカーノードを正常にデプロイし、動的 IP アドレスを使用してワーカーノードを追加するには、NMStateConfig CR が必要です。クラスターネットワーク DHCP は、これらのネットワーク設定を新しいワーカーノードに自動的に設定しません。

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

検証

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

    $ oc get nodes

    出力例

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

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

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

前提条件

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

手順

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

    $ oc get nodes

    出力例

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

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

    注記

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

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

    $ oc get csr

    出力例

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

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

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

    注記

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

    注記

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

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

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name> は、現行の CSR のリストからの CSR の名前です。
    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

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

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

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

    $ oc get csr

    出力例

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

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

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

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name> は、現行の CSR のリストからの CSR の名前です。
    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

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

    $ oc get nodes

    出力例

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

    注記

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

関連情報