制御プレーン ノードの置き換え
概要 OpenShift クラスター内の問題ノードを識別して置き換える方法について説明します。
コントロール プレーン ノードを交換するには、まず問題のあるノードを識別して削除する必要があります。問題のノードを削除した後、新しい置換ノードを追加できます。
ジュニパーは、情報提供を目的として、これらの手順の例を示しています。公式の手順については、Red Hat OpenShiftのドキュメント(https://docs.openshift.com/)をご覧ください。
不健全なコントロール プレーン ノードの削除
この手順を使用して、不健全な制御プレーン ノードを識別して削除します。
- コントロール プレーン ノードのステータスを確認して、問題のメンバーを識別します。
user@ai-client:~# oc get nodes -l node-role.kubernetes.io/master NAME STATUS ROLES AGE VERSION ocp1.mycluster.contrail.lan Ready master 16d v1.21.6+bb8d50a ocp2.mycluster.contrail.lan Ready master 16d v1.21.6+bb8d50a ocp3.mycluster.contrail.lan NotReady master 16d v1.21.6+bb8d50a
この例では、ocp3 が正常でないノードです。 - Etcd データベースのバックアップの手順に従って、正常なノードの 1 つで etcd データベースをバックアップします。
- etcd メンバーをリストします。
user@ai-client:~# oc get pods -n openshift-etcd -o wide | grep -v etcd-quorum-guard | grep etcd etcd-ocp1 4/4 Running 0 18d 172.16.0.11 ocp1 <none> <none> etcd-ocp2 4/4 Running 0 18d 172.16.0.12 ocp2 <none> <none> etcd-ocp3 4/4 Running 0 18d 172.16.0.13 ocp3 <none> <none>
- 正常なノード(ocp1 など)の etcd ポッドにリモート シェルを開きます。
user@ai-client:~# oc rsh -n openshift-etcd etcd-ocp1 Defaulted container "etcdctl" out of: etcdctl, etcd, etcd-metrics, etcd-health-monitor, setup (init), etcd-ensure-env-vars (init), etcd-resources-copy (init)
- etcd メンバーをリストします。
sh-4.4# etcdctl member list -w table +------------------+---------+------+--------------------------+--------------------------+------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER | +------------------+---------+------+--------------------------+--------------------------+------------+ | 19faf45778a1ddd3 | started | ocp3 | https://172.16.0.13:2380 | https://172.16.0.13:2379 | false | | ad4840148f3f241c | started | ocp1 | https://172.16.0.11:2380 | https://172.16.0.11:2379 | false | | b1f7a55fb3caa3b6 | started | ocp2 | https://172.16.0.12:2380 | https://172.16.0.12:2379 | false | +------------------+---------+------+--------------------------+--------------------------+------------+
- 問題のノードで etcd メンバーを削除します。
sh-4.4# etcdctl member remove 19faf45778a1ddd3 Member 19faf45778a1ddd3 removed from cluster 60f3fdb1b921fd7
- もう一度メンバー・リストを表示します。
sh-4.4# etcdctl member list -w table +------------------+-----------+------+--------------------------+--------------------------+------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER | +------------------+-----------+------+--------------------------+--------------------------+------------+ | ad4840148f3f241c | started | ocp1 | https://172.16.0.11:2380 | https://172.16.0.11:2379 | false | | b1f7a55fb3caa3b6 | started | ocp2 | https://172.16.0.12:2380 | https://172.16.0.12:2379 | false | +------------------+-----------+------+--------------------------+--------------------------+------------+
- を入力exitしてリモート シェルを終了します。
- AIクライアントノードに戻り、問題などが含まれているメンバーの古い秘密を削除します。
- 問題(削除)メンバーのシークレットを一覧表示します。
user@ai-client:~# oc get secrets -n openshift-etcd | grep ocp3 etcd-peer-ocp3 kubernetes.io/tls 2 18d etcd-serving-metrics-ocp3 kubernetes.io/tls 2 18d etcd-serving-ocp3 kubernetes.io/tls 2 18d
- ピアシークレットを削除します。
user@ai-client:~# oc delete secret -n openshift-etcd etcd-peer-ocp3 secret "etcd-peer-ocp3" deleted
- メトリックシークレットを削除します。
user@ai-client:~# oc delete secret -n openshift-etcd etcd-serving-metrics-ocp3 secret "etcd-serving-metrics-ocp3" deleted
- サービスシークレットを削除します。
user@ai-client:~# oc delete secret -n openshift-etcd etcd-serving-ocp3 secret "etcd-serving-ocp3" deleted
- 問題(削除)メンバーのシークレットを一覧表示します。
- 最後に、問題のノードを削除します。
- 問題ノードにコードを接続します。
user@ai-client:~# oc adm cordon ocp3 node/ocp3 cordoned
- 問題のノードをドレインします。
user@ai-client:~# oc adm drain ocp3 --ignore-daemonsets=true --delete-emptydir-data --force node/ocp3 already cordoned <trimmed>
- 問題のノードを削除します。
user@ai-client:~# oc delete node ocp3 node "ocp3" deleted
- ノードを一覧表示します。
user@ai-client:~# oc get nodes NAME STATUS ROLES AGE VERSION ocp1 Ready master 19d v1.21.6+bb8d50a ocp2 Ready master 19d v1.21.6+bb8d50a ocp4 Ready worker 18d v1.21.6+bb8d50a ocp5 Ready worker 18d v1.21.6+bb8d50a
これで、問題のあるノードを特定して削除できました。 - 問題ノードにコードを接続します。
置き換えのコントロール プレーン ノードを追加します。
既存の OpenShift クラスターに置換コントロール プレーン ノードを追加するには、次の手順を実行します。OpenShift クラスターには、3 つのコントロール プレーン ノードが正確に含まれます。この手順を使用して、すでに 3 つの制御プレーン ノードを持つクラスタにノードを追加することはできません。
この手順は、遅延バインディングの例を示しています。遅延バインディングでは、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キーを設定します。
- ディスカバリーブート 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, "openshift_version": "4.8", "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 と呼ぶ名前です。
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":"5c858ed9-26cf-446d-817c-4c4261541657"
InfraEnv ID を変数に格納します。例えば：
export INFRA_ENV_ID="5c858ed9-26cf-446d-817c-4c4261541657"
- 画像のダウンロード 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 '.'
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 PATCH --header "Content-Type: application/json" "$AI_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts/$HOST_ID" -H "Authorization: Bearer $TOKEN" -d "{ \"machine_config_pool_name\": \"master\"}" | jq -r"machine_config_pool_name": "master",
- 既存のクラスタをインポートします。
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":"c5bbb159-78bc-41c9-99b7-d8a4727a3890"
- AddHostsClusterのクラスタIDを参照して、新しいホストをクラスタにバインドします。
curl -X POST "$AI_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts/$HOST_ID/actions/bind" -H "accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" -d '{"cluster_id":"c5bbb159-78bc-41c9-99b7-d8a4727a3890"}'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 '.'
"status": "known", "status_info": "Host is ready to be installed",
- 新しいノードをインストールします。
curl -X POST -H "accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" "$AI_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts/$HOST_ID/actions/install"
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 '.'
"status_info": "Host has rebooted and no further updates will be posted. Please check console for progress and to possibly approve pending CSRs",
- 新しいノードが再起動されると、既存のクラスタへの参加を試みます。これにより、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