このページの改善にご協力ください
本ユーザーガイドの改善にご協力いただけませんか? このページの下部までスクロールし、[GitHub でこのページの編集] を選択します。皆さまにご協力いただくことで、あらゆる人々に使いやすいユーザーガイドになります。
AWS Outposts で Amazon EKS クラスターをデプロイする
このトピックでは、Outpost でローカルクラスターを実行する際に考慮すべき事項について、概要を説明します。また、Outpost でローカルクラスターをデプロイする方法についても説明します。
重要
-
これらの考慮事項は、関連する Amazon EKS ドキュメントには記載されていません。Amazon EKS ドキュメントに記載されている他のトピックの情報が、ここに紹介する考慮事項と競合する場合は、こちらの考慮事項を優先してください。
-
これらの考慮事項は変更される可能性があり、変更は頻繁に行われる場合があります。そのため、このトピックは定期的に確認することをお勧めします。
-
考慮事項の多くは、AWS Cloud でクラスターを作成する場合の考慮事項とは異なります。
-
ローカルクラスターは Outpost ラックのみをサポートします。単一のローカルクラスターは、単一の論理 Outpost を構成する複数の物理 Outpost ラックにわたって実行できます。単一のローカルクラスターを複数の論理 Outposts にわたって実行することはできません。各論理 Outpost には、単一の Outpost ARN があります。
-
ローカルクラスターは、Outpost のアカウントで Kubernetes コントロールプレーンを実行および管理します。Kubernetes コントロールプレーンインスタンスでワークロードを実行したり、Kubernetes コントロールプレーンのコンポーネントを変更することはできません。これらのノードは Amazon EKS サービスによって管理されます。Kubernetes コントロールプレーンへの変更は、パッチ適用などの自動 Amazon EKS 管理アクションでは存続しません。
-
ローカルクラスターは、セルフマネージド理型アドオンとセルフマネージド型 Amazon Linux ノードグループをサポートしています。Amazon VPC CNI plugin for Kubernetes、kube-proxy、CoreDNS アドオンはローカルクラスターに自動的にインストールされます。
-
ローカルクラスターでは、Outposts で Amazon EBS を使用する必要があります。お客様の Outpost では、Kubernetes コントロールプレーンストレージに使用できる Amazon EBS が必要です。
-
ローカルクラスターは、Outposts で Amazon EBS を使用します。お客様の Outpost では、Kubernetes コントロールプレーンストレージに使用できる Amazon EBS が必要です。Outposts は、Amazon EBS
gp2
ボリュームのみをサポートします。 -
Amazon EBS のバックアップ対象である Kubernetes
PersistentVolumes
は、Amazon EBS CSI ドライバーを使用してサポートされています。 -
ローカルクラスターのコントロールプレーンインスタンスは、可用性の高いスタックされたトポロジ
で設定されます。クォーラムを維持するには、3 つのコントロールプレーンインスタンスのうち 2 つが常に正常である必要があります。クォーラムが失われた場合、AWS 新しいマネージドインスタンスを有効にするにはいくつかのサービス側のアクションが必要になるため、サポートにお問い合わせください。
前提条件
-
Outposts デプロイオプション、キャパシティに関する考慮事項に基づく AWS Outposts での Amazon EKS クラスターのインスタンスタイプとプレイスメントグループの選択、および VPC 要件と考慮事項に精通していること。
-
既存の Outpost。詳細については、「AWS Outposts とは」を参照してください。
-
コンピュータまたは AWS CloudShell に、
kubectl
コマンドラインツールがインストールされていること。バージョンは、ご使用のクラスターの Kubernetes バージョンと同じか、1 つ前のマイナーバージョン以前、あるいはそれより新しいバージョンが使用できます。例えば、クラスターのバージョンが1.29
である場合、kubectl
のバージョン1.28
、1.29
、または1.30
が使用できます。kubectl
をインストールまたはアップグレードする方法については、「kubectl と eksctl のセットアップ」を参照してください。 -
ご使用のデバイスまたは AWS CloudShell で、バージョン
2.12.3
以降、または AWS コマンドラインインターフェイス (AWS CLI) のバージョン1.27.160
以降がインストールおよび設定されていること。現在のバージョンを確認するには、「aws --version | cut -d / -f2 | cut -d ' ' -f1
」を参照してください。macOS のyum
、apt-get
、または Homebrew などのパッケージマネージャーは、AWS CLI の最新バージョンより数バージョン遅れることがあります。最新バージョンをインストールするには、「AWS コマンドラインインターフェイスユーザーガイド」の「インストール」および「aws configure を使用したクイック設定」を参照してください。AWS CloudShell にインストールされている AWS CLI バージョンも最新バージョンより数バージョン遅れることがあります。更新するには、「AWS CloudShell ユーザーガイド」の「ホームディレクトリへの AWS CLI のインストール」を参照してください。 -
Amazon EKS クラスターへの
create
およびdescribe
のアクセス許可を持つ IAM プリンシパル (ユーザーまたはロール)。詳細については、Outpost にローカル Kubernetes クラスターを作成しますおよびすべてのクラスターの一覧表示または説明を参照してください。
ローカルの Amazon EKS クラスターが作成される時点で、クラスターを作成する IAM プリンシパルが恒久的に追加されています。とりわけ、プリンシパルは管理者として、Kubernetes RBAC 承認テーブルに追加されます。このエンティティには system:masters
アクセス許可が付与されています。このエンティティの ID は、クラスター設定には表示されません。したがって、クラスターを作成したエンティティをメモし、削除しないようにすることが重要です。初期状態では、サーバーを作成したプリンシパルのみが、kubectl
を使用して Kubernetes API サーバーへのコールを実行することができます。コンソールを使用してクラスターを作成する場合は、クラスター上で kubectl
コマンドを実行する際、同じ IAM 認証情報が AWS SDK 認証情報チェーンにあることを確認する必要があります。クラスターの作成が完了したら、他の IAM プリンシパルにクラスターへのアクセスを付与できます。