クラスターのアップグレードが失敗した場合に EKS Anywhere クラスターを稼働状態に戻すにはどうすればよいですか?

所要時間4分

eksctl コマンドを使用して Amazon Elastic Kubernetes サービス (Amazon EKS) Anywhere 管理クラスターをアップグレードしたいです。ただし、アップグレードプロセスが失敗するか、完了前に中断されます。

解決策

Amazon EKS Anywhere 管理クラスターをアップグレードする場合、プロセスには検証フェーズとアップグレードフェーズの 2 つのフェーズが含まれます。失敗したアップグレードの回復手順は、アップグレードのどのフェーズが中断されたかによって異なります。

検証フェーズ

EKS Anywhere クラスターをアップグレードすると、eksctl は一連のプリフライトチェックを実行して、クラスターの準備が整っていることを確認します。これはアップグレード前に発生し、eksctl は更新された仕様に合わせてクラスターを変更します。

eksctl がこれらのチェックを実行すると、次の例のようなメッセージが表示されます。

Performing setup and validations
   Connected to server
   Authenticated to vSphere
   Datacenter validated
   Network validated
Creating template. This might take a while.
   Datastore validated
   Folder validated
   Resource pool validated
   Datastore validated
   Folder validated
   Resource pool validated
   Datastore validated
   Folder validated
   Resource pool validated
   Machine config tags validated
   Control plane and Workload templates validated
   Vsphere provider validation
   Validate certificate for registry mirror
   Control plane ready
   Worker nodes ready
   Nodes ready
   Cluster CRDs ready
   Cluster object present on workload cluster
   Upgrade cluster kubernetes version increment
   Validate authentication for git provider
   Validate immutable fields
   Upgrade preflight validations pass

次に、eksctl は引き続き管理クラスターで実行される CAPI コントローラーの検証を行います。これらのコントローラーのどれかをアップグレードする必要がある場合、eksctl はそれらもアップグレードします。このプロセス中に、eksctl は管理クラスターをアップグレードするための KiND ブートストラップクラスターも作成します。このプロセスを反映したメッセージが表示されます。

Ensuring etcd CAPI providers exist on management cluster before
Pausing EKS-A cluster controller reconcile
Pausing GitOps cluster resources reconcile
Upgrading core components
Creating bootstrap cluster
Provider specific pre-capi-install-setup on bootstrap cluster
Provider specific post-setup
Installing cluster-api providers on bootstrap cluster

これらのチェックまたはアクションのいずれかが失敗した場合、アップグレードは停止し、管理クラスターは元のバージョンのままになります。

失敗した特定のチェックの詳細については、eksctl ログを確認してください。

検証段階での問題

このフェーズで障害から回復するには、次の手順を実行してください。

1.検証が失敗した原因となった問題をトラブルシューティングした上で修正します。

2.eksctl anywhere クラスターアップグレードコマンドを再実行します。**-v9 ** フラグを使用するのがベストプラクティスです。

アップグレードフェーズ

アップグレード段階では、eksctl は次の主なアクションを実行します。

管理クラスターの CAPI オブジェクト (マシン、KubeadmControlPlane、etcdAdmCluster など) をブートストラップクラスターに移動します
etcd とコントロールプレーンのコンポーネントをアップグレードします
ワーカーノードコンポーネントをアップグレードします

このフェーズでは、次の例のようなメッセージが表示されます。

Moving cluster management from bootstrap to workload cluster
Applying new EKS-A cluster resource
Resuming EKS-A controller reconcile
Updating Git Repo with new EKS-A cluster spec
GitOps field not specified, update git repo skipped
Forcing reconcile Git repo with latest commit
GitOps not configured, force reconcile flux git repo skipped
Resuming GitOps cluster resources kustomization
Writing cluster config file
    Cluster upgraded!

eksctl は、Kubernetes デプロイメントと同様に、ローリングプロセスを使用してその場でアップグレードを実行します。また、このアップグレードで新しい仮想マシン (VM) を作成し、古い仮想マシンを削除します。このプロセスは、すべてのコントロールプレーンコンポーネントがアップグレードされるまで、各コンポーネントに 1 つずつ適用されます。

VM の実行に失敗すると、アップグレードは失敗し、設定されたタイムアウト間隔後に停止します。ローリングプロセスでは、クラスターが準備完了状態のままになるように、古い仮想マシンを実行し続けます。

アップグレード段階での問題

このフェーズの障害から回復するには、次の手順を実行してください。

1.アップグレードが失敗する原因となった問題をトラブルシューティングして修正します。失敗の詳細については、eksctl ログを確認してください。

2.回復プロセスを容易にするために、環境変数を設定します。

**CLUSTER\ _NAME:**クラスターの名前
CLITOOLS\ _CONTT:アップグレードの中断後に環境に残っているイメージcli-toolsを実行するコンテナの名前
**キンドキューブ:**KinD ブートストラップクラスターへのアクセスに使用する Kubeconfig ファイル
**管理用キューブ:**管理クラスターへのアクセスに使用する Kubeconfig ファイル
**EKSA\ _VSPHERE\ _USERNAME と EKSA\ _VSPHERE\ _PASSWPRD:**vCenter にアクセスするための認証情報

これらの変数の次の例を参照してください。

CLUSTER_NAME=cluster3
CLITOOLS_CONT=eksa_1681572481616591501
KINDKUBE=$CLUSTER_NAME/generated/${CLUSTER_NAME}.kind.kubeconfig
MGMTKUBE=$CLUSTER_NAME/$CLUSTER_NAME-eks-a-cluster.kubeconfig
EKSA_VSPHERE_USERNAME=xxxxx
EKSA_VSPHERE_PASSWORD=yyyyy

3.マシンやクラスターなどの管理クラスターの CAPI コンポーネントが 準備完了 状態であることを確認します。また、管理クラスターのkubeApi-serverが応答性があることを確認してください。そのためには、以下のコマンドを実行してください。

kubectl --kubeconfig $KINDKUBE -n eksa-system get machines
docker exec -i $CLITOOLS_CONT clusterctl describe cluster cluster3  --kubeconfig $KINDKUBE -n eksa-system
kubectl --kubeconfig $MGMTKUBE -n kube-system get node

次の例のような出力が表示されます。

NAME                            CLUSTER    NODENAME                        PROVIDERID                                       PHASE     AGE     VERSION
cluster3-2snw8                  cluster3   cluster3-2snw8                  vsphere://4230efe1-e1f5-c8e5-9bff-12eca320f5db   Running   3m13s   v1.23.17-eks-1-23-19
cluster3-etcd-chkc5             cluster3                                   vsphere://4230826c-b25d-937a-4728-3e607e6af579   Running   4m14s
cluster3-md-0-854976576-tw6hr   cluster3   cluster3-md-0-854976576-tw6hr   vsphere://4230f2e5-0a4b-374c-f06b-41ac1f80e41f   Running   4m30s   v1.22.17-eks-1-22-24

$ docker exec -i $CLITOOLS_CONT clusterctl describe cluster cluster3  --kubeconfig $KINDKUBE -n eksa-system
NAME                                               READY  SEVERITY  REASON  SINCE  MESSAGE
Cluster/cluster3                                   True                     49s
├─ClusterInfrastructure - VSphereCluster/cluster3  True                     4m53s
├─ControlPlane - KubeadmControlPlane/cluster3      True                     49s
│ └─Machine/cluster3-2snw8                         True                     2m51s
└─Workers
  ├─MachineDeployment/cluster3-md-0                True                     4m53s
  │ └─Machine/cluster3-md-0-854976576-tw6hr        True                     4m53s
  └─Other
    └─Machine/cluster3-etcd-chkc5                  True                     3m55s

$ kubectl --kubeconfig $MGMTKUBE -n kube-system get node
NAME                             STATUS   ROLES                  AGE   VERSION
cluster3-md-0-854976576-tw6hr    Ready    [none]                 18m   v1.22.17-eks-a51510b
cluster3-2snw8                   Ready    control-plane,master   19m   v1.23.17-eks-a51510b

4.管理クラスタ CAPI コンポーネントをバックアップします。

mkdir ${CLUSTER_NAME}-backup
docker exec -i $CLITOOLS_CONT clusterctl move --to-directory ${CLUSTER_NAME}-backup  --kubeconfig $KINDKUBE -n eksa-system

5.管理クラスタ CAPI コンポーネントを管理クラスタに戻します。

$ docker exec -i $CLITOOLS_CONT clusterctl move --to-kubeconfig $MGMTKUBE  --kubeconfig $KINDKUBE -n eksa-system
Performing move...
Discovering Cluster API objects
Moving Cluster API objects Clusters=1
Moving Cluster API objects ClusterClasses=0
Creating objects in the target cluster
Deleting objects from the source cluster

次の例のような出力が表示されます。

$ docker exec -i $CLITOOLS_CONT clusterctl move --to-kubeconfig $MGMTKUBE  --kubeconfig $KINDKUBE -n eksa-system
Performing move...
Discovering Cluster API objects
Moving Cluster API objects Clusters=1
Moving Cluster API objects ClusterClasses=0
Creating objects in the target cluster
Deleting objects from the source cluster

6.マシンやクラスターなどの管理クラスターの CAPI コンポーネントが KinD ブートストラップクラスターに含まれていないかを確認してください。管理クラスターに表示されていることを確認してください。そのためには、以下のコマンドを実行します。

kubectl --kubeconfig $KINDKUBE -n eksa-system get cluster -n eksa-system
kubectl --kubeconfig $MGMTKUBE get machines -n eksa-system

次の例のような出力が表示されます。

$ kubectl --kubeconfig $KINDKUBE -n eksa-system get cluster -n eksa-system
No resources found in eksa-system namespace.

$ kubectl --kubeconfig $MGMTKUBE get machines -n eksa-system
NAME                           CLUSTER    NODENAME                       PROVIDERID                                       PHASE     AGE     VERSION
cluster2-4n7qd                 cluster2   cluster2-4n7qd                 vsphere://4230fb07-2823-3474-c41f-b7223dec3089   Running   2m27s   v1.23.17-eks-1-23-19
cluster2-etcd-h4tpl            cluster2                                  vsphere://42303b36-1991-67a9-e942-dd9959760649   Running   2m27s
cluster2-md-0-fd6c558b-6cfvq   cluster2   cluster2-md-0-fd6c558b-6cfvq   vsphere://423019a3-ad3f-1743-e7a8-ec8772d3edc2   Running   2m26s   v1.22.17-eks-1-22-24

7.アップグレードを再実行します。次のフラグ**--force-cleanup-v9**フラグを使用してください:

eksctl anywhere upgrade cluster -f cluster3/cluster3-eks-a-cluster.yaml --force-cleanup -v9

クラスターのアップグレードが失敗した場合に EKS Anywhere クラスターを稼働状態に戻すにはどうすればよいですか?

解決策

検証フェーズ

アップグレードフェーズ

関連情報

関連するコンテンツ