EKS Anywhere クラスターのブートストラップはどのように機能しますか?

所要時間2分

Amazon Elastic Kubernetes サービス (Amazon EKS) Anywhere のブートストラッププロセスを理解したいです。

解決方法

ブートストラップクラスター

初期スタンドアロンクラスターまたは管理クラスターを作成すると、Amazon EKS Anywhere はブートストラップクラスターも作成します。これは一時的な単一ノードの Kubernetes in Docker (KiND) クラスターで、メインクラスターの作成を容易にするために別の管理マシンに作成されます。

EKS Anywhere は、CAPI および CAPX オペレータをホストするブートストラップクラスタを管理マシン上に作成します。ブートストラップクラスターを作成するためには、EKS Anywhere は以下のステップを完了する必要があります。

KiND ノードイメージを取得する
ノードを準備する
設定を書き込む
コントロールプレーンを起動する
CNI をインストールする
KIND ベースの単一ノードクラスタに StorageClass をインストールする

クラスターを作成する

ブートストラップクラスターが管理マシン上で実行され、適切に設定されると、ターゲットクラスターの作成が開始されます。EKS Anywhere は kubectl を使用して以下のプロセスでターゲットクラスター設定を適用します。

1. etcd、コントロールプレーン、およびワーカーノードが準備完了になった後、ターゲットクラスターはネットワーキングの設定を受け取ります。

2. ターゲットクラスターにデフォルトのストレージクラスがインストールされます。

3. ターゲットクラスターにCAPIプロバイダが設定されます。これにより、ターゲットクラスターは管理するために必要なコンポーネントを制御および実行できます。

4. CAPI がターゲットクラスタで実行されると、CAPI オブジェクトはブートストラップクラスタからターゲットクラスタの CAPI サービスに移動されます。これは clusterctl コマンドで内部的に発生します。

5. ターゲットクラスターは、Kubernetes CRD と EKS Anywhere に固有のその他のアドオンを受け取ります。

6. クラスター構成が保存されます。

ブートストラッププロセスは、**CLUSTER_NAME/generated/CLUSTER_NAME-eks-a-cluster.yaml.**に配置される YAML ファイルを作成します。

ブートストラップが成功すると、この YAML ファイルはCLUSTER_NAME/CLUSTER_NAME-eks-a-cluster.yaml に移動します。

同様に、Kubeconfig はCLUSTER_NAME/generated/CLUSTER_NAME.kind.kubeconfig から CLUSTER_NAME/CLUSTER_NAME-eks-a-cluster.kubeconfig に移動します。

etcd、コントロールプレーン、およびワーカーノードが準備完了になると、ワークロードクラスターはネットワーキングの設定を受け取ります。クラスターがアクティブであり、新しいクラスターで CAPI サービスが実行されている場合、ブートストラップクラスターは不要になります。その後、サービスはブートストラップクラスターを削除します。

パッケージワークフロー

ブートストラッププロセス中、EKS Anywhere はターゲットクラスターの作成、クラスターのアップグレード、および削除のワークフローで次のロジックを使用します。

クラスターの作成

クラスターの作成における完全なパッケージのワークフローについては、GitHubの「create.go」を参照してください。このワークフローでは、EKS Anywhere は次のロジックを使用します。

セットアップと検証
**注:**この手順が失敗した場合は、プレフライトが失敗したか、レジストリが正しく設定されていない可能性があります。
新しいブートストラップクラスターの作成
新しい KiND クラスターの作成
ブートストラップクラスターでのプロバイダー固有の事前インストールセットアップ
cluster-api プロバイダーへのブートストラップクラスターのインストール
プロバイダー固有のポストセットアップ
新しいワークロードクラスターの作成
外部の etcd の準備完了待機
コントロールプレーンの利用可能になるのを待機
ワークロード kubeconfig の生成待機
ワークロードクラスターにネットワーキングのインストール
ブートストラップクラスターにマシンのヘルスチェックのインストール
コントロールプレーンとワーカーマシンの準備完了待機
管理にリソースのインストール
eks-a コンポーネントタスクのインストール
Git 運用マネージャーのインストール
クラスタ管理の移行
クラスター設定の書き込み
ブートストラップクラスターの削除
キュレーションされたパッケージのインストール

クラスターのアップグレード

クラスターアップグレード中のパッケージワークフロー全体については、GitHub の「upgrade.go」を参照してください。このワークフローでは、EKS Anywhere は次のロジックを使用します。

セットアップと検証
シークレットの更新
etcd CAPI コンポーネントの存在を確認
コアコンポーネントのアップグレード
必要なアップグレードの確認
EKS-A 調整の一時停止
ブートストラップクラスターの作成
CAPI のインストール
管理をブートストラップクラスターに移行
管理をワークロードクラスターに移行
ワークロードクラスターのアップグレード
ブートストラップクラスターの削除
ワークロードクラスターと Git リソースの更新
EKS-A 調整を再開
クラスター設定の書き込み

クラスターの削除

クラスターの削除中のパッケージワークフロー全体については、GitHub の「delete.go」を参照してください。このワークフローでは、EKS Anywhere は次のロジックを使用します。

セットアップと検証
管理クラスターの作成
CAPI のインストール
クラスタ管理の移行
ワークロードクラスターの削除
Git リポジトリのクリーンアップ
パッケージリソースの削除
管理クラスターを削除

クラスター作成中のエラー

問題やエラーが発生した場合は、管理マシンと capc-controller-manager のログを確認してください。capc-system 名前空間の kubectl を使用して capc コントローラーマネージャーのログを表示します。さらにトラブルシューティングを行うには、eksa-system 名前空間にあるクラスターの CAPI オブジェクトのステータスを確認してください。

また、capi-kubeadm-bootstrap-controller、capi-kubeadm-control-plane-controller、capi-controller-manager など、他の CAPI マネージャーのエラーに関する関連情報が見つかる場合もあります。これらのマネージャーは連携して動作し、kubectl get pods-A コマンドを使用してそれぞれを独自の名前空間に配置できます。詳細については、「EKS Anywhere のトラブルシューティングガイド」を参照してください。

ブートストラッププロセス中のリンティングエラーを修正するスクリプトについては、GitHub の「bootstrapper.go」を参照してください。