ワーカー・ノードの追加
この手順を使用して、ワーカー・ノードをOpenShiftクラスターに追加します。
この手順例は、純粋に情報提供を目的としています。公式な手順については、Red Hat OpenShift ドキュメント (https://docs.openshift.com/) を参照してください。
この手順では、事前バインディングの例を示します。事前バインディングでは、既存のクラスター用に事前構成された ISO を生成します。ノードがその ISO で起動すると、ノードは自動的に既存のクラスタにアクセスします。
これにより、1 つ以上の CertificateSigningRequest (CSR) が新しいノードから既存のクラスターに送信されます。CSRは、(既存の)クラスタのクライアント証明書を取得するための要求にすぎません。これらの要求は明示的に承認する必要があります。承認されると、既存のクラスターから新しいノードにクライアント証明書が提供され、新しいノードが既存のクラスターに参加できるようになります。
- Assisted Installer クライアントとして使用しているマシン (VM または BMS) にログインします。Assisted Installer クライアントマシンは、Red Hat がホストする Assisted Installer サービスへの Assisted Installer API 呼び出しを発行する場所です。
- 後の手順で使用する環境変数を設定して、デプロイを準備します。
- 既存のクラスターに使用するのと同じ SSH キーを設定します。
この例では、デフォルトの場所 ~/.ssh/id_rsa.pub からその SSH キーを取得し、変数に格納します。
export CLUSTER_SSHKEY=$(cat ~/.ssh/id_rsa.pub)
- イメージプルシークレットがなくなった場合は、イメージプルシークレットを Red Hat アカウントからローカルコンピューターにダウンロードします。プルシークレットにより、インストールは OpenShift コンポーネントのコンテナーイメージを提供するサービスおよびレジストリーにアクセスできます。
Red Hat がホストする Assisted Installer を使用している場合は、https://console.redhat.com/openshift/downloads ページからプルシークレットファイル (pull-secret) をダウンロードできます。プル シークレット ファイルを Assisted Installer クライアント マシンにコピーします。この例では、プルシークレットを pull-secret.txt というファイルに格納します。
次のように、空白を取り除き、内容を JSON 文字列形式に変換して、環境変数に格納します。
export PULL_SECRET=$(sed '/^[[:space:]]*$/d' pull-secret.txt | jq -R .)
- オフライン入力しトークンがなくなった場合は、Red Hat アカウントからオフライン入力しトークンをコピーします。OpenShift Cluster Manager API トークンを使用すると、(Assisted Installer クライアントマシン上で) Red Hat がホストする Assisted Installer API サービスと対話できます。
トークンは、ローカル環境変数にコピーして貼り付けることができる文字列です。Red Hat がホストする Assisted Installer を使用している場合は、 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 Cluster Manager API トークン。 – トークン OFFLINE_ACCESS_TOKENから生成 (更新) したトークン。 – CLUSTER_NAME 既存のクラスターの名前。 マイクラスター CLUSTER_DOMAIN 既存のクラスターのベースドメイン。 contrail.lan OS_CLUSTER_ID 既存のクラスターの OpenShift クラスター ID。 1777102A - 1FE1 - 407A - 9441 - 9D0bad4F5968 AI_URL Assisted Installer サービスの URL。この例では、Red Hat がホストする Assisted Installer を使用します。 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\"}"クラスターをインポートすると、Assisted Installer サービスによって AddHostsCluster のクラスター ID が返されます。応答に埋め込まれたクラスター ID を注意深く探します。例えば：
"id":"19b809b5-69c4-42d8-9e5e-56aae4aba386"
- ディスカバリー・ブートISOを生成します。この ISO を使用して、クラスターに追加するノードを起動します。
ISO は、セットアップするインフラストラクチャ環境に基づいて、インフラストラクチャに合わせてカスタマイズされます。
- インフラストラクチャ環境を記述するファイルを作成します。この例では、「infra-envs-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 は、AddHostsCluster のクラスター ID (前の手順で取得) です。
user_managed_networkingとvip_dhcp_allocationは、既存のクラスターと同じ値に設定されます。
- InfraEnv を登録します。これに応答して、Assisted Installer サービスは 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 を登録すると、Assisted Installer サービスから 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-envs-addhost.json」という名前を付けます。
- 新しいワーカー・ノードをディスカバリー・ブートISOでブートします。インフラストラクチャに最も便利な起動方法を選択します。新しいノードが、Red Hat がホストする Assisted Installer にアクセスできるネットワークに接続されて起動することを確認します。
- 新しいノードを既存のクラスターにインストールします。
- 新しいノードを調べて、そのロールが worker に設定されていることを確認します。
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 '.'
ホスト ロールが worker に設定されている場合にのみ続行します。
- 新しいノードのホスト 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 '.'
- 新しいノードを調べて、そのロールが worker に設定されていることを確認します。
- 新しいノードが再起動されると、既存のクラスタへの参加が試行されます。これにより、1 つ以上の CertificateSigningRequest (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