作業者ノードの追加
OpenShift クラスターにワーカー ノードを追加するには、次の手順を実行します。
この例の手順は情報提供を目的として提供します。公式の手順については、Red Hat OpenShiftのドキュメント(https://docs.openshift.com/)をご覧ください。
この手順は、早期バインディングの例を示しています。初期バインディングでは、既存のクラスタに対して事前設定されたISOを生成します。その ISO でノードが起動すると、ノードは自動的に既存のクラスタに到達します。
これにより、1 つ以上の CertificateSigningRequests(CSR)が新しいノードから既存のクラスタに送信されます。CSRは、(既存の)クラスタのクライアント証明書を取得する単なるリクエストです。これらの要求を明示的に承認する必要があります。承認されると、既存のクラスタはクライアント証明書を新しいノードに提供し、新しいノードは既存のクラスタへの参加を許可されます。
- アシストインストーラークライアントとして使用しているマシン(VMまたはBMS)にログインします。Assisted Installer クライアント マシンは、Red Hat がホストするアシスト インストーラー サービスに対して、Assisted Installer API 呼び出しを発行する場所です。
- 後のステップで使用する環境変数を設定して、導入を準備します。
- 既存のクラスタに使用するのと同じSSHキーを設定します。
この例では、デフォルトの場所 ~/.ssh/id_rsa.pubからSSH キーを取得し、変数に格納します。
export CLUSTER_SSHKEY=$(cat ~/.ssh/id_rsa.pub)
- イメージ プル シークレットがもうない場合は、Red Hat アカウントのイメージ プル シークレットをローカル コンピューターにダウンロードします。プル シークレットを使用すると、OpenShift コンポーネントのコンテナ イメージを提供するサービスとレジストリにインストールしてアクセスできます。
Red Hat の Hosted Assisted Installer を使用している場合は、https://console.redhat.com/openshift/downloads ページからプル シークレット ファイル(プルシークレット)をダウンロードできます。プルシークレットファイルを Assisted Installer クライアント マシンにコピーします。この例では、プルシークレットを pull-secret.txt と呼ばれるファイルに格納しています。
空白を取り除き、内容を JSON 文字列形式に変換し、次のように環境変数に保存します。
export PULL_SECRET=$(sed '/^[[:space:]]*$/d' pull-secret.txt | jq -R .)
- オフライン アクセス トークンがなくなった場合は、Red Hat アカウントからオフライン アクセス トークンをコピーします。OpenShift クラスター マネージャー API トークンを使用すると、(支援インストーラー クライアント マシン上で)Red Hat がホストするアシスト インストーラー API サービスとやり取りできます。
トークンは、ローカル環境変数にコピーアンドペーストできる文字列です。Red Hat のホスト型支援インストーラーを使用している場合は、 https://console.redhat.com/openshift/downloads から API トークンをコピーできます。
export OFFLINE_ACCESS_TOKEN='<paste offline access token here>'
- OFFLINE_ACCESS_TOKENからトークンを生成(更新)します。この生成されたトークンは、API コマンドを発行するたびに使用します。
export TOKEN=$(curl --silent --data-urlencode "grant_type=refresh_token" --data-urlencode "client_id=cloud-services" --data-urlencode "refresh_token=${OFFLINE_ACCESS_TOKEN}" https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token | jq -r .access_token)メモ：このトークンは定期的に期限切れになります。このトークンの有効期限が切れると、API コマンドを発行するたびに HTTP 4xx 応答が返されます。期限切れになったときにトークンを更新するか、または期限切れ前に定期的にトークンを更新します。トークンが期限切れになったときにトークンを更新しても何の害もありません。
- 既存のクラスタの OpenShift クラスタ ID を取得します。
例: 変数に保存します。
oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}' 1777102a-1fe1-407a-9441-9d0bad4f5968export $OS_CLUSTER_ID="1777102a-1fe1-407a-9441-9d0bad4f5968"
- 残りの環境変数を設定します。
表 1 は、前のステップで説明したものも含め、この手順で設定する必要があるすべての環境変数を示しています。
表 1: 環境変数 変数の 説明 の例 CLUSTER_SSHKEY 既存のクラスタに使用する(パブリック)SSHキー。追加する新しいノードにも同じキーを使用する必要があります。 – PULL_SECRET ダウンロードし、削除し、JSON 文字列形式に変換したシークレットを取得します。 – OFFLINE_ACCESS_TOKEN コピーした OpenShift クラスター マネージャー API トークン。 – トークン OFFLINE_ACCESS_TOKENから生成(更新)したトークン。 – CLUSTER_NAME 既存のクラスターの名前。 クラスタ CLUSTER_DOMAIN 既存のクラスターのベース ドメイン。 contrail.lan OS_CLUSTER_ID 既存のクラスターの OpenShift クラスター ID。 1777102a-1fe1-407a-9441-9d0bad4f5968 AI_URL 支援インストーラー サービスの URL。この例では、Red Hat のホスト型支援インストーラーを使用します。 https://api.openshift.com
- 既存のクラスタに使用するのと同じSSHキーを設定します。
- 既存のクラスタをインポートします。
curl -X POST "$AI_URL/api/assisted-install/v2/clusters/import" -H "accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" -d "{\"name\":\"$CLUSTER_NAME\",\"openshift_cluster_id\":\"$OS_CLUSTER_ID\",\"api_vip_dnsname\":\"api.$CLUSTER_NAME.$CLUSTER_DOMAIN\"}"クラスターをインポートすると、アシスト インストーラー サービスは AddHostsCluster のクラスター ID を返します。応答にクラスター ID が埋め込まれているのは注意して確認してください。例えば：
"id":"19b809b5-69c4-42d8-9e5e-56aae4aba386"
- ディスカバリーブート ISO を生成します。この ISO を使用して、クラスタに追加するノードを起動します。
ISO は、設定するインフラストラクチャ環境に基づいてインフラストラクチャに合わせてカスタマイズされています。
- インフラストラクチャ環境を説明するファイルを作成します。この例では infra-jsons-addhost.jsonと名付けます
cat << EOF > ./infra-envs-addhost.json { "name": "<InfraEnv Name>", "ssh_authorized_key": "$CLUSTER_SSHKEY", "pull_secret": $PULL_SECRET, "cluster_id": "<AddHostsCluster ID>", "openshift_version": "<same as for existing cluster>", "user_managed_networking": <same as for existing cluster>, "vip_dhcp_allocation": <same as for existing cluster>, "base_dns_domain": "$CLUSTER_DOMAIN", } EOF- InfraEnv Name InfraEnv と呼ぶ名前です。
- AddHostsCluster ID は、AddHostsクラスターのクラスタIDです(前のステップで取得)。
user_managed_networking既存のクラスタとvip_dhcp_allocation同じ値に設定されます。
- InfraEnv を登録します。これに応じて、アシストインストーラサービスはInfraEnv IDを割り当て、指定されたインフラストラクチャ環境に基づいてディスカバリーブートISOを構築します。
curl -X POST "$AI_URL/api/assisted-install/v2/infra-envs" -H "accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" -d @infra-envs-addhosts.json
InfraEnv を登録すると、支援インストーラー サービスから InfraEnv ID が返されます。応答に埋め込まれている InfraEnv ID を慎重に探してください。例えば：
"id":"78d20699-f25b-462c-bc1d-4738590a9344"
InfraEnv ID を変数に格納します。例えば：
export INFRA_ENV_ID="78d20699-f25b-462c-bc1d-4738590a9344"
- 画像のダウンロード URL を取得します。
curl -s $AI_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/downloads/image-url -H "accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" | jq '.url'
- ISO をダウンロードしてファイルに保存します。この例では、それをai-liveiso-addhosts.isoに保存します。
curl -L "<image URL>" -H "Authorization: Bearer $TOKEN" -o ./ai-liveiso-addhosts.iso
- インフラストラクチャ環境を説明するファイルを作成します。この例では infra-jsons-addhost.jsonと名付けます
- 検出ブート ISO で新しいワーカー ノードを起動します。インフラストラクチャにとって最も便利なブート方法を選択します。Red Hat の Hosted Assisted Installer にアクセスできるネットワークに接続された新しいノードが起動していることを確認します。
- 既存のクラスタに新しいノードをインストールします。
- 新しいノードを検査して、その役割が作業者に設定されていることを確認します。
curl -s -X GET --header "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" $AI_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts | jq '.'
ホストロールが作業者に設定されている場合のみ、続行します。
- 新しいノードのホスト ID を取得します。
export HOST_ID=$(curl -s -X GET --header "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" $AI_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts | jq -r '.[].id')
- 新しいノードをインストールします。
curl -X POST "$AI_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts/$HOST_ID/actions/install" -H "accept: application/json" -H "Authorization: Bearer $TOKEN" | jq -r
- インストールの進行状況を確認します。
curl -s -X GET --header "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" $AI_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts | jq '.'
- 新しいノードを検査して、その役割が作業者に設定されていることを確認します。
- 新しいノードが再起動されると、既存のクラスタへの参加を試みます。これにより、1 つ以上の CertificateSigningRequests(CSR)が新しいノードから既存のクラスタに送信されます。CSR 申請を承認する必要があります。
- 保留中の CSR を確認します。
例えば：
root@ai-client:~/contrail# oc get csr -A NAME AGE SIGNERNAME REQUESTOR CONDITION csr-gblnm 20s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending
保留中の CSR が表示されるまで、このコマンドを定期的に繰り返す必要がある場合があります。
- CSR を承認します。
例えば：
root@ai-client:~/contrail# oc adm certificate approve csr-gblnm certificatesigningrequest.certificates.k8s.io/csr-gblnm approved
- 保留中の CSR を確認します。
- 新しいノードが稼働し、既存のクラスタで稼働していることを確認します。
oc get nodes