高可用性を実現するために AWS Outposts でローカル Amazon EKS クラスターを作成する

デバイスまたは AWS CloudShell に eksctl コマンドラインツールのバージョン 0.194.0 以降をインストールします。eksctl をインストールまたはアップグレードするには、eksctl ドキュメントの「インストール」を参照してください。

次のコンテンツをデバイスにコピーします。次の値を置き換えたら、変更したコマンドを実行して outpost-control-plane.yaml ファイルを作成します。

前のステップで作成した設定ファイルを使用してクラスターを作成します。eksctl は、クラスターをデプロイするために VPC と 1 つのサブネットを Outpost に作成します。

eksctl create cluster -f outpost-control-plane.yaml

クラスターのプロビジョニングには数分かかります。クラスターの作成中は、数行の出力が表示されます。出力の最後の行は、次のサンプル行のようになります。

[✓]  EKS cluster "my-cluster" in "region-code" region is ready

eksctl コマンドはクラスターを作成した IAM プリンシパル (ユーザーまたはロール) のアクセスエントリを自動的に作成し、クラスター上の Kubernetes オブジェクトに対して IAM プリンシパル管理者にアクセス許可を付与しました。クラスター作成者にクラスター上の Kubernetes オブジェクトへの管理者アクセス権を付与したくない場合は、前の設定ファイルに次のテキストを追加します: bootstrapClusterCreatorAdminPermissions: false (metadata、vpc および outpost と同じレベル)。オプションを追加した場合、クラスターの作成後に少なくとも 1 つの IAM プリンシパルのアクセスエントリを作成する必要があります。そうしないと、IAM プリンシパルはクラスター上の Kubernetes オブジェクトにアクセスできなくなります。

Amazon EKS の要件を満たす既存の VPC とサブネットが必要です。詳細については、「AWS Outposts で Amazon EKS クラスターの VPC とサブネットを作成する」を参照してください。

既にローカルクラスター IAM ロールがある場合、または eksctl を使用してクラスターを作成する場合は、このステップはスキップできます。デフォルトでは、eksctl により、ロールが自動的に作成されます。

Amazon EKS コンソールを開きます。

コンソール画面の上部で、サポートされている AWS リージョン を選択したことを確認します。

[クラスターを追加]、[作成] の順にクリックします。

[クラスターの設定] ページで、次のフィールドの値を入力または選択します。

[ネットワーキングの指定] ページで、次のフィールドの値を選択します。

[オブザーバビリティの設定] ページでは、有効にする [メトリクス] と [コントロールプレーンのロギング] オプションをオプションで選択できます。デフォルトでは、それぞれのログタイプは無効化されています。

[確認と作成] ページで、前のページで入力または選択した情報を確認します。変更する必要がある場合は、[編集] を選択します。そのままでよければ、[作成] を選択します。クラスターがプロビジョニングされている間、[ステータス] フィールドに [作成中] と表示されます。

クラスターのプロビジョニングには数分かかります。

クラスターを作成すると、作成された Amazon EC2 コントロールプレーンのインスタンスを表示できます。

aws ec2 describe-instances --query 'Reservations[*].Instances[*].{Name:Tags[?Key==`Name`]|[0].Value}' | grep my-cluster-control-plane

出力例は次のとおりです。

"Name": "my-cluster-control-plane-id1"
"Name": "my-cluster-control-plane-id2"
"Name": "my-cluster-control-plane-id3"

各インスタンスは node-role.eks-local.amazonaws.com/control-plane で汚染されているため、コントロールプレーンインスタンスでワークロードがスケジュールされることはありません。テイントの詳細については、Kubernetes ドキュメントの「テイントと容認」を参照してください。Amazon EKS はローカルクラスターの状態を継続的に監視します。セキュリティパッチや問題のあるインスタンスの修復などの自動管理アクションを実行します。ローカルクラスターがクラウドから切断されると、再接続時にクラスターが正常な状態に修復されるようアクションが実行されます。

eksctl を使用してクラスターを作成した場合、このステップはスキップできます。eksctl がこのステップを完了します。新しいコンテキストを kubectl config ファイルに追加して、kubectl がクラスターと通信できるようにします。ファイルを作成し更新する手順については、「kubeconfig ファイルを作成して kubectl を EKS クラスターに接続する」を参照しください。

aws eks update-kubeconfig --region region-code --name my-cluster

出力例は次のとおりです。

Added new context arn:aws:eks:region-code:111122223333:cluster/my-cluster to /home/username/.kube/config

ローカルクラスターの Kubernetes API サーバーに接続するには、サブネットのローカルゲートウェイにアクセスするか、VPC 内から接続します。Outpost ラックをオンプレミスネットワークに接続する方法の詳細については、「AWS Outposts ユーザーガイド」の「How local gateways for racks work」(ラックのローカルゲートウェイの仕組み) を参照してください。ダイレクト VPC ルーティングを使用しており、Outpost サブネットにローカルゲートウェイへのルートがある場合、Kubernetes コントロールプレーンインスタンスのプライベート IP アドレスがローカルネットワークを介して自動的にブロードキャストされます。ローカルクラスターのKubernetes API サーバーエンドポイントは Amazon Route 53 (Route 53) でホストされます。API サービスエンドポイントは、パブリック DNS サーバーによって Kubernetes API サーバーのプライベート IP アドレスに解決されます。

ローカルクラスターの Kubernetes コントロールプレーンインスタンスは、クラスターのライフサイクルを通じて変更されない固定プライベート IP アドレスを静的なエラスティックネットワークインターフェイスで構成されます。Kubernetes API サーバーとやり取りするマシンは、ネットワーク接続が切断されている間は Route 53 に接続できない場合があります。このような場合は、操作の継続性を確保するために、静的プライベート IP アドレスを使用して /etc/hosts を構成することをお勧めします。また、ローカル DNS サーバーを設定して Outpost に接続することもお勧めします。詳細については、「AWS Outposts ドキュメント」を参照してください。次のコマンドを実行して、クラスターとの通信が確立されていることを確認します。

kubectl get svc

出力例は次のとおりです。

NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.100.0.1   <none>        443/TCP   28h

(オプション) AWS Cloud から切断された状態のときにローカルクラスターへの認証をテストします。手順については、AWS Outposts でローカル Amazon EKS クラスターを準備して、ネットワークの切断に備える を参照してください。