第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 アドレスがない場合、
apiserverとetcdの間の通信で失敗する可能性があります。
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 レコードが存在することを確認してください。
手順
- OpenShift Cluster Manager にログインし、ワーカーノードを追加するシングルノードクラスターをクリックします。
- Add hosts をクリックし、新しいワーカーノードの検出 ISO をダウンロードして、必要に応じて SSH 公開キーを追加し、クラスター全体のプロキシー設定を設定します。
- 検出 ISO を使用してターゲットホストを起動し、ホストがコンソールで検出されるまで待ちます。ホストが検出されたら、インストールを開始します。
インストールが進行するにつれて、インストールはワーカーノードの保留中の証明書署名要求 (CSR) を生成します。プロンプトが表示されたら、保留中の CSR を承認してインストールを完了します。
ワーカーノードが正常にインストールされると、クラスター Web コンソールにワーカーノードとして一覧表示されます。
重要新しいワーカーノードは、元のクラスターと同じ方法で暗号化されます。
10.1.3. Assisted Installer API を使用したワーカーノードの追加 リンクのコピーリンクがクリップボードにコピーされました!
Assisted InstallerREST API に対してコマンドラインコマンドを記述することで、ワーカーノードをクラスターに追加できます。この方法は、Web コンソールを使用する代替手段を提供する。
ワーカーノードを追加する前に、OpenShift Cluster Manager にログインし、API に対して認証する必要があります。認証後、Assisted InstallerREST 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 InstallerREST API に対してコマンドラインコマンドを記述することで、ワーカーノードをクラスターに追加できます。この方法は、Web コンソールを使用する代替手段を提供する。
前提条件
-
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><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>", "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 クラスターのインストール中に設定されたクラスター名と一致する必要があります。
クラスターをインポートし、
$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変数を設定します。- Red Hat OpenShift Cluster Manager からプルシークレット をダウンロードしてください。
$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>" }')ここでは、以下のようになります。
< プルシークレットファイルへのパス >- Red Hat OpenShift Cluster Manager からダウンロードしたプルシークレット を含むローカルファイルへのパスを指定します。
<ssh 公開鍵へのパス >- ホストへのアクセスに必要な公開 SSH 鍵へのパスを指定します。この値を設定しないと、検出モードでホストにアクセスできません。
< インフラ環境名 >-
InfraEnvリソースのプレーンテキスト名を指定します。 <iso_image_type>-
ISO イメージの種類を指定します。full
-isoまたはminimal-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=$VERSIONISO をダウンロードします。
$ curl -L -s '<iso_url>' --output rhcos-live-minimal.iso<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><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.33.4 compute-1.example.com Ready worker 11m v1.33.4
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><ocp_version>は、現在のバージョン (latest-4.20など) に置き換えます。ホストアーキテクチャーを設定します。
$ ARCH=<architecture><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-installRHCOS 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.isoRHCOS 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>" } ] } }, "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です。
-
ネットワークからアクセスできる 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 を手動で有効にするには、次の
NMStateConfigCR を単一ノードの 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"重要NMStateConfigCR は、静的 IP アドレスを持つワーカーノードのデプロイメントを正常に実行する場合、およびシングルノードの OpenShift が静的 IP アドレスでデプロイされている場合に動的 IP アドレスを持つワーカーノードを追加する場合に必要です。クラスターネットワーク DHCP は、これらのネットワーク設定を新しいワーカーノードに自動的に設定しません。
- インストールが進行するにつれて、インストールはワーカーノードの保留中の証明書署名要求 (CSR) を生成します。プロンプトが表示されたら、保留中の CSR を承認してインストールを完了します。
- インストールが完了したら、ホストを再起動してください。ホストは、新しいワーカーノードとしてクラスターに参加します。
検証
新しいワーカーノードが
Readyのステータスで、クラスターに正常に追加されたことを確認します。$ oc get nodes出力例
NAME STATUS ROLES AGE VERSION control-plane-1.example.com Ready master,worker 56m v1.33.4 compute-1.example.com Ready worker 11m v1.33.4
10.1.5. マシンの証明書署名要求の承認 リンクのコピーリンクがクリップボードにコピーされました!
クラスターにマシンを追加するには、各マシン用に生成された証明書署名要求 (CSR) のステータスを確認します。手動承認が必要な場合は、まずクライアントからのリクエストを承認し、次にサーバーからのリクエストを承認してください。
前提条件
- マシンがクラスターに追加されています。
手順
クラスターがマシンを認識していることを確認します。
$ oc get nodes出力例
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出力には作成したすべてのマシンがリスト表示されます。
注記上記の出力には、一部の 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サービスアカウントによって提出されていることを確認し、ノードの 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 が承認されるまで利用できない可能性があります。
クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。
$ 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>ここでは、以下のようになります。
<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.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注記サーバー CSR の承認後にマシンが
Readyステータスに移行するまでに数分の時間がかかる場合があります。