第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 ワーカーノードをインストールするには、次の要件に対応する必要があります。
- 管理ホスト: ISO を準備し、インストールを監視するためのコンピューターが必要です。
実稼働環境グレードサーバー: 単一ノードの OpenShift ワーカーノードをインストールするには、OpenShift Container Platform サービスと実稼働環境ワークロードを実行するのに十分なリソースを備えたサーバーが必要です。
表10.1 最小リソース要件 プロファイル 仮想 CPU メモリー ストレージ 最低限
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 アドレスがない場合、
apiserver
とetcd
の間の通信で失敗する可能性があります。
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 レコードが存在することを確認してください。
手順
- OpenShift Cluster Manager にログインし、ワーカーノードを追加する単一ノードクラスターをクリックします。
- Add hosts をクリックし、新しいワーカーノードの検出 ISO をダウンロードして、必要に応じて SSH 公開キーを追加し、クラスター全体のプロキシー設定を設定します。
- 検出 ISO を使用してターゲットホストを起動し、ホストがコンソールで検出されるまで待ちます。ホストが検出されたら、インストールを開始します。
インストールが進行するにつれて、インストールはワーカーノードの保留中の証明書署名要求 (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
をインストールします。
手順
- OpenShift Cluster Manager にログインし、API トークンをコピーします。
次のコマンドを実行して、コピーした API トークンを使用して
$OFFLINE_TOKEN
変数を設定します。$ export OFFLINE_TOKEN=<copied_api_token>
以前に設定した
$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 レコードが存在することを確認してください。
手順
- Assisted Installer REST API に対して認証し、セッションの JSON Web トークン (JWT) を生成します。生成された JWT トークンは 15 分間のみ有効です。
次のコマンドを実行して、
$API_URL
変数を設定します。$ export API_URL=<api_url> 1
- 1
<api_url>
を Assisted Installer API の URL に置き換えます (例:https://api.openshift.com
)。
次のコマンドを実行して、単一ノードの OpenShift クラスターをインポートします。
$OPENSHIFT_CLUSTER_ID
変数を設定します。クラスターにログインし、次のコマンドを実行します。$ export OPENSHIFT_CLUSTER_ID=$(oc get clusterversion -o jsonpath='{.items[].spec.clusterID}')
クラスターのインポートに使用される
$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 }')
クラスターをインポートし、
$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')
次のコマンドを実行して、クラスターの
InfraEnv
リソースを生成し、$INFRA_ENV_ID
変数を設定します。- console.redhat.com の Red Hat OpenShift Cluster Manager からプルシークレットファイルをダウンロードします。
$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 イメージタイプに置き換えます。
$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')
次のコマンドを実行して、クラスターワーカーノードの検出 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
ISO をダウンロードします。
$ curl -L -s '<iso_url>' --output rhcos-live-minimal.iso 1
- 1
<iso_url>
を前の手順の ISO の URL に置き換えます。
-
ダウンロードした
rhcos-live-minimal.iso
から新しいワーカーホストを起動します。 インストールされていない クラスター内のホストのリストを取得します。新しいホストが表示されるまで、次のコマンドを実行し続けます。
$ 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
新しいワーカーノードの
$HOST_ID
変数を設定します。次に例を示します。$ HOST_ID=<host_id> 1
- 1
<host_id>
を前の手順のホスト ID に置き換えます。
以下のコマンドを実行して、ホストがインストールできる状態であることを確認します。
注記完全な
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": [] } }
前のコマンドでホストの準備ができていることが示されたら、次のコマンドを実行し、/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}"
インストールが進行するにつれて、インストールはワーカーノードの保留中の証明書署名要求 (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" } ] }
オプション: 次のコマンドを実行して、クラスターのすべてのイベントを表示します。
$ 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"}
- クラスターにログインし、保留中の CSR を承認してインストールを完了します。
検証
新しいワーカーノードが
Ready
のステータスで、クラスターに正常に追加されたことを確認します。$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION control-plane-1.example.com Ready master,worker 56m v1.27.3 compute-1.example.com Ready worker 11m v1.27.3
10.1.4. 単一ノードの OpenShift クラスターへのワーカーノードの手動での追加
Red Hat Enterprise Linux CoreOS (RHCOS) ISO からワーカーノードを起動し、クラスターの worker.ign
ファイルを使用して新しいワーカーノードをクラスターに参加させることにより、単一ノードの OpenShift クラスターにワーカーノードを手動で追加できます。
前提条件
- ベアメタルに単一ノードの OpenShift クラスターをインストールします。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - ワーカーノードを追加するクラスターに必要なすべての DNS レコードが存在することを確認してください。
手順
OpenShift Container Platform バージョンを設定します。
$ OCP_VERSION=<ocp_version> 1
- 1
<ocp_version>
を現在のバージョン (latest-4.14
など) に置き換えます。
ホストアーキテクチャーを設定します。
$ ARCH=<architecture> 1
- 1
<architecture>
をターゲットホストアーキテクチャー (aarch64
やx86_64
など) に置き換えます。
次のコマンドを実行して、実行中の単一ノードクラスターから
worker.ign
データを取得します。$ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
-
ネットワークからアクセスできる Web サーバーで
worker.ign
ファイルをホストします。 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
RHCOS ISO URL を取得します。
$ ISO_URL=$(./openshift-install coreos print-stream-json | grep location | grep $ARCH | grep iso | cut -d\" -f4)
RHCOS ISO をダウンロードします。
$ curl -L $ISO_URL -o rhcos-live.iso
RHCOS ISO とホストされている
worker.ign
ファイルを使用して、ワーカーノードをインストールします。- RHCOS ISO と任意のインストール方法を使用して、ターゲットホストを起動します。
- ターゲットホストが RHCOS ISO から起動したら、ターゲットホストでコンソールを開きます。
ローカルネットワークで DHCP が有効になっていない場合は、RHCOS インストールを実行する前に、新しいホスト名で Ignition ファイルを作成し、ワーカーノードの静的 IP アドレスを設定する必要があります。以下の手順を実行します。
静的 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
)。
変更したネットワークインターフェイスを有効にします。
$ nmcli con up <network_interface>
新しい 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
です。
-
ネットワークからアクセスできる Web サーバーで
new-worker.ign
ファイルをホストします。 次の
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
)。
DHCP が有効になっているネットワークでは、静的 IP を設定する必要はありません。ターゲットホストコンソールから次の
coreos-installer
コマンドを実行して、システムをインストールします。$ coreos-installer install --ignition-url=<hosted_worker_ign_file> <hard_disk>
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 は、これらのネットワーク設定を新しいワーカーノードに自動的に設定しません。
- インストールが進行するにつれて、インストールはワーカーノードの保留中の証明書署名要求 (CSR) を生成します。プロンプトが表示されたら、保留中の CSR を承認してインストールを完了します。
- インストールが完了したら、ホストを再起動します。ホストは、新しいワーカーノードとしてクラスターに参加します。
検証
新しいワーカーノードが
Ready
のステータスで、クラスターに正常に追加されたことを確認します。$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION control-plane-1.example.com Ready master,worker 56m v1.27.3 compute-1.example.com Ready worker 11m v1.27.3
10.1.5. マシンの証明書署名要求の承認
マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。
前提条件
- マシンがクラスターに追加されています。
手順
クラスターがマシンを認識していることを確認します。
$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.27.3 master-1 Ready master 63m v1.27.3 master-2 Ready master 64m v1.27.3
出力には作成したすべてのマシンがリスト表示されます。
注記上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。
保留中の証明書署名要求 (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 が表示される可能性があります。
追加したマシンの保留中の CSR すべてが
Pending
ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。注記CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に
machine-approver
によって自動的に承認されます。注記ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、
oc exec
、oc rsh
、およびoc logs
コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR がsystem:node
またはsystem:admin
グループのnode-bootstrapper
サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。
$ oc adm certificate approve <csr_name> 1
- 1
<csr_name>
は、現行の CSR のリストからの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
注記一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。
クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。
$ 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 ...
残りの 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
すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが
Ready
になります。以下のコマンドを実行して、これを確認します。$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION master-0 Ready master 73m v1.27.3 master-1 Ready master 73m v1.27.3 master-2 Ready master 74m v1.27.3 worker-0 Ready worker 11m v1.27.3 worker-1 Ready worker 11m v1.27.3
注記サーバー CSR の承認後にマシンが
Ready
ステータスに移行するまでに数分の時間がかかる場合があります。
関連情報
- CSR の詳細は、Certificate Signing Requests を参照してください。