**このページの改善にご協力ください** このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。 # AWS Outposts を使用して Amazon EKS をオンプレミスにデプロイする Amazon EKS を使用して、オンプレミス Kubernetes アプリケーションを AWS Outposts で実行できます。次の方法で Amazon EKS を Outposts にデプロイできます。 + **拡張クラスター** - Outpost の AWS リージョンとノードで Kubernetes コントロールプレーンを実行します。 + **ローカルクラスター** - Outpost で Kubernetes コントロールプレーンとノードを実行します。 どちらのデプロイオプションでも、Kubernetes コントロールプレーンは、AWS によって完全に管理されています。クラウドで使用するのと同じ Amazon EKS API、ツール、コンソールを使用して Outposts で Amazon EKS を作成および実行することができます。 以下の図に、これらのデプロイのオプションを示します。 ![\[Outpost デプロイオプション\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/outposts-deployment-options.png) ## 各デプロイオプションを使用する時 ローカルクラスターと拡張クラスターはどちらも汎用のデプロイオプションであり、さまざまなアプリケーションに使用できます。 ローカルクラスターでは、Amazon EKS クラスター全てを Outposts でローカルに実行できます。この方法により、クラウドへの一時的なネットワーク切断によって生じる可能性のあるアプリケーションダウンタイムのリスクを軽減できます。このようなネットワーク接断は、ファイバーの切断や天候によって発生する可能性があります。すべての Amazon EKS クラスター全体が Outposts でローカルに実行されるため、アプリケーションは引き続き使用できます。クラウドへのネットワーク切断中にクラスターオペレーションを実行できます。詳細については、「[AWS Outposts でローカル Amazon EKS クラスターを準備して、ネットワークの切断に備える](eks-outposts-network-disconnects.md)」を参照してください。Outposts から親 AWS リージョンへのネットワーク接続の品質が気になる場合、およびネットワークの切断による高可用性を必要とする場合は、ローカルクラスターデプロイオプションを使用してください。 拡張クラスターでは、Kubernetes コントロールプレーンが親 AWS リージョンで動作するため、Outpost の容量を節約できます。このオプションは、Outpost から AWS リージョンへの信頼性が高く冗長なネットワーク接続に投資できる場合に適している可能性があります。このオプションでは、ネットワーク接続の品質が重要です。Kubernetes が Kubernetes コントロールプレーンとノード間のネットワーク切断を処理する方法によって、アプリケーションのダウンタイムが発生する可能性があります。Kubernetes の動作の詳細については、Kubernetes ドキュメントの「[Scheduling, Preemption, and Eviction](https://kubernetes.io/docs/concepts/scheduling-eviction/)」を参照してください。 ## デプロイオプションの比較 以下の表は、これら 2 つのオプションの違いを比較したものです。 | 機能 | 拡張クラスター | ローカルクラスター | | --- | --- | --- | | Kubernetes コントロールプレーンの場所 | AWS リージョン | Outpost | | Kubernetes コントロールプレーンのアカウント | AWS アカウント | お客様のアカウント | | リージョナルな可用性 | 「[サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/eks.html#eks_region)」を参照してください | 米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (東京)、アジアパシフィック (シドニー)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、中東 (バーレーン)、南米 (サンパウロ) | | Kubernetes マイナーバージョン | eks/latest/userguide/kubernetes-versions.html[Supported Amazon EKS versions,type="documentation"]。 | eks/latest/userguide/kubernetes-versions.html[Supported Amazon EKS versions,type="documentation"]。 | | プラットフォームのバージョン | 「[EKS platform-versions](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)」を参照 | 「[AWS Outposts の Kubernetes および Amazon EKS プラットフォームバージョンについて説明します。](eks-outposts-platform-versions.md)」を参照してください。 | | Outpost フォームファクター | Outpost ラック | Outpost ラック | | ユーザーインターフェイス | AWS マネジメントコンソール、AWS CLI、Amazon EKS API、`eksctl`、AWS CloudFormation、および Terraform | AWS マネジメントコンソール、AWS CLI、Amazon EKS API、`eksctl`、AWS CloudFormation、および Terraform | | マネージドポリシー | [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy) および [AWS 管理ポリシー: AmazonEKSServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy) | [AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) および [AWS マネージドポリシー: AmazonEKSLocalOutpostServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) | | クラスター VPC およびサブネット | 「[VPC とサブネットの Amazon EKS ネットワーキング要件を表示する](network-reqs.md)」を参照してください。 | 「[AWS Outposts で Amazon EKS クラスターの VPC とサブネットを作成する](eks-outposts-vpc-subnet-requirements.md)」を参照してください | | クラスターエンドポイントのアクセス | 公共または個人、あるいはその両方 | 非公開のみ | | Kubernetes API サーバー認証 | AWS Identity and Access Management (IAM) および OIDC | IAM および `x.509` 証明書 | | ノードタイプ | セルフマネージド型のみ | セルフマネージド型のみ | | ノードのコンピュートタイプ | Amazon EC2 オンデマンド | Amazon EC2 オンデマンド | | ノードストレージタイプ | Amazon EBS `gp2` とローカル NVMe SSD | Amazon EBS `gp2` とローカル NVMe SSD | | Amazon EKS 最適化 AMI | Amazon Linux、Windows、Bottlerocket | Amazon Linux のみ | | IP バージョン | `IPv4` のみ | `IPv4` のみ | | アドオン | Amazon EKS アドオンまたはセルフマネージドアドオン | セルフマネージド型アドオンのみ | | デフォルトの Container Network Interface | Amazon VPC CNI Kubernetes用プラグイン | Amazon VPC CNI Kubernetes用プラグイン | | Kubernetes コントロールプレーンのログ | Amazon CloudWatch Logs | Amazon CloudWatch Logs | | 負荷分散 | [AWS Load Balancer Controller](aws-load-balancer-controller.md) を使用して Application Load Balancer のみをプロビジョニングします (Network Load Balancer はプロビジョニングしない) | [AWS Load Balancer Controller](aws-load-balancer-controller.md) を使用して Application Load Balancer のみをプロビジョニングします (Network Load Balancer はプロビジョニングしない) | | シークレットエンベロープ暗号化 | 「[既存のクラスターで KMS を使用して Kubernetes シークレットを暗号化する](enable-kms.md)」を参照してください | サポートされていません | | サービスアカウントの IAM ロール | 「[サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md)」を参照してください | サポートされていません | | トラブルシューティング | 「[Amazon EKS クラスターとノードに関する問題をトラブルシューティングする](troubleshooting.md)」を参照してください | 「[AWS Outposts でローカル Amazon EKS クラスターをトラブルシューティングする](eks-outposts-troubleshooting.md)」を参照してください | **Topics** # 高可用性を実現するために AWS Outposts でローカル Amazon EKS クラスターを作成する ローカルクラスターを使用すると、Amazon EKS クラスターすべてを AWS Outposts でローカルに実行できます。これにより、クラウドへの一時的なネットワーク切断によって生じる可能性のあるアプリケーションダウンタイムのリスクを軽減できます。このような接断は、ファイバーの切断や天候によって発生する可能性があります。Kubernetes クラスター全体が Outposts でローカルに実行されるため、アプリケーションは引き続き使用できます。クラウドへのネットワーク切断中にクラスターオペレーションを実行できます。詳細については、「[AWS Outposts でローカル Amazon EKS クラスターを準備して、ネットワークの切断に備える](eks-outposts-network-disconnects.md)」を参照してください。次の図は、ローカルクラスターのデプロイを示しています。 ![\[Outpost のローカルクラスター\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/outposts-local-cluster.png) ローカルクラスターは一般的に Outposts ラックで使用できます。 ## サポート対象の AWS リージョン ローカルクラスターを作成できる AWS リージョンは、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、中東 (バーレーン)、南米 (サンパウロ) です。サポートされる機能の詳細については、「[デプロイオプションの比較](eks-outposts.md#outposts-overview-comparing-deployment-options)」を参照してください。 **Topics** # 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](managing-vpc-cni.md)、[kube-proxy](managing-kube-proxy.md)、[CoreDNS](managing-coredns.md) アドオンはローカルクラスターに自動的にインストールされます。 + ローカルクラスターでは、Outposts で Amazon EBS を使用する必要があります。お客様の Outpost では、Kubernetes コントロールプレーンストレージに使用できる Amazon EBS が必要です。Outposts は、Amazon EBS `gp2` ボリュームのみをサポートします。 + Amazon EBS のバックアップ対象である Kubernetes `PersistentVolumes` は、Amazon EBS CSI ドライバーを使用してサポートされています。 + ローカルクラスターのコントロールプレーンインスタンスは、[可用性の高いスタックされたトポロジ](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/)で設定されます。クォーラムを維持するには、3 つのコントロールプレーンインスタンスのうち 2 つが常に正常である必要があります。クォーラムが失われた場合、新しいマネージドインスタンスを有効にするにはいくつかのサービス側のアクションが必要になるため、AWS サポートにお問い合わせください。 **前提条件** + [Outposts デプロイオプション](eks-outposts.md#outposts-overview-comparing-deployment-options)、[キャパシティに関する考慮事項に基づく AWS Outposts での Amazon EKS クラスターのインスタンスタイプとプレイスメントグループの選択](eks-outposts-capacity-considerations.md)、および [VPC 要件と考慮事項](eks-outposts-vpc-subnet-requirements.md)に精通していること。 + 既存の アウトポスト。詳細については、「[AWS Outposts とは](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)」を参照してください。 + コンピュータまたは AWS CloudShell に、`kubectl` コマンドラインツールがインストールされていること。バージョンはご使用のクラスターの Kubernetes バージョンと同じか、1 つ前のマイナーバージョン以前、あるいはそれより新しいバージョンが使用できます。例えば、クラスターのバージョンが `1.29` である場合、`kubectl` のバージョン `1.28`、`1.29`、または `1.30` が使用できます。`kubectl` をインストールまたはアップグレードする方法については「[`kubectl` および `eksctl` のセットアップ](install-kubectl.md)」を参照してください。 + ご使用のデバイスまたは AWS クラウドシェル で、バージョン `2.12.3` 以降、または AWS コマンドラインインターフェイス (AWS CLI のバージョン `1.27.160` 以降がインストールおよび設定されていること。現在のバージョンを確認するには「`aws --version | cut -d / -f2 | cut -d ' ' -f1`」を参照してください。`yum`、`apt-get`、macOS 用の Homebrew などのパッケージマネージャーは、多くの場合 AWS CLI の最新バージョンより数バージョン古くなっています。最新バージョンをインストールするには「*AWS コマンドラインインターフェイスユーザーガイド*」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」および「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。AWS クラウドシェル にインストールされている AWS CLI バージョンも最新バージョンより数バージョン遅れることがあります。更新するには、「*AWS CloudShell ユーザーガイド*」の「[ホームディレクトリへの AWS CLI のインストール](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)」を参照してください。 + Amazon EKS クラスターへの `create` および `describe` のアクセス許可を持つ IAM プリンシパル (ユーザーまたはロール)。詳細については、「[Outpost にローカル Kubernetes クラスターを作成する](security-iam-id-based-policy-examples.md#policy-create-local-cluster)」および「[すべてのクラスターの一覧表示または説明](security-iam-id-based-policy-examples.md#policy-example2)」を参照してください。 ローカルの Amazon EKS クラスターが作成される時点で、クラスターを作成する [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)が恒久的に追加されています。とりわけ、プリンシパルは管理者として、Kubernetes RBAC 承認テーブルに追加されます。このエンティティには `system:masters` アクセス許可が付与されています。このエンティティの ID は、クラスター設定には表示されません。したがって、クラスターを作成したエンティティをメモし、削除しないようにすることが重要です。初期状態では、サーバーを作成したプリンシパルのみが、`kubectl` を使用して Kubernetes API サーバーへの呼び出しを実行できます。コンソールを使用してクラスターを作成する場合は、クラスター上で `kubectl` コマンドを実行する際、同じ IAM 認証情報が AWS SDK 認証情報チェーンにあることを確認する必要があります。クラスターの作成が完了したら、他の IAM プリンシパルにクラスターへのアクセスを付与できます。 ## Amazon EKS ローカルクラスターを作成します。 このページで説明されている以下のツールを使用して、ローカルクラスターを作成できます。 + [`eksctl`](#eksctl_create_cluster_outpost) + [AWS マネジメントコンソール](#console_create_cluster_outpost) [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/eks/create-cluster.html)、[Amazon EKS API](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html)、[AWS SDK](https://aws.amazon.com/developer/tools/)、[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-eks-cluster-outpostconfig.html) または [Terraform](https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest) を使用して Outposts にクラスターを作成することもできます。 ### `eksctl` **`eksctl` を使用してローカルクラスターを作成するには** 1. デバイスまたは AWS CloudShell に `eksctl` コマンドラインツールのバージョン `0.215.0` 以降をインストールします。`eksctl` をインストールまたはアップグレードするには`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。 1. 次のコンテンツをデバイスにコピーします。次の値を置き換えたら、変更したコマンドを実行して `outpost-control-plane.yaml` ファイルを作成します。 + *region-code* は、クラスターを作成する [サポートされている AWS リージョン](eks-outposts-local-cluster-overview.md#outposts-control-plane-supported-regions)に置き換えます。 + *my-cluster* の部分は、自分のクラスター名に置き換えます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前は、クラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。名前は、クラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。 + *vpc-ExampleID1* と *subnet-ExampleID1* を既存の VPC とサブネットの ID に置き換えます。VPC とサブネットは、[AWS Outposts で Amazon EKS クラスターの VPC とサブネットを作成する](eks-outposts-vpc-subnet-requirements.md)要件を満たす必要があります。 + *uniqueid* を Outpost の ID に置き換えます。 + *m5.large* を Outpost で使用可能なインスタンスタイプに置き換えます。インスタンスタイプを選択する前に、「[キャパシティに関する考慮事項に基づいて、AWS Outposts で Amazon EKS クラスターのインスタンスタイプとプレイスメントグループを選択する](eks-outposts-capacity-considerations.md)」を参照してください。3 つのコントロールプレーンインスタンスがデプロイされます。この番号を変更することはできません。 ``` cat >outpost-control-plane.yaml < **AWS マネジメントコンソール を使用してクラスターを作成するには** 1. Amazon EKS の要件を満たす既存の VPC とサブネットが必要です。詳細については、「[AWS Outposts で Amazon EKS クラスターの VPC とサブネットを作成する](eks-outposts-vpc-subnet-requirements.md)」を参照してください。 1. 既にローカルクラスター IAM ロールがある場合、または `eksctl` を使用してクラスターを作成する場合は、このステップはスキップできます。デフォルトでは`eksctl` により、ロールが自動的に作成されます。 1. IAM 信頼ポリシー用の JSON ファイルを作成するには次のコマンドを実行してください。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 1. Amazon EKS クラスターの IAM ロールを作成します。IAM ロールを作成するには、ロールを作成する [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)に `iam:CreateRole` アクション (許可) を割り当てる必要があります。 ``` aws iam create-role --role-name myAmazonEKSLocalClusterRole --assume-role-policy-document file://"eks-local-cluster-role-trust-policy.json" ``` 1. [AmazonEKSLocalOutpostClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html) という名前の Amazon EKS マネージド型ポリシーをロールにアタッチします。IAM ポリシーを [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)にアタッチするにはポリシーのアタッチを行っているプリンシパルに、次のいずれかの IAM アクション (許可) を割り当てる必要があります: `iam:AttachUserPolicy` または `iam:AttachRolePolicy`。 ``` aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSLocalOutpostClusterPolicy --role-name myAmazonEKSLocalClusterRole ``` 1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。 1. コンソール画面の上部で、[サポートされている AWS リージョン](eks-outposts-local-cluster-overview.md#outposts-control-plane-supported-regions) を選択したことを確認します。 1. **[クラスターを追加]**、**[作成]** の順にクリックします。 1. **[クラスターの設定]** ページで、次のフィールドの値を入力または選択します。 + **[Kubernetes コントロールプレーンの場所]** – AWS Outposts を選択します。 + **[Outpost ID]** - コントロールプレーンを作成する Outpost の ID を選択します。 + **[インスタンスタイプ]** - インスタンスタイプを選択します。Outpost で使用可能なインスタンスタイプのみが表示されます。ドロップダウンリストでは、各インスタンスタイプにそのインスタンスタイプに推奨されるノード数が示されています。インスタンスタイプを選択する前に、「[キャパシティに関する考慮事項に基づいて、AWS Outposts で Amazon EKS クラスターのインスタンスタイプとプレイスメントグループを選択する](eks-outposts-capacity-considerations.md)」を参照してください。すべてのレプリカは、同じインスタンスタイプを使用してデプロイされます。クラスターの作成後にインスタンスタイプを変更することはできません。3 つのコントロールプレーンインスタンスがデプロイされます。この番号を変更することはできません。 + **[名前]** - クラスターの名前。AWS アカウント内で一意にする必要があります。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前は、クラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。名前は、クラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。 + **[Kubernetes バージョン]** – クラスターで使用する Kubernetes バージョンを選択します。以前のバージョンを使用する必要がない限り、最新バージョンを選択することをお勧めします。 + **[クラスターサービスロール]** - AWS リソースを管理することを Kubernetes コントロールプレーンに許可するために、前のステップで作成した Amazon EKS クラスター IAM ロールを選択します。 + **[Kubernetes クラスター管理者アクセス]** — クラスターを作成する IAM プリンシパル (ロールまたはユーザー) にクラスター上の Kubernetes オブジェクトへの管理者アクセス権を付与する場合は、デフォルト (許可) をそのまま使用します。Amazon EKS は IAM プリンシパルのアクセスエントリを作成し、クラスター管理者にそのアクセスエントリに対するアクセス許可を付与します。アクセスエントリの詳細については「[EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する](access-entries.md)」を参照してください。 クラスターを作成するプリンシパルとは異なる IAM プリンシパルに Kubernetes クラスターオブジェクトへの管理者アクセス権を付与したい場合は、拒否のオプションを選択します。クラスターの作成後、アクセスエントリを作成する IAM アクセス許可を持つすべての IAM プリンシパルは、Kubernetes クラスターオブジェクトへのアクセスを必要とする任意の IAM プリンシパルのアクセスエントリを追加できます。必要な IAM アクセス許可の詳細については、サービス認可リファレンスの「[Amazon Elastic Kubernetes Service で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)」を参照してください。拒否のオプションを選択し、アクセスエントリを作成しない場合、IAM プリンシパルはクラスター上の Kubernetes オブジェクトにアクセスできなくなります。 + **[タグ]** - (オプション) クラスターにタグを追加します。詳細については、「[タグを使用して Amazon EKS リソースを整理する](eks-using-tags.md)」を参照してください。このページを読み終えたら、**[次へ]** を選択してください。 1. **[ネットワーキングの指定]** ページで、次のフィールドの値を選択してください： + **[VPC]** - 既存の VPC を選択します。VPC には、作成するクラスター、ノード、およびその他の Kubernetes リソースで利用できる十分な数の IP アドレスが必要です。VPC は、「[VPC の要件と考慮事項](eks-outposts-vpc-subnet-requirements.md#outposts-vpc-requirements)」に記載されている要件を満たしている必要があります。 + **[サブネット]** - デフォルトで、前のフィールドで指定した VPC 内の利用可能なすべてのサブネットがあらかじめ選択されています。選択するサブネットは、「[サブネットの要件と考慮事項](eks-outposts-vpc-subnet-requirements.md#outposts-subnet-requirements)」に記載されている要件を満たしている必要があります。 + **[セキュリティグループ]** - (オプション) Amazon EKS が作成するネットワークインターフェイスに関連付ける 1 つまたは複数のセキュリティグループを指定します。Amazon EKS は、クラスターと VPC 間の通信を可能にするセキュリティグループを自動的に作成します。Amazon EKS はこのセキュリティグループおよびユーザーが選択したセキュリティグループを、作成するネットワークインターフェイスに関連付けます。Amazon EKS が作成するクラスターセキュリティグループの詳細については「[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)」を参照してください。Amazon EKS が作成するクラスターセキュリティグループのルールを変更できます。独自のセキュリティグループを追加することを選択した場合、クラスターの作成後に選択したセキュリティグループを変更することはできません。オンプレミスホストがクラスターエンドポイントと通信するためには、クラスターセキュリティグループからのインバウンドトラフィックを許可する必要があります。入出力のインターネット接続がないクラスター (プライベートクラスターとも呼ばれる) の場合は、次のいずれかを行う必要があります。 + 必要となる VPC エンドポイントに関連付けられたセキュリティグループを追加します。必要となるエンドポイントの詳細については、「[AWS サービスへのサブネットアクセス](eks-outposts-vpc-subnet-requirements.md#subnet-access-to-services)」の「[インターフェイス VPC エンドポイントの使用](eks-outposts-vpc-subnet-requirements.md#vpc-subnet-requirements-vpc-endpoints)」を参照してください。 + VPC エンドポイントに関連付けられたセキュリティグループからのトラフィックを許可するように、Amazon EKS が作成したセキュリティグループを変更します。このページを読み終えたら、**[次へ]** を選択してください。 1. **[オブザーバビリティの設定]** ページでは、有効にする **[メトリクス]** と **[コントロールプレーンのロギング]** オプションをオプションで選択できます。デフォルトでは、それぞれのログタイプは無効化されています。 + Prometheus メトリクスの詳細については、「[ステップ 1: Prometheus メトリクスを有効にする](prometheus.md#turn-on-prometheus-metrics)」を参照してください。 + 「**コントロールプレーン**」に関する詳細に関しては、「[コントロールプレーンログを CloudWatch Logs に送信する](control-plane-logs.md)」を参照してください。このページを読み終えたら、**[次へ]** を選択してください。 1. **[確認と作成]** ページで、前のページで入力または選択した情報を確認します。変更する必要がある場合は**[編集]** を選択してください。そのままでよければ、**[作成]** を選択してください。クラスターがプロビジョニングされている間、**[ステータス]** フィールドに **[作成中]** と表示されます。 クラスターのプロビジョニングには数分かかります。 ## Amazon EKS ローカルクラスターを表示する 1. クラスターを作成すると、作成された 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 ドキュメントの「[Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)」を参照してください。Amazon EKS はローカルクラスターの状態を継続的に監視します。セキュリティパッチや問題のあるインスタンスの修復などの自動管理アクションを実行します。ローカルクラスターがクラウドから切断されると、再接続時にクラスターが正常な状態に修復されるようアクションが実行されます。 1. `eksctl` を使用してクラスターを作成した場合、このステップはスキップできます。`eksctl` がこのステップを完了します。新しいコンテキストを `kubectl` `config` ファイルに追加して、`kubectl` がクラスターと通信できるようにします。ファイルを作成し更新する手順については、「[kubeconfig ファイルを作成して kubectl を EKS クラスターに接続する](create-kubeconfig.md)」を参照しください。 ``` 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 ``` 1. ローカルクラスターの Kubernetes API サーバーに接続するには、サブネットのローカルゲートウェイにアクセスするか、VPC 内から接続します。Outpost ラックをオンプレミスネットワークに接続する方法の詳細については、「AWS Outposts ユーザーガイド」の「[How local gateways for racks work](https://docs.aws.amazon.com/outposts/latest/userguide/how-racks-work.html)」(ラックのローカルゲートウェイの仕組み) を参照してください。ダイレクト 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 ドキュメント](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html#dns)」を参照してください。次のコマンドを実行して、クラスターとの通信が確立されていることを確認します。 ``` kubectl get svc ``` 出力例は次のとおりです。 ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.100.0.1 443/TCP 28h ``` 1. (オプション) AWS Cloud から切断された状態のときにローカルクラスターへの認証をテストします。手順については、「[AWS Outposts でローカル Amazon EKS クラスターを準備して、ネットワークの切断に備える](eks-outposts-network-disconnects.md)」を参照してください。 ### 内部リソース Amazon EKS はクラスターで次のリソースを作成します。リソースは、Amazon EKS 内部で使用するためのものです。クラスターが適切に機能しなくなるため、これらのリソースは編集または変更しないでください。 + 次の[ミラーポッド](https://kubernetes.io/docs/reference/glossary/?all=true#term-mirror-pod): + `aws-iam-authenticator-node-hostname ` + `eks-certificates-controller-node-hostname ` + `etcd-node-hostname ` + `kube-apiserver-node-hostname ` + `kube-controller-manager-node-hostname ` + `kube-scheduler-node-hostname ` + 次のセルフマネージド型アドオン: + `kube-system/coredns` + `kube-system/` `kube-proxy` (最初のノードを追加するまで作成されません) + `kube-system/aws-node` (最初のノードを追加するまで作成されません)。ローカルクラスターは、クラスターネットワークに Amazon VPC CNI plugin for Kubernetes プラグインを使用します。コントロールプレーンインスタンス (名前が `aws-node-controlplane-*` のポッド) の設定を変更しないでください。プラグインが新しいネットワークインターフェイスを作成したときに、デフォルト値を変更できる設定変数があります。詳細については、GitHub の[ドキュメント](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md)を参照してください。 + 次のサービス: + `default/kubernetes` + `kube-system/kube-dns` + `eks.system` という名前の `PodSecurityPolicy` + `eks:system:podsecuritypolicy` という名前の `ClusterRole` + `eks:system` という名前の `ClusterRoleBinding` + [クラスターセキュリティグループ](sec-group-reqs.md)に加えて、Amazon EKS は `eks-local-internal-do-not-use-or-edit-cluster-name-uniqueid ` という名前の AWS アカウントにセキュリティグループを作成します。このセキュリティグループにより、コントロールプレーンインスタンスで実行されている Kubernetes コンポーネント間のトラフィックが自由に流れるようになります。 推奨される次の手順は以下の通りです。 + [クラスターを作成した IAM プリンシパルに、AWS マネジメントコンソール 内の Kubernetes リソースを表示するために必要な許可を付与する](view-kubernetes-resources.md#view-kubernetes-resources-permissions) + [IAM エンティティにクラスターへのアクセスを許可する](grant-k8s-access.md)。エンティティに Amazon EKS コンソールで Kubernetes リソースを表示させる場合は、[必要なアクセス許可](view-kubernetes-resources.md#view-kubernetes-resources-permissions)をエンティティに付与します。 + [クラスターのログ記録を設定する](control-plane-logs.md) + [ネットワークの切断](eks-outposts-network-disconnects.md)中に何が起こるかをよく理解してください。 + [クラスターにノードを追加する](eks-outposts-self-managed-nodes.md) + `etcd` のバックアップ計画を設定することを検討してください。Amazon EKS は、ローカルクラスターの `etcd` の自動バックアップと復元をサポートしていません。詳細については、Kubernetes ドキュメントの「[etcd クラスターのバックアップ](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)」を参照してください。2 つの主なオプションは、`etcdctl` を使用してスナップショットの作成を自動化する、または Amazon EBS ストレージボリュームのバックアップを使用することです。 # AWS Outposts の Kubernetes および Amazon EKS プラットフォームバージョンについて説明します。 ローカルクラスターのプラットフォームバージョンはAWS Outposts 上の Amazon EKS クラスターの機能を表します。バージョンには Kubernetes コントロールプレーン上で実行されるコンポーネントが含まれており、Kubernetes API サーバーフラグが有効になっています。また、現在の Kubernetes パッチバージョンも含まれています。各 Kubernetes マイナーバージョンには、 プラットフォームバージョンが 1 つ以上関連付けられています。別の Kubernetes マイナーバージョンのプラットフォームバージョンは独立しています。クラウド内のローカルクラスターと Amazon EKS クラスターのプラットフォームバージョンは独立しています。 `1.31` など、新しい Kubernetes マイナーバージョンがローカルクラスターで使用可能になると、その Kubernetes マイナーバージョンの最初のプラットフォームバージョンは `eks-local-outposts.1` から始まります。また、Amazon EKS では、新しいプラットフォームバージョンを定期的にリリースすることで、新しい Kubernetes コントロールプレーン設定を有効化し、セキュリティ修正プログラムを提供します。 マイナーバージョンで新しいローカルクラスタープラットフォームのバージョンが使用可能になった場合: + プラットフォームのバージョン番号がインクリメントされます (`eks-local-outposts.n+1`)。 + Amazon EKS は既存のすべての既存のローカルクラスターを、対応する Kubernetes マイナーバージョン用の最新のプラットフォームバージョンに自動的に更新します。既存のプラットフォームバージョンの自動更新は段階的にロールアウトされます。ロールアウトプロセスは、3 つのインスタンスすべてが新しいインスタンスに置き換えられるまで、Outpost で実行されているマネージド型 Kubernetes コントロールプレーンインスタンスを一度に 1 つずつ置き換えます。 + Kubernetes コントロールプレーンインスタンスの置換プロセスは、サービスの中断のリスクがある場合、進行を停止します。Amazon EKS は、他の 2 つの Kubernetes コントロールプレーンインスタンスが正常で、クラスターノードとしての準備状況条件にすべて合格した場合にのみ、インスタンスの置き換えを試みます。 + プラットフォームバージョンのロールアウトが完了するまでに通常 30 分もかかりません。クラスターが長時間 `UPDATING` 状態のままである場合は、「[AWS Outposts でローカル Amazon EKS クラスターをトラブルシューティングする](eks-outposts-troubleshooting.md)」を参照し、AWS サポートに問い合わせてください。AWS サポートからの指示がない限り、Kubernetes コントロールプレーンインスタンスを手動で終了しないでください。 + Amazon EKS は対応するパッチバージョンを適用して新しいノード AMI を発行する可能性があります。すべてのパッチバージョンは単一の Kubernetes マイナーバージョンに対して、Kubernetes コントロールプレーンとノード AMI との間で互換性があります。 新しいプラットフォームバージョンでは重大な変更が発生したり、サービスが中断されたりすることはありません。 ローカルクラスターは常に、指定された Kubernetes バージョン用に入手可能な最新のプラットフォームバージョン (`eks-local-outposts.n`) で作成されます。 現在および最新の プラットフォームバージョンを以下の表に示します。 この特定のドキュメントページへのすべてのソースファイルの変更通知を受け取るには、RSS リーダーを使用して次の URL をサブスクライブできます。 ``` https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/outposts/eks-outposts-platform-versions.adoc.atom ``` ## Kubernetes バージョン `1.31` 以下のアドミッションコントローラーは、すべての `1.31` プラットフォームバージョンで有効です: `CertificateApproval`、`CertificateSigning`、`CertificateSubjectRestriction`、`ClusterTrustBundleAttest`、`DefaultIngressClass`、`DefaultStorageClass`、`DefaultTolerationSeconds`、`ExtendedResourceToleration`、`LimitRanger`、`MutatingAdmissionWebhook`、`NamespaceLifecycle`、`NodeRestriction`、`PersistentVolumeClaimResize`、`PodSecurity`、`Priority`、`ResourceQuota`、`RuntimeClass`、`ServiceAccount`、`StorageObjectInUseProtection`、`TaintNodesByCondition`、`ValidatingAdmissionPolicy`、`ValidatingAdmissionWebhook` | Kubernetes バージョン | Amazon EKS プラットフォームバージョン | リリースノート | リリース日 | | --- | --- | --- | --- | | `1.31.14` | `eks-local-outposts.8` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。kube-proxy は `v1.31.14` に更新されました。AWSIAM オーセンティケーター が `v0.7.8` に更新されました。Kubernetes 向け Amazon VPC CNI プラグインは `v1.20.4` に更新されました。Bottlerocket のバージョンを `v1.52.0` に更新しました。 | 2025 年 12 月 23 日 | | `1.31.12` | `eks-local-outposts.5` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。kube-proxy は `v1.31.10` に更新されました。AWSIAM オーセンティケーター が `v0.7.4` に更新されました。Kubernetes 向け Amazon VPC CNI プラグインは `v1.20.2` に更新されました。Bottlerocket のバージョンを `v1.47.0` に更新しました。 | 2025 年 10 月 3 日 | | `1.31.9` | `eks-local-outposts.4` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。kube-proxy は `v1.31.9` に更新されました。AWSIAM オーセンティケーター が `v0.7.2` に更新されました。Amazon VPC CNI plugin for Kubernetes が `v1.20.0` に更新されました。Bottlerocket バージョンが `v1.43.0` に更新されました。 | 2025 年 8 月 9 日 | | `1.31.7` | `eks-local-outposts.3` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。kube-proxy は `v1.31.9` に更新されました。AWSIAM オーセンティケーター が `v0.7.1` に更新されました。Kubernetes 向け Amazon VPC CNI プラグインは `v1.19.5` に更新されました。Bottlerocket のバージョンを `v1.40.0` に更新しました。 | 2025 年 6 月 19 日 | | `1.31.6` | `eks-local-outposts.2` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。Bottlerocket のバージョンを `v1.36.0` に更新しました。 | 2025 年 4 月 24 日 | | `1.31.6` | `eks-local-outposts.1` | アウトポスト のローカル Amazon EKS クラスター用 Kubernetes バージョン `v1.31` の初回リリース。 | 2025 年 4 月 9 日 | ## Kubernetes バージョン `1.30` 以下のアドミッションコントローラーは、すべての `1.30` プラットフォームバージョンで有効です: `CertificateApproval`、`CertificateSigning`、`CertificateSubjectRestriction`、`ClusterTrustBundleAttest`、`DefaultIngressClass`、`DefaultStorageClass`、`DefaultTolerationSeconds`、`ExtendedResourceToleration`、`LimitRanger`、`MutatingAdmissionWebhook`、`NamespaceLifecycle`、`NodeRestriction`、`PersistentVolumeClaimResize`、`PodSecurity`、`Priority`、`ResourceQuota`、`RuntimeClass`、`ServiceAccount`、`StorageObjectInUseProtection`、`TaintNodesByCondition`、`ValidatingAdmissionPolicy`、`ValidatingAdmissionWebhook` | Kubernetes バージョン | Amazon EKS プラットフォームバージョン | リリースノート | リリース日 | | --- | --- | --- | --- | | `1.30.14` | `eks-local-outposts.10` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。AWSIAM オーセンティケーター が `v0.7.8` に更新されました。Kubernetes 向け Amazon VPC CNI プラグインは `v1.20.4` に更新されました。Bottlerocket のバージョンを `v1.52.0` に更新しました。 | 2025 年 12 月 23 日 | | `1.30.14` | `eks-local-outposts.7` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。kube-proxy は `v1.30.14` に更新されました。AWSIAM オーセンティケーター が `v0.7.4` に更新されました。Kubernetes 向け Amazon VPC CNI プラグインは `v1.20.2` に更新されました。Bottlerocket のバージョンを `v1.47.0` に更新しました。 | 2025 年 10 月 3 日 | | `1.30.13` | `eks-local-outposts.6` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。kube-proxy は `v1.30.13` に更新されました。AWSIAM オーセンティケーター が `v0.7.2` に更新されました。Kubernetes 向け Amazon VPC CNI プラグインは `v1.20.0` に更新されました。Bottlerocket のバージョンを `v1.43.0` に更新しました。 | 2025 年 8 月 9 日 | | `1.30.11` | `eks-local-outposts.5` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。kube-proxy は `v1.30.11` に更新されました。AWSIAM オーセンティケーター が `v0.7.1` に更新されました。Amazon VPC CNI plugin for Kubernetes が `v1.19.5` に更新されました。Bottlerocket バージョンが `v1.40.0` に更新されました。 | 2025 年 6 月 19 日 | | `1.30.10` | `eks-local-outposts.4` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。Bottlerocket のバージョンを `v1.36.0` に更新しました。 | 2025 年 4 月 24 日 | | `1.30.10` | `eks-local-outposts.3` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。kube-proxy は `v1.30.10` に更新されました。AWSIAM オーセンティケーター が `v0.6.29` に更新されました。Kubernetes 向け Amazon VPC CNI プラグインは `v1.19.2` に更新されました。CoreDNS が `v1.11.4` に更新されました。AWSクラウドコントローラーマネージャーが `v1.30.8` に更新されました。Bottlerocket のバージョンを `v1.34.0` に更新しました。 | 2025 年 3 月 27 日 | | `1.30.7` | `eks-local-outposts.2` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。kube-proxy は `v1.30.7` に更新されました。AWSIAM オーセンティケーター が `v0.6.28` に更新されました。Kubernetes 向け Amazon VPC CNI プラグインは `v1.19.0` に更新されました。Bottlerocket のバージョンを `v1.29.0` に更新しました。 | 2025 年 1 月 10 日 | | `1.30.5` | `eks-local-outposts.1` | アウトポスト のローカル Amazon EKS クラスター用 Kubernetes バージョン `v1.30` の初回リリース。 | 2024 年 11 月 13 日 | ## Kubernetes バージョン `1.29` 以下のアドミッションコントローラーは、すべての `1.29` プラットフォームバージョンで有効です: `CertificateApproval`、`CertificateSigning`、`CertificateSubjectRestriction`、`ClusterTrustBundleAttest`、`DefaultIngressClass`、`DefaultStorageClass`、`DefaultTolerationSeconds`、`ExtendedResourceToleration`、`LimitRanger`、`MutatingAdmissionWebhook`、`NamespaceLifecycle`、`NodeRestriction`、`PersistentVolumeClaimResize`、`PodSecurity`、`Priority`、`ResourceQuota`、`RuntimeClass`、`ServiceAccount`、`StorageObjectInUseProtection`、`TaintNodesByCondition`、`ValidatingAdmissionPolicy`、`ValidatingAdmissionWebhook` | Kubernetes バージョン | Amazon EKS プラットフォームバージョン | リリースノート | リリース日 | | --- | --- | --- | --- | | `1.29.15` | `eks-local-outposts.13` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。AWSIAM オーセンティケーター が `v0.7.8` に更新されました。Kubernetes 向け Amazon VPC CNI プラグインは `v1.20.4` に更新されました。Bottlerocket のバージョンを `v1.52.0` に更新しました。 | 2025 年 12 月 23 日 | | `v1.29.15` | `eks-local-outposts.10` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。AWSIAM オーセンティケーター が `v0.7.4` に更新されました。Kubernetes 向け Amazon VPC CNI プラグインは `v1.20.2` に更新されました。Bottlerocket のバージョンを `v1.47.0` に更新しました。 | 2025 年 10 月 3 日 | | `v1.29.15` | `eks-local-outposts.9` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。AWSIAM オーセンティケーター が `v0.7.2` に更新されました。Kubernetes 向け Amazon VPC CNI プラグインは `v1.20.0` に更新されました。Bottlerocket のバージョンを `v1.43.0` に更新しました。 | 2025 年 8 月 9 日 | | `v1.29.15` | `eks-local-outposts.8` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。kube-proxy は `v1.29.15` に更新されました。AWSIAM オーセンティケーター が `v0.7.1` に更新されました。Kubernetes 向け Amazon VPC CNI プラグインは `v1.19.5` に更新されました。Bottlerocket のバージョンを `v1.40.0` に更新しました。 | 2025 年 6 月 19 日 | | `v1.29.14` | `eks-local-outposts.7` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。Bottlerocket のバージョンを `v1.36.0` に更新しました。 | 2025 年 3 月 24 日 | | `v1.29.14` | `eks-local-outposts.6` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。kube-proxy は `v1.29.14` に更新されました。Kubernetes 向け Amazon VPC CNI プラグインは `v1.19.2` に更新されました。CoreDNS が `v1.11.4` に更新されました。AWSクラウドコントローラーマネージャーが `v1.29.8` に更新されました。Bottlerocket のバージョンを `v1.34.0` に更新しました。 | 2025 年 3 月 27 日 | | `v1.29.11` | `eks-local-outposts.5` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。kube-proxy は `v1.29.11` に更新されました。Kubernetes 向け Amazon VPC CNI プラグインは `v1.19.0` に更新されました。CoreDNS イメージを `v1.11.3` に更新しました。Bottlerocket のバージョンを `v1.29.0` に更新しました。 | 2025年1月10日 | | `1.29.9` | `eks-local-outposts.4` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。kube-proxy は `v1.29.9` に更新されました。AWSIAM オーセンティケーター が `v0.6.26` に更新されました。Bottlerocket のバージョンを `v1.26.0` に更新しました。 | 2024 年 11 月 8 日 | | `1.29.6` | `eks-local-outposts.3` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。Bottlerocket のバージョンを `v1.22.0` に更新しました。 | 2024 年 10 月 22 日 | | `1.29.6` | `eks-local-outposts.2` | セキュリティの修正および機能強化が行われた新しいプラットフォームバージョン。Bottlerocket のバージョンを `v1.21.0` に更新しました。 | 2024 年 8 月 27 日 | | `1.29.6` | `eks-local-outposts.1` | アウトポスト のローカル Amazon EKS クラスター用 Kubernetes バージョン `v1.29` の初回リリース。 | 2024 年 8 月 20 日 | # AWS Outposts で Amazon EKS クラスターの VPC とサブネットを作成する ローカルクラスターを作成する際には、VPC と、Outposts で実行されるプライベートサブネットを少なくとも 1 つ指定します。このトピックでは、ローカルクラスターの VPC およびサブネットの要件と考慮事項について概要を説明します。 ## VPC の要件と考慮事項 ローカルクラスターを作成する際には、指定する VPC が次の要件と考慮事項を満たす必要があります。 + VPC には、作成するローカルクラスター、任意のノード、およびその他の Kubernetes リソースで利用できるだけの十分な数の IP アドレスが必要です。使用する VPC に十分な IP アドレスがない場合は、使用可能な IP アドレスの数を増やしてください。この操作を行うには、VPC への[追加の Classless Inter-Domain Routing (CIDR) ブロックの関連付け](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr)が必要になります。クラスターの作成前または作成後に、プライベート (RFC 1918) とパブリック (非 RFC 1918) の CIDR ブロックを VPC に関連付けることができます。クラスターで VPC に関連付けた CIDR ブロックが認識されるまでに、最大 5 時間かかることがあります。 + VPC に IP プレフィックスを割り当てたり、IPv6 CIDR ブロックを持たせることはできません。これらの制約があるため、 [プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md) および [クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md) でカバーされた情報は VPC には適用されません。 + VPC では DNS ホスト名と DNS 解決が有効になっています。これらの機能がないと、ローカルクラスターの作成は失敗し、機能を有効にしてクラスターを再作成する必要があります。詳細については、「Amazon VPC ユーザーガイド」の「[DNS attributes for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html)」(VPC の DNS 属性) を参照してください。 + ローカルネットワーク経由でローカルクラスターにアクセスするには、VPC が Outpost のローカルゲートウェイルートテーブルに関連付けられている必要があります。詳細については、「AWS Outposts ユーザーガイド」の「[VPC アソシエーション](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html#vpc-associations)」を参照してください。 ## サブネットの要件と考慮事項 クラスターを作成する際には、少なくとも 1 つのプライベートサブネットを指定します。複数のサブネットを指定すると、Kubernetes コントロールプレーンインスタンスはサブネット全体に均等に分散されます。1 つ以上のサブネットを指定する場合、サブネットは同じ Outpost 上に存在する必要があります。また、相互に通信するために、サブネットには適切なルートとセキュリティグループ権限も必要です。ローカルクラスターの作成時に、指定するサブネットは次の要件を満たす必要があります。 + サブネットはすべて、同じロジカル Outpost 上に存在すること。 + サブネットには、Kubernetes コントロールプレーンインスタンスに対して、合計で 3 つ以上の使用可能な IP アドレスを用意してください。3 つのサブネットを指定する場合、各サブネットには少なくても 1 つ以上の使用可能な IP アドレスが必要です。2 つのサブネットを指定する場合、各サブネットには少なくても 2 つ以上の利用可能な IP アドレスが必要です。1 つのサブネットを指定する場合、サブネットには少なくても 3 つ以上の利用可能な IP アドレスが必要です。 + ローカルネットワーク経由で Kubernetes API サーバーにアクセスするため、サブネットには Outpost ラックの[ローカルゲートウェイ](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html)へのルートがあります。サブネットに Outpost ラックのローカルゲートウェイへのルートがない場合は、VPC 内から Kubernetes API サーバーと通信する必要があります。 + サブネットでは IP アドレスベースの命名を使用する必要があります。Amazon EC2 の[リソースベースの命名](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html#instance-naming-rbn)は、Amazon EKS でサポートされていません。 ## AWS サービスへのサブネットアクセス Outposts 上のローカルクラスターのプライベートサブネットは、リージョンレベルの AWS サービスと通信できる必要があります。アウトバウンドインターネットアクセスに [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)を使用するか、VPC 内ですべてのトラフィックをプライベートに保ちたい場合は、[インターフェイス VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)を使用することによって、これを実現できます。 ### NAT ゲートウェイの使用 Outposts 上のローカルクラスターのプライベートサブネットには、Outposts の親アベイラビリティーゾーンにあるパブリックサブネット内の NAT ゲートウェイへのルートを持つ、関連付けられたルートテーブルが必要です。パブリックサブネットには、[インターネットゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html)へのルートが必要です。NAT ゲートウェイはアウトバウンドのインターネットアクセスを可能にし、インターネットから Outpost のインスタンスへの未承諾なインバウンド接続を防ぎます。 ### インターフェイス VPC エンドポイントの使用 Outposts のローカルクラスターのプライベートサブネットにアウトバウンドインターネット接続がない場合、または VPC 内ですべてのトラフィックをプライベートに保ちたい場合は、クラスターを作成する前に、リージョンレベルのサブネットで次のインターフェイス VPC エンドポイントと[ゲートウェイエンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html)を作成する必要があります。 | エンドポイント | エンドポイントタイプ | | --- | --- | | `com.amazonaws.region-code.ssm` | インターフェイス | | `com.amazonaws.region-code.ssmmessages` | インターフェイス | | `com.amazonaws.region-code.ec2messages` | インターフェイス | | `com.amazonaws.region-code.ec2` | インターフェイス | | `com.amazonaws.region-code.secretsmanager` | インターフェイス | | `com.amazonaws.region-code.logs` | インターフェイス | | `com.amazonaws.region-code.sts` | インターフェイス | | `com.amazonaws.region-code.ecr.api` | インターフェイス | | `com.amazonaws.region-code.ecr.dkr` | インターフェイス | | `com.amazonaws.region-code.s3` | ゲートウェイ | エンドポイントは次の要件を満たしている必要があります。 + Outpost の親アベイラビリティーゾーンにあるプライベートサブネットに作成されている + プライベートDNS 名が有効になっている + プライベート Outpost サブネットの CIDR 範囲からのインバウンド HTTPS トラフィックを許可するセキュリティグループがアタッチされている エンドポイントを作成すると料金が発生します。詳細については「[AWS プライベートリンク の料金](https://aws.amazon.com/privatelink/pricing/)」を参照してください。Pod が他の AWS サービスにアクセスする必要がある場合は、追加のエンドポイントを作成する必要があります。エンドポイントの包括的なリストについては、「[AWS PrivateLink と統合する AWS のサービス](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html)」を参照してください。 ## 「VPC を作成する」 以下の AWS CloudFormation テンプレートのいずれかを使用して、前の要件を満たす VPC を作成できます。 + **[テンプレート 1](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-09-20/amazon-eks-local-outposts-vpc-subnet.yaml)** — このテンプレートは、Outpost に 1 つのプライベートサブネット、また AWS リージョンに 1 つのパブリックサブネットを持つ VPC を作成します。プライベートサブネットには、AWS リージョンのパブリックサブネットにある NAT Gateway 経由でのインターネットへのルートがあります。このテンプレートを使用して、出力インターネットアクセスを持つサブネットにローカルクラスターを作成できます。 + **[テンプレート 2](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-03-20/amazon-eks-local-outposts-fully-private-vpc-subnet.yaml)** — このテンプレートは、Outpost に 1 つのプライベートサブネットと、入力または出力のインターネットアクセスがないサブネット (プライベートサブネットとも呼ばれる) にローカルクラスターを作成するために必要な最小限の VPC エンドポイントセットを含む VPC を作成します。 # AWS Outposts でローカル Amazon EKS クラスターを準備して、ネットワークの切断に備える ローカルネットワークが AWS Cloud との接続を失った場合でも、Outpost にあるローカル Amazon EKS クラスターは引き続き使用できます。このトピックでは、ネットワークの切断とそれに関連する考慮事項に備えて、ローカルクラスターを準備する方法について説明します。 + ローカルクラスターにより、計画外の一時的なネットワーク切断中も安定してオペレーションを継続できます。AWSOutposts は、データセンター内の AWS Cloud の拡張機能として機能する完全に接続された製品であることに変わりはありません。Outpost と AWS Cloud 間のネットワークが切断された場合には、接続の復元を試みることをお勧めします。手順については、「AWS Outpostsユーザーガイド」の「[AWS Outposts ラックネットワークのトラブルシューティングチェックリスト](https://docs.aws.amazon.com/outposts/latest/userguide/network-troubleshoot.html)」を参照してください。ローカルクラスター上の問題をトラブルシューティングする方法については、「[AWS Outposts でローカル Amazon EKS クラスターをトラブルシューティングする](eks-outposts-troubleshooting.md)」を参照してください。 + Outposts は、Outpost の接続状態を監視するために使用できる `ConnectedStatus` 指標を出力します。詳細については、「AWS Outposts ユーザーガイド」の「[Outposts メトリクス](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-cloudwatch-metrics.html#outposts-metrics)」を参照してください。 + ローカルクラスターでは、[AWS Identity and Access Management authenticator for Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator) を使用する、デフォルトの認証メカニズムとして IAM を使用します。ネットワークの切断中には、IAM は使用できません。ですから、ローカルクラスターが、ネットワークの切断中にクラスターの接続に使用できる `x.509` 証明書を使用する代替認証メカニズムをサポートします。クラスターの `x.509` 証明書を取得して使用する方法については、「[ネットワーク切断中のローカルクラスターへの認証](#outposts-network-disconnects-authentication)」を参照してください。 + ネットワークの切断中に Route 53 にアクセスできない場合は、オンプレミス環境上にあるローカル DNS サーバーを使用することを検討してください。Kubernetes コントロールプレーンインスタンスは静的 IP アドレスを使用します。ローカル DNS サーバーを使用する代わりに、エンドポイントのホスト名と IP アドレスを使用してクラスターに接続するホストを設定できます。詳細については、AWS Outposts ユーザーガイドの [DNS](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html#dns) を参照してください。 + ネットワークの切断中にアプリケーショントラフィックの増加が予想する場合は、クラウドに接続したときにクラスターに予備のコンピューティング容量をプロビジョニングできます。Amazon EC2 インスタンスは AWS Outposts の料金に含まれています。そのため、スペアインスタンスを実行しても AWS の使用コストには影響しません。 + ネットワークが切断されている間、ワークロードの作成、更新、スケーリングオペレーションを有効にするには、アプリケーションのコンテナイメージにローカルネットワークを介してアクセスでき、クラスターに十分な容量がある必要があります。ローカルクラスターはコンテナレジストリをホストしません。Pod がそれらのノードで以前に実行されていた場合、コンテナイメージはノードにキャッシュされます。アプリケーションのコンテナイメージをクラウドの Amazon ECR から通常にプルする場合は、ローカルキャッシュまたはレジストリの実行を検討してください。ローカルキャッシュまたはレジストリは、ネットワーク切断中にワークロードリソースの作成、更新、スケーリングオペレーションが必要になった場合に便利です。 + ローカルクラスターは、Amazon EBS を永続ボリュームのデフォルトストレージクラスとして使用し、Amazon EBS 永続ボリュームのライフサイクルを管理するために Amazon EBS CSI ドライバーを使用しています。ネットワークの切断中は、Amazon EBS によってバックアップされる Pod を作成、更新、またはスケーリングすることはできません。これらのオペレーションにはクラウド内の Amazon EBS API への呼び出しが必要だからです。ステートフルワークロードをローカルクラスターにデプロイしていて、ネットワークの切断中に作成、更新、またはスケーリングオペレーションが必要な場合は、別のストレージメカニズムの使用を検討してください。 + AWS Outposts が、関連する AWS リージョン内 API (Amazon EBS または Amazon S3 の API など) にアクセスできない場合、Amazon EBS スナップショットを作成または削除することはできません。 + ALB (Ingress) と AWS Certificate Manager (ACM) を統合すると、証明書がプッシュされ、AWS Outposts ALB コンピューティングインスタンスのメモリに保存されます。現在の TLS ターミネーションは、AWS リージョンとの接続が切断された場合でも引き続き機能します。このコンテキストでの変更操作は失敗します (新しい入力定義、新しい ACM ベースの証明書 API 操作、ALB コンピューティングスケール、証明書のローテーションなど)。詳細については、「AWS Certificate Manager ユーザーガイド」の「[マネージド型の証明書の更新のトラブルシューティング](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-renewal.html)」を参照してください。 + Amazon EKS コントロールプレーンのログは、ネットワークの切断中に Kubernetes コントロールプレーンインスタンスでローカルにキャッシュされます。再接続すると、ログは親 AWS リージョンの CloudWatch Logs に送信されます。[Prometheus](https://prometheus.io/)、[Grafana](https://grafana.com/)、または Amazon EKS パートナーソリューションを使用して、Kubernetes API サーバーのメトリクスエンドポイントを使用して、またはログに Fluent Bit を使用してクラスターをローカルで監視できます。 + アプリケーショントラフィックに Outposts で AWS Load Balancer Controller を使用している場合、AWS Load Balancer Controller が前面にある既存の Pod は、ネットワークの切断中もトラフィックを受信し続けます。ネットワーク切断中に作成された新しい Pod は、Outpost が AWS クラウドに再接続されるまでトラフィックを受信しません。ネットワーク切断中のスケーリングのニーズに対応するために、AWS Cloud に接続している間はアプリケーションのレプリカ数を設定することを検討してください。 + Amazon VPC CNI plugin for Kubernetes は、デフォルトで[セカンダリ IP モード](https://aws.github.io/aws-eks-best-practices/networking/vpc-cni/#overview)になります。`WARM_ENI_TARGET`=`1` で構成されているため、プラグインは使用可能な IP アドレスの「完全な伸縮性ネットワークインターフェイス」を維持できます。接続されていない状態でのスケーリングのニーズに応じて、`WARM_ENI_TARGET`、`WARM_IP_TARGET`、`MINIMUM_IP_TARGET` の値を変更することを検討してください。詳細については、「GitHub」の「プラグインの [readme](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) ファイル」を参照してください。各インスタンスタイプによりサポートされる Pod の最大数のリストについては、GitHub の [eni-max-pods.txt](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/misc/eni-max-pods.txt) ファイルを参照してください。 ## ネットワーク切断中のローカルクラスターへの認証 AWS Identity and Access Management (IAM) は、ネットワークの切断中は使用できません。切断されている間は、IAM 認証情報を使用してローカルクラスターを認証することはできません。しかしながら、切断時に `x509` 証明書を使用して、ローカルネットワークを介してクラスターに接続できます。切断時に使用するクライアント `X509` 証明書をダウンロードして保存する必要があります。このトピックでは、証明書を作成して使用し、クラスターが接続されていない状態のときにクラスターを認証する方法を説明します。 1. 証明書署名リクエストを作成します。 1. 証明書署名リクエストを生成します。 ``` openssl req -new -newkey rsa:4096 -nodes -days 365 \ -keyout admin.key -out admin.csr -subj "/CN=admin" ``` 1. Kubernetes で証明書署名リクエストを作成します。 ``` BASE64_CSR=$(cat admin.csr | base64 -w 0) cat << EOF > admin-csr.yaml apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata: name: admin-csr spec: signerName: kubernetes.io/kube-apiserver-client request: ${BASE64_CSR} usages: - client auth EOF ``` 1. `kubectl` を使用して証明書署名リクエストを作成します。 ``` kubectl create -f admin-csr.yaml ``` 1. 証明書登録リクエストのステータスを確認します。 ``` kubectl get csr admin-csr ``` 出力例は次のとおりです。 ``` NAME AGE REQUESTOR CONDITION admin-csr 11m kubernetes-admin Pending ``` Kubernetes が証明書署名リクエストを作成しました。 1. 証明書署名リクエストを承認します。 ``` kubectl certificate approve admin-csr ``` 1. 証明書署名リクエストの承認のステータスを再確認します。 ``` kubectl get csr admin-csr ``` 出力例は次のとおりです。 ``` NAME AGE REQUESTOR CONDITION admin-csr 11m kubernetes-admin Approved ``` 1. 証明書を取得して検証します。 1. 証明書を取得する。 ``` kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt ``` 1. 証明書を検証する。 ``` cat admin.crt ``` 1. `admin` ユーザーのクラスターロールバインディングを作成します。 ``` kubectl create clusterrolebinding admin --clusterrole=cluster-admin \ --user=admin --group=system:masters ``` 1. 接続されていない状態のユーザースコープの kubeconfig を生成します。 ダウンロードした `admin` 証明書を使用して `kubeconfig` ファイルを生成できます。次のコマンドの *my-cluster* と *apiserver-endpoint* を置き換えます。 ``` aws eks describe-cluster --name my-cluster \ --query "cluster.certificateAuthority" \ --output text | base64 --decode > ca.crt ``` ``` kubectl config --kubeconfig admin.kubeconfig set-cluster my-cluster \ --certificate-authority=ca.crt --server apiserver-endpoint --embed-certs ``` ``` kubectl config --kubeconfig admin.kubeconfig set-credentials admin \ --client-certificate=admin.crt --client-key=admin.key --embed-certs ``` ``` kubectl config --kubeconfig admin.kubeconfig set-context admin@my-cluster \ --cluster my-cluster --user admin ``` ``` kubectl config --kubeconfig admin.kubeconfig use-context admin@my-cluster ``` 1. `kubeconfig` ファイルを表示する。 ``` kubectl get nodes --kubeconfig admin.kubeconfig ``` 1. Outpost で既にサービスが稼働している場合は、この手順をスキップしてください。Outpost で実行されているサービスが Amazon EKS のみで、その Outpost が現在本番環境ではない場合は、ネットワークの切断をシミュレートできます。ローカルクラスターで本番環境に入る前に、切断をシミュレートして、接続されていない状態でもクラスターにアクセスできることを確認できます。 1. Outpostを AWS リージョンに接続するネットワークデバイスにファイアウォールルールを適用します。これにより、Outpost のサービスリンクが切断されます。新しいインスタンスを作成することはできません。現在実行中のインスタンスは、AWS リージョンおよびインターネットへの接続を失います。 1. `x509` 証明書を使用して、切断時にローカルクラスターへの接続をテストできます。`kubeconfig` を前の手順で作成した `admin.kubeconfig` に必ず変更してください。*my-cluster* の部分は、お客様のローカルクラスター名に置き換えます。 ``` kubectl config use-context admin@my-cluster --kubeconfig admin.kubeconfig ``` ローカルクラスターが接続されていない状態で問題が発生した場合は、サポートチケットを開くことをお勧めします。 # キャパシティに関する考慮事項に基づいて、AWS Outposts で Amazon EKS クラスターのインスタンスタイプとプレイスメントグループを選択する このトピックでは、Kubernetes コントロールプレーンインスタンスタイプを選択し、(オプションで) プレイスメントグループを使用して Outpost のローカル Amazon EKS クラスターの高可用性要件を満たすためのガイダンスを提供します。 Outposts でローカルクラスターの Kubernetes コントロールプレーンに使用するインスタンスタイプ (`m5`、`c5`、`r5` など) を選択する前に、Outpost 設定で使用可能なインスタンスタイプを確認します。使用可能なインスタンスタイプを特定したら、ワークロードに必要なノード数に基づいてインスタンスサイズ (`large`、`xlarge`、`2xlarge` など) を選択します。次のテーブルは、インスタンスサイズを選択する際のレコメンデーションを示しています。 **注記** インスタンスサイズは Outposts にスロットされている必要があります。ローカルクラスターの存続期間中、Outposts で使用可能なサイズの 3 つのインスタンス用に十分な容量を確保してください。使用可能な Amazon EC2 インスタンスタイプのリストについては、「[AWS Outposts ラックの特徴](https://aws.amazon.com/outposts/rack/features/)」の「コンピューティングとストレージ」セクションを参照してください。 | ノードの数。 | Kubernetes コントロールプレーンのインスタンスサイズ | | --- | --- | | 1～20 | `large` | | 21～100 | `xlarge` | | 101～250 | `2xlarge` | | 251～500 | `4xlarge` | Kubernetes コントロールプレーンのストレージには、`etcd` に要求される IOPS を満たすために、ローカルクラスターごとに 246 GB の Amazon EBS ストレージが必要です。ローカルクラスターの作成時に、Amazon EBS ボリュームは自動的にプロビジョニングされます。 ## コントロールプレーンの配置 `OutpostConfig.ControlPlanePlacement.GroupName` プロパティでプレイスメントグループを指定しない場合、Kubernetes コントロールプレーン用にプロビジョニングされた Amazon EC2 インスタンスは、Outpost で利用可能な基盤となる容量全体にわたって、特定のハードウェア配置の強制を受けません。 プレイスメントグループを使用すると、Outpost のローカル Amazon EKS クラスターの高可用性要件を満たすことができます。クラスターの作成中にプレイスメントグループを指定することで、Kubernetes コントロールプレーンインスタンスの配置に影響を与えます。インスタンスは基盤となる独立したハードウェア (ラックまたはホスト) に分散されるため、ハードウェア障害発生時のインスタンス間の影響が最小限に抑えられます。 設定できるスプレッドのタイプは、デプロイの Outpost ラックの数によって異なります。 + **単一の論理的な Outpost に 1 つまたは 2 つの物理ラックを使用するデプロイ** - Kubernetes コントロールプレーンインスタンス用に選択したインスタンスタイプで構成されたホストが少なくとも 3 つ必要です。*ホストレベルのスプレッド*を使用する*スプレッド*プレイスメントグループにより、すべての Kubernetes コントロールプレーンインスタンスが、Outpost デプロイで使用可能な基盤となるラック内の個別のホストで実行されるようになります。 + **単一の論理的な Outpost に 3 つ以上の物理ラックを使用するデプロイ** - Kubernetes コントロールプレーンインスタンス用に選択したインスタンスタイプで構成されたホストが少なくとも 3 つ必要です。*ラックレベルスプレッド*を使用する*スプレッド*プレイスメントグループにより、すべての Kubernetes コントロールプレーンインスタンスが、Outpost デプロイ内の個別のラックで実行されるようになります。または、前のオプションで説明したように、ホストレベルのスプレッドプレイスメントグループを使用することもできます。 希望するプレイスメントグループの作成はお客様の責任となります。`CreateCluster` API を呼び出すときにプレイスメントグループを指定します。プレイスメントグループとその作成方法の詳細については、「Amazon EC2 ユーザーガイド」の「[プレイスメントグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)」を参照してください。 + プレイスメントグループを指定する場合、ローカルの Amazon EKS クラスターを正常に作成するには、Outpost に使用可能なスロット容量が必要です。容量は、ホストタイプとラックスプレッドタイプのどちらを使用するかによって異なります。十分な容量がない場合、クラスターは `Creating` 状態のままになります。[DescribeCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html) API レスポンスのヘルスフィールドで `Insufficient Capacity Error` を確認できます。作成プロセスを進めるには、容量を解放する必要があります。 + Amazon EKS ローカルクラスタープラットフォームとバージョンの更新中に、クラスターの Kubernetes コントロールプレーンインスタンスはローリング更新戦略を使用して新しいインスタンスに置き換えられます。この交換プロセス中に、各コントロールプレーンインスタンスは終了し、それぞれのスロットが解放されます。代わりに新しい更新済みインスタンスがプロビジョニングされます。更新されたインスタンスは、リリースされたスロットに配置される可能性があります。スロットが別の無関係なインスタンスによって消費され、必要なスプレッドトポロジー要件を満たす容量が残っていない場合、クラスターは `Updating` 状態のままになります。[DescribeCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html) API レスポンスのヘルスフィールドでそれぞれの `Insufficient Capacity Error` を確認できます。更新プロセスを進めて以前の高可用性レベルを再設定できるように、容量を解放する必要があります。 + AWS リージョンごとにアカウントあたり、最大 500 個のプレイスメントグループを作成できます。詳細については、「Amazon EC2 ユーザーガイド」の「[一般的なルールと制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#placement-groups-limitations-general)」を参照してください。 # AWS Outposts でローカル Amazon EKS クラスターをトラブルシューティングする このトピックでは、ローカルクラスターの使用中に表示される可能性がある一般的なエラーとそのトラブルシューティング方法について説明します。ローカルクラスターはクラウド内の Amazon EKS クラスターと似ていますが、Amazon EKS による管理方法にはいくつかの違いがあります。 **重要** AWS サポートから明示的に指示されていない限り、Outpost で実行されているマネージド型 EKS ローカルクラスターの `Kubernetes` コントロールプレーンインスタンスを終了しないでください。これらのインスタンスを終了すると、複数のインスタンスが同時に終了した場合にローカルクラスターが失われるなど、ローカルクラスターサービスの可用性にリスクが伴います。EKS ローカルクラスターの `Kubernetes` コントロールプレーンインスタンスは、EC2 インスタンスコンソールでは `eks-local:controlplane-name` タグで識別します。 ## API の動作 ローカルクラスターは Amazon EKS API を通して作成されますが、非同期で実行されます。つまり、Amazon EKS API へのリクエストはローカルクラスターに対してすぐに返されます。ただし、これらのリクエストは成功し、入力検証エラーにより迅速に失敗するか、あるいは失敗して説明入りの検証エラーが発生する可能性があります。この動作は、Kubernetes API と同様です。 ローカルクラスターは `FAILED` ステータスに移行しません。Amazon EKS は、クラスターの状態をユーザーが要求した望ましい状態と一致させようと継続的に試みます。その結果、根本的な問題が解決されるまで、長期間にわたってローカルクラスターが `CREATING` 状態のままになる可能性があります。 ## クラスターヘルスフィールドについて説明します [describe-cluster](https://docs.aws.amazon.com/cli/latest/reference/eks/describe-cluster.html) Amazon EKS AWS CLI コマンドを使用して、ローカルクラスターの問題を検出できます。ローカルクラスターの問題は、`describe-cluster` コマンドの応答の `cluster.health` フィールドによって明らかになります。このフィールドに含まれるメッセージには、エラーコード、説明メッセージ、および関連するリソース ID が含まれます。この情報は、Amazon EKS API および AWS CLI のみから利用可能です。次の例では、*my-cluster* をローカルクラスターの名前に置き換えます。 ``` aws eks describe-cluster --name my-cluster --query 'cluster.health' ``` 出力例は次のとおりです。 ``` { "issues": [ { "code": "ConfigurationConflict", "message": "The instance type 'm5.large' is not supported in Outpost 'my-outpost-arn'.", "resourceIds": [ "my-cluster-arn" ] } ] } ``` 問題が修復できない場合は、ローカルクラスターを削除して新しいクラスターを作成する必要がある場合があります。たとえば、Outpost で利用できないインスタンスタイプでクラスターをプロビジョニングしようとしている場合などです。下表は、一般的なヘルス関連のエラーを示しています。 | エラーシナリオ | コード | メッセージ | ResourceIds | | --- | --- | --- | --- | | 指定されたサブネットが見つかりませんでした。 | `ResourceNotFound` | `The subnet ID subnet-id does not exist` | 指定されたすべてのサブネット ID | | 指定されたサブネットが同じ VPC に属していません。 | `ConfigurationConflict` | `Subnets specified must belong to the same VPC` | 指定されたすべてのサブネット ID | | 指定されたサブネットの一部が、指定された Outpost に属していません。 | `ConfigurationConflict` | `Subnet subnet-id expected to be in outpost-arn, but is in other-outpost-arn ` | 問題のあるサブネット ID | | 指定されたサブネットの中には、どの Outpost にも属していないものがあります。 | `ConfigurationConflict` | `Subnet subnet-id is not part of any Outpost` | 問題のあるサブネット ID | | 指定されたサブネットの中には、コントロールプレーンインスタンス用のエラスティックネットワークインターフェイスを作成するだけの十分な空きアドレスがないものがあります。 | `ResourceLimitExceeded` | `The specified subnet does not have enough free addresses to satisfy the request.` | 問題のあるサブネット ID | | 指定されたコントロールプレーンインスタンスタイプは、お使いの Outpost でサポートされていません。 | `ConfigurationConflict` | `The instance type type is not supported in Outpost outpost-arn ` | クラスター ARN | | コントロールプレーン Amazon EC2 インスタンスを終了したか、`run-instance` が成功し、観察された状態が `Terminated` に変わりました。これは、Outpost が再接続され、Amazon EBS の内部エラーが原因で Amazon EC2 内部ワークフローが失敗した後、一定期間発生する可能性があります。 | `InternalFailure` | `EC2 instance state "Terminated" is unexpected` | クラスター ARN | | Outpost の容量が不足しています。これは、クラスターの作成中に Outpost が AWS リージョンから切断された場合にも発生する可能性があります。 | `ResourceLimitExceeded` | `There is not enough capacity on the Outpost to launch or start the instance.` | クラスター ARN | | アカウントがセキュリティグループの制限を超えています。 | `ResourceLimitExceeded` | Amazon EC2 API から返されたエラーメッセージ | ターゲット VPC ID | | アカウントがエラスティックネットワークインターフェイスの制限を超えています。 | `ResourceLimitExceeded` | Amazon EC2 API から返されたエラーメッセージ | ターゲットサブネット ID | | AWS Systems Manager を介してコントロールプレーンインスタンスにアクセスできません。解決策については、「[AWS Systems Manager を介してコントロールプレーンインスタンスにアクセスできません。](#outposts-troubleshooting-control-plane-instances-ssm)」を参照してください。 | `ClusterUnreachable` | Amazon EKS コントロールプレーンインスタンスには SSM 経由ではアクセスできません。SSM とネットワーク設定を確認し、EKS on Outposts のトラブルシューティングドキュメントを参照してください。 | Amazon EC2 インスタンス ID | | マネージドセキュリティグループまたはエラスティックネットワークインターフェイスの詳細を取得中に、エラーが発生しました。 | Amazon EC2 クライアントエラーコードに基づきます。 | Amazon EC2 API から返されたエラーメッセージ | すべてのマネージドセキュリティグループ ID | | セキュリティグループのイングレスルールを承認または取り消す際にエラーが発生しました。これは、クラスターとコントロールプレーンの両方のセキュリティグループに適用されます。 | Amazon EC2 クライアントエラーコードに基づきます。 | Amazon EC2 API から返されたエラーメッセージ | 問題のあるセキュリティグループの ID | | コントロールプレーンインスタンスのエラスティックネットワークインターフェイスの削除中にエラーが発生しました。 | Amazon EC2 クライアントエラーコードに基づきます。 | Amazon EC2 API から返されたエラーメッセージ | 問題のあるエラスティックネットワークインターフェイス ID | 次の表は、`describe-cluster` 応答のヘルスフィールドに表示される他の AWS サービスからのエラーを示しています。 | Amazon EC2 エラーコード | クラスターヘルス問題コード | 説明 | | --- | --- | --- | | `AuthFailure` | `AccessDenied` | このエラーは、さまざまな理由で発生する可能性があります。最も一般的な理由は、サービスにリンクされたロールポリシーの範囲を狭めるためにサービスが使用するタグが、コントロールプレーンインスタンスから誤って削除された場合に発生するのです。この場合、Amazon EKS はこれらの AWS リソースを管理および監視できなくなります。 | | `UnauthorizedOperation` | `AccessDenied` | このエラーは、さまざまな理由で発生する可能性があります。最も一般的な理由は、サービスにリンクされたロールポリシーの範囲を狭めるためにサービスが使用するタグが、コントロールプレーンインスタンスから誤って削除された場合に発生するのです。この場合、Amazon EKS はこれらの AWS リソースを管理および監視できなくなります。 | | `InvalidSubnetID.NotFound` | `ResourceNotFound` | このエラーは、セキュリティグループのイングレスルールのサブネット ID が見つからない場合に発生します。 | | `InvalidPermission.NotFound` | `ResourceNotFound` | このエラーは、セキュリティグループのイングレスルールの権限が正しくない場合に発生します。 | | `InvalidGroup.NotFound` | `ResourceNotFound` | このエラーは、セキュリティグループのイングレスルールのグループが見つからない場合に発生します。 | | `InvalidNetworkInterfaceID.NotFound` | `ResourceNotFound` | このエラーは、セキュリティグループのイングレスルールのネットワークインターフェイス ID が見つからない場合に発生します。 | | `InsufficientFreeAddressesInSubnet` | `ResourceLimitExceeded` | このエラーは、サブネットリソースのクォータを超えたときに発生します。 | | `InsufficientCapacityOnOutpost` | `ResourceLimitExceeded` | このエラーは、outpost のクォータを超えたときに発生します。 | | `NetworkInterfaceLimitExceeded` | `ResourceLimitExceeded` | このエラーは、エラスティックネットワークインターフェイスのクォータを超えた場合に発生します。 | | `SecurityGroupLimitExceeded` | `ResourceLimitExceeded` | このエラーは、セキュリティグループのクォータを超えたときに発生します。 | | `VcpuLimitExceeded` | `ResourceLimitExceeded` | Amazon EC2 インスタンスを新規アカウントで作成するときに発生します。エラーは次のようなものになります: 「`You have requested more vCPU capacity than your current vCPU limit of 32 allows for the instance bucket that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit."` | | `InvalidParameterValue` | `ConfigurationConflict` | Amazon EC2 は、指定されたインスタンスタイプが Outpost でサポートされていない場合、このエラーコードを返します。 | | その他のすべての障害 | `InternalFailure` | なし | ## クラスターを作成または変更できません ローカルクラスターには、クラウド内にホストされている Amazon EKS クラスターとは異なるアクセス権限とポリシーが必要です。クラスターの作成に失敗し `InvalidPermissions` エラーが表示される場合は、使用しているクラスターロールに [AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) マネージドポリシーがアタッチされているかどうかをもう一度確認します。その他すべての API 呼び出しには、クラウド内の Amazon EKS クラスターと同じ権限セットが必要です。 ## クラスターが `CREATING` の状態でスタックしています ローカルクラスターの作成にかかる時間は、いくつかの要因によって異なります。ネットワーク設定、Outpost の設定、およびクラスターの設定などが要因として考えられます。通常、ローカルクラスターは 15 ～ 20 分以内に作成され、`ACTIVE` ステータスに変わります。ローカルクラスターが `CREATING` 状態を維持する場合は、`describe-cluster` を呼び出すと `cluster.health` 出力フィールドに原因に関する情報が表示されます。 次は、最も一般的な問題を示しています。 + クラスターが Systems Manager のある AWS リージョンからコントロールプレーンインスタンスに接続できません。地域内の踏み台ホストから `aws ssm start-session --target instance-id ` を呼び出すことでこれを検証できます。このコマンドがうまくいかない場合は、Systems Manager がコントロールプレーンインスタンスで実行されているかどうかを確認します。または、別の回避策として、クラスターを削除して再度作成することもできます。 + EBS ボリュームの KMS キーのアクセス許可が原因で、コントロールプレーンインスタンスの作成に失敗します。暗号化された EBS ボリュームのユーザーマネージド KMS キーでは、キーにアクセスできない場合、コントロールプレーンインスタンスは終了します。インスタンスが終了した場合、AWS マネージド KMS キーに切り替えるか、ユーザーマネージドキーポリシーがクラスターロールに必要なアクセス許可を付与していることを確認します。 + Systems Manager のコントロールプレーンインスタンスが、インターネットにアクセスできない可能性があります。クラスターの作成時に指定したサブネットに NAT ゲートウェイとインターネットゲートウェイを備えた VPC があるかどうかを確認します。VPC 到達可能性アナライザーを使用して、コントロールプレーンインスタンスがインターネットゲートウェイに到達できることを確認します。詳細については、「[VPC Reachability Analyzer の開始方法](https://docs.aws.amazon.com/vpc/latest/reachability/getting-started.html)」を参照してください。 + 指定したロール ARN にポリシーがありません。[AWS マネージドポリシー: AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) がロールから削除されたかどうかを確認します。これは、AWS CloudFormation スタックの設定が間違っている場合にも発生する可能性があります。 + 指定されているすべてのサブネットが同じ Outpost に関連付けられており、相互に到達できる必要があります。クラスターの作成時に複数のサブネットを指定すると、Amazon EKS はコントロールプレーンインスタンスを複数のサブネットに分散させようとします。 + Amazon EKS マネージド セキュリティグループは、エラスティックネットワークインターフェイスに適用されます。しかしながら、NACL ファイアウォールルールなどの他の設定要素が、エラスティックネットワークインターフェイスのルールと競合する可能性があります。 **VPC とサブネット DNS の設定が誤っているか、欠落しています** 「[AWS Outposts で Amazon EKS クラスターの VPC とサブネットを作成する](eks-outposts-vpc-subnet-requirements.md)」を確認します。 ## クラスターが `UPDATING` の状態でスタックしています Amazon EKS は既存のすべてのローカルクラスターを、対応する Kubernetes マイナーバージョン用の最新のプラットフォームバージョンに自動的にアップデートします。プラットフォームバージョンの詳細については、「[AWS Outposts の Kubernetes および Amazon EKS プラットフォームバージョンについて説明します。](eks-outposts-platform-versions.md)」を参照してください。 プラットフォームバージョンの自動ロールアウト中に、クラスターのステータスが `UPDATING` に変わります。更新プロセスでは、すべての Kubernetes コントロールプレーンインスタンスを、それぞれの Kubernetes マイナーバージョン用にリリースされた最新のセキュリティパッチとバグ修正を含む新しいインスタンスに置き換えます。一般的に、ローカルクラスタープラットフォームの更新プロセスは 30 分以内に完了し、クラスターは `ACTIVE` ステータスに戻ります。ローカルクラスターが長時間 `UPDATING` 状態になる場合は、`describe-cluster` を呼び出すと `cluster.health` 出力フィールドで原因に関する情報を確認できます。 Amazon EKS は、ローカルクラスターの可用性を維持し、サービスの中断を防ぐために、3 つの Kubernetes コントロールプレーンインスタンスのうち少なくとも 2 つが正常で運用可能なクラスターノードであるようにします。ローカルクラスターが `UPDATING` 状態で停止している場合、通常は、プロセスが続行された場合に 2 つのインスタンスの最小可用性が保証されないインフラストラクチャまたは設定の問題が原因です。したがって、ローカルクラスターサービスの中断を防ぐために、更新プロセスの進行が停止します。 更新プロセスを完了し、3 つの Kubernetes コントロールプレーンインスタンスの高可用性でローカルクラスターを `ACTIVE` に戻すことができるように、`UPDATING` 状態で停止しているローカルクラスターをトラブルシューティングし、根本原因に対処することが重要です。 AWS サポートから明示的に指示されていない限り、Outposts でマネージド型 EKS ローカルクラスターの `Kubernetes` インスタンスを終了しないでください。これは、別のコントロールプレーンノードが完全には正常ではなく、間違ったインスタンスを終了すると、サービスの中断やローカルクラスターのデータ損失のリスクが生じる可能性が高いため、ローカルクラスターが `UPDATING` 状態で停止した場合、特に重要です。 次は、最も一般的な問題を示しています。 + ローカルクラスターが最初に作成された以降のネットワーク設定の変更により、1 つまたは複数のコントロールプレーンインスタンスが System Manager に接続できません。地域内の踏み台ホストから `aws ssm start-session --target instance-id ` を呼び出すことでこれを検証できます。このコマンドがうまくいかない場合は、Systems Manager がコントロールプレーンインスタンスで実行されているかどうかを確認します。 + EBS ボリュームの KMS キーのアクセス許可が原因で、新しいコントロールプレーンインスタンスを作成できません。暗号化された EBS ボリュームのユーザーマネージド KMS キーでは、キーにアクセスできない場合、コントロールプレーンインスタンスは終了します。インスタンスが終了した場合、AWS マネージド KMS キーに切り替えるか、ユーザーマネージドキーポリシーがクラスターロールに必要なアクセス許可を付与していることを確認します。 + Systems Manager のコントロールプレーンインスタンスが、インターネットにアクセスできない可能性があります。クラスターの作成時に指定したサブネットに NAT ゲートウェイとインターネットゲートウェイを備えた VPC があるかどうかを確認します。VPC 到達可能性アナライザーを使用して、コントロールプレーンインスタンスがインターネットゲートウェイに到達できることを確認します。詳細については、「[VPC Reachability Analyzer の開始方法](https://docs.aws.amazon.com/vpc/latest/reachability/getting-started.html)」を参照してください。プライベートネットワークにアウトバウンドインターネット接続がない場合は、必要なすべての VPC エンドポイントとゲートウェイエンドポイントがクラスターのリージョンサブネットにまだ存在することを確認してください (「[AWS サービスへのサブネットアクセス](eks-outposts-vpc-subnet-requirements.md#subnet-access-to-services)」を参照)。 + 指定したロール ARN にポリシーがありません。[AWS managed policy: AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) がロールから削除されたかどうかを確認します。 + 新しい Kubernetes コントロールプレーンインスタンスのいずれかで、予期しないブートストラップ障害が発生した可能性があります。この例外的なケースのトラブルシューティングとログ収集に関する詳細なガイダンスについては、[AWS サポートセンター](https://console.aws.amazon.com/support/home)にチケットを提出してください。 ## ノードをクラスターに結合できない + AMI に関する問題: + 互換性のない AMI を使用しています。Amazon EKS 最適化 Amazon Linux 2 AMI のみがサポートされています (`amazon-linux-2`、`amazon-linux-2-gpu`、`amazon-linux-2-arm64`)。AL2023 ノードを AWS Outposts で EKS Local Clusters に結合しようとしても、ノードをクラスターに結合できません。詳細については、「[AWS Outposts で Amazon Linux ノードを作成する](eks-outposts-self-managed-nodes.md)」を参照してください。 + AWS CloudFormation テンプレートを使用してノードを作成した場合、サポートされていない AMI を使用していないことを確認します。 + AWS IAM Authenticator `ConfigMap` が見つからない - 見つからない場合は、作成する必要があります。詳細については、「[`aws-auth`   `ConfigMap` をクラスターに適用する](auth-configmap.md#aws-auth-configmap)」を参照してください。 + 間違ったセキュリティグループが使用されている - ワーカーノードのセキュリティグループには、必ず `eks-cluster-sg-cluster-name-uniqueid ` を使用してください。スタックが使用されるたびに、選択したセキュリティグループは AWS CloudFormation によって変更され、新しいセキュリティグループを使用できるようになります。 + 予期しないプライベートリンクの VPC 手順に従う - CA データが間違っている (`--b64-cluster-ca`) または API エンドポイント (`--apiserver-endpoint`) が渡されました。 ## ログの収集 Outpost が関連付けられている AWS リージョンから切断された場合でも、Kubernetes クラスターは依然として正常に動作し続けるはずです。ただし、クラスターが正常に機能しない場合は、「[AWS Outposts でローカル Amazon EKS クラスターを準備して、ネットワークの切断に備える](eks-outposts-network-disconnects.md)」にあるトラブルシューティング手順に従ってください。他の問題が発生した場合は、AWS サポートにお問い合わせください。AWSサポートからログ収集ツールをダウンロードして実行する方法を説明します。この方法により、Kubernetes クラスターコントロールプレーンインスタンスからログを収集し、詳細な調査のために AWS サポートに送信できます。 ## AWS Systems Manager を介してコントロールプレーンインスタンスにアクセスできません。 Amazon EKS コントロールプレーンインスタンスが AWS Systems Manager (Systems Manager) を通してアクセスでない場合、Amazon EKS はクラスターに対して次のエラーを表示します。 ``` Amazon EKS control plane instances are not reachable through SSM. Please verify your SSM and network configuration, and reference the EKS on Outposts troubleshooting documentation. ``` この問題を解決するには、VPC とサブネットが「[AWS Outposts で Amazon EKS クラスターの VPC とサブネットを作成する](eks-outposts-vpc-subnet-requirements.md)」の要件を満たしており、AWS Systems Manager ユーザーガイドの「[Session Manager の設定](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html)」にある手順が完了していることを確認してください。 # AWS Outposts で Amazon Linux ノードを作成する **重要** Outposts 上の Amazon EKS Local Clusters は、次の Amazon EKS 最適化 Amazon Linux 2023 AMI から作成されたノードのみをサポートします。 標準 Amazon Linux 2023 (`amazon-linux-2023/x86_64/standard`) 高速 Nvidia Amazon Linux 2023 (`amazon-linux-2023/x86_64/nvidia`) 高速 Neuron Amazon Linux 2023 (`amazon-linux-2023/x86_64/neuron`) AWS は、EKS AL2 最適化 AMI と AL2 高速化 AMI に対するサポートを、2025 年 11 月 26 日に終了しました。お客様は、こちらのサポート終了 (EOS) の日付 (2025 年 11 月 26 日) 以降も EKS AL2 AMI をご使用いただけますが、EKS はこの日以降、新しい Kubernetes バージョンや AL2 AMI の更新 (マイナーリリース、パッチ、バグ修正を含む) をリリースすることはありません。AL2 の非推奨の詳細については、[こちら](https://docs.aws.amazon.com/eks/latest/userguide/eks-ami-deprecation-faqs.html)を参照してください。 このトピックは Amazon EKS クラスターに登録されている Outpost 上の Amazon Linux ノードの 自動スケーリング グループを起動する方法を説明します。クラスターはAWS クラウド または アウトポスト に置くことができます。 + 既存の アウトポスト。詳細については「[AWS アウトポスト とは](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)」を参照してください。 + 既存の Amazon EKS クラスター。AWS クラウド にクラスターをデプロイするには「[Amazon EKS クラスターを作成します。](create-cluster.md)」を参照してください。Outpost にクラスターをデプロイするには「[高可用性を実現するために AWS Outposts でローカル Amazon EKS クラスターを作成する](eks-outposts-local-cluster-overview.md)」を参照してください。 + AWS クラウド のクラスターにノードを作成しており、AWS Outposts、AWS 波長、または AWS ローカルゾーン が有効になっている AWS リージョンにサブネットがあるとします。この場合、クラスターを作成したときに、これらのサブネットが渡されていない必要があります。Outpost 上のクラスターにノードを作成する場合はクラスターの作成時に Outpost サブネットを渡しておく必要があります。 + (AWS クラウド上のクラスターに推奨) 必要な IAM ポリシーがアタッチされた独自の IAM ロールで設定された Amazon VPC CNI plugin for Kubernetes アドオン。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。ローカルクラスターはサービスアカウントの IAM ロールをサポートしていません。 `eksctl` または AWS マネジメントコンソール (AWS クラウドFormation テンプレートを使用) で、セルフマネージド型の Amazon Linux ノードグループを作成できます。Terraform を使用することもできます。 このページで説明されている以下のツールを使用して、ローカルクラスターのセルフマネージド型ノードグループを作成できます。 + [`eksctl`](#eksctl_create_nodes_outpost) + [AWS マネジメントコンソール](#console_create_nodes_outpost) **重要** セルフマネージド型ノードグループにはアカウント内の Amazon EC2 インスタンスが含まれています。これらのインスタンスはお客様または代わりに Amazon EKS がコント役割プレーンのバージョンを更新しても、自動的にはアップグレードされません。セルフマネージド型ノードグループは更新が必要であることをコンソールに表示しません。更新が必要なノードを確認するにはクラスターの **[概要]** タブにある **[ノード]** のリストからノードを選択して、そこにインストールされている `kubelet` バージョンを表示します。ノードは手動で更新する必要があります。詳細については、「[クラスターのためにセルフマネージドノードを更新する](update-workers.md)」を参照してください。 セルフマネージド型ノードで kubelet が使用する証明書は、1 年の有効期限で発行されます。デフォルトでは、証明書のローテーションは**有効になっていません** (https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/\$1kubelet-config-k8s-io-v1beta1-KubeletConfiguration を参照)。つまり、セルフマネージド型ノードを 1 年以上にわたって実行し続けると、Kubernetes API に対して認証できなくなります。 ベストプラクティスとして、お客様は定期的にセルフマネージド型ノードグループを更新して、最新の Amazon EKS 最適化 AMI から CVE およびセキュリティパッチを受け取ることをお勧めします。セルフマネージド型ノードグループで使用される AMI を更新すると、ノードの再作成もトリガーされ、kubelet 証明書の有効期限が切れたことによる問題が発生しないようにします。 または、セルフマネージド型ノードグループの作成時にクライアント証明書のローテーション (https://kubernetes.io/docs/tasks/tls/certificate-rotation/ を参照) を有効にして、現在の証明書の有効期限が近づくと kubelet 証明書が更新されるようにすることもできます。 ## `eksctl` **`eksctl` を使用して自己管理型Linuxノードを起動するには ** 1. デバイスまたは AWS クラウドシェル にインストールされている `eksctl` コマンドラインツールのバージョン `0.215.0` 以降をインストールします。`eksctl` をインストールまたはアップグレードするには`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。 1. クラスターが AWS クラウド にあり、**AmazonEKS\$1CNI\$1Policy** マネージド IAM ポリシーが [Amazon EKS ノードの IAM ロール](create-node-role.md)へアタッチされている場合は代わりに Kubernetes `aws-node` サービスアカウントに関連付けた IAM ロールに割り当てることをお勧めします。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。クラスターが Outpost にある場合はポリシーをノードロールにアタッチする必要があります。 1. 次のコマンドは既存のクラスターにノードグループを作成します。クラスターは`eksctl` を使用して作成されている必要があります。*al-nodes* を、ノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。*マイクラスター* の部分は自分のクラスター名に置き換えます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前はクラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。クラスターが Outpost に存在する場合は*id* を Outpost サブネットの ID に置き換えます。AWS クラウド にクラスターが存在する場合、*id* をクラスターの作成時に指定しなかったサブネットの ID に置き換えます。残りのサンプル値は独自の値に置き換えます。デフォルトでは、ノードはコントロールプレーンと同じ Kubernetes バージョンで作成されます。 *インスタンス型* を Outpost で利用可能なインスタンスタイプに置き換えます。 *マイキー* を Amazon EC2 キーペアまたはパブリックキーの名前に置き換えます。このキーは起動後のノードに SSH 接続するために使用されます。Amazon EC2 キーペアをまだ持っていない場合はAWS マネジメントコンソール で作成できます。詳細については「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。 次のコマンドを使用して、ノードグループを作成します。 ``` eksctl create nodegroup --cluster my-cluster --name al-nodes --node-type instance-type \ --nodes 3 --nodes-min 1 --nodes-max 4 --managed=false \ --node-volume-type gp2 --subnet-ids subnet-id \ --node-ami-family AmazonLinux2023 ``` クラスターを AWS クラウド 上にデプロイしている場合: + デプロイするノードグループではインスタンスのブロックとは異なる CIDR ブロックから `IPv4` アドレスを Pod に割り当てることができます。詳細については、「[カスタムネットワーキングを使用して代替サブネットに Pod をデプロイする](cni-custom-network.md)」を参照してください。 + デプロイするノードグループはアウトバウンドインターネットアクセスを必要としません。詳細については「[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)」を参照してください。 利用できるすべてのオプションとデフォルトの詳細なリストについては`eksctl` ドキュメントの「[AWS Outposts サポート](https://eksctl.io/usage/outposts/)」を参照してください。 + ノードがクラスターに参加できない場合は「[Amazon EKS クラスターとノードに関する問題をトラブルシューティングする](troubleshooting.md)」の「[ノードをクラスターに結合できません](troubleshooting.md#worker-node-fail)」および「[AWS アウトポスト でローカル Amazon EKS クラスターをトラブルシューティングする](eks-outposts-troubleshooting.md)」の「[ノードをクラスターに結合できない](eks-outposts-troubleshooting.md#outposts-troubleshooting-unable-to-join-nodes-to-a-cluster)」を参照してください。 + 出力例は次のとおりです。ノードの作成中に、複数の行が出力されます。出力の最後の行は次のサンプル行が表示されます。 ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (オプション) [サンプルアプリケーション](sample-deployment.md)をデプロイして、クラスターと Linux ノードをテストします。 ## AWS マネジメントコンソール **ステップ 1: AWS マネジメントコンソール を使用してセルフマネージド型の リナックス ノードを起動する**` 1. AWS クラウドフォーメーション テンプレートの最新バージョンをダウンロードします。 ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-24/amazon-eks-outpost-nodegroup.yaml ``` 1. [AWS クラウドFormation コンソール](https://console.aws.amazon.com/cloudformation/)を開きます。 1. **[スタックの作成]** を選択し、**[新しいリソースを使用 (標準)]** を選択してください。 1. **[テンプレートの指定]** で、**[テンプレートファイルのアップロード]** を選択し、**[ファイルを選択]** を選択してください。前のステップでダウンロードした `amazon-eks-nodegroup.yaml` ファイルを選択し、**[次へ]** を選択してください。 1. **[スタックの詳細の指定]** ページで、必要に応じて次のパラメータを入力し、**[次へ]** を選択してください： + **スタック名**: AWS クラウドFormation スタックのスタック名を選択してください：例えば、*al-nodes* という名前にすることができます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前はクラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。 + **ApiServerEndpoint**: EKS コンソール、または DescribeCluster API で表示される Kubernetes API Server エンドポイントを入力します。 + **[クラスター名]**: クラスターの名前を入力してください：この名前が、クラスター名と一致しない場合、ノードはクラスターに参加できません。 + **ClusterId**: EKS サービスによってクラスターに割り当てられた ID を入力します。DescribeCluster API で表示されます。この ID が、クラスター ID と一致しない場合、ノードはクラスターに参加できません。 + **CertificateAuthority**: Kubernetes の証明機関の base64 エンコード文字列を入力します。EKS コンソール、または DescribeCluster API で表示されます。 + **ServiceCidr**: Kubernetes サービス CIDR を入力します。EKS コンソール、または DescribeCluster API で表示されます。 + [**クラスター制御プレーンセキュリティグループ**]: [VPC](creating-a-vpc.md) の作成時に生成した AWS クラウドフォーメーション 出力の [**セキュリティグループs**] 値を選択してください。 次のステップでは該当するグループを取得する 1 つのオペレーションを説明します。 1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。 1. クラスターの名前を選択してください。 1. **[ネットワーキング]** タブを選択してください。 1. **[クラスター制御プレーンセキュリティグループ]** ドロップダウンリストから選択する場合は**[追加のセキュリティグループ]** の値をリファレンスとして使用します。 + **[ノードグループ名]**: ノードグループの名前を入力してください。この名前はノードに対して作成される自動スケーリングノードグループを識別するために後で使用できます。 + **[ノード自動スケーリンググループ最小サイズ]**: ノードの 自動スケーリング グループがスケールインできる最小ノード数を入力してください： + **ノード自動スケーリンググループ希望容量**: スタック作成時にスケーリングする必要のあるノード数を入力してください。 + **[NodeAutoScalingGroupMaxSize]**: ノードの 自動スケーリング グループがスケールアウトできる最大ノード数を入力してください。 + **[ノードインスタンス型]**: ノードのインスタンスタイプを選択してください：クラスターが AWS クラウド で動作している場合は詳細については「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を参照してください。クラスターが Outpost で実行されている場合、Outpost で使用できるインスタンスタイプのみを選択できます。 + **[NodeImageIdSSMParam]**: 最新の Amazon EKS 最適化 AMI の Amazon EC2 Systems Manager のパラメータが、可変 Kubernetes バージョン用に事前設定されています。Amazon EKS でサポートされている別の Kubernetes マイナーバージョンを使用するには、*1.XX* を別の[サポートされているバージョン](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)に置き換えます。クラスターと同じ Kubernetes バージョンを指定することをお勧めします。 Amazon EKS 最適化高速 AMI を使用するには、*NodeImageIdSSMParam* 値を目的の SSM パラメータに更新します。SSM から EKS AMI ID を取得する方法については、[こちら](https://docs.aws.amazon.com/eks/latest/userguide/retrieve-ami-id.html)を参照してください。 **注記** Amazon EKS ノード AMI は Amazon リナックス をベースとしています。Amazon Linux のセキュリティまたはプライバシーに関するイベントを、[Amazon Linux セキュリティセンター](https://alas.aws.amazon.com/)で追跡できます。そのためには目的のバージョンのタブを選択してください。該当する RSS フィードをサブスクライブすることもできます。セキュリティおよびプライバシーイベントには問題の概要、影響を受けるパッケージ、および問題を修正するためにインスタンスを更新する方法などがあります。 + **ノードイメージId**: (オプション) (Amazon EKS 最適化 AMI の代わりに) 独自のカスタム AMI を使用している場合はAWS リージョンのノード AMI ID を入力してください。ここで値を指定すると、**[ノードイメージIdSSMParam]** フィールドの値はすべて上書きされます。 + **[ノードボリュームサイズ]**: ノードのルートボリュームのサイズを GiB 単位で指定します。 + **[ノードボリューム型]**: ノードのルートボリュームタイプを指定します。 + **[キー名]**: 起動後に、SSH を使用してノードに接続するときに使用できる Amazon EC2 SSH キーペアの名前を入力してください。Amazon EC2 キーペアをまだ持っていない場合はAWS マネジメントコンソール で作成できます。詳細については*「アマゾン EC2 ユーザーガイド」*の「[アマゾン EC2 キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。 **注記** ここでキーペアを指定しないと、AWS クラウドフォーメーション スタックの作成は失敗します。 + **[無効IMDSv1]**: 各ノードはデフォルトでインスタンスメタデータサービスバージョン 1 (IMDSv1) および IMDSv2 をサポートします。IMDSv1 は無効にできます。ノードグループ内の将来のノードおよび Pod が MDSv1 を使用しないようにするには **DisableIMDSv1** を **true** に設定します。IDMS の詳細については「[インスタンスメタデータサービスの設定](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)」を参照してください。ノードでのそれへのアクセス制限について詳しくは[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)を参照してください。 + **[VpcId]**: 作成した [VPC](creating-a-vpc.md) の ID を入力します：VPC を選択する前に、「[VPC の要件と考慮事項](eks-outposts-vpc-subnet-requirements.md#outposts-vpc-requirements)」を確認してください。 + **[サブネット]**: クラスターが Outpost にある場合、VPC 内で少なくとも 1 つのプライベートサブネットを選択してください：サブネットを選択する前に、「[サブネットの要件と考慮事項](eks-outposts-vpc-subnet-requirements.md#outposts-subnet-requirements)」を確認してください。クラスターの **[ネットワーキング]** タブから、各サブネットリンクを開き、プライベートのサブネットを確認できます。 1. **[スタックオプションの設定]** ページで、希望する設定を選択し、**[次へ]** を選択してください。 1. **[AWS クラウドフォーメーション が IAM リソースを作成する可能性を認識しています]** の左にあるチェックボックスを選択して、**[スタックの作成]** を選択してください。 1. スタックの作成が完了したら、コンソールで選択し、**[出力]** を選択してください。 1. 作成されたノードグループの **[ノードインスタンス役割]** を記録します。これはAmazon EKS ノードを設定する際、必要になります。 **ステップ 2: ノードを有効にしてクラスターに参加する** 1. `aws-auth` `ConfigMap` がすでにあるかどうかを確認します。 ``` kubectl describe configmap -n kube-system aws-auth ``` 1. `aws-auth` `ConfigMap` が表示されている場合は必要に応じて更新してください。 1. 編集する `ConfigMap` を開きます。 ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. 必要に応じて新しい `mapRoles` エントリを追加します。`rolearn` 値を、前の手順で記録した **[ノードインスタンス役割]** 値に設定します。 ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes [...] ``` 1. ファイルを保存し、テキストエディタを終了します。 1. 「`Error from server (NotFound): configmaps "aws-auth" not found`」というエラーが表示されたら、ストック `ConfigMap` を適用してください。 1. 設定マップをダウンロードします。 ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml ``` 1. `aws-auth-cm.yaml` ファイルで、`rolearn` を前の手順で記録した **[ノードインスタンス役割]** 値に設定します。これを行うにはテキストエディタを使用するか、*マイノードインスタンス役割* を置き換えて次のコマンドを実行してください： ``` sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml ``` 1. 設定を適用します。このコマンドが完了するまで数分かかることがあります。 ``` kubectl apply -f aws-auth-cm.yaml ``` 1. ノードのステータスを監視し、`Ready` ステータスになるまで待機します。 ``` kubectl get nodes --watch ``` `Ctrl`\$1`C` を入力して、シェルプロンプトに戻ります。 **注記** 認可またはリソースタイプのエラーが発生した場合はトラブルシューティングトピックの「[許可されていないか、アクセスが拒否されました (`kubectl`)](troubleshooting.md#unauthorized)」を参照してください。 ノードがクラスターに参加できない場合は「[Amazon EKS クラスターとノードに関する問題をトラブルシューティングする](troubleshooting.md)」の「[ノードをクラスターに結合できません](troubleshooting.md#worker-node-fail)」および「[AWS アウトポスト でローカル Amazon EKS クラスターをトラブルシューティングする](eks-outposts-troubleshooting.md)」の「[ノードをクラスターに結合できない](eks-outposts-troubleshooting.md#outposts-troubleshooting-unable-to-join-nodes-to-a-cluster)」を参照してください。 1. Amazon EBS CSI ドライバーをインストールします。詳細についてはGitHub の [Installation](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md) を参照してください。**[ドライバーのアクセス許可を設定]** セクションでは**[IAM インスタンスプロファイルの使用]** オプションの指示に従うことを確認します。`gp2` ストレージクラスを使用する必要があります。`gp3` ストレージクラスはサポートされていません。 クラスターの `gp2` ストレージクラスを作成するには以下のステップを実行してください。 1. 次のコマンドを実行して、`gp2-storage-class.yaml` ファイルを作成します。 ``` cat >gp2-storage-class.yaml <