**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# Amazon EKS クラスターのライフサイクルと設定
このセクションでは、Kubernetes クラスターの完全なライフサイクル管理と、それらを設定するさまざまな方法に関する詳細なガイダンスを提供します。クラスターの作成、クラスターの状態のモニタリング、Kubernetes バージョンの更新、クラスターの削除について説明します。また、エンドポイントアクセスの設定、Windows サポートの有効化/無効化、プライベートクラスターの設定、自動スケールの実装、マルチ AZ セットアップでのトラフィックリダイレクトのゾーンシフトによる耐障害性を高める方法に関する高度なトピックも含まれています。
**Topics**
+ [Amazon EKS Auto Mode クラスターを作成する](create-cluster-auto.md)
+ [Amazon EKS クラスターを作成します。](create-cluster.md)
+ [Amazon EKS プロビジョンドコントロールプレーン](eks-provisioned-control-plane.md)
+ [Kubernetes バージョンアップグレードの準備およびクラスターインサイトでの設定ミスのトラブルシューティング](cluster-insights.md)
+ [既存のクラスターを新しい Kubernetes バージョンに更新する](update-cluster.md)
+ [クラスターを削除](delete-cluster.md)
+ [クラスター API サーバーエンドポイント](cluster-endpoint.md)
+ [EKS クラスターに WiWindows ノードをデプロイする](windows-support.md)
+ [Windows サポートを無効にする](disable-windows-support.md)
+ [インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)
+ [Karpenter と Cluster Autoscaler を使用したクラスターコンピューティングのスケーリング](autoscaling.md)
+ [Amazon EKS での Amazon Application Recovery Controller (ARC) のゾーンシフトの詳細](zone-shift.md)
+ [EKS ゾーンシフトを有効にしてアベイラビリティーゾーンの障害を回避する](zone-shift-enable.md)
# Amazon EKS Auto Mode クラスターを作成する
このトピックでは、高度な設定オプションを使用して Amazon EKS Auto Mode クラスターを作成する詳細な手順について説明します。前提条件、ネットワーキングオプション、アドオン設定を取り上げています。このプロセスには、IAM ロールの設定、クラスター設定の構成、ネットワーキングパラメータの指定、アドオンの選択が含まれます。ユーザーは、AWS マネジメントコンソールまたは AWS CLI のいずれかを使用してクラスターを作成でき、どちらの方法でもステップバイステップのガイダンスが付いています。
より複雑でないセットアッププロセスを求める場合は、クラスター作成手順の簡略化について以下を参照してください。
+ [eksctl CLI を使用して EKS Auto Mode クラスターを作成する](automode-get-started-eksctl.md)
+ [AWS CLI を使用して EKS Auto Mode クラスターを作成する](automode-get-started-cli.md)
+ [AWS マネジメントコンソール を使用して EKS Auto Mode クラスターを作成する](automode-get-started-console.md)
この高度な設定ガイドは、EKS Auto Mode クラスターのセットアップをより細かく制御する必要があり、Amazon EKS の概念と要件に精通しているユーザーを対象としています。高度な設定に進む前に、すべての前提条件を満たし、EKS Auto Mode クラスターのネットワーキングおよび IAM 要件を十分に理解してください。
EKS Auto Mode には、追加の IAM アクセス許可が必要です。詳細については、以下を参照してください。
+ [EKS Auto Mode クラスターの IAM ロール](automode-get-started-cli.md#auto-mode-create-roles)
+ [EKS Auto Mode での ID とアクセスについての説明](auto-learn-iam.md)
**注記**
EKS Auto Mode を使用せずにクラスターを作成する場合は、「[Amazon EKS クラスターを作成します。](create-cluster.md)」を参照してください。
このトピックでは、高度な設定を取り上げています。EKS Auto Mode を使用して開始する場合は、「[Amazon EKS 自動モードl クラスターを作成する](create-auto.md)」を参照してください。
## 前提条件
+ [Amazon EKS の要件](network-reqs.md) を満たす既存の VPC とサブネット。本番用にクラスターをデプロイする前に、VPC とサブネットの要件を十分に理解しておくことをお勧めします。VPC とサブネットがない場合は[Amazon EKS に用意されている AWS クラウドフォーメーション テンプレート](creating-a-vpc.md)を使用して作成できます。
+ デバイスまたは AWS クラウドシェル に、`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`」を参照してください。最新バージョンをインストールするには「*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)」を参照してください。
+ EKS および IAM リソースを作成および変更するアクセス許可を持つ [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)。
## クラスターの作成 - AWS コンソール
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. **[クラスターを追加]**、**[作成]** の順にクリックします。
1. *[設定オプション]* で **[カスタム設定]** を選択します。
+ このトピックでは、カスタム設定を取り上げています。クイック設定の詳細については、「[AWS マネジメントコンソール を使用して EKS Auto Mode クラスターを作成する](automode-get-started-console.md)」を参照してください。
1. **[EKS Auto Mode を使用する]** が有効になっていることを確認します。
+ このトピックでは、EKS Auto Mode でのクラスターの作成を取り上げています。EKS Auto Mode を使用せずにクラスターを作成する方法の詳細については、「[Amazon EKS クラスターを作成します。](create-cluster.md)」を参照してください。
1. **[クラスターの設定]** ページで、次のフィールドに入力します：
+ **[名前]** - クラスターの名前。この名前には英数字 (大文字と小文字が区別されます)、ハイフン、下線のみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前はクラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。
+ **[クラスター IAM ロール]** – ユーザーに代わって AWS リソースを管理することを Kubernetes コントロールプレーンに許可するために作成した Amazon EKS クラスター IAM ロールを選択します。EKS Auto Mode 用のクラスター IAM ロールをまだ作成していない場合は、IAM コンソールで **[推奨ロールを作成]** ボタンを選択して、必要なアクセス許可を持つロールを作成します。
+ **[Kubernetes バージョン]** – クラスターで使用する Kubernetes のバージョン。以前のバージョンが必要でない限り、最新バージョンを選択することをお勧めします。
+ **[アップグレードポリシー]** – クラスターに対して設定する Kubernetes バージョンポリシー。クラスターを標準サポートバージョンでのみ実行したい場合は、**[標準]** を選択できます。バージョンの標準サポート終了時にクラスターの延長サポートに入りたい場合は、**[延長]** を選択できます。現在延長サポートを利用中の Kubernetes バージョンを選択した場合、オプションとして標準サポートを選択することはできません。
1. [クラスターを設定] ページの **[Auto Mode コンピューティング]** セクションで、次のフィールドに入力します。
+ **ノードプール** – ノードプールでビルドを使用するかどうかを決定します。詳細については、「[組み込み NodePool を有効または無効にする](set-builtin-node-pools.md)」を参照してください。
+ **ノード IAM ロール** – 組み込みノードプールのいずれかを有効にする場合は、ノード IAM ロールを選択する必要があります。EKS Auto Mode は、このロールを新しいノードに割り当てます。クラスターの作成後はこの値を変更することはできません。EKS Auto Mode 用のノード IAM ロールをまだ作成していない場合は、[推奨ロールを作成] ボタンを選択して、必要なアクセス許可を持つロールを作成します。このロールの詳細については、「[EKS Auto Mode での ID とアクセスについての説明](auto-learn-iam.md)」を参照してください。
1. [クラスターの設定] ページの **[クラスターアクセス]** セクションで、次のフィールドに入力します。
+ **[クラスター管理者アクセスをブートストラップ]** – クラスター作成者は自動的に Kubernetes 管理者になります。これを無効にする場合は、**[クラスター管理者アクセスを拒否]** を選択します。
+ **[クラスター認証モード]** – EKS Auto Mode には、EKS アクセスエントリ、EKS API 認証モードが必要です。必要に応じて、**[EKS API と ConfigMap]** を選択して `ConfigMap` 認証モードを有効にできます。
1. 「クラスターの設定」ページの残りのフィールドに入力します。
+ **[Secret encryption]** (シークレット暗号化) – (オプション) KMS キーを使用して Kubernetes シークレットのシークレット暗号化を有効にするよう選択します。クラスターを作成した後で、これを有効にすることもできます。この機能を有効にする前に、[既存のクラスターで KMS を使用して Kubernetes シークレットを暗号化する](enable-kms.md) の情報をよく理解していることを確認してください。
+ **[ARC ゾーンシフト]** – EKS Auto Mode は ARC ゾーンシフトをサポートしていません。
+ **[タグ]** - (オプション) クラスターにタグを追加します。詳細については、「[タグを使用して Amazon EKS リソースを整理する](eks-using-tags.md)」を参照してください。
このページを読み終えたら、**[次へ]** を選択してください。
1. **[ネットワーキングの指定]** ページで、次のフィールドの値を選択してください：
+ **[VPC]** – [Amazon EKS VPC 要件](network-reqs.md#network-requirements-vpc)を満たす既存の VPC を選択し、そこでクラスターを作成します。VPC を選択する前に、「[VPC とサブネットの Amazon EKS ネットワーキング要件を表示する](network-reqs.md)」の要件と考慮事項をすべて理解しておくことをお勧めします。クラスターの作成後は使用する VPC を変更できません。VPC が表示されていない場合はまず作成する必要があります。詳細については「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」を参照してください。
+ **[サブネット]** - デフォルトで、前のフィールドで指定した VPC 内の利用可能なすべてのサブネットがあらかじめ選択されています。少なくとも 2 つ選択する必要があります。
選択するサブネットは [Amazon EKS サブネットの要件](network-reqs.md#network-requirements-subnets)を満たす必要があります。サブネットを選択する前に、[Amazon EKS VPC およびサブネットの要件と考慮事項](network-reqs.md)をすべて理解しておくことをお勧めします。
**[セキュリティグループ]** - (オプション Amazon EKS が作成するネットワークインターフェイスに関連付ける 1 つまたは複数のセキュリティグループを指定します。
セキュリティグループを選択するかどうかにかかわらず、Amazon EKS はクラスターと VPC 間の通信を可能にするセキュリティグループを作成します。Amazon EKS はこのセキュリティグループおよびユーザーが選択したセキュリティグループを、作成するネットワークインターフェイスに関連付けます。Amazon EKS が作成するクラスターセキュリティグループの詳細については「[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)」を参照してください。Amazon EKS が作成するクラスターセキュリティグループのルールを変更できます。
+ **クラスターの IP アドレスファミリーの選択** – **IPv4** と **IPv6** のどちらかを選択できます。
デフォルトで、Kubernetes は `IPv4` アドレスを Pod とサービスに割り当てます。`IPv6` ファミリーの使用を決定する前に、[VPC の要件と考慮事項](network-reqs.md#network-requirements-vpc)、[サブネットの要件と考慮事項](network-reqs.md#network-requirements-subnets)、[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)、および [クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md) のトピックの考慮事項と要件をすべて理解していることを確認します。`IPv6` ファミリーを選択すると、Kubernetes が `IPv6` サービスアドレスを割り当てる範囲を `IPv4` ファミリーで指定できるようには指定できません。Kubernetes は、一意のローカルアドレス範囲 (`fc00::/7`) からサービスにアドレスを割り当てます。
+ (オプション) **[Kubernetes サービス IP アドレスの範囲を設定する]** を選択し、**[サービスの `IPv4` 範囲]** を指定します。
独自の範囲を指定すると、Kubernetes サービスと VPC にピアリングまたは接続されたその他のネットワークとの間の競合を防ぐことができます。CIDR 表記で範囲を入力します。例: `10.2.0.0/16`。
この CIDR ブロックでは以下の要件を満たす必要があります：
+ `10.0.0.0/8`、`172.16.0.0/12`、または `192.168.0.0/16` のいずれかの範囲内にある。
+ 最小サイズが `/24`、最大サイズが `/12`。
+ Amazon EKS リソースの VPC の範囲と重複しない。
このオプションを指定できるのは`IPv4` アドレスファミリーを使用してクラスターを作成するときのみです。これを指定しない場合、Kubernetes は、`10.100.0.0/16` または `172.20.0.0/16` のいずれかの CIDR ブロックからサービス IP アドレスを割り当てます。
+ **[クラスターエンドポイントのアクセス]** で、オプションを選択してください。クラスターを作成した後で、このオプションを変更できます。デフォルト以外のオプションを選択する前に、オプションとその意味を理解しておいてください。詳細については「[クラスター API サーバーエンドポイント](cluster-endpoint.md)」を参照してください。
このページを読み終えたら、**[次へ]** を選択してください。
1. (オプション) **[オブザーバビリティの設定]** ページで、有効にする **[メトリクス]** と **[コントロールプレーンのロギング]** オプションを選択してください。デフォルトではそれぞれのログタイプは無効化されています。
+ Prometheus メトリクスの詳細については、「[ステップ 1: Prometheus メトリクスを有効にする](prometheus.md#turn-on-prometheus-metrics)」を参照してください。
+ **[トラフィック設定]** のオプションの詳細については「[コントロールプレーンログを CloudWatch Logs に送信する](control-plane-logs.md)」を参照してください。
+ このページを読み終えたら、**[次へ]** を選択してください。
1. **[アドオンの選択]** ページで、クラスターに追加するアドオンを選択してください。**[Amazon EKS アドオン]** と **[AWS マーケットプレイス アドオン]** は必要な数だけ選択できます。インストールする **AWS マーケットプレイス アドオン**がリストされていない場合はページ番号をクリックして追加のページ結果を表示するか、または検索ボックスにテキストを入力して使用可能な **AWS マーケットプレイス アドオン**を検索できます。**[カテゴリ]**、**[ベンダー]**、または **[料金モデル]** でフィルタリングして、検索結果からアドオンを選択することもできます。クラスターを作成する際に、「[EKS Pod Identity が Pod に AWS サービスへのアクセス権を付与する仕組みを学ぶ](pod-identities.md)」で詳述されているように、EKS ポッドアイデンティティー をサポートするアドオンを表示、選択、インストールできます。
+ EKS Auto Mode は、特定のアドオンの機能を自動化します。EKS Auto Mode クラスターに EKS マネージドノードグループをデプロイする場合は、**[追加の Amazon EKS アドオン]** を選択し、オプションを確認します。CoreDNS や kube-proxy などのアドオンをインストールすることが必要になる場合があります。EKS は、このセクションのアドオンをセルフマネージドノードとノードグループにのみインストールします。
+ このページを読み終えたら、**[次へ]** を選択してください。
1. **[選択したアドオン設定の構成]** ページで、インストールするバージョンを選択し、[次へ] を選択してください。クラスターを作成した後はいつでも新しいバージョンに更新できます。
EKS ポッドアイデンティティー をサポートするアドオンの場合、コンソールを使用して、アドオン専用に事前入力された名前、AWS マネージドポリシー、信頼ポリシーを使用してロールを自動的に生成できます。既存のロールを再利用したり、サポートされているアドオン用の新しいロールを作成したりできます。コンソールを使用して EKS ポッドアイデンティティー をサポートするアドオンのロールを作成するためのステップについては「[アドオンの作成 (AWS コンソール）](creating-an-add-on.md#create_add_on_console)」を参照してください。アドオンが EKS Pod Identity をサポートしていない場合、クラスターの作成後にウィザードを使用してサービスアカウント用の IAM ロール (IRSA 作成する手順を示すメッセージが表示されます。
クラスターの作成後に、各アドオンの設定を更新できます。アドオンの設定の詳細については「[Amazon EKS アドオンを更新する](updating-an-add-on.md)」を参照してください。このページを読み終えたら、**[次へ]** を選択してください。
1. **[確認と作成]** ページで、前のページで入力または選択した情報を確認します。変更する必要がある場合は**[編集]** を選択してください。そのままでよければ、**[作成]** を選択してください。クラスターがプロビジョニングされている間、**[ステータス]** フィールドに **[作成中]** と表示されます。
**注記**
リクエストで指定したアベイラビリティーゾーンのいずれかに、Amazon EKS クラスターの作成に十分な容量がない場合にはエラーが表示されることがあります。このエラー出力には新しいクラスターをサポートできるアベイラビリティーゾーンが表示されます。アカウント向けにサポートされているアベイラビリティーゾーンにある 2 つ以上のサブネットを使用して、クラスターを作成します。詳細については「[容量不足](troubleshooting.md#ice)」を参照してください。
クラスターのプロビジョニングには数分かかります。
## クラスターの作成 - AWS CLI
次の CLI の手順では、IAM リソースの作成とクラスターの作成について説明します。
### EKS Auto Mode クラスター IAM ロールを作成する
#### ステップ 1: 信頼ポリシーを作成する
Amazon EKS サービスがロールを引き受けることを許可する信頼ポリシーを作成します。ポリシーを `trust-policy.json` として保存します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
#### ステップ 2: IAM ロールを作成する
信頼ポリシーを使用して、クラスター IAM ロールを作成します。
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://trust-policy.json
```
#### ステップ 3: ロール ARN をメモする
以降のステップで使用する新しいロールの ARN を取得して保存します。
```
aws iam get-role --role-name AmazonEKSAutoClusterRole --query "Role.Arn" --output text
```
#### ステップ 4: 必要なポリシーをアタッチする
次の AWS マネージドポリシーをクラスター IAM ロールにアタッチして、必要なアクセス許可を付与します。
**AmazonEKSClusterPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
```
**AmazonEKSコンピュートポリシー**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSComputePolicy
```
**AmazonEKSブロックストレージポリシー**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**AmazonEKSロードバランシングポリシー**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**AmazonEKSNetworkingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSNetworkingPolicy
```
### EKS Auto Mode ノード IAM ロールを作成する
#### ステップ 1: 信頼ポリシーを作成する
Amazon EKS サービスがロールを引き受けることを許可する信頼ポリシーを作成します。ポリシーを `node-trust-policy.json` として保存します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
#### ステップ 2: ノード IAM ロールを作成する
前のステップの **node-trust-policy.json** ファイルを使用して、ロールを引き受けることができるエンティティを定義します。次のコマンドを実行してノード IAM ロールを作成します。
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
#### ステップ 3: ロール ARN をメモする
ロールを作成したら、ノード IAM ロールの ARN を取得して保存します。以降のステップでこの ARN が必要になります。次のコマンドを使用して ARN を取得します。
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
#### ステップ 4: 必要なポリシーをアタッチする
次の AWS マネージドポリシーをノード IAM ロールにアタッチして、必要なアクセス許可を付与します。
**AmazonEKSWorkerNodeMinimalPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
**AmazonEC2ContainerRegistryPullOnly**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
### クラスターを作成する
1. 下記のコマンドを使用して、クラスターを作成します。コマンドを実行する前に、次の置き換えを行います：
+ *地域コード* はクラスターを作成する AWS リージョンに置き換えます。
+ *マイクラスター* の部分は自分のクラスター名に置き換えます。この名前には英数字 (大文字と小文字が区別されます)、ハイフン、下線のみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前はクラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。
+ *1.30* を [Amazon EKS がサポートする任意のバージョン](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)に置き換えます。
+ *111122223333* は、自分のアカウント ID に置き換えます。
+ クラスターロールとノードロールに異なる名前の IAM ロールを作成した場合は、ARN を置き換えます。
+ `subnetIds` の値を独自の値に置き換えます。さらに ID を追加することもできます。少なくとも 2 つのサブネット ID を指定する必要があります。
選択するサブネットは [Amazon EKS サブネットの要件](network-reqs.md#network-requirements-subnets)を満たす必要があります。サブネットを選択する前に、[Amazon EKS VPC およびサブネットの要件と考慮事項](network-reqs.md)をすべて理解しておくことをお勧めします。
+ セキュリティグループ ID を指定しない場合はコマンドから `,securityGroupIds=sg-` を削除します。1 つまたは複数のセキュリティグループ ID を指定する場合は`securityGroupIds` の値を独自の値に置き換えます。さらに ID を追加することもできます。
セキュリティグループを選択するかどうかにかかわらず、Amazon EKS はクラスターと VPC 間の通信を可能にするセキュリティグループを作成します。Amazon EKS はこのセキュリティグループおよびユーザーが選択したセキュリティグループを、作成するネットワークインターフェイスに関連付けます。Amazon EKS が作成するクラスターセキュリティグループの詳細については「[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)」を参照してください。Amazon EKS が作成するクラスターセキュリティグループのルールを変更できます。
```
aws eks create-cluster \
--region region-code \
--name my-cluster \
--kubernetes-version 1.30 \
--role-arn arn:aws:iam::111122223333:role/AmazonEKSAutoClusterRole \
--resources-vpc-config '{"subnetIds": ["subnet-ExampleID1","subnet-ExampleID2"], "securityGroupIds": ["sg-ExampleID1"], "endpointPublicAccess": true, "endpointPrivateAccess": true}' \
--compute-config '{"enabled": true, "nodeRoleArn": "arn:aws:iam::111122223333:role/AmazonEKSAutoNodeRole", "nodePools": ["general-purpose", "system"]}' \
--kubernetes-network-config '{"elasticLoadBalancing": {"enabled": true}}' \
--storage-config '{"blockStorage": {"enabled": true}}' \
--access-config '{"authenticationMode": "API"}'
```
**注記**
リクエストで指定したアベイラビリティーゾーンのいずれかに、Amazon EKS クラスターの作成に十分な容量がない場合にはエラーが表示されることがあります。このエラー出力には新しいクラスターをサポートできるアベイラビリティーゾーンが表示されます。アカウント向けにサポートされているアベイラビリティーゾーンにある 2 つ以上のサブネットを使用して、クラスターを作成します。詳細については「[容量不足](troubleshooting.md#ice)」を参照してください。
必要に応じて前のコマンドに追加する必要があるオプションの設定を次に示します。これらのオプションは、クラスターの作成時にのみ有効にすることができ、作成後は有効にできません。
+ どの `IPv4` Classless Inter-domain Routing (CIDR) ブロックから Kubernetes がサービス IP アドレスを割り当てるかを指定する場合、`--kubernetes-network-config serviceIpv4Cidr=` を次のコマンドに追加することによって指定する必要があります。
独自の範囲を指定すると、Kubernetes サービスと VPC にピアリングまたは接続されたその他のネットワークとの間の競合を防ぐことができます。CIDR 表記で範囲を入力します。例: `10.2.0.0/16`。
この CIDR ブロックでは以下の要件を満たす必要があります：
+ `10.0.0.0/8`、`172.16.0.0/12`、または `192.168.0.0/16` のいずれかの範囲内にある。
+ 最小サイズが `/24`、最大サイズが `/12`。
+ Amazon EKS リソースの VPC の範囲と重複しない。
このオプションを指定できるのは`IPv4` アドレスファミリーを使用してクラスターを作成するときのみです。これを指定しない場合、Kubernetes は、`10.100.0.0/16` または `172.20.0.0/16` のいずれかの CIDR ブロックからサービス IP アドレスを割り当てます。
+ クラスターを作成していて、そのクラスターで `IPv4` アドレスではなく `IPv6` アドレスを Pod とサービスに割り当てるようにする場合は、次のコマンドに `--kubernetes-network-config ipFamily=ipv6` を追加します。
デフォルトで、Kubernetes は `IPv4` アドレスを Pod とサービスに割り当てます。`IPv6` ファミリーの使用を決定する前に、[VPC の要件と考慮事項](network-reqs.md#network-requirements-vpc)、[サブネットの要件と考慮事項](network-reqs.md#network-requirements-subnets)、[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)、および [クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md) のトピックの考慮事項と要件をすべて理解していることを確認します。`IPv6` ファミリーを選択すると、Kubernetes が `IPv6` サービスアドレスを割り当てる範囲を `IPv4` ファミリーで指定できるようには指定できません。Kubernetes は、一意のローカルアドレス範囲 (`fc00::/7`) からサービスにアドレスを割り当てます。
1. クラスターがプロビジョニングされるまでに数分かかります。クラスターのステータスのクエリを実行するには次のコマンドを使用します。
```
aws eks describe-cluster --region region-code --name my-cluster --query "cluster.status"
```
## 次のステップ
+ [kubeconfig ファイルを作成して kubectl を EKS クラスターに接続する](create-kubeconfig.md)
+ [EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する](access-entries.md)
+ [クラスターのシークレット暗号化を有効にする](enable-kms.md)。
+ [クラスターのログ記録を設定する](control-plane-logs.md)。
+ [クラスターにノードを追加する](eks-compute.md)。
# Amazon EKS クラスターを作成します。
**注記**
このトピックでは EKS 自動モードを使用しない Amazon EKS クラスターの作成を取り上げています。
EKS 自動モードl クラスターの詳細な作成手順については「[Amazon EKS Auto Mode クラスターを作成する](create-cluster-auto.md)」を参照してください。
EKS 自動モードl を使用して開始するには「[Amazon EKS – EKS Auto Mode の使用開始](getting-started-automode.md)」を参照してください。
このトピックでは使用可能なオプションの概要と、Amazon EKS クラスターの作成時に考慮すべき点を説明します。ノードのコンピューティングとしてオンプレミスインフラストラクチャを使用してクラスターを作成する必要がある場合は「[ハイブリッドノードを使用して Amazon EKS クラスターを作成する](hybrid-nodes-cluster-create.md)」を参照してください。Amazon EKS クラスターを初めて作成する場合は[Amazon EKS の使用を開始する](getting-started.md) のガイドのいずれかに従うことをお勧めします。これらのガイドは使用可能なすべてのオプションを展開することなく、シンプルでデフォルトのクラスターを作成するのに役立ちます。
## 前提条件
+ [Amazon EKS の要件](network-reqs.md) を満たす既存の VPC とサブネット。本番用にクラスターをデプロイする前に、VPC とサブネットの要件を十分に理解しておくことをお勧めします。VPC とサブネットがない場合は[Amazon EKS に用意されている AWS クラウドフォーメーション テンプレート](creating-a-vpc.md)を使用して作成できます。
+ デバイスまたは AWS クラウドシェル に、`kubectl` コマンドラインツールがインストールされていること。バージョンはご使用のクラスターの Kubernetes バージョンと同じか、1 つ前のマイナーバージョン以前、あるいはそれより新しいバージョンが使用できます。`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 プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)。詳細については[Outpost にローカル Kubernetes クラスターを作成する](security-iam-id-based-policy-examples.md#policy-create-local-cluster)および[すべてのクラスターの一覧表示または説明](security-iam-id-based-policy-examples.md#policy-example2)を参照してください。
## ステップ 1: クラスター IAM ロールを作成する
1. 既にクラスター IAM ロールがある場合、または `eksctl` を使用してクラスターを作成する場合はこのステップはスキップできます。デフォルトでは`eksctl` により、ロールが自動的に作成されます。
1. IAM 信頼ポリシー用の JSON ファイルを作成するには次のコマンドを実行してください。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Amazon EKS クラスターの IAM ロールを作成します。必要であれば、前のステップでファイルを書き込んだコンピュータ上のパスを *eks-cluster-role-trust-policy.json* の前につけます。このコマンドは前のステップで作成した信頼ポリシーをロールに関連付けます。IAM ロールを作成するにはロールを作成する [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)に `iam:CreateRole` アクション (許可) を割り当てる必要があります。
```
aws iam create-role --role-name myAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Amazon EKS 管理のポリシーを割り当てるか、独自のカスタムポリシーを作成できます。カスタムポリシーで使用する必要がある最小限の許可については「[Amazon EKS クラスター の IAM ロール](cluster-iam-role.md)」を参照してください。
[AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) という名前の 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/AmazonEKSClusterPolicy --role-name myAmazonEKSClusterRole
```
### サービスにリンクされたロール
Amazon EKS では､サービスにリンクされたロールが自動的に作成されます`AWSServiceRoleForAmazonEKS`。
これはクラスター IAM ロールに追加されます。サービスにリンクされたロールはAmazon EKS に直接リンクされた一意のタイプの IAM ロールです。このロールにより、Amazon EKS はアカウント内のクラスターを管理できます。詳細については「[Amazon EKS クラスターのロールの使用](using-service-linked-roles-eks.md)」を参照してください。
EKS クラスターの作成に使用する IAM アイデンティティには、サービスにリンクされたロールを作成するアクセス許可が必要です。これには `iam:CreateServiceLinkedRole` 権限が含まれます。
サービスにリンクされたロールがまだ存在せず、現在の IAM ロールに作成するための十分なアクセス許可がない場合、クラスター作成オペレーションは失敗します。
## ステップ 2: クラスターを作成する
以下を使用してクラスターを作成できます：
+ [`eksctl`](#step2-eksctl)
+ [の AWS マネジメントコンソール](#step2-console)
+ [AWS CLI](#step2-cli)
### クラスターを作成します - eksctl
1. デバイスまたは AWS クラウドシェル にインストールされている `eksctl` コマンドラインツールのバージョン `0.215.0` 以降が必要です。`eksctl` をインストールまたはアップグレードするには`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。
1. デフォルトの AWS リージョンに、Amazon EKS のデフォルト Kubernetes バージョンを使用して、Amazon EKS `IPv4` クラスターを作成します。コマンドを実行する前に、次の置き換えを行います：
1. *地域コード* はクラスターを作成する AWS リージョンに置き換えます。
1. *マイクラスター* の部分は自分のクラスター名に置き換えます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前はクラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。
1. *1.35* を [Amazon EKS がサポートする任意のバージョン](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)に置き換えます。
1. 要件を満たすように `vpc-private-subnets` の値を変更します。さらに ID を追加することもできます。少なくとも 2 つのサブネット ID を指定する必要があります。パブリックサブネットを指定する場合は`--vpc-private-subnets` を `--vpc-public-subnets` に変更できます。パブリックサブネットにはインターネットゲートウェイへのルートに関連付けられたルートテーブルがありますが、プライベートサブネットには関連付けられたルートテーブルがありません。可能な限り、プライベートサブネットを使用することをお勧めします。
選択するサブネットは [Amazon EKS サブネットの要件](network-reqs.md#network-requirements-subnets)を満たす必要があります。サブネットを選択する前に、[Amazon EKS VPC およびサブネットの要件と考慮事項](network-reqs.md)をすべて理解しておくことをお勧めします。
1. 次のコマンドを実行してください：
```
eksctl create cluster --name my-cluster --region region-code --version 1.35 --vpc-private-subnets subnet-ExampleID1,subnet-ExampleID2 --without-nodegroup
```
クラスターのプロビジョニングには数分かかります。クラスターの作成中は数行の出力が表示されます。出力の最後の行は次のサンプル行のようになります。
```
[✓] EKS cluster "my-cluster" in "region-code" region is ready
```
1. 「[ステップ 3: kubeconfig を更新する](#step3)」に進みます
#### オプション設定
`eksctl` を使用してクラスターを作成するときに指定できるほとんどのオプションを表示するには`eksctl create cluster --help` コマンドを使用します。使用可能なオプションをすべて表示するには`config` ファイルを使用します。詳細については「`eksctl` ドキュメント」の「[Using config files](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files)」(設定ファイルの使用） と「[設定ファイルのスキーマ](https://eksctl.io/usage/schema/)」を参照してください。[設定ファイルの例](https://github.com/weaveworks/eksctl/tree/master/examples)は、GitHub で見つけることができます。
必要に応じて前のコマンドに追加する必要があるオプションの設定を次に示します。これらのオプションはクラスターの作成時にのみ有効にすることができ、作成後は有効にできません。これらのオプションを指定する必要がある場合は前のコマンドを使用するのではなく、[eksctl config ファイル](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files)を使用してクラスターを作成し、設定を指定する必要があります。
+ Amazon EKS が作成するネットワークインターフェイスに割り当てる 1 つまたは複数のセキュリティグループを指定する場合は[securityGroup](https://eksctl.io/usage/schema/#vpc-securityGroup) オプションを指定します。
セキュリティグループを選択するかどうかにかかわらず、Amazon EKS はクラスターと VPC 間の通信を可能にするセキュリティグループを作成します。Amazon EKS はこのセキュリティグループおよびユーザーが選択したセキュリティグループを、作成するネットワークインターフェイスに関連付けます。Amazon EKS が作成するクラスターセキュリティグループの詳細については「[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)」を参照してください。Amazon EKS が作成するクラスターセキュリティグループのルールを変更できます。
+ どの `IPv4` Classless Inter-domain Routing (CIDR) ブロックから Kubernetes がサービス IP アドレスを割り当てるかを指定する場合、[serviceIPv4CIDR](https://eksctl.io/usage/schema/#kubernetesNetworkConfig-serviceIPv4CIDR) オプションを指定します。
独自の範囲を指定すると、Kubernetes サービスと VPC にピアリングまたは接続されたその他のネットワークとの間の競合を防ぐことができます。CIDR 表記で範囲を入力します。例: `10.2.0.0/16`。
この CIDR ブロックでは以下の要件を満たす必要があります：
+ `10.0.0.0/8`、`172.16.0.0/12`、または `192.168.0.0/16` のいずれかの範囲内にある。
+ 最小サイズが `/24`、最大サイズが `/12`。
+ Amazon EKS リソースの VPC の範囲と重複しない。
このオプションを指定できるのは`IPv4` アドレスファミリーを使用してクラスターを作成するときのみです。これを指定しない場合、Kubernetes は、`10.100.0.0/16` または `172.20.0.0/16` のいずれかの CIDR ブロックからサービス IP アドレスを割り当てます。
+ クラスターを作成していて、そのクラスターで `IPv4` アドレスではなく `IPv6` アドレスを Pod とサービスに割り当てるようにする場合は、[ipFamily](https://eksctl.io/usage/schema/#kubernetesNetworkConfig-ipFamily) オプションを指定します。
デフォルトで、Kubernetes は `IPv4` アドレスを Pod とサービスに割り当てます。`IPv6` ファミリーの使用を決定する前に、「[VPC の要件と考慮事項](network-reqs.md#network-requirements-vpc)」、「[サブネットの要件と考慮事項](network-reqs.md#network-requirements-subnets)」、「[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)」、および「[クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md)」のトピックの考慮事項と要件をすべて理解していることを確認します。`IPv6` ファミリーを選択すると、Kubernetes が `IPv6` サービスアドレスを割り当てる範囲を `IPv4` ファミリーで指定できるようには指定できません。Kubernetes は、一意のローカルアドレス範囲 (`fc00::/7`) からサービスにアドレスを割り当てます。
### クラスターの作成 - AWS コンソール
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. **[クラスターを追加]**、**[作成]** の順にクリックします。
1. **[設定オプション]** で **[カスタム設定]** を選択してください。
+ EKS 自動モードl でクラスターをすばやく作成する方法については「[AWS マネジメントコンソール を使用して EKS Auto Mode クラスターを作成する](automode-get-started-console.md)」を参照してください。
1. **[EKS 自動モードl]** で、**[EKS 自動モードl を使用する]** をオフに切り替えます。
+ カスタム設定で EKS 自動モードl クラスターを作成する方法については「[Amazon EKS Auto Mode クラスターを作成する](create-cluster-auto.md)」を参照してください。
1. **[クラスターの設定]** ページで、次のフィールドに入力します：
+ **[名前]** - クラスターの名前。この名前には英数字 (大文字と小文字が区別されます)、ハイフン、下線のみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前はクラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。
+ **[クラスター IAM ロール]** – ユーザーに代わって AWS リソースを管理することを Kubernetes コントロールプレーンに許可するために作成した Amazon EKS クラスター IAM ロールを選択します。
+ **[Kubernetes バージョン]** – クラスターで使用する Kubernetes のバージョン。以前のバージョンが必要でない限り、最新バージョンを選択することをお勧めします。
+ **[サポートタイプ]** — クラスターに設定する Kubernetes バージョンポリシー。クラスターを標準サポートバージョンでのみ実行する場合は**[標準サポート]** を選択できます。バージョンの標準サポート終了時にクラスターで延長サポートに入る場合は**[延長サポート]** を選択できます。現在延長サポートを利用中の Kubernetes バージョンを選択した場合、オプションとして標準サポートを選択することはできません。
+ **[Secret encryption]** (シークレット暗号化) – (オプション) KMS キーを使用して Kubernetes シークレットのシークレット暗号化を有効にするよう選択します。クラスターを作成した後で、これを有効にすることもできます。この機能を有効にする前に、[既存のクラスターで KMS を使用して Kubernetes シークレットを暗号化する](enable-kms.md) の情報をよく理解していることを確認してください。
+ **[タグ]** - (オプション) クラスターにタグを追加します。詳細については「[タグを使用して Amazon EKS リソースを整理する](eks-using-tags.md)」を参照してください。
+ **[ARC ゾーンシフト]** – (任意 Route53 アプリケーションリカバリコントローラー を使用して、アベイラビリティーゾーンの障害を軽減できます。詳細については「[Amazon EKS での Amazon Application Recovery Controller (ARC) のゾーンシフトの詳細](zone-shift.md)」を参照してください。
1. [クラスターの設定] ページの **[クラスターアクセス]** セクションで、次のフィールドに入力します：
+ **[クラスター管理者アクセスをブートストラップ]** – クラスター作成者は自動的に Kubernetes 管理者になります。これを無効にする場合は**[クラスター管理者アクセスを拒否]** を選択してください。
+ **[クラスター認証モード]** – IAM ユーザーおよびロールに Kubernetes API へのアクセスを許可する方法を決定します。詳細については「[クラスター認証モードを設定する](grant-k8s-access.md#set-cam)」を参照してください。
このページを読み終えたら、**[次へ]** を選択してください。
1. **[ネットワーキングの指定]** ページで、次のフィールドの値を選択してください：
+ **[VPC]** – [Amazon EKS VPC 要件](network-reqs.md#network-requirements-vpc)を満たす既存の VPC を選択し、そこでクラスターを作成します。VPC を選択する前に、「[VPC とサブネットの Amazon EKS ネットワーキング要件を表示する](network-reqs.md)」の要件と考慮事項をすべて理解しておくことをお勧めします。クラスターの作成後は使用する VPC を変更できません。VPC が表示されていない場合はまず作成する必要があります。詳細については「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」を参照してください。
+ **[サブネット]** - デフォルトで、前のフィールドで指定した VPC 内の利用可能なすべてのサブネットがあらかじめ選択されています。少なくとも 2 つ選択する必要があります。
選択するサブネットは [Amazon EKS サブネットの要件](network-reqs.md#network-requirements-subnets)を満たす必要があります。サブネットを選択する前に、[Amazon EKS VPC およびサブネットの要件と考慮事項](network-reqs.md)をすべて理解しておくことをお勧めします。
**[セキュリティグループ]** - (オプション Amazon EKS が作成するネットワークインターフェイスに関連付ける 1 つまたは複数のセキュリティグループを指定します。
セキュリティグループを選択するかどうかにかかわらず、Amazon EKS はクラスターと VPC 間の通信を可能にするセキュリティグループを作成します。Amazon EKS はこのセキュリティグループおよびユーザーが選択したセキュリティグループを、作成するネットワークインターフェイスに関連付けます。Amazon EKS が作成するクラスターセキュリティグループの詳細については「[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)」を参照してください。Amazon EKS が作成するクラスターセキュリティグループのルールを変更できます。
+ **クラスターの IP アドレスファミリーの選択** – **IPv4** と **IPv6** のどちらかを選択できます。
デフォルトで、Kubernetes は `IPv4` アドレスを Pod とサービスに割り当てます。`IPv6` ファミリーの使用を決定する前に、[VPC の要件と考慮事項](network-reqs.md#network-requirements-vpc)、[サブネットの要件と考慮事項](network-reqs.md#network-requirements-subnets)、[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)、および [クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md) のトピックの考慮事項と要件をすべて理解していることを確認します。`IPv6` ファミリーを選択すると、Kubernetes が `IPv6` サービスアドレスを割り当てる範囲を `IPv4` ファミリーで指定できるようには指定できません。Kubernetes は、一意のローカルアドレス範囲 (`fc00::/7`) からサービスにアドレスを割り当てます。
+ (オプション) **[Kubernetes サービス IP アドレスの範囲を設定する]** を選択し、**[サービスの `IPv4` 範囲]** を指定します。
独自の範囲を指定すると、Kubernetes サービスと VPC にピアリングまたは接続されたその他のネットワークとの間の競合を防ぐことができます。CIDR 表記で範囲を入力します。例: `10.2.0.0/16`。
この CIDR ブロックでは以下の要件を満たす必要があります：
+ `10.0.0.0/8`、`172.16.0.0/12`、または `192.168.0.0/16` のいずれかの範囲内にある。
+ 最小サイズが `/24`、最大サイズが `/12`。
+ Amazon EKS リソースの VPC の範囲と重複しない。
このオプションを指定できるのは`IPv4` アドレスファミリーを使用してクラスターを作成するときのみです。これを指定しない場合、Kubernetes は、`10.100.0.0/16` または `172.20.0.0/16` のいずれかの CIDR ブロックからサービス IP アドレスを割り当てます。
+ **[クラスターエンドポイントのアクセス]** で、オプションを選択してください。クラスターを作成した後で、このオプションを変更できます。デフォルト以外のオプションを選択する前に、オプションとその意味を理解しておいてください。詳細については「[クラスター API サーバーエンドポイント](cluster-endpoint.md)」を参照してください。
このページを読み終えたら、**[次へ]** を選択してください。
1. (オプション) **[オブザーバビリティの設定]** ページで、有効にする **[メトリクス]** と **[コントロールプレーンのロギング]** オプションを選択してください。デフォルトではそれぞれのログタイプは無効化されています。
+ Prometheus メトリクスの詳細については、「[ステップ 1: Prometheus メトリクスを有効にする](prometheus.md#turn-on-prometheus-metrics)」を参照してください。
+ **[トラフィック設定]** のオプションの詳細については「[コントロールプレーンログを CloudWatch Logs に送信する](control-plane-logs.md)」を参照してください。
このページを読み終えたら、**[次へ]** を選択してください。
1. **[アドオンの選択]** ページで、クラスターに追加するアドオンを選択してください。特定のアドオンが事前に選択されています。**[Amazon EKS アドオン]** と **[AWS マーケットプレイス アドオン]** は必要な数だけ選択できます。インストールする **AWS マーケットプレイス アドオン**がリストされていない場合はページ番号をクリックして追加のページ結果を表示するか、または検索ボックスにテキストを入力して使用可能な **AWS マーケットプレイス アドオン**を検索できます。**[カテゴリ]**、**[ベンダー]**、または **[料金モデル]** でフィルタリングして、検索結果からアドオンを選択することもできます。クラスターを作成する際に、「[EKS Pod Identity が Pod に AWS サービスへのアクセス権を付与する仕組みを学ぶ](pod-identities.md)」で詳述されているように、EKS ポッドアイデンティティー をサポートするアドオンを表示、選択、インストールできます。
このページを読み終えたら、**[次へ]** を選択してください。
Amazon VPC CNI、CoreDNS、kube-proxy などの一部のアドオンはデフォルトでインストールされます。デフォルトのアドオンのいずれかを無効にすると、Kubernetes アプリケーションを実行する機能に影響する場合があります。
1. **[選択したアドオン設定の構成]** ページで、インストールするバージョンを選択し、[次へ] を選択してください。クラスターを作成した後はいつでも新しいバージョンに更新できます。
EKS ポッドアイデンティティー をサポートするアドオンの場合、コンソールを使用して、アドオン専用に事前入力された名前、AWS マネージドポリシー、信頼ポリシーを使用してロールを自動的に生成できます。既存のロールを再利用したり、サポートされているアドオン用の新しいロールを作成したりできます。コンソールを使用して EKS ポッドアイデンティティー をサポートするアドオンのロールを作成するためのステップについては「[アドオンの作成 (AWS コンソール）](creating-an-add-on.md#create_add_on_console)」を参照してください。アドオンが EKS Pod Identity をサポートしていない場合、クラスターの作成後にウィザードを使用してサービスアカウント用の IAM ロール (IRSA 作成する手順を示すメッセージが表示されます。
クラスターの作成後に、各アドオンの設定を更新できます。アドオンの設定の詳細については「[Amazon EKS アドオンを更新する](updating-an-add-on.md)」を参照してください。このページを読み終えたら、**[次へ]** を選択してください。
1. **[確認と作成]** ページで、前のページで入力または選択した情報を確認します。変更する必要がある場合は**[編集]** を選択してください。そのままでよければ、**[作成]** を選択してください。クラスターがプロビジョニングされている間、**[ステータス]** フィールドに **[作成中]** と表示されます。
**注記**
リクエストで指定したアベイラビリティーゾーンのいずれかに、Amazon EKS クラスターの作成に十分な容量がない場合にはエラーが表示されることがあります。このエラー出力には新しいクラスターをサポートできるアベイラビリティーゾーンが表示されます。アカウント向けにサポートされているアベイラビリティーゾーンにある 2 つ以上のサブネットを使用して、クラスターを作成します。詳細については「[容量不足](troubleshooting.md#ice)」を参照してください。
クラスターのプロビジョニングには数分かかります。
1. 「[ステップ 3: kubeconfig を更新する](#step3)」に進みます
### クラスターの作成 - AWS CLI
1. 下記のコマンドを使用して、クラスターを作成します。コマンドを実行する前に、次の置き換えを行います：
+ *地域コード* はクラスターを作成する AWS リージョンに置き換えます。
+ *マイクラスター* の部分は自分のクラスター名に置き換えます。この名前には英数字 (大文字と小文字が区別されます)、ハイフン、下線のみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前はクラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。
+ *1.35* を [Amazon EKS がサポートする任意のバージョン](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)に置き換えます。
+ *111122223333* をアカウント ID に、*myAmazonEKSClusterRole* をクラスター IAM ロールの名前に置き換えます。
+ `subnetIds` の値を独自の値に置き換えます。さらに ID を追加することもできます。少なくとも 2 つのサブネット ID を指定する必要があります。
選択するサブネットは [Amazon EKS サブネットの要件](network-reqs.md#network-requirements-subnets)を満たす必要があります。サブネットを選択する前に、[Amazon EKS VPC およびサブネットの要件と考慮事項](network-reqs.md)をすべて理解しておくことをお勧めします。
+ セキュリティグループ ID を指定しない場合はコマンドから `,securityGroupIds=sg-` を削除します。1 つまたは複数のセキュリティグループ ID を指定する場合は`securityGroupIds` の値を独自の値に置き換えます。さらに ID を追加することもできます。
セキュリティグループを選択するかどうかにかかわらず、Amazon EKS はクラスターと VPC 間の通信を可能にするセキュリティグループを作成します。Amazon EKS はこのセキュリティグループおよびユーザーが選択したセキュリティグループを、作成するネットワークインターフェイスに関連付けます。Amazon EKS が作成するクラスターセキュリティグループの詳細については「[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)」を参照してください。Amazon EKS が作成するクラスターセキュリティグループのルールを変更できます。
```
aws eks create-cluster --region region-code --name my-cluster --kubernetes-version 1.35 \
--role-arn arn:aws:iam::111122223333:role/myAmazonEKSClusterRole \
--resources-vpc-config subnetIds=subnet-ExampleID1,subnet-ExampleID2,securityGroupIds=sg-ExampleID1
```
**注記**
リクエストで指定したアベイラビリティーゾーンのいずれかに、Amazon EKS クラスターの作成に十分な容量がない場合にはエラーが表示されることがあります。このエラー出力には新しいクラスターをサポートできるアベイラビリティーゾーンが表示されます。アカウント向けにサポートされているアベイラビリティーゾーンにある 2 つ以上のサブネットを使用して、クラスターを作成します。詳細については「[容量不足](troubleshooting.md#ice)」を参照してください。
必要に応じて前のコマンドに追加する必要があるオプションの設定を次に示します。これらのオプションはクラスターの作成時にのみ有効にすることができ、作成後は有効にできません。
+ デフォルトではEKS はクラスターの作成時に複数のネットワーキングアドオンをインストールします。これには Amazon VPC CNI、CoreDNS、kube-proxy が含まれます。
これらのデフォルトのネットワーキングアドオンのインストールを無効にする場合は以下のパラメータを使用します。これはCilium などの代替 CNI に使用できます。詳細については「[EKS API リファレンス](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html)」を参照してください。
`aws eks create-cluster --no-bootstrap-self-managed-addons …`
+ どの `IPv4` Classless Inter-domain Routing (CIDR) ブロックから Kubernetes がサービス IP アドレスを割り当てるかを指定する場合、`--kubernetes-network-config serviceIpv4Cidr=` を次のコマンドに追加することによって指定する必要があります。
独自の範囲を指定すると、Kubernetes サービスと VPC にピアリングまたは接続されたその他のネットワークとの間の競合を防ぐことができます。CIDR 表記で範囲を入力します。例: `10.2.0.0/16`。
この CIDR ブロックでは以下の要件を満たす必要があります：
+ `10.0.0.0/8`、`172.16.0.0/12`、または `192.168.0.0/16` のいずれかの範囲内にある。
+ 最小サイズが `/24`、最大サイズが `/12`。
+ Amazon EKS リソースの VPC の範囲と重複しない。
このオプションを指定できるのは`IPv4` アドレスファミリーを使用してクラスターを作成するときのみです。これを指定しない場合、Kubernetes は、`10.100.0.0/16` または `172.20.0.0/16` のいずれかの CIDR ブロックからサービス IP アドレスを割り当てます。
+ クラスターを作成していて、そのクラスターで `IPv4` アドレスではなく `IPv6` アドレスを Pod とサービスに割り当てるようにする場合は、次のコマンドに `--kubernetes-network-config ipFamily=ipv6` を追加します。
デフォルトで、Kubernetes は `IPv4` アドレスを Pod とサービスに割り当てます。`IPv6` ファミリーの使用を決定する前に、[VPC の要件と考慮事項](network-reqs.md#network-requirements-vpc)、[サブネットの要件と考慮事項](network-reqs.md#network-requirements-subnets)、[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)、および [クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md) のトピックの考慮事項と要件をすべて理解していることを確認します。`IPv6` ファミリーを選択すると、Kubernetes が `IPv6` サービスアドレスを割り当てる範囲を `IPv4` ファミリーで指定できるようには指定できません。Kubernetes は、一意のローカルアドレス範囲 (`fc00::/7`) からサービスにアドレスを割り当てます。
1. クラスターがプロビジョニングされるまでに数分かかります。クラスターのステータスのクエリを実行するには次のコマンドを使用します。
```
aws eks describe-cluster --region region-code --name my-cluster --query "cluster.status"
```
出力が「`ACTIVE`」を返すまで、次のステップに進まないでください。
1. 「[ステップ 3: kubeconfig を更新する](#step3)」に進みます
## ステップ 3: kubeconfig を更新する
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. 次のコマンドを実行して、クラスターとの通信を確認します。
```
kubectl get svc
```
出力例は次のとおりです。
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.100.0.1 443/TCP 28h
```
## ステップ 4: クラスターのセットアップ
1. (推奨) Amazon EKS アドオンを使用するか、固有の AWS Identity and Access Management (IAM) アクセス許可を個々の Kubernetes ワークロードに付与できるようにするには、クラスター用に [IAM OpenID Connect (OIDC) プロバイダーを作成](enable-iam-roles-for-service-accounts.md)します。クラスター用に IAM OIDC プロバイダーを作成する必要があるのは 1 回だけです。Amazon EKS アドオンの詳細については「[Amazon EKS アドオン](eks-add-ons.md)」を参照してください。ワークロードに特定の IAM アクセス許可を割り当てる方法については「[サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md)」を参照してください。
1. (推奨) Amazon EC2 ノードをクラスターにデプロイする前に Amazon VPC CNI plugin for Kubernetes プラグイン用にクラスターを設定します。デフォルトではプラグインはクラスターとともにインストールされています。Amazon EC2 ノードをクラスターに追加すると、プラグインは追加する各 Amazon EC2 ノードに自動的にデプロイされます。プラグインでは次の IAM ポリシーのいずれかを IAM ロールにアタッチする必要があります。クラスターが `IPv4` ファミリーを使用する場合は[AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) マネージド IAM ポリシーを使用します。クラスターが `IPv6` ファミリーを使用している場合、[自ら作成した IAM ポリシー](cni-iam-role.md#cni-iam-role-create-ipv6-policy)を使用します。
ポリシーをアタッチする IAM ロールはノード IAM ロール、またはプラグインにのみ使用される専用ロールです。このロールにポリシーをアタッチすることをお勧めします。ロールの作成の詳細については「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」または「[Amazon EKS ノードの IAM ロール](create-node-role.md)」を参照してください。
1. AWS マネジメントコンソール を使用してクラスターをデプロイした場合、このステップはスキップできます。AWS マネジメントコンソールでは、デフォルトで、Amazon VPC CNI plugin for Kubernetes、CoreDNS、および `kube-proxy` Amazon EKS アドオンがデプロイされます。
`eksctl` または AWS CLI のいずれかを使用してクラスターをデプロイする場合、Amazon VPC CNI plugin for Kubernetes、CoreDNS、および `kube-proxy` セルフマネージド型アドオンがデプロイされます。クラスターと共に Amazon EKS アドオンにデプロイされる、Amazon VPC CNI plugin for Kubernetes、CoreDNS、および `kube-proxy` セルフマネージド型アドオンを移行できます。詳細については、「[Amazon EKS アドオン](eks-add-ons.md)」を参照してください。
1. (オプション) まだ作成していない場合は、クラスターの Prometheus メトリクスを有効にできます。詳細については「Amazon Managed Service for Prometheus ユーザーガイド」の「[スクレイパーの作成](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-create)」を参照してください。
1. Amazon EBS ボリュームを使用するクラスターにワークロードをデプロイする予定の場合、ワークロードをデプロイする前に、[Amazon EBS CSI](ebs-csi.md) をクラスターにインストールする必要があります。
## 次のステップ
+ クラスターを作成した [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)はクラスターにアクセスできる唯一のプリンシパルです。[他の IAM プリンシパルに許可を付与](grant-k8s-access.md)して、クラスターにアクセスできるようにします。
+ クラスターを作成した IAM プリンシパルが、前提条件で参照されている最低限の IAM 許可しか持たない場合、そのプリンシパルに Amazon EKS 許可を追加することができます。Amazon EKS 許可を IAM プリンシパルに付与する方法については「[Amazon EKS の Identity and Access Management](security-iam.md)」を参照してください。
+ クラスターを作成した IAM プリンシパル、またはその他のプリンシパルに Amazon EKS コンソールで Kubernetes リソースを表示させる場合は、[必要なアクセス許可](view-kubernetes-resources.md#view-kubernetes-resources-permissions)をエンティティに付与します。
+ ノードと IAM プリンシパルが VPC 内からクラスターにアクセスできるようにする場合、クラスターのプライベートエンドポイントを有効にします。デフォルトではパブリックエンドポイントは有効です。プライベートエンドポイントを有効にした後、必要に応じてパブリックエンドポイントを無効にできます。詳細については「[クラスター API サーバーエンドポイント](cluster-endpoint.md)」を参照してください。
+ [クラスターのシークレット暗号化を有効にする](enable-kms.md)。
+ [クラスターのログ記録を設定する](control-plane-logs.md)。
+ [クラスターにノードを追加する](eks-compute.md)。
# Amazon EKS プロビジョンドコントロールプレーン
## 概要:
Amazon EKS プロビジョンドコントロールプレーンは、クラスター管理者が一連のスケーリング階層から選択し、選択した階層を指定して、クラスターのコントロールプレーンから非常に高く予測可能なパフォーマンスを実現できるようにする機能です。これにより、クラスター管理者は、コントロールプレーンが常に指定された容量でプロビジョニングされるようにできます。
Amazon EKS には、クラスターのコントロールプレーン用に 2 つのオペレーションモードが用意されています。デフォルトでは、Amazon EKS クラスターは**スタンダードモード**を使用します。このモードでは、コントロールプレーンはワークロードの需要に応じて自動的にスケールアップおよびスケールダウンします。スタンダードモードでは、ワークロードのニーズを満たすのに十分なコントロールプレーン容量が動的に割り当てられ、ほとんどのユースケースで推奨されるソリューションです。ただし、コントロールプレーンのスケーリングによるパフォーマンスの変動を一切許容できない特殊なワークロードや、非常に大量のコントロールプレーン容量を必要とするワークロードの場合は、オプションで**プロビジョンドモード**を使用できます。プロビジョンドモードでは、要求の厳しいワークロード要件に常に対応できるコントロールプレーン容量を事前に割り当てることができます。
**注記**
プロビジョンドモードは、デフォルトのスタンダードモードと共に追加のコントロールプレーンオペレーションモードです。プロビジョンドモードを導入しても、スタンダードモードの動作は変わりません。
EKS プロビジョンドコントロールプレーンを使用すると、クラスター管理者は必要なコントロールプレーン容量を事前にプロビジョニングできるため、常に利用可能なクラスターのコントロールプレーンから予測可能で高いパフォーマンスが得られます。また、EKS プロビジョンドコントロールプレーンは、ステージングから本番稼働、ディザスタリカバリサイトまで、環境間で同じコントロールプレーン容量をクラスター管理者がプロビジョニングできるようにします。これは、環境間で得られるコントロールプレーンのパフォーマンスに一貫性があり、予測可能であることを確実にするために重要なことです。最後に、EKS プロビジョンドコントロールプレーンでは、非常に高いレベルのコントロールプレーンパフォーマンスにアクセスできるため、Kubernetes で非常にスケーラブルな AI ワークロード、高性能コンピューティング、大規模なデータ処理ワークロードを実行できます。
既存および新規の Amazon EKS クラスターはすべて、デフォルトでスタンダードモードで動作します。コントロールプレーンから高い予測可能なパフォーマンスを必要とするクラスターでは、EKS プロビジョンドコントロールプレーン機能の使用をオプトインできます。標準または延長サポートの EKS 時間単位料金に加えて、特定のコントロールプレーンのスケーリング階層に対する時間単位料金が請求されます。料金に関する詳細については、「[Amazon EKS の料金](https://aws.amazon.com/eks/pricing/)」を参照してください。
![\[Amazon EKS コントロールプレーンモード\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/control-plane-modes.png)
## ユースケース
EKS プロビジョンドコントロールプレーンは、高い予測可能なコントロールプレーンのパフォーマンスがオペレーションにとって重要な特定のシナリオに対処するように設計されています。これらのユースケースを理解することで、EKS プロビジョンドコントロールプレーンがワークロードに適したソリューションかどうかを判断できます。
**パフォーマンスクリティカルなワークロード** – Kubernetes コントロールプレーンから最小のレイテンシーと最大のパフォーマンスを必要とするワークロードの場合、EKS プロビジョンドコントロールプレーンは、コントロールプレーンのスケーリングによるパフォーマンスの変動を排除する容量を提供します。
**大規模にスケーラブルなワークロード** – AI トレーニングや推論、高性能コンピューティング、大規模なデータ処理など、クラスターで実行されている多数のノードを必要とする非常にスケーラブルなワークロードを実行する場合、プロビジョンドコントロールプレーンは、これらの要求の厳しいワークロードをサポートするために必要なコントロールプレーン容量を提供します。
**予想される需要の高いイベント** – e コマースの販売やプロモーション、製品の発売、ホリデーシーズンのショッピング、スポーツやエンターテインメントの大規模なイベントなど、今後のイベントが原因でコントロールプレーンのリクエストが急増すると予想される場合、プロビジョンドコントロールプレーンでは、コントロールプレーンの容量を事前にスケールできます。このプロアクティブアプローチにより、自動スケーリングが需要に応答するのを待たずに、増加した負荷をコントロールプレーンが処理できるようになります。
**環境の一貫性** – プロビジョンドコントロールプレーンを使用すると、ステージング環境と本番稼働環境間でコントロールプレーンの容量とパフォーマンスを照合できるため、本番稼働環境へのデプロイ前に潜在的な問題を特定できます。環境間で同じコントロールプレーン層を維持することで、テスト結果に本番稼働の動作を正確に反映し、ロールアウト中に発生するパフォーマンス関連の予期しない問題のリスクを減らすことができます。
**ディザスタリカバリと事業継続性** – ディザスタリカバリのシナリオでは、プロビジョンドコントロールプレーンを使用すると、プライマリ環境と同じレベルの容量でフェイルオーバー環境をプロビジョニングできます。これにより、ディザスタリカバリクラスターは、アクティブ化された瞬間から本番稼働クラスターと同じコントロールプレーンのパフォーマンス特性を持つため、フェイルオーバーイベント中の中断を最小限に抑え、迅速な復旧が可能になります。
## コントロールプレーンのスケーリング階層
EKS プロビジョンドコントロールプレーンは、T シャツサイズ (XL、2XL、4XL、8XL) で命名されたスケーリング階層を提供します。各階層は、クラスターのコントロールプレーンのパフォーマンス特性を決定する 3 つの主要な Kubernetes 属性によって容量を定義します。これらの属性を理解することで、ワークロード要件に適した階層を選択できます。
**API リクエスト同時実行数**は、Kubernetes コントロールプレーンの API サーバーが同時に処理できるリクエストの数を測定します。これは、高スループットワークロードにとって重要です。
**ポッドスケジューリングレート**は、デフォルトの Kubernetes スケジューラがノードでポッドをスケジュールできる速度を示し、1 秒あたりのポッド数で測定されます。
**クラスターデータベースのサイズ**は、クラスターの状態/メタデータを保持するデータベースである etcd に割り当てられたストレージ領域を示します。
プロビジョンドコントロールプレーンを使用して特定のスケーリング階層でクラスターのコントロールプレーンをプロビジョニングすると、EKS はクラスターのコントロールプレーンがその階層に対応する制限を維持するようにします。コントロールプレーンのスケーリング階層の制限は、次の表に示すように、Kubernetes のバージョンによって異なります。
### EKS v1.28 および v1.29
| プロビジョンドコントロールプレーンのスケーリング階層 | API リクエスト同時実行数 (同時実行枠) | ポッドスケジューリングレート (ポッド/秒) | クラスターデータベースサイズ (GB) |
| --- | --- | --- | --- |
| XL | 1700 | 100 | 16 |
| 2XL | 3400 | 100 | 16 |
| 4XL | 6800 | 100 | 16 |
| 8XL | 13600 | 100 | 16 |
### EKS v1.30 以降
| プロビジョンドコントロールプレーンのスケーリング階層 | API リクエスト同時実行数 (同時実行枠) | ポッドスケジューリングレート (ポッド/秒) | クラスターデータベースサイズ (GB) |
| --- | --- | --- | --- |
| XL | 1700 | 167 | 16 |
| 2XL | 3400 | 283 | 16 |
| 4XL | 6800 | 400 | 16 |
| 8XL | 13600 | 400 | 16 |
### コントロールプレーンのスケーリング階層の使用率のモニタリング
Amazon EKS には、コントロールプレーンの階層使用率のモニタリングに役立つメトリクスがいくつか用意されています。これらのメトリクスは [Amazon CloudWatch メトリクス](cloudwatch.md)として公開されており、CloudWatch および EKS コンソールからアクセスできます。さらに、これらのメトリクスは EKS クラスターの Prometheus エンドポイントからスクレイピングできます ([こちら](prometheus.md)を参照)。
| | **Prometheus メトリクス** | **CloudWatch メトリクス** |
| --- | --- | --- |
| **API リクエスト同時実行数** | apiserver\$1flowcontrol\$1current\$1executing\$1seats | apiserver\$1flowcontrol\$1current\$1executing\$1seats |
| **ポッドのスケジュールレート** | scheduler\$1schedule\$1attempts\$1total | scheduler\$1schedule\$1attempts\$1total、scheduler\$1schedule\$1attempts\$1SCHEDULED、scheduler\$1schedule\$1attempts\$1UNSCHEDULABLE |
| **クラスターデータベースサイズ** | apiserver\$1storage\$1size\$1bytes | apiserver\$1storage\$1size\$1bytes |
Amazon EKS コンソールでコントロールプレーンの使用率を表示できます。クラスターの概要ページから、**[クラスターをモニタリング]** を選択してオブザーバビリティダッシュボードにアクセスし、**[コントロールプレーンのモニタリング]** タブを選択して、**[コントロールプレーンのスケーリング]**セクションでコントロールプレーンの使用率を表示します。
![\[EKS クラスターのモニタリング\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/monitor-cluster.png)
![\[EKS コントロールプレーンのモニタリング\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/control-plane-monitoring.png)
### 階層容量と実際のパフォーマンスについて
プロビジョンドコントロールプレーンのスケーリング階層を選択すると、階層属性は Amazon EKS がコントロールプレーンに適用する基盤となる設定を表します。ただし、実際のパフォーマンスは、特定のワークロードパターン、設定、Kubernetes のベストプラクティスへの準拠によって異なります。例えば、4XL 階層では API Priority and Fairness (APF) が 6,800 の同時リクエスト枠で設定されていますが、コントロールプレーンから得られる実際のリクエストスループットは、実行されるオペレーションのタイプによって異なります。例えば、Kubernetes は get リクエストよりも list リクエストに対して大きなペナルティを課すため、コントロールプレーンで同時に処理される list リクエストの実効数は、get リクエストより少なくなります ([こちら](https://docs.aws.amazon.com/eks/latest/best-practices/scale-control-plane.html#_api_priority_and_fairness)を参照)。同様に、4XL 階層ではデフォルトのスケジューラ QPS が 400 に設定されていますが、実際のポッドスケジューリングレートは、ノードの準備状況やスケジューリング時のヘルスなどの要因によって異なります。最適なパフォーマンスを実現するには、アプリケーションが Kubernetes のベストプラクティス ([こちら](https://docs.aws.amazon.com/eks/latest/best-practices/scalability.html)を参照) に従っており、ワークロードの特性に合わせて適切に設定されていることを確認します。
## 考慮事項
+ **スタンダードコントロールプレーン容量** – EKS スタンダードコントロールプレーンモードは、価格対パフォーマンス比に優れており、ほとんどのユースケースに推奨されるオプションです。ただし、コントロールプレーンのスケーリングによるパフォーマンスの変動を一切許容できない特殊なワークロードや、非常に大量のコントロールプレーン容量を必要とするワークロードの場合は、オプションでプロビジョンドモードの使用を検討できます。
+ **オプトインが必要** – 既存のクラスターは、スタンダードコントロールプレーンから、より高い[料金](https://aws.amazon.com/eks/pricing/) の EKS プロビジョンドコントロールプレーン階層へ自動的にスケールアップされることはありません。新しい EKS プロビジョンドコントロールプレーンスケーリング階層のいずれかに明示的にオプトインする必要があります。
+ **終了制限** – スタンダードコントロールプレーンモードは、最大 8 GB のクラスターデータベース (etcd) サイズをサポートします。プロビジョンドモードの使用中にクラスターのデータベースサイズが 8 GB を超える場合は、データベースサイズを 8 GB 未満に減らすまで、スタンダードモードに戻すことはできません。例えば、プロビジョンドモードで 14 GB のデータベースストレージを使用している場合は、スタンダードモードに戻る前に、まずデータベース使用率を 8 GB 未満に減らす必要があります。
+ **自動階層スケーリングなし** – EKS プロビジョンドコントロールプレーンは、階層間で自動的にスケーリングされません。スケーリング階層を選択すると、クラスターのコントロールプレーンはその階層に固定されたままになり、一貫した予測可能なパフォーマンスが確保されます。ただし、階層使用率メトリクスをモニタリングし、EKS プロビジョンドコントロールプレーン API を使用して、定義したしきい値をこれらのメトリクスが超えたときにスケールアップまたはスケールダウンすることで、独自の自動スケーリングソリューションを柔軟に実装できるため、スケーリング戦略とコスト最適化を完全に制御できます。
+ **現在の階層の表示** – Amazon EKS コンソール、Amazon Web Services CLI、または API を使用して、現在のコントロールプレーンのスケーリング階層を表示できます。CLI では、次の `describe-cluster` コマンドを実行できます。`aws eks describe-cluster --name cluster-name`
+ **階層の移行時間** – Amazon EKS コンソール、Amazon EKS API、または CLI を使用して、スケーリング階層を終了または移動できます。Amazon EKS では、`ScalingTierConfigUpdate` という新しいクラスター更新タイプが導入されています。この更新タイプでは、内容を確認し、移行の進行状況をモニタリングできます。階層変更コマンドを実行した後、クラスターの更新を一覧表示すると、ステータスが `Updating` の `ScalingTierConfigUpdate` タイプの新しい更新が表示されます。更新が完了するとステータスは `Successful` に変わり、エラーが発生した場合は `Failed` に変わります。更新のエラーフィールドには、失敗の理由が示されます。階層を切り替える頻度に制限はありません。コントロールプレーン階層の変更には数分かかります。このプロセスでは、EKS が古い API サーバーを終了する前に新しい API サーバーを起動するため、API サーバーのダウンタイムはありません。
+ **最適な階層の選択** – クラスターに最適なプロビジョンドコントロールプレーンのスケーリング階層を決定するために、最上位の階層 (8XL) でクラスターをプロビジョニングして負荷テストを実行できます。次に、負荷テストを実行して、クラスターのコントロールプレーンに対するピーク需要をシミュレートします。ピーク負荷時のコントロールプレーン階層使用率メトリクスを観察し、これらの観測値を指針として使用し、プロビジョンドモードに適した階層を選択します。
+ **プロビジョンドコントロールプレーンの料金** – クラスターが稼働しているプロビジョンドコントロールプレーンのスケーリング階層について、時間単位の料金が請求されます。これは、標準または延長サポートの時間単位の料金に追加されます。詳細については、「Amazon EKS の料金」[ページ](https://aws.amazon.com/eks/pricing/)を参照してください。
+ **より大きなスケーリング階層** – 8XL を超えるスケーリング階層でクラスターを実行する場合は、Amazon Web Services アカウントチームに連絡して、追加の料金情報を確認してください。
+ **Kubernetes バージョンとリージョンのサポート** – EKS プロビジョンドコントロールプレーンは、すべての Amazon Web Services 商用、GovCloud、中国リージョンでサポートされています。プロビジョンドコントロールプレーンは EKS v1.28 以降で動作します。
# Amazon EKS プロビジョンドコントロールプレーンの開始方法
このガイドでは、AWS CLI と AWS マネジメントコンソールを使用して、EKS プロビジョンドコントロールプレーンをセットアップして使用する手順について説明します。
## 前提条件
開始する前に、以下を確認してください。
+ ** AWS CLI** – Amazon EKS など AWS のサービスを操作するためのコマンドラインツールです。詳細については *AWS コマンドラインインターフェイスユーザーガイド*の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」を参照してください。AWS CLI のインストール後は設定も行っておくことをお勧めします。詳細については *AWS コマンドラインインターフェイスユーザーガイド*の「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。なお、このページにある **[update-kubeconfig]** オプションを使用するにはAWS CLI v2 が必要です。
+ **必要な IAM アクセス許可** – 使用している IAM セキュリティプリンシパルには Amazon EKS の IAM ロール、サービスにリンクされたロール、AWS クラウドフォーメーション、VPC、その関連リソースを操作するための権限が必要になります。詳細については *IAM ユーザーガイド*の「[アクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html)」および「[サービスにリンクされたロールの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html)」を参照してください。このガイドのすべてのステップは1 つのユーザーとして実行する必要があります。現在のユーザーを確認するには次のコマンドを実行してください：
```
aws sts get-caller-identity
```
**注記**
このトピック内のステップはバッシュ シェル内で実行することが推奨されます。Bash シェルを使用していない場合、行継続文字や、変数の設定と使用に関する方法など、一部のスクリプトコマンドのためにシェルの調整が必要となります。さらに、シェルの引用規則とエスケープ規則は異なる場合があります。詳細については *AWS コマンドラインインターフェイスのユーザーガイド*の「[AWS CLI での文字列への引用符の使用](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-quoting-strings.html)」を参照してください。
## EKS プロビジョンドコントロールプレーン - AWS CLI
### EKS プロビジョンドコントロールプレーンスケーリング階層を使用してクラスターを作成する
```
aws eks create-cluster --name prod-cluster \
--role-arn arn:aws:iam::012345678910:role/eks-service-role-AWSServiceRoleForAmazonEKS-J7ONKE3BQ4PI \
--resources-vpc-config subnetIds=subnet-6782e71e,subnet-e7e761ac,securityGroupIds=sg-6979fe18 \
--control-plane-scaling-config tier=tier-xl
```
レスポンス:
```
{
"cluster": {
"name": "my-eks-cluster",
"arn": "arn:aws:eks:us-east-2:111122223333:cluster/my-eks-cluster",
"createdAt": "2024-03-14T11:31:44.348000-04:00",
"version": "1.26",
"endpoint": "https://JSA79429HJDASKJDJ8223829MNDNASW.yl4.us-east-2.eks.amazonaws.com",
"roleArn": "arn:aws:iam::111122223333:role/eksctl-my-eks-cluster-cluster-ServiceRole-zMF6CBakwwbW",
"resourcesVpcConfig": {
"subnetIds": [
"subnet-0fb75d2d8401716e7",
"subnet-02184492f67a3d0f9",
"subnet-04098063527aab776",
"subnet-0e2907431c9988b72",
"subnet-04ad87f71c6e5ab4d",
"subnet-09d912bb63ef21b9a"
],
"securityGroupIds": [
"sg-0c1327f6270afbb36"
],
"clusterSecurityGroupId": "sg-01c84d09d70f39a7f",
"vpcId": "vpc-0012b8e1cc0abb17d",
"endpointPublicAccess": true,
"endpointPrivateAccess": true,
"publicAccessCidrs": [
"22.19.18.2/32"
]
},
"controlPlaneScalingConfig": {
"tier": "tier-xl"
},
"kubernetesNetworkConfig": {
"serviceIpv4Cidr": "10.100.0.0/16",
"ipFamily": "ipv4"
},
"logging": {
"clusterLogging": [
{
"types": [
"api",
"audit",
"authenticator",
"controllerManager",
"scheduler"
],
"enabled": true
}
]
},
"identity": {
"oidc": {
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/JSA79429HJDASKJDJ8223829MNDNASW"
}
},
"status": "CREATING",
"certificateAuthority": {
"data": "CA_DATA_STRING..."
},
"platformVersion": "eks.14",
"tags": {
"aws:cloudformation:stack-name": "eksctl-my-eks-cluster-cluster",
"alpha.eksctl.io/cluster-name": "my-eks-cluster",
"karpenter.sh/discovery": "my-eks-cluster",
"aws:cloudformation:stack-id": "arn:aws:cloudformation:us-east-2:111122223333:stack/eksctl-my-eks-cluster-cluster/e752ea00-e217-11ee-beae-0a9599c8c7ed",
"auto-delete": "no",
"eksctl.cluster.k8s.io/v1alpha1/cluster-name": "my-eks-cluster",
"EKS-Cluster-Name": "my-eks-cluster",
"alpha.eksctl.io/cluster-oidc-enabled": "true",
"aws:cloudformation:logical-id": "ControlPlane",
"alpha.eksctl.io/eksctl-version": "0.173.0-dev+a7ee89342.2024-03-01T03:40:57Z",
"Name": "eksctl-my-eks-cluster-cluster/ControlPlane"
},
"health": {
"issues": []
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP"
}
}
}
```
### クラスターのコントロールプレーンスケーリング階層を表示する
```
aws eks describe-cluster --name prod-cluster
```
レスポンス:
```
{
"cluster": {
"name": "my-eks-cluster",
"arn": "arn:aws:eks:us-east-2:111122223333:cluster/my-eks-cluster",
"createdAt": "2024-03-14T11:31:44.348000-04:00",
"version": "1.26",
"endpoint": "https://JSA79429HJDASKJDJ8223829MNDNASW.yl4.us-east-2.eks.amazonaws.com",
"roleArn": "arn:aws:iam::111122223333:role/eksctl-my-eks-cluster-cluster-ServiceRole-zMF6CBakwwbW",
"resourcesVpcConfig": {
"subnetIds": [
"subnet-0fb75d2d8401716e7",
"subnet-02184492f67a3d0f9",
"subnet-04098063527aab776",
"subnet-0e2907431c9988b72",
"subnet-04ad87f71c6e5ab4d",
"subnet-09d912bb63ef21b9a"
],
"securityGroupIds": [
"sg-0c1327f6270afbb36"
],
"clusterSecurityGroupId": "sg-01c84d09d70f39a7f",
"vpcId": "vpc-0012b8e1cc0abb17d",
"endpointPublicAccess": true,
"endpointPrivateAccess": true,
"publicAccessCidrs": [
"22.19.18.2/32"
]
},
"controlPlaneScalingConfig": {
"tier": "tier-xl"
},
"kubernetesNetworkConfig": {
"serviceIpv4Cidr": "10.100.0.0/16",
"ipFamily": "ipv4"
},
"logging": {
"clusterLogging": [
{
"types": [
"api",
"audit",
"authenticator",
"controllerManager",
"scheduler"
],
"enabled": true
}
]
},
"identity": {
"oidc": {
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/JSA79429HJDASKJDJ8223829MNDNASW"
}
},
"status": "ACTIVE",
"certificateAuthority": {
"data": "CA_DATA_STRING..."
},
"platformVersion": "eks.14",
"tags": {
"aws:cloudformation:stack-name": "eksctl-my-eks-cluster-cluster",
"alpha.eksctl.io/cluster-name": "my-eks-cluster",
"karpenter.sh/discovery": "my-eks-cluster",
"aws:cloudformation:stack-id": "arn:aws:cloudformation:us-east-2:111122223333:stack/eksctl-my-eks-cluster-cluster/e752ea00-e217-11ee-beae-0a9599c8c7ed",
"auto-delete": "no",
"eksctl.cluster.k8s.io/v1alpha1/cluster-name": "my-eks-cluster",
"EKS-Cluster-Name": "my-eks-cluster",
"alpha.eksctl.io/cluster-oidc-enabled": "true",
"aws:cloudformation:logical-id": "ControlPlane",
"alpha.eksctl.io/eksctl-version": "0.173.0-dev+a7ee89342.2024-03-01T03:40:57Z",
"Name": "eksctl-my-eks-cluster-cluster/ControlPlane"
},
"health": {
"issues": []
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP"
}
}
}
```
### EKS プロビジョンドコントロールプレーンを使用するようにクラスターを更新する
```
aws eks update-cluster-config --name prod-cluster \
--control-plane-scaling-config tier=tier-2xl
```
レスポンス:
```
{
"update": {
"id": "7551c64b-1d27-4b1e-9f8e-c45f056eb6fd",
"status": "InProgress",
"type": "ScalingTierConfigUpdate",
"params": [
{
"type": "UpdatedTier",
"value": "tier-2xl"
},
{
"type": "PreviousTier",
"value": "tier-xl"
}
],
"createdAt": 1565807210.37,
"errors": []
}
}
```
### コントロールプレーンスケーリングの更新を表示する
```
aws eks list-updates --name example
```
レスポンス:
```
{
"updateIds": [
"7551c64b-1d27-4b1e-9f8e-c45f056eb6fd1"
]
}
```
### プロビジョンドコントロールプレーンから標準コントロールプレーンに移行する
```
aws eks update-cluster-config --name prod-cluster \
--control-plane-scaling-config tier=standard
```
レスポンス:
```
{
"update": {
"id": "7551c64b-1d27-4b1e-9f8e-c45f056eb6fd",
"status": "InProgress",
"type": "ScalingTierConfigUpdate",
"params": [
{
"type": "UpdatedTier",
"value": "standard"
},
{
"type": "PreviousTier",
"value": "tier-2xl"
}
],
"createdAt": 1565807210.37,
"errors": []
}
}
```
## EKS プロビジョンドコントロールプレーン - AWS マネジメントコンソール
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. **[クラスターを作成]** を選択します。
1. *[設定オプション]* で **[カスタム設定]** を選択します。
1. 下にスクロールして、**[コントロールプレーンスケーリング階層]** に移動します。**[スケーリング階層を使用]** を選択して、プロビジョンドコントロールプレーンを有効にします。
1. XL、2XL、4XL、8XL などのさまざまなスケーリング階層オプションから、クラスターにプロビジョニングするコントロールプレーンスケーリング階層を選択します。
1. 必要に応じて、他のクラスター設定オプションを選択します。最後のステップで、**[クラスターの作成]** を選択します。クラスターの作成が完了するまでに数分かかる場合があります。
# Kubernetes バージョンアップグレードの準備およびクラスターインサイトでの設定ミスのトラブルシューティング
Amazon EKS クラスターインサイトでは、問題の検出と解決のための推奨事項が提供され、クラスターの管理に役立ちます。すべての Amazon EKS クラスターは、Amazon EKS がキュレートしたインサイトのリストと照合して、自動的かつ定期的にチェックされます。これらの*インサイトチェック*は Amazon EKS によって完全に管理され、どのような検出結果にも対処するための推奨事項を提示します。
## クラスターインサイトタイプ
+ **設定インサイト**: クラスターまたはワークロードの機能を損なう可能性のある EKS Hybrid Nodes の設定ミスを特定します。
+ **アップグレードインサイト**: Kubernetes の新しいバージョンにアップグレードする機能に影響を与える可能性のある問題を特定します。
## 考慮事項
+ **頻度**: Amazon EKS は、クラスターインサイトを 24 時間ごとに更新します。また、最新のステータスを確認するときには、手動で更新することもできます。例えば、問題に対処した後でクラスターインサイトを手動で更新して、実際に問題が解決したかどうかを確認できます。
+ **アクセス許可**: Amazon EKS は、すべての EKS クラスターでクラスターインサイトのクラスターアクセスエントリを自動的に作成します。このエントリは、クラスターに関する情報を表示するアクセス許可を EKS に付与します。Amazon EKS は、この情報を使用してインサイトを生成します。詳細については、「[AmazonEKSClusterInsightsPolicy](access-policy-permissions.md#access-policy-permissions-AmazonEKSClusterInsightsPolicy)」を参照してください。
## ユースケース
Amazon EKS のクラスターインサイトは、Kubernetes クラスターの健全性、信頼性、および最適な設定を維持するのに役立つ自動チェックを提供します。以下は、アップグレードの準備状況や設定のトラブルシューティングを含む、クラスターインサイトの主要なユースケースです。
### アップグレードインサイト
アップグレードインサイトは、クラスターインサイト内の特定のタイプのインサイトチェックです。これらのチェックは Kubernetes バージョンアップグレードの準備状況に関するインサイトを返します。Amazon EKS は、すべての EKS クラスターでアップグレードインサイトチェックを実行します。
**重要**
Amazon EKS では、特定のクラスターインサイトの問題が発生した際に `--force` フラグでのクラスターアップグレードが必要となる機能が一時的にロールバックされています。詳細については、GitHub の「[Temporary rollback of enforcing upgrade insights on update cluster version](https://github.com/aws/containers-roadmap/issues/2570)」を参照してください。
クラスターの更新に関する詳細については、「[ステップ 3: クラスターコントロールプレーンを更新する](update-cluster.md#update-cluster-control-plane)」を参照してください。
クラスターの Kubernetes バージョンを更新する前に、[Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)のオブザーバビリティダッシュボードにある **[アップグレード]** タブを使用できます。クラスターに問題が見つかった場合は、確認して適切な修正を行います。問題には、Amazon EKS および Kubernetes のドキュメントへのリンクも含まれます。問題を修正したら、オンデマンドでクラスターインサイトを更新して、最新のインサイトを取得してください。すべての問題が解決したら、[クラスターを更新](update-cluster.md)します。
Amazon EKS は Kubernetes バージョンアップグレードの準備状況に関するインサイトを返します。アップグレードインサイトは、Kubernetes クラスターのアップグレードに影響する可能性のある問題を特定します。これにより、管理者がアップグレードの準備に費やす労力が最小限に抑えられ、新しい Kubernetes バージョンでのアプリケーションの信頼性が高まります。クラスターは、Amazon EKS によって Kubernetes バージョンアップグレードに影響する可能性のある問題のリストと照合して自動的にスキャンされます。Amazon EKS は、各 Kubernetes バージョンリリースで行われた変更のレビューに基づいて、インサイトチェックのリストを頻繁に更新します。
Amazon EKS のアップグレードインサイトにより、新しいバージョンのテストと検証のプロセスがスピードアップします。また、クラスター管理者やアプリケーション開発者は、懸念事項を浮き彫りにし、修正に関するアドバイスを提供することで、最新の Kubernetes 機能を活用できます。
### 設定インサイト
EKS クラスターインサイトは、ハイブリッドノードを使用して Amazon EKS クラスターを自動的にスキャンし、Kubernetes コントロールプレーンからウェブフックへの通信、exec やログなどの kubectl コマンドなどに障害をもたらす設定の問題を特定します。設定インサイトは問題を明らかにし、修復に関する推奨事項を提供し、完全に機能するハイブリッドノードのセットアップまでの時間を短縮します。
## はじめに
実行されたインサイトチェックのリストと、Amazon EKS によって特定された関連する問題を確認するには、AWS マネジメントコンソール、AWS CLI、AWS SDK、および Amazon EKS `ListInsights` API オペレーションを使用できます。開始するには、「[クラスターインサイトを表示する](view-cluster-insights.md)」を参照してください。
# クラスターインサイトを表示する
Amazon EKS は、**設定インサイト**と**アップグレードインサイト**の 2 種類のインサイトを提供します。**設定インサイト**は、クラスターまたはワークロードの機能を損なう可能性のある EKS Hybrid Nodes の設定ミスを特定します。**アップグレードインサイト**は、Kubernetes の新しいバージョンにアップグレードする機能に影響を与える可能性のある問題を特定します。
実行されたインサイトチェックのリストと、Amazon EKS によって特定された関連する問題を確認するには、AWS マネジメントコンソール、AWS CLI、AWS SDK、および Amazon EKS `ListInsights` API オペレーションを呼び出すことができます。
## 設定インサイトを表示する (コンソール)
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. クラスターのリストから、インサイトを確認する Amazon EKS クラスターの名前を選択します。
1. **[クラスターを監視する]** を選択します。
1. **[クラスターヘルス]** タブを選択します。
1. **[設定インサイト]** テーブルには、次の列が表示されます。
+ **名前** — Amazon EKS がクラスターに対して実行したチェック。
+ **インサイトステータス** – ステータスが `Error` のインサイトは、クラスター機能に影響を与える可能性のある設定ミスがあることを意味します。ステータスが `Warning` のインサイトは、設定が文書化されたアプローチと一致しないことを意味しますが、クラスター機能を意図的に設定すると機能する可能性があります。ステータスが `Passing` のインサイトは、Amazon EKS でこのインサイトチェックに関連する問題がクラスター内で検出されなかったことを意味します。
+ **バージョン** – 該当するバージョン。
+ **最終更新時刻** – このクラスターについてのインサイトのステータスが最後に更新された時刻。
+ **説明** — アラートと修復のための推奨アクションを含むインサイトチェックの情報。
## アップグレードインサイトを表示する (コンソール)
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. クラスターのリストから、インサイトを確認する Amazon EKS クラスターの名前を選択します。
1. **[クラスターを監視する]** を選択します。
1. **[アップグレードインサイト]** タブを選択します。
1. 最新のデータを表示するには、**[インサイトを更新]** ボタンを選択し、更新操作が完了するまで待ちます。
1. **[アップグレードインサイト]** テーブルには、次の列が表示されます。
+ **名前** — Amazon EKS がクラスターに対して実行したチェック。
+ **インサイトステータス** — ステータスが「エラー」のインサイトは、通常、影響を受ける Kubernetes バージョンが現在のクラスターバージョンの N\$11 であることを意味し、ステータスが「警告」とは、インサイトが将来の Kubernetes バージョン N\$12 以上に適用されることを意味します。ステータスが「合格」のインサイトは、Amazon EKS がこのインサイトチェックに関連する問題をクラスター内で発見しなかったことを意味します。インサイトステータスが「不明」の場合は、Amazon EKS はクラスターがこのインサイトチェックの影響を受けているかどうかを判断できないことを意味します。
+ **バージョン** — インサイトにより問題の可能性がチェックされた Kubernetes バージョン。
+ **最終更新時刻** – このクラスターについてのインサイトのステータスが最後に更新された時刻。
+ **前回の移行時刻** – このインサイトのステータスが最後に変更された時刻。
+ **説明** — アラートと修復のための推奨アクションを含むインサイトチェックの情報。
## クラスターインサイトを表示する (AWS CLI)
1. 最新のデータを表示するには、指定されたクラスターのインサイトを更新します。必要に応じてコマンドに次の変更を加えてから、そのコマンドを実行してください。
+ *region-code* を、AWS リージョンのコードに置き換えます。
+ *マイクラスター* の部分は自分のクラスター名に置き換えます。
```
aws eks start-insights-refresh --region region-code --cluster-name my-cluster
```
1. インサイト更新のステータスを追跡するには、次のコマンドを実行します。*マイクラスター* の部分は自分のクラスター名に置き換えます。
```
aws eks describe-insights-refresh --cluster-name my-cluster
```
出力例は次のとおりです。
```
{
"message": "Insights refresh is in progress",
"status": "IN_PROGRESS",
"startedAt": "2025-07-30T13:36:09-07:00"
}
```
1. 指定されたクラスターのインサイトをリストします。必要に応じてコマンドに次の変更を加えてから、そのコマンドを実行してください。
+ *region-code* を、AWS リージョンのコードに置き換えます。
+ *マイクラスター* の部分は自分のクラスター名に置き換えます。
```
aws eks list-insights --region region-code --cluster-name my-cluster
```
出力例は次のとおりです。
```
{
"insights":
[
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"name": "Kubelet version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557309.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",
"insightStatus":
{
"status": "UNKNOWN",
"reason": "Unable to determine status of node kubelet versions.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"name": "Cluster health issues",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for any cluster health issues that prevent successful upgrade to the next Kubernetes version on EKS.",
"insightStatus":
{
"status": "PASSING",
"reason": "No cluster health issues detected.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"name": "EKS add-on version compatibility",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks version of installed EKS add-ons to ensure they are compatible with the next version of Kubernetes. ",
"insightStatus": { "status": "PASSING", "reason": "All installed EKS add-on versions are compatible with next Kubernetes version."},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEccccc",
"name": "kube-proxy version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks version of kube-proxy in cluster to see if upgrade would cause non compliance with supported Kubernetes kube-proxy version skew policy.",
"insightStatus":
{
"status": "PASSING",
"reason": "kube-proxy versions match the cluster control plane version.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEddddd",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
],
"nextToken": null,
}
```
1. インサイトの詳細を表示するには、次のコマンドを実行します。必要に応じてコマンドに次の変更を加えてから、そのコマンドを実行してください。
+ *region-code* を、AWS リージョンのコードに置き換えます。
+ *a1b2c3d4-5678-90ab-cdef-EXAMPLE22222* を、クラスターインサイトのリストから取得したインサイト ID に置き換えます。
+ *マイクラスター* の部分は自分のクラスター名に置き換えます。
```
aws eks describe-insight --region region-code --id a1b2c3d4-5678-90ab-cdef-EXAMPLE22222 --cluster-name my-cluster
```
出力例は次のとおりです。
```
{
"insight":
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"name": "Kubelet version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "1.27",
"lastRefreshTime": 1734557309.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",
"insightStatus":
{
"status": "UNKNOWN",
"reason": "Unable to determine status of node kubelet versions.",
},
"recommendation": "Upgrade your worker nodes to match the Kubernetes version of your cluster control plane.",
"additionalInfo":
{
"Kubelet version skew policy": "https://kubernetes.io/releases/version-skew-policy/#kubelet",
"Updating a managed node group": "https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html",
},
"resources": [],
"categorySpecificSummary":
{ "deprecationDetails": [], "addonCompatibilityDetails": [] },
},
}
```
# 既存のクラスターを新しい Kubernetes バージョンに更新する
**ヒント**
今後開催予定の Amazon EKS ワークショップに[登録](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)してください。
Amazon EKS で利用可能な新しい Kubernetes バージョンがある場合には、Amazon EKS クラスターを最新バージョンに更新できます。
**重要**
クラスターをアップグレードすると、以前のバージョンにダウングレードすることはできません。新しい Kubernetes バージョンに更新する前に、「[Understand the Kubernetes version lifecycle on EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)」の情報と、本トピック内の更新手順を確認することをお勧めします。
新しい Kubernetes バージョンでは、大幅な変更が加えられている場合があります。このため、本稼働用クラスターで更新を行う前に、新しいバージョンの Kubernetes に対するアプリケーションの動作をテストしておくことをお勧めします。この際は、継続的な統合ワークフローを構築し、新しい Kubernetes バージョンに移行する前にアプリケーションの動作をテストします。
更新プロセスに含まれている Amazon EKS が、更新された Kubernetes バージョンを使用しながら新しい API サーバーノードを起動することで、既存のバージョンを置き換えます。Amazon EKS は、これらの新しいノードで、ネットワークトラフィックの標準インフラストラクチャと準備状況に関するヘルスチェックを実行し、想定どおりに動作していることを確認します。ただし、クラスターのアップグレードを開始すると、一時停止または停止することはできません。これらのヘルスチェックのいずれかが失敗すると、Amazon EKS はインフラストラクチャのデプロイを元に戻します。クラスターは前の Kubernetes バージョンのままになります。この際も、実行中のアプリケーションは影響を受けません。また、クラスターが不確定または回復不可能な状態のままになることもありません。Amazon EKS は定期的にすべてのマネージド型クラスターをバックアップします。さらに、必要に応じてクラスターを復元するメカニズムも存在します。Kubernetes インフラストラクチャの管理プロセスは、継続的に評価、改善されています。
クラスターをアップグレードする際、Amazon EKS には、クラスターの作成時に指定したサブネット内に、最大で 5 つの使用可能な IP アドレスが必要となります。Amazon EKS は、指定したサブネットのいずれかに、新しいクラスターの Elastic Network Interface (ネットワークインターフェイス) を作成します。新しいネットワークインターフェイスは、既存のネットワークインターフェイスがあるのとはｂサブネット内に作成される場合があります。ですので、クラスター作成時に指定したサブネットのいずれでも[必要なクラスターとの通信](sec-group-reqs.md)が許可されるよう、セキュリティグループルールを設定します。クラスターの作成時に指定したサブネットのいずれかが存在しない、使用できる十分な IP アドレスがない、または必要なクラスターとの通信を許可するセキュリティグループルールがない場合、更新が失敗する可能性があります。
クラスターの API サーバーエンドポイントに常にアクセスできるように、Amazon EKS では高可用性を備えた Kubernetes コントロールプレーンを提供しており、アップデート実行中に API サーバーインスタンスのローリングアップデートを行います。Kubernetes API サーバーエンドポイントをサポートする API サーバーインスタンスの IP アドレスの変更を考慮するために、API サーバークライアントが再接続を適切に管理しているか確認する必要があります。`kubectl` の最新バージョンと公式にサポートされている Kubernetes クライアント[ライブラリ](https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api)は、この再接続プロセスを透過的に実行します。
**注記**
クラスターの更新の詳細については、「EKS Best Practices Guide」の「[Best Practices for Cluster Upgrades](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)」を参照してください。このリソースは、アップグレードを計画し、クラスターのアップグレード戦略を理解するのに役立ちます。
## Amazon EKS Auto Mode の考慮事項
+ Amazon EKS Auto Mode のコンピューティング機能は、Kubernetes バージョンのノードを制御します。コントロールプレーンをアップグレードすると、EKS Auto Mode はマネージドノードの段階的な更新を開始します。EKS Auto Mode は、ポッドの停止状態の予算を尊重します。
+ コンピューティングの自動スケーリング、ブロックストレージ、ロードバランシング機能など、Amazon EKS Auto Mode の機能を手動でアップグレードする必要はありません。
## 概要
Amazon EKS クラスターのアップグレードプロセスの概要は以下のとおりです。
1. クラスターがアップグレードをサポートする状態であることを確認します。これには、クラスターにデプロイされたリソースで使用されている Kubernetes API をチェックし、クラスターに正常性の問題がないことを確認することが含まれます。クラスターのアップグレードの準備状況を評価する際には、Amazon EKS のアップグレードインサイトを使用する必要があります。
1. コントロールプレーンを次のマイナーバージョンにアップグレードします (1.34 から 1.35 など)。
1. データプレーン内のノードをコントロールプレーンのノードと一致するようにアップグレードします。
1. その他にクラスターで実行されているアプリケーション (`cluster-autoscaler` など) がある場合は、そのアプリケーションをアップグレードします。
1. Amazon EKS が提供するアドオン (デフォルトで含まれるアドオンなど) をアップグレードします。
+ [Amazon VPC CNI の推奨バージョン](managing-vpc-cni.md)
+ [CoreDNS の推奨バージョン](managing-coredns.md)
+ [`kube-proxy` の推奨バージョン](managing-kube-proxy.md)
1. クラスターと通信しているクライアントがある場合は、そのクライアントをアップグレードします (`kubectl` など)。
## ステップ 1: アップグレードの準備をする
クラスターコントロールプレーンの Kubernetes バージョンと、ノードの Kubernetes バージョンを比較します。
+ クラスターコントロールプレーンの Kubernetes バージョンを取得します。
```
kubectl version
```
+ ノードの Kubernetes バージョンを取得します。このコマンドでは、セルフマネージド型およびマネージド型の Amazon EC2、Fargate、およびハイブリッドノードがすべて返されます。各 Fargate Pod は、独自のノードとしてリストされます。
```
kubectl get nodes
```
コントロールプレーンを新しい Kubernetes バージョンに更新する前に、クラスター内のマネージド型ノードと Fargate ノードの双方の Kubernetes マイナーバージョンが、コントロールプレーンのバージョンと同じであることを確認してください。例えば、コントロールプレーンがバージョン `1.29` を実行し、かつノードの 1 つがバージョン `1.28` を実行している場合、コントロールプレーンを 1.30 に更新する前に、ノードをバージョン `1.29` に更新する必要があります。また、コントロールプレーンを更新する前に、セルフマネージド型ノードとハイブリッドノードをコントロールプレーンと同じバージョンに更新することをお勧めします。詳細については[クラスターのためにマネージドノードグループを更新する](update-managed-node-group.md)、[クラスターのためにセルフマネージドノードを更新する](update-workers.md)、および[クラスターのハイブリッドノードをアップグレードする](hybrid-nodes-upgrade.md)を参照してください。Fargate ノードのマイナーバージョンがコントロールプレーンのバージョンよりも古い場合、まずノードの示す Pod を削除します。次に、コントロールプレーンを更新します。残りの Pod は、再デプロイ後に新しいバージョンに更新されます。
## ステップ 2: アップグレードに関する考慮事項を確認する
Amazon EKS クラスターインサイトは、非推奨の Kubernetes API の使用など、Kubernetes バージョンのアップグレードに影響を与える可能性のある問題のリストに照らして、クラスターを自動的にスキャンします。Amazon EKS は、Kubernetes プロジェクトの変更の評価に基づいて、実行するインサイトチェックのリストを定期的に更新します。また、Amazon EKS は、新しいバージョンに伴って Amazon EKS サービスに変更が導入された際にも、インサイトチェックのリストを更新します。詳細については、「[Kubernetes バージョンアップグレードの準備およびクラスターインサイトでの設定ミスのトラブルシューティング](cluster-insights.md)」を参照してください。
Kubernetes ドキュメントの「[Deprecated API Migration Guide](https://kubernetes.io/docs/reference/using-api/deprecation-guide/)」を確認してください。
### アップグレードインサイトを確認する
Amazon EKS アップグレードインサイトを使用して問題を特定します。詳細については、「[アップグレードインサイトを表示する (コンソール)](view-cluster-insights.md#view-upgrade-insights-console)」を参照してください。
### 詳細な考慮事項
+ Amazon EKS は可用性の高いコントロールプレーンを実行しているため、一回に更新できるのはマイナーバージョン 1 つのみです。この要件の詳細については、「[Kubernetes Version and Version Skew Support Policy](https://kubernetes.io/docs/setup/version-skew-policy/#kube-apiserver)」 (Kubernetes のバージョンおよびバージョンスキューのサポートポリシー) を参照してください。現在のクラスターバージョンが `1.28` であり、`1.30` に更新することを仮定します。最初にバージョン `1.28` クラスターをバージョン `1.29` に更新し、次にバージョン `1.29` クラスターをバージョン `1.30` に更新する必要があります。
+ ノード上の Kubernetes `kube-apiserver` と `kubelet` 間のバージョンスキューを確認してください。
+ Kubernetes バージョン `1.28` 以降、`kubelet` は `kube-apiserver` より最大 3 マイナーバージョン古い場合があります。「[Kubernetes アップストリームバージョンのスキューポリシー](https://kubernetes.io/releases/version-skew-policy/#kubelet)」を参照してください。
+ マネージドノードと Fargate ノードの `kubelet` が Kubernetes バージョン `1.25` 以降の場合は、`kubelet` バージョンを更新せずに最大 3 バージョン先までクラスターを更新できます。例えば、`kubelet` がバージョン `1.25` である場合、`kubelet` のバージョンを `1.25` のままにしていても、Amazon EKS クラスターのバージョンは `1.25` から `1.26`、`1.27`、`1.28` に更新できます。
+ 更新を開始する前のベストプラクティスとして、ノード上の `kubelet` がコントロールプレーンと同じ Kubernetes バージョンであることを確認してください。
+ クラスターが `1.8.0` より前のバージョンの Amazon VPC CNI Plugin for Kubernetes で設定されている場合は、クラスターを更新する前に、プラグインを最新バージョンに更新することをお勧めします。プラグインのアップデートについては、「[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md)」を参照してください。
+ Amazon EKS クラスターのバックアップを取得することで、アップグレードプロセス中に障害が発生した場合に、Amazon EKS クラスターの状態と永続的ストレージを復元できます。「[AWS Backup を使用して EKS クラスターをバックアップする](integration-backup.md)」を参照してください。
## ステップ 3: クラスターコントロールプレーンを更新する
**重要**
Amazon EKS では、特定のクラスターインサイトの問題が発生した際に `--force` フラグでのクラスターアップグレードが必要となる機能が一時的にロールバックされています。詳細については、GitHub の「[Temporary rollback of enforcing upgrade insights on update cluster version](https://github.com/aws/containers-roadmap/issues/2570)」を参照してください。
Amazon EKS は、「最終更新時間」から 24 時間後にクラスターインサイトを更新します。問題に対処した時刻とクラスターインサイトの「最終更新時間」を比較できます。
さらに、非推奨 API の使用に対処した後、インサイトのステータスが更新されるまでに最大 30 日かかる場合があります。アップグレードインサイトは、常に、過去 30 日の期間中の非推奨 API の使用を確認しています。
EKS コントロールプレーンバージョンのアップグレードリクエストは、以下を使用して送信できます。
+ [eksctl](#step3-eksctl)
+ [AWS コンソール](#step3-console)
+ [AWS CLI](#step3-cli)
### クラスターの更新 - eksctl
この手順には、`eksctl` バージョン `0.215.0` 以降が必要です。お使いのバージョンは、以下のコマンドを使用して確認できます。
```
eksctl version
```
`eksctl` のインストールと更新の手順については、`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。
Amazon EKS コントロールプレーンの Kubernetes バージョンを更新します。`` をクラスター名に置き換えます。`` は、Amazon EKS がサポートする、クラスターの更新先のバージョン番号に置き換えてください。サポートされているバージョン番号のリストについては、「[Amazon EKS supported versions](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)」を参照してください。
```
eksctl upgrade cluster --name --version --approve
```
この更新は完了までに数分かかることがあります。
「[ステップ 4: クラスターコンポーネントを更新する](#step4)」に進みます。
### クラスターの更新 - AWS コンソール
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. アップグレードするクラスターに対して **[今すぐアップグレード]** を選択します。
1. クラスターの更新先のバージョンを選択し、**[アップグレード]** を選択します。
1. この更新は完了までに数分かかることがあります。「[ステップ 4: クラスターコンポーネントを更新する](#step4)」に進みます。
### クラスターの更新 - AWS CLI
1. AWS CLI がインストールされ、ログインしていることを確認します。詳細については、「[AWS CLI の最新バージョンのインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。
1. 次の AWS CLI コマンドを使用して、Amazon EKS クラスターを更新します。アップグレードするクラスターの `` と `` を置き換えます。`` は、Amazon EKS がサポートする、クラスターの更新先のバージョン番号に置き換えてください。サポートされているバージョン番号のリストについては、「[Amazon EKS supported versions](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)」を参照してください。
```
aws eks update-cluster-version --name \
--kubernetes-version --region
```
出力例は次のとおりです。
```
{
"update": {
"id": "",
"status": "InProgress",
"type": "VersionUpdate",
"params": [
{
"type": "Version",
"value": ""
},
{
"type": "PlatformVersion",
"value": "eks.1"
}
],
[...]
"errors": []
}
```
1. この更新は完了までに数分かかることがあります。クラスター更新のステータスをモニタリングするには、次のコマンドを使用します。同じ `` と `` を使用することに加えて、前のコマンドで返された `` を使用します。
```
aws eks describe-update --name \
--region --update-id
```
`Successful` ステータスが表示されると、更新は完了です。
1. 「[ステップ 4: クラスターコンポーネントを更新する](#step4)」に進みます。
## ステップ 4: クラスターコンポーネントを更新する
1. クラスターの更新が完了したら、更新したクラスターでの Kubernetes と同じマイナーバージョンに、ノードを更新する必要があります。詳細については[クラスターのためにセルフマネージドノードを更新する](update-workers.md)、[クラスターのためにマネージドノードグループを更新する](update-managed-node-group.md)、および[クラスターのハイブリッドノードをアップグレードする](hybrid-nodes-upgrade.md)を参照してください。Fargate で起動される新しい Pod であれば、クラスターのバージョンと一致する `kubelet` バージョンを持っています。それまでに存在していた Fargate Pod は変更されていません。
1. (オプション) クラスターを更新する前に、そのクラスターに Kubernetes Cluster Autoscaler をデプロイしてある場合は、更新後の Kubernetes のメジャーバージョンとマイナーバージョンに一致するように、Cluster Autoscaler を最新バージョンに更新します。
1. ウェブブラウザで Cluster Autoscaler の[リリース](https://github.com/kubernetes/autoscaler/releases)ページを開き、クラスターの Kubernetes メジャーバージョンとマイナーバージョンに一致する最新の Cluster Autoscaler バージョンを見つけます。例えば、クラスターの Kubernetes バージョンが `1.30` である場合、`1.30` で始まる最新の Cluster Autoscaler リリースを見つけます。次のステップで使用するため、そのリリースのセマンティックバージョン番号 (例: `1.30.n`) を書き留めておきます。
1. 次のコマンドを使用して、Cluster Autoscaler イメージタグを、前のステップで書き留めたバージョンに設定します。必要に応じて、`X.XX.X` を独自の値に置き換えます。
```
kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=registry.k8s.io/autoscaling/cluster-autoscaler:vX.XX.X
```
1. (GPU ノードを含むクラスターのみ) クラスターに GPU 対応のノードグループ (`p3.2xlarge` など) がある場合は、クラスターの [NVIDIA Device Plugin for Kubernetes](https://github.com/NVIDIA/k8s-device-plugin) DaemonSet を更新する必要があります。次のコマンドを実行する前に、`` を必要となる [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin/releases) バージョンに置き換えます。
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin//deployments/static/nvidia-device-plugin.yml
```
1. Amazon VPC CNI Plugin for Kubernetes、CoreDNS、および `kube-proxy` アドオンを更新します。[サービスアカウントトークン](service-accounts.md#boundserviceaccounttoken-validated-add-on-versions)にリストされている最小バージョンに対してアドオンを更新することをお勧めします。
+ Amazon EKS アドオンを使用している場合は、Amazon EKS コンソールで **[クラスター]** をクリックし、左のナビゲーションペインで更新したクラスター名を選択します。通知がコンソールに表示されます。更新可能なアドオンごとに、新しいバージョンが利用可能であることが通知されます。アドオンを更新するには、**[アドオン]** タブを選択します。更新があるアドオンが表示されているボックスで [**今すぐ更新**] を選択し、使用可能なバージョンを選択してから、[**更新**] を選択します。
+ 別の方法として、AWS CLI または `eksctl` を使用してアドオンを更新することもできます。詳細については、「[Amazon EKS アドオンを更新する](updating-an-add-on.md)」を参照してください。
1. 必要に応じて、`kubectl` のバージョンを更新します。Amazon EKS クラスターコントロールプレーンとのマイナーバージョンの相違が 1 つ以内である `kubectl` バージョンを使用する必要があります。
## Amazon EKS クラスターの Kubernetes バージョンをダウングレードする
Amazon EKS クラスターの Kubernetes をダウングレードすることはできません。代わりに、以前の Amazon EKS バージョンで新しいクラスターを作成し、ワークロードを移行します。
# クラスターを削除
Amazon EKS クラスターの使用が終了したら、関連付けられたリソースを削除して、不要なコストが発生しないようにする必要があります。
`eksctl`、AWS マネジメントコンソール、またはAWS CLI を使用してクラスターを削除できます。
## 考慮事項
+ クラスター作成者が削除されたためにエラーが発生した場合は、[この記事](https://aws.amazon.com/premiumsupport/knowledge-center/eks-api-server-unauthorized-error)を参照して解決してください。
+ Amazon Managed Service for Prometheus リソースはクラスターのライフサイクル外にあるため、クラスターとは別途維持する必要があります。クラスターを削除するときは、対象コストを抑えるために、該当するスクレイパーも削除してください。詳細については、「*Amazon Managed Service for Prometheus ユーザーガイド*」の「[スクレイパーの検出と作成](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-list-delete)」を参照してください。
+ 接続されたクラスターを削除するには、「[Amazon EKS コンソールから Kubernetes クラスターの登録を解除する](deregister-connected-cluster.md)」を参照してください。
+ クラスターを削除する前に、クラスターの削除保護が無効になっていることを確認してください。
### EKS Auto Mode に関する考慮事項
+ EC2 マネージドインスタンスを含む、すべての EKS Auto Mode ノードが削除されます
+ すべてのロードバランサーが削除されます
詳細については、「[EKS 自動モードl を無効にする](auto-disable.md)」を参照してください。
## 前提となる手順
クラスターを削除する前に最初に実行する必要があるステップを以下に示します。これらのステップは、クラスターの削除に使用する方法に関係なく適用されます。
1. クラスターで実行されているすべてのサービスを一覧表示します。
```
kubectl get svc --all-namespaces
```
1. 関連付けられた `EXTERNAL-IP` 値のあるサービスすべてを削除します。これらのサービスの前面には Elastic Load Balancing のロードバランサーが置かれているため、そのロードバランサーや関連するリソースを適切に解放するためには、これらのサービスを Kubernetes から削除する必要があります。*service-name* を説明に従って各サービスの名前に置き換えます。
```
kubectl delete svc service-name
```
1. Ingress リソースも削除します。Ingress リソースを削除しない場合、クラスターを削除しても Application Load Balancer は残ります。*ingress-name* をお使いの Ingress リソースの名前に置き換えます。
```
kubectl get ingress --all-namespaces
```
```
kubectl delete ing ingress-name
```
## クラスターの削除 (eksctl)
この手順には、`eksctl` バージョン `0.215.0` 以降が必要です。お使いのバージョンは、以下のコマンドを使用して確認できます。
```
eksctl version
```
`eksctl` のインストールまたはアップグレードの手順については、`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。
1. [前提条件の手順](#prerequisite-steps)を実行します。その後、以下のコマンドを使用して、クラスターとそれに関連するノードを削除します。この時、*prod* は実際のクラスター名に置き換えてください。
```
eksctl delete cluster --name prod
```
出力:
```
[ℹ] using region region-code
[ℹ] deleting EKS cluster "prod"
[ℹ] will delete stack "eksctl-prod-nodegroup-standard-nodes"
[ℹ] waiting for stack "eksctl-prod-nodegroup-standard-nodes" to get deleted
[ℹ] will delete stack "eksctl-prod-cluster"
[✔] the following EKS cluster resource(s) for "prod" will be deleted: cluster. If in doubt, check CloudFormation console
```
## クラスターを削除する (AWS コンソール)
1. [前提条件の手順](#prerequisite-steps)を実行します。その後、すべてのノードグループと Fargate プロファイルを削除します。
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで Amazon EKS **[クラスター]** を選択し、クラスターのタブ付きリストから、削除するクラスター名を選択します。
1. **[コンピューティング]** タブを選択し、削除するノードグループを選択します。**[削除]** を選択し、ノードグループの名前を入力し、**[削除]** を選択します。クラスター内のすべてのノードグループを削除します。
**注記**
ここでリストに表示されるノードグループは、[マネージド型ノードグループ](managed-node-groups.md)のみです。
1. 削除する **[Fargate プロファイル]** を選択し、**[削除]** を選択し、プロファイルの名前を入力した上で **[削除]** を選択します。クラスター内のすべてのFargate プロファイルを削除します。
1. すべての[セルフマネージド型ノードの AWS CloudFormation スタック](https://docs.aws.amazon.com/eks/latest/userguide/worker)を削除します。
1. [AWS CloudFormation コンソール](https://console.aws.amazon.com/cloudformation/)を開きます。
1. 削除するノードスタックを選択し、**[削除]** を選択します。
1. **[スタックの削除]** 確認ダイアログボックスで、**[スタックを削除]** をクリックします。クラスター内のすべてのセルフマネージド型ノードスタックを削除します。
1. クラスターを削除します。
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 削除するクラスターを選択し、**[削除]** を選択します。
1. クラスターの削除確認画面で、**[削除]** を選択します。
1. (オプション) VPC AWS CloudFormation スタックを削除します。
1. [AWS CloudFormation コンソール](https://console.aws.amazon.com/cloudformation/)を開きます。
1. 削除する VPC スタックを選択し、**[削除]** をクリックします。
1. **[スタックの削除]** 確認ダイアログボックスで、**[スタックを削除]** をクリックします。
## クラスターを削除する (AWS CLI)
1. [前提条件の手順](#prerequisite-steps)を実行します。その後、すべてのノードグループと Fargate プロファイルを削除します。
1. 次のコマンドを使用して、クラスター内のノードグループを一覧表示します。
```
aws eks list-nodegroups --cluster-name my-cluster
```
**注記**
ここでリストに表示されるノードグループは、[マネージド型ノードグループ](managed-node-groups.md)のみです。
1. 次のコマンドを使用して、各ノードグループを削除します。クラスター内のすべてのノードグループを削除します。
```
aws eks delete-nodegroup --nodegroup-name my-nodegroup --cluster-name my-cluster
```
1. 次のコマンドを使用して、クラスターの Fargate プロファイルを一覧表示します。
```
aws eks list-fargate-profiles --cluster-name my-cluster
```
1. 次のコマンドを使用して、各 Fargate プロファイルを削除します。クラスター内のすべてのFargate プロファイルを削除します。
```
aws eks delete-fargate-profile --fargate-profile-name my-fargate-profile --cluster-name my-cluster
```
1. すべての[セルフマネージド型ノードの AWS CloudFormation スタック](https://docs.aws.amazon.com/eks/latest/userguide/worker)を削除します。
1. 次のコマンドを使用して、使用可能な AWS CloudFormation スタックを一覧表示します。出力結果から、ノードテンプレート名を見つけます。
```
aws cloudformation list-stacks --query "StackSummaries[].StackName"
```
1. 次のコマンドを使用して、各ノードスタックを削除します。この際、*node-stack* の部分は実際のノードスタック名に置き換えます。クラスター内のすべてのセルフマネージド型ノードスタックを削除します。
```
aws cloudformation delete-stack --stack-name node-stack
```
1. 以下のコマンドを使用して、クラスターを削除します。*my-cluster* は実際のクラスター名に置き換えてください。
```
aws eks delete-cluster --name my-cluster
```
1. (オプション) VPC AWS CloudFormation スタックを削除します。
1. 次のコマンドを使用して、使用可能な AWS CloudFormation スタックを一覧表示します。結果の出力で VPC テンプレート名を見つけます。
```
aws cloudformation list-stacks --query "StackSummaries[].StackName"
```
1. 以下のコマンドを使用して、VPC スタックを削除します。*my-vpc-stack* は実際の VPC スタック名に置き換えてください。
```
aws cloudformation delete-stack --stack-name my-vpc-stack
```
# EKS クラスターを誤って削除しないように保護する
EKS クラスターを誤って削除すると、Kubernetes クラスターのオペレーションが損なわれる可能性があります。
EKS クラスターを誤って削除しないように保護できるようになりました。クラスターで削除保護を有効にすると、クラスターを削除する際は、まず削除保護を無効化しなければならなくなります。
削除保護の目的は、事故を防ぐことです。クラスターを削除する権限を持つユーザーを慎重に制限する必要があります。
削除保護が有効になっているアクティブなクラスターを削除しようとすると、`InvalidRequestException` を受け取ります。
**重要**
クラスターで削除保護を有効にした場合、削除保護を削除してからクラスターを削除するためには、UpdateClusterConfig と DeleteCluster IAM アクセス許可の**両方**が必要です。
**注記**
クラスターの状態が作成中、失敗、または削除中の場合は、削除保護が有効になっている場合でもクラスターを削除できます。
## 既存のクラスターの削除保護を有効にするには
これは、アクティブなステータスのクラスターでのみ実行できます。
```
aws eks update-cluster-config --name --region --deletion-protection
```
## 既存のクラスターの削除保護を無効にするには
```
aws eks update-cluster-config --name --region --no-deletion-protection
```
# クラスター API サーバーエンドポイント
このトピックでは、Amazon EKS クラスターの Kubernetes API サーバーエンドポイントや上限へのプライベートアクセスを有効化する方法、あるいは、インターネットからのパブリックアクセスを完全に無効化する方法について説明します。
新しいクラスターを作成すると、Amazon EKS によってマネージド型の Kubernetes API サーバーのエンドポイントが作成されます。ユーザーはこのエンドポイントを、(`kubectl` などの Kubernetes 管理ツールにより) クラスターとの通信に使用します。デフォルトでは、この API サーバーエンドポイントはインターネットに公開されます。API サーバーへのアクセスの保護には、AWS Identity and Access Management (IAM) と、ネイティブの Kubernetes [ロールベースアクセスコントロール](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) が組み合わせて使用されます。このエンドポイントは*クラスターパブリックエンドポイント*と呼ばれます。また、*クラスタープライベートエンドポイント*もあります。クラスタープライベートエンドポイントの詳細についてはセクション [クラスタープライベートエンドポイント](#cluster-endpoint-private) を参照してください。
## `IPv6` クラスターエンドポイント形式
EKS は2024 年 10 月以降に作成された新しい `IPv6` クラスターに対して、次の形式で一意のデュアルスタックエンドポイントを作成します。*IPv6 クラスター*はクラスターの IP ファミリー (`ipFamily`) 設定で `IPv6` を選択するクラスターです。
**Example**
EKS クラスターパブリック／プライベートエンドポイント: `eks-cluster.region.api.aws`
EKS クラスターパブリック／プライベートエンドポイント: `eks-cluster.region.api.aws`
EKS クラスターパブリック／プライベートエンドポイント: `eks-cluster---region---api.amazonwebservices.com.rproxy.goskope.com.cn`
**注記**
デュアルスタッククラスターエンドポイントは2024 年 10 月に導入されました。`IPv6` クラスターの詳細については「[クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md)」を参照してください。2024 年 10 月より前に作成されたクラスターは代わりに次のエンドポイント形式を使用します。
## `IPv4` クラスターエンドポイント形式
EKS はクラスターの IP ファミリー (ipFamily 設定で `IPv4` を選択したクラスターごとに、次の形式で一意のエンドポイントを作成します：
**Example**
EKS クラスターパブリック／プライベートエンドポイント `eks-cluster.region.eks.amazonaws.com`
EKS クラスターパブリック／プライベートエンドポイント `eks-cluster.region.eks.amazonaws.com`
EKS クラスターパブリック／プライベートエンドポイント `eks-cluster---region.amazonwebservices.com.rproxy.goskope.com.cn`
**注記**
2024 年 10 月以前、`IPv6` クラスターはこのエンドポイント形式も使用していました。これらのクラスターではパブリックエンドポイントとプライベートエンドポイントの両方において、このエンドポイントから解決できるのは `IPv4` アドレスのみです。
## クラスタープライベートエンドポイント
Kubernetes API サーバーへのプライベートアクセスを有効にすると、ノードと API サーバー間のすべての通信が VPC 内で行われるようになります。インターネットから API サーバーにアクセスできる IP アドレスを制限したり、API サーバーへのインターネットアクセスを完全に無効にしたりできます。
**注記**
このエンドポイントは Kubernetes API サーバー用であり、AWS API と通信するための従来の AWS PrivateLink エンドポイントではないため、Amazon VPC コンソール上にはエンドポイントとして表示されません。
クラスターでエンドポイントへのプライベートアクセスを有効にすると、Amazon EKS によって自動的に ルート 53 のプライベートホストゾーンが作成され、クラスターの VPC に関連付けられます。このプライベートホストゾーンは Amazon EKS によって管理され、アカウントの ルート 53 リソースには表示されません。プライベートホストゾーンが API サーバーに正しくトラフィックをルーティングするためにはVPC で `enableDnsHostnames` と `enableDnsSupport` が `true` に設定され、VPC 用に設定された DHCP オプションで、ドメイン名サーバーリストに `AmazonProvidedDNS` が含まれている必要があります。詳細については[Amazon VPC ユーザーガイド](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating)の「*VPC の DNS サポートを表示および更新する*」を参照してください。
API サーバーエンドポイントのアクセス要件は新しいクラスターを作成するときに定義できます。また、クラスターの API サーバーエンドポイントのアクセスは随時更新できます。
## クラスターエンドポイントのアクセスの変更
既存クラスターのエンドポイントのアクセスを変更するにはこのセクションの手順に従ってください。次の表はサポートされている API サーバーエンドポイントのアクセスの組み合わせとそれらに関連付けられている動作を示しています。
| エンドポイントのパブリックアクセス | エンドポイントのプライベートアクセス | 行動 |
| --- | --- | --- |
| 有効 | 無効 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/cluster-endpoint.html) |
| 有効 | 有効 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/cluster-endpoint.html) |
| Disabled | 有効 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/cluster-endpoint.html) |
**エンドポイントアクセスコントロール**
以下のエンドポイントアクセスを制御する方法のいずれも、それぞれのエンドポイントにのみ影響することに注意してください。
*クラスターセキュリティグループ*
クラスターセキュリティグループは、*kubelet API* とプライベートエンドポイントへの接続という 2 つのタイプの接続を制御します。`kubelet` API への接続は、`kubectl attach`、`kubectl cp`、`kubectl exec`、`kubectl logs`、`kubectl port-forward` の各コマンドで使用されます。クラスターセキュリティグループがパブリックエンドポイントに影響することはありません。
*パブリックアクセス CIDR*
*パブリックアクセス CIDR* は、CIDR ブロックのリストでパブリックエンドポイントへのアクセスを制御します。パブリックアクセス CIDR はプライベートエンドポイントに影響しないことに注意してください。パブリックアクセス CIDR の動作は、以下で説明するように、`IPv6` クラスターと `IPv4` クラスターが作成された日付によって異なります。
**パブリックエンドポイントの CIDR ブロック (`IPv6` クラスター)**
パブリックエンドポイントはデュアルスタックであるため、`IPv6` クラスターのパブリックエンドポイントに `IPv6` および `IPv4` CIDR ブロックを追加できます。これは、2024 年 10 月以降に作成した `ipFamily` が `IPv6` に設定されている新しいクラスターにのみ適用されます。これらのクラスターは、新しいエンドポイントドメイン名 `api.aws` で識別できます。
**パブリックエンドポイントの CIDR ブロック (`IPv4` クラスター)**
`IPv4` クラスターのパブリックエンドポイントに `IPv4` CIDR ブロックを追加できます。`IPv4` クラスターのパブリックエンドポイントに `IPv6` CIDR ブロックを追加することはできません。試みると、EKS は次のエラーメッセージを返します: `The following CIDRs are invalid in publicAccessCidrs`
**パブリックエンドポイントの CIDR ブロック (2024 年 10 月以前に作成された `IPv6` クラスター)**
2024 年 10 月以前に作成した古い `IPv6` クラスターのパブリックエンドポイントに `IPv4` CIDR ブロックを追加できます。これらのクラスターは `eks.amazonaws.com` エンドポイントで識別できます。2024 年 10 月以前に作成したこれらの古い `IPv6` クラスターのパブリックエンドポイントに `IPv6` CIDR ブロックを追加することはできません。試みると、EKS は次のエラーメッセージを返します: `The following CIDRs are invalid in publicAccessCidrs`
## プライベート専用 API サーバーへのアクセス
クラスターの Kubernetes API サーバーエンドポイントに対するパブリックアクセスを無効にした場合は、VPC または[接続されたネットワーク](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)内からのみ API サーバーにアクセスできます。Kubernetes API サーバーエンドポイントにアクセスする方法はいくつかあります。
**接続されたネットワーク**
[AWS トランジットゲートウェイ](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)またはその他の[接続](https://docs.aws.amazon.com/aws-technical-content/latest/aws-vpc-connectivity-options/introduction.html)オプションを使用してネットワークを VPC に接続し、接続されたネットワークのコンピュータを使用します。接続されたネットワークからのポート 443 でのイングレストラフィックを許可するためのルールが、Amazon EKS コントロールプレーンセキュリティグループに含まれていることを確認する必要があります。
**Amazon EC2 踏み台ホスト**
Amazon EC2 インスタンスをクラスターの VPC のパブリックサブネットで起動し、SSH 経由でそのインスタンスにログインして `kubectl` コマンドが実行できます。詳細については[AWS での Linux 踏み台ホスト](https://aws.amazon.com/quickstart/architecture/linux-bastion/)を参照してください。踏み台ホストからのポート 443 でのイングレストラフィックを許可するためのルールが、Amazon EKS コントロールプレーンセキュリティグループに含まれていることを確認する必要があります。詳細については「[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)」を参照してください。
踏み台ホスト用に `kubectl` を設定するときにはクラスターの RBAC 設定に既にマッピングされている AWS 認証情報を使用するか、踏み台が使用する [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) を RBAC 設定に追加してから、エンドポイントのパブリックアクセスを削除します。詳細については[IAM ユーザーおよびロールに Kubernetes API へのアクセスを付与する](grant-k8s-access.md)および[許可されていないか、アクセスが拒否されました (`kubectl`)](troubleshooting.md#unauthorized)を参照してください。
** AWS クラウド9 IDE**
AWS クラウド9 はブラウザだけでコードを記述、実行、およびデバッグできるクラウドベースの統合開発環境 (IDE） です。クラスターの VPC に AWS クラウド9 IDE を作成し、その IDE を使用してクラスターと通信できます。詳細については「[AWS クラウド9 で環境を作成する](https://docs.aws.amazon.com/cloud9/latest/user-guide/create-environment.html)」を参照してください。Amazon EKS コントロールプレーンセキュリティグループに、IDE セキュリティグループからのポート 443 でのイングレストラフィックを許可するためのルールが、含まれていることを確認する必要があります。詳細については「[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)」を参照してください。
AWS クラウド9 IDE 用に `kubectl` を設定するときにはクラスターの RBAC 設定に既にマッピングされている AWS 認証情報を使用するか、IDE が使用する IAM プリンシパルを RBAC 設定に追加してから、エンドポイントのパブリックアクセスを削除してください。詳細については、「[IAM ユーザーおよびロールに Kubernetes API へのアクセスを付与する](grant-k8s-access.md)」および「[許可されていないか、アクセスが拒否されました (`kubectl`)](troubleshooting.md#unauthorized)」を参照してください。
📝 [GitHub でこのページを編集する](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23cluster-endpoint%5D&type=code)
# クラスター API サーバーエンドポイントへのネットワークアクセスを設定する
次のセクションでは、AWS マネジメントコンソール または AWS CLI を使用して、クラスター API サーバーのエンドポイントアクセスを変更できます。
## エンドポイントアクセスの設定 - AWS コンソール
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. クラスター名を選択すると、そのクラスターの情報を表示されます。
1. **[ネットワーキング]** タブを選択し、**[エンドポイントアクセスを管理]** を選択します。
1. **[プライベートアクセス]** の場合はクラスターの Kubernetes API サーバーエンドポイントに対するプライベートアクセスを有効にするか無効にするかを選択してください。プライベートアクセスを有効にした場合、クラスターの VPC 内から送信される Kubernetes API リクエストはプライベート VPC エンドポイントを使用します。パブリックアクセスを無効にするにはプライベートアクセスを有効にする必要があります。
1. **[パブリックアクセス]** の場合はクラスターの Kubernetes API サーバーエンドポイントに対するパブリックアクセスを有効にするか無効にするかを選択してください。パブリックアクセスを無効にすると、クラスターの Kubernetes API サーバーはクラスター VPC 内からのみリクエストを受信できます。
1. (オプション) [**パブリックアクセス**] で有効化を行うと、インターネットからパブリックエンドポイントと通信するためのアドレスを指定できるようになります。[**詳細設定**] を選択してください。などの CIDR ブロックを入力します。。**ブロックに[予約済みアドレス](https://en.wikipedia.org/wiki/Reserved_IP_addresses)を含めることはできません。[**ソースの追加**] を選択すると、追加のブロックを入力できます。指定できる CIDR ブロックには最大数があります。詳細については、「[Amazon EKS と Fargate Service Quotas を表示して管理する](service-quotas.md)」を参照してください。ブロックをまったく指定しない場合、パブリック API サーバーエンドポイントは、`IPv4` (`0.0.0.0/0`) と、さらにデュアルスタック `IPv6` クラスターの `IPv6` (`::/0`) の両方のすべての IP アドレスからのリクエストを受信します。CIDR ブロックを使用してパブリックエンドポイントへのアクセスを制限する場合は、同時にプライベートエンドポイントアクセスも有効化することをお勧めします。これにより、ノードと (使用している場合は) Fargate Pods がクラスターと通信できるようになります。プライベートエンドポイントが有効になっていない場合はパブリックアクセスエンドポイントの CIDR ソースに、VPC からの出力ソースを含める必要があります。例えば、プライベートサブネットに NAT ゲートウェイを介してインターネットと通信するノードがある場合、パブリックエンドポイントで許可された CIDR ブロックの一部として、NAT ゲートウェイのアウトバウンド IP アドレスを追加する必要があります。
1. [**更新**] を選択して終了します。
## エンドポイントアクセスの設定 - AWS CLI
AWS CLI バージョン `1.27.160` 以降を使用して、次のステップを実行してください。現在のバージョンは`aws --version` で確認できます。AWS CLI をインストールまたはアップグレードするには「[AWS CLI のインストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」を参照してください。
1. 次の AWS CLI コマンドを使用してクラスター API サーバーエンドポイントのアクセスを更新します。クラスター名と必要なエンドポイントアクセス値を置き換えます。`endpointPublicAccess=true` を設定した場合は(オプションで) 1 つの CIDR ブロック、または `publicAccessCidrs` の CIDR ブロックのカンマ区切りリストを入力できます。ブロックに[予約済みアドレス](https://en.wikipedia.org/wiki/Reserved_IP_addresses)を含めることはできません。CIDR ブロックを指定すると、パブリック API サーバーエンドポイントはリストされたブロックからのリクエストのみを受信します。指定できる CIDR ブロックには最大数があります。詳細については「[Amazon EKS と Fargate Service Quotas を表示して管理する](service-quotas.md)」を参照してください。CIDR ブロックを使用してパブリックエンドポイントへのアクセスを制限する場合は同時にプライベートエンドポイントアクセスも有効化することをお勧めします。これにより、ノードと (存在している場合は Fargate Pods がクラスターと通信できるようになります。プライベートエンドポイントが有効になっていない場合はパブリックアクセスエンドポイントの CIDR ソースに、VPC からの出力ソースを含める必要があります。例えば、プライベートサブネットに NAT ゲートウェイを介してインターネットと通信するノードがある場合、パブリックエンドポイントで許可された CIDR ブロックの一部として、NAT ゲートウェイのアウトバウンド IP アドレスを追加する必要があります。CIDR ブロックをまったく指定しない場合、パブリック API サーバーエンドポイントはすべての (0.0.0.0/0) IP アドレスからのリクエストと、さらにデュアルスタック `IPv6` クラスターの `IPv6` (`::/0`) も受信します。
**注記**
次のコマンドはAPI サーバーエンドポイントの 1 つの IP アドレスからのプライベートアクセスとパブリックアクセスを有効にします。*203.0.113.5/32* は単一の CIDR ブロック、またはネットワークアクセスを制限する CIDR ブロックのカンマ区切りリストに置き換えます。
```
aws eks update-cluster-config \
--region region-code \
--name my-cluster \
--resources-vpc-config endpointPublicAccess=true,publicAccessCidrs="203.0.113.5/32",endpointPrivateAccess=true
```
出力例は次のとおりです。
```
{
"update": {
"id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000",
"status": "InProgress",
"type": "EndpointAccessUpdate",
"params": [
{
"type": "EndpointPublicAccess",
"value": "true"
},
{
"type": "EndpointPrivateAccess",
"value": "true"
},
{
"type": "publicAccessCidrs",
"value": "[\"203.0.113.5/32\"]"
}
],
"createdAt": 1576874258.137,
"errors": []
}
}
```
1. 次のコマンドでエンドポイントアクセス更新のステータスをモニタリングします。この際、以前のコマンドで返ったクラスター名と更新 ID を使用します。ステータスが `Successful` と表示されたら、更新は完了です。
```
aws eks describe-update \
--region region-code \
--name my-cluster \
--update-id e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000
```
出力例は次のとおりです。
```
{
"update": {
"id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000",
"status": "Successful",
"type": "EndpointAccessUpdate",
"params": [
{
"type": "EndpointPublicAccess",
"value": "true"
},
{
"type": "EndpointPrivateAccess",
"value": "true"
},
{
"type": "publicAccessCidrs",
"value": "[\"203.0.113.5/32\"]"
}
],
"createdAt": 1576874258.137,
"errors": []
}
}
```
📝 [GitHub でこのページを編集する](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23config-cluster-endpoint%5D&type=code)
# EKS クラスターに WiWindows ノードをデプロイする
Amazon EKS クラスターの Windows サポートを有効にして管理し、Linux コンテナと一緒に Windows コンテナを実行する方法について説明します。
## 考慮事項
Windows ノードをデプロイする前に、以下の考慮事項を確認してください。
+ EKS Auto Mode は Windows ノードをサポートしていません
+ `HostProcess` ポッドを使用して Windows ノードでホスト ネットワークを使用できます。詳細については、Kubernetes ドキュメントの「[Create a Windows HostProcessPod](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/)」を参照してください。
+ CoreDNS など、Linux でのみ動作するコアシステム Pod を実行するには、Amazon EKS クラスターに 1 つ以上の Linux ノードまたは Fargate ノードが含まれている必要があります。
+ `kubelet` および `kube-proxy` イベントログは `EKS Windows` Event Log にリダイレクトされ、200 MB の制限に設定されます。
+ Windows ノードで実行されている Pod で、[[セキュリティグループを個別のポッドに割り当てる]](security-groups-for-pods.md) を使用することはできません。
+ Windows ノードで[カスタムネットワーク](cni-custom-network.md)を使用することはできません。
+ `IPv6` を Windows ノードで使用することはできません。
+ Windows ノードは、ノードごとに 1 つの Elastic Network Interface をサポートします。デフォルトでは、Windows ノードごとに実行できる Pod の数は、ノードのインスタンスタイプの Elastic Network Interface ごとに使用できる IP アドレスの数から 1 を引いた数に等しくなります。詳細については、「*Amazon EC2 ユーザーガイド*」の「[各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-eni.html#AvailableIpPerENI)」を参照してください。
+ Amazon EKS クラスターでは、ロードバランサーを持つ単一のサービスが、最大 1,024 個のバックエンド Pod をサポートできます。各ポッドには固有の IP アドレスがあります。[OS ビルド 17763.2746](https://support.microsoft.com/en-us/topic/march-22-2022-kb5011551-os-build-17763-2746-preview-690a59cd-059e-40f4-87e8-e9139cc65de4) で始まる [Windows Server 更新プログラム](https://github.com/microsoft/Windows-Containers/issues/93)以降、以前の 64 個の Pod という上限はなくなりました。
+ Windows コンテナは Fargate の Amazon EKS Pod ではサポートされていません。
+ Windows を搭載した Amazon EKS Hybrid Nodes をホストのオペレーティングシステムとして使用することはできません。
+ `vpc-resource-controller` ポッドからはログを取得できません。コントローラーをデータプレーンにデプロイしていたときには取得できていました。
+ `IPv4` アドレスが新しいポッドに割り当てられるまでにはクールダウン期間があります。これは、古い `kube-proxy` ルールが原因で、同じ `IPv4` アドレスを持つ古いポッドにトラフィックが流れるのを防ぎます。
+ コントローラーのソースは GitHub で管理されます。コントローラーに関する投稿や、問題の登録を行うには、GitHub の [project](https://github.com/aws/amazon-vpc-resource-controller-k8s) にアクセスしてください。
+ Windows マネージド型ノードグループのカスタム AMI ID を指定するときは、AWS IAM オーセンティケーター設定マップに `eks:kube-proxy-windows` を追加します。詳細については、「[AMI ID を指定する場合の制限と条件](launch-templates.md#mng-ami-id-conditions)」を参照してください。
+ サブネットで使用可能な IPv4 アドレスを保持することが重要な場合は、「[EKS Best Practices Guide - Windows Networking IP Address Management](https://aws.github.io/aws-eks-best-practices/windows/docs/networking/#ip-address-management)」のガイダンスを参照してください。
+ EKS アクセスエントリに関する考慮事項
+ Windows ノードで使用するアクセスエントリには、タイプとして `EC2_WINDOWS` を指定する必要があります。詳細については、「[アクセスエントリを作成する](creating-access-entries.md)」を参照してください。
Windows ノード用のアクセスエントリを作成するには、次のように指定します。
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/ --type EC2_Windows
```
## 前提条件
+ 既存のクラスター。
+ CoreDNS を実行するには、クラスターに少なくとも 1 つ (推奨値は少なくとも 2 つ) の Linux ノードまたは Fargate Pod が必要です。レガシー Windows サポートを有効にする場合は、CoreDNS の実行に Linux ノードを使用する必要があります (Fargate Pod は使用できません)。
+ 既存の [Amazon EKS クラスター IAM ロール](cluster-iam-role.md)。
## Windows サポートを有効にする
1. クラスターに Amazon Linux ノードがなく、Pod のセキュリティグループを使用する場合は、次のステップに進みます。それ以外の場合は、[クラスターのロール](cluster-iam-role.md)に `AmazonEKSVPCResourceController` マネージドポリシーがアタッチされていることを確認します。*eksClusterRole* は、自分のクラスターのロール名に置き換えてください。
```
aws iam list-attached-role-policies --role-name eksClusterRole
```
出力例は次のとおりです。
```
{
"AttachedPolicies": [
{
"PolicyName": "AmazonEKSClusterPolicy",
"PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
},
{
"PolicyName": "AmazonEKSVPCResourceController",
"PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSVPCResourceController"
}
]
}
```
前の出力のようにポリシーがアタッチされている場合は、次のステップをスキップします。
1. **[AmazonEKSVPCResourceController](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html)** マネージド型ポリシーを [Amazon EKS クラスターの IAMロール](cluster-iam-role.md)にアタッチします。*eksClusterRole* は、自分のクラスターのロール名に置き換えてください。
```
aws iam attach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
```
1. VPC CNI ConfigMap を更新して Windows IPAM を有効にします。Helm チャートを使用するか、Amazon EKS アドオンとして VPC CNI がクラスターにインストールされた場合、ConfigMap を直接変更できない場合がありますのでご注意ください。Amazon EKS アドオンの設定に関する詳細については、「[Amazon EKS アドオンのためにカスタマイズできるフィールドを決定する](kubernetes-field-management.md)」を参照してください。
1. 次の内容で、*vpc-resource-controller-configmap.yaml* という名前のファイルを作成します。
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-windows-ipam: "true"
```
1. `ConfigMap` をクラスターに適用する
```
kubectl apply -f vpc-resource-controller-configmap.yaml
```
1. クラスターの認証モードが `aws-auth` configmap を有効にするように設定されている場合は、次の手順を実行します。
+ `aws-auth` `ConfigMap` に、Windows ノードのインスタンスロールに `eks:kube-proxy-windows` RBAC 権限グループを含めるマッピングが含まれていることを確認します。次のコマンドを使用してインストールします。
```
kubectl get configmap aws-auth -n kube-system -o yaml
```
出力例は次のとおりです。
```
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
- eks:kube-proxy-windows # This group is required for Windows DNS resolution to work
rolearn: arn:aws:iam::111122223333:role/eksNodeRole
username: system:node:{{EC2PrivateDNSName}}
[...]
```
グループの下に `eks:kube-proxy-windows` がリストされているはずです。グループが指定されていない場合は、必要なグループを含むように `ConfigMap` を更新するか、作成する必要があります。`aws-auth` `ConfigMap`の詳細については、「[`aws-auth` `ConfigMap` をクラスターに適用する](auth-configmap.md#aws-auth-configmap)」を参照してください。
1. クラスターの認証モードが `aws-auth` configmap を無効にするように設定されている場合は、EKS アクセスエントリを使用できます。Windows インスタンスで使用する新しいノードロールを作成すると、EKS によって `EC2_WINDOWS` タイプのアクセスエントリが自動的に作成されます。
## Windows ポッドをデプロイする
クラスターにポッドをデプロイするときに、さまざまなノードタイプを混在させて実行する場合に使用するオペレーティングシステムを指定する必要があります。
Linux Pod の場合は、マニフェストで以下のノードセレクターテキストを使用します。
```
nodeSelector:
kubernetes.io/os: linux
kubernetes.io/arch: amd64
```
Windows Pod の場合は、マニフェストで以下のノードセレクターテキストを使用します。
```
nodeSelector:
kubernetes.io/os: windows
kubernetes.io/arch: amd64
```
[サンプルアプリケーション](sample-deployment.md)をデプロイして、使用されているノードセレクタを確認できます。
## Windows ノードでより高い Pod 密度をサポートする
Amazon EKS では、各 Pod に VPC の `IPv4` アドレスが割り当てられます。このため、ノード上でさらに多くの Pod を実行するのに十分なリソースがある場合でも、ノードにデプロイできる Pod の数の上限は、使用可能な IP アドレスによって制限されます。Windows ノードでサポートされる Elastic Network Interface は 1 つだけなので、デフォルトでは Windows ノードで使用できる IP アドレスの最大数は次のようになります。
```
Number of private IPv4 addresses for each interface on the node - 1
```
1 つの IP アドレスがネットワークインターフェイスのプライマリ IP アドレスとして使用されるため、Pod に割り当てることはできません。
IP プレフィックスの委任を有効にすると、Windows ノードで Pod 密度をより高めることができます。この機能により、セカンダリ `IPv4` アドレスを割り当てる代わりに、プライマリネットワークインターフェイスに `/28``IPv4` プレフィックスを割り当てることができます。IP プレフィックスを割り当てると、ノードで使用できる `IPv4` アドレスの最大数が次のように増加します。
```
(Number of private IPv4 addresses assigned to the interface attached to the node - 1) * 16
```
使用可能な IP アドレス数が大幅に増加したため、使用可能な IP アドレスによってノード上の Pod の数をスケーリングできる機能が制限されることはありません。詳細については、「[プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md)」を参照してください。
# Windows サポートを無効にする
1. クラスターに Amazon Linux ノードが含まれていて、[ポッドのセキュリティグループ](security-groups-for-pods.md)をそれらとともに使用する場合は、このステップをスキップしてください。
[クラスターのロール](cluster-iam-role.md)から `AmazonVPCResourceController` マネージド IAM ポリシーを削除します。*eksClusterRole* は、実際に使用するクラスターのロールに置き換えてください。
```
aws iam detach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
```
1. `amazon-vpc-cni` ConfigMap で Windows IPAM を無効にします。
```
kubectl patch configmap/amazon-vpc-cni \
-n kube-system \
--type merge \
-p '{"data":{"enable-windows-ipam":"false"}}'
```
# インターネットアクセスが制限されたプライベートクラスターをデプロイする
このトピックでは、AWS Cloud にデプロイされているが、アウトバウンドインターネットアクセスがない Amazon EKS クラスターをデプロイする方法について説明します。AWS Outposts にローカルクラスターがある場合、このトピックの代わりに「[AWS Outposts で Amazon Linux ノードを作成する](eks-outposts-self-managed-nodes.md)」を参照してください。
Amazon EKS でのネットワークに詳しくない場合は、「[De-mystifying cluster networking for Amazon EKS worker nodes (Amazon EKS ワーカーノードのクラスターネットワークを解明する)](https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes)」を参照してください。クラスターにアウトバウンドインターネットアクセスがない場合、次の要件を満たす必要があります。
## クラスターアーキテクチャの要件
+ クラスターは VPC 内のコンテナレジストリからイメージを取得する必要があります。VPC 内に Amazon Elastic Container Registry を作成し、そこにコンテナイメージをコピーしてノードの取得元にすることができます。詳細については、「[あるリポジトリから別のリポジトリにコンテナイメージをコピーする](copy-image-to-repository.md)」を参照してください。
+ クラスターでは、エンドポイントのプライベートアクセスが有効になる必要があります。これは、ノードをクラスターエンドポイントに登録するために必要です。エンドポイントのパブリックアクセスはオプションです。詳細については、「[クラスター API サーバーエンドポイント](cluster-endpoint.md)」を参照してください。
## ノードの要件
+ セルフマネージド型 Linux ノードおよび Windows ノードには、起動する前に次のブートストラップ引数を含める必要があります。これらの引数は Amazon EKS のイントロスペクションをバイパスするため、VPC 内からの Amazon EKS API へのアクセスは不要です。
1. 次のコマンドを使用して、クラスターのエンドポイントの値を確認します。*マイクラスター* の部分は自分のクラスター名に置き換えます。
```
aws eks describe-cluster --name my-cluster --query cluster.endpoint --output text
```
出力例は次のとおりです。
```
https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
```
1. 次のコマンドを使用して、クラスターの認証機関の値を確認します。*マイクラスター* の部分は自分のクラスター名に置き換えます。
```
aws eks describe-cluster --name my-cluster --query cluster.certificateAuthority --output text
```
返された出力は長い文字です。
1. NodeConfig オブジェクト内の `apiServerEndpoint` および `certificateAuthority` の値を、前のコマンドで返された出力の値に置き換えます。セルフマネージド型 Amazon Linux 2023 ノードを起動する際にブートストラップ引数を指定する方法の詳細については、「[セルフマネージド Amazon Linux ノードを作成する](launch-workers.md)」および「[セルフマネージド Microsoft Windows ノードの作成](launch-windows-workers.md)」を参照してください。
+ Linux ノードの場合:
```
---
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: [.replaceable]https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
certificateAuthority: [.replaceable]Y2VydGlmaWNhdGVBdXRob3JpdHk=
...
```
その他の引数については、GitHub の「[ブートストラップのスクリプト](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh)」を参照してください。
+ Windows ノードの場合:
**注記**
カスタムサービス CIDR を使用している場合は`-ServiceCIDR` パラメータを使用して指定する必要があります。そうしないと、クラスター内の Pod の DNS 解決が失敗します。
```
-APIServerEndpoint cluster-endpoint -Base64ClusterCA certificate-authority
```
その他の引数については「[ブートストラップスクリプトの設定パラメータ](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters)」を参照してください。
+ クラスターの `aws-auth` `ConfigMap` は VPC 内から作成する必要があります。エントリの作成と `aws-auth` `ConfigMap` への追加の詳細については、ターミナルで `eksctl create iamidentitymapping --help` と入力してください。サーバーに `ConfigMap` が存在しない場合は、このコマンドを使用して ID マッピングを追加したときに `eksctl` によって作成されます。
## ポッドの要件
+ **Pod Identity** – EKS Pod Identity と共に設定されたポッドは、EKS Auth API から認証情報を取得します。アウトバウンドインターネットアクセスがない場合は、EKS Auth API の VPC エンドポイントを作成して使用する必要があります: `com.amazonaws.region-code.eks-auth`。EKS と EKS Auth VPC エンドポイントの詳細については、「[AWS プライベートリンクを使用して Amazon EKS にアクセスする](vpc-interface-endpoints.md)」を参照してください。
+ **IRSA** - [サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md)で設定されたポッドは、AWS Security Token Service (AWS STS) API コールから認証情報を取得します。アウトバウンドインターネットアクセスがない場合は、VPC 内で AWS STS VPC エンドポイントを作成して使用する必要があります。ほとんどの AWS `v1` SDK は、AWS STS VPC エンドポイントを使用しないグローバル AWS STS エンドポイント (`sts.amazonaws.com`) をデフォルトで使用します。AWS STS VPC エンドポイントを使用するには、リージョンの AWS STS エンドポイント (`sts.region-code.amazonaws.com`) を使用するように SDK を構成する必要がある場合があります。詳細については、「[サービスアカウントの AWS Security Token Service エンドポイントを設定する](configure-sts-endpoint.md)」を参照してください。
+ Pod がアクセスする必要のあるすべての AWS サービスについて、クラスターの VPC サブネットに VPC インターフェイスエンドポイントが必要です。詳細については、「[インターフェイス VPC エンドポイントを使用して AWS サービスにアクセスする](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)」を参照してください。下表には、一般的に使用されるサービスとエンドポイントがリスト表示されています。エンドポイントの詳細なリストについては、[AWS PrivateLink ガイド](https://docs.aws.amazon.com/vpc/latest/privatelink/)の「[AWS PrivateLink と連携する AWS サービス](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html)」を参照してください。
VPC エンドポイントのために [[プライベート DNS 名を有効にする]](https://docs.aws.amazon.com/vpc/latest/privatelink/interface-endpoints.html#enable-private-dns-names) ことをお勧めします。これにより、ワークロードはパブリック AWS サービスエンドポイントを問題なく引き続き使用できます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/private-clusters.html)
+ セルフマネージド型ノードはすべて、必要な VPC インターフェイスエンドポイントを持つサブネットにデプロイする必要があります。マネージド型ノードグループを作成する場合には、VPC インターフェイスエンドポイントのセキュリティグループでサブネットの CIDR を許可するか、ノードのセキュリティグループを作成し VPC インターフェイスエンドポイントのセキュリティグループに追加する必要があります。
+ **EFS ストレージ ** - Pod で Amazon EFS ボリュームを使用する場合、「[Store an elastic file system with Amazon EFS](efs-csi.md)」をデプロイする前に、Amazon EKS クラスターと同じ AWS リージョンを使用するように、ドライバーの [kustomization.yaml](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/deploy/kubernetes/overlays/stable/kustomization.yaml) ファイルを変更して、コンテナイメージを設定する必要があります。
+ Route 53 は AWS PrivateLink をサポートしていません。プライベート Amazon EKS クラスターから Route 53 DNS レコードを管理することはできません。これは Kubernetes [external-dns](https://github.com/kubernetes-sigs/external-dns) に影響します。
+ EKS 最適化 AMI を使用した場合は、上記の表に挙げた `ec2` エンドポイントを有効にする必要があります。あるいは、ノードの DNS 名を手動で設定することもできます。最適化 AMI では、EC2 API を使用して、ノードの DNS 名を自動的に設定します。
+ [AWS Load Balancer Controller](aws-load-balancer-controller.md) を使用して、AWS Application Load Balancer (ALB) および Network Load Balancer をプライベートクラスターにデプロイできます。デプロイするときは、[コマンドラインフラグ](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/configurations/#controller-command-line-flags)を使用して、`enable-shield`、`enable-waf`、および `enable-wafv2` を false に設定する必要があります。Ingress オブジェクトのホスト名を使用した[証明書の検出](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/cert_discovery/#discover-via-ingress-rule-host)は、サポートされていません。これは、コントローラーが VPC インターフェイスエンドポイントを持たない AWS Certificate Manager に到達する必要があるからです。
このコントローラーでは、Fargate で必要な IP ターゲットを持つネットワークロードバランサをサポートします。詳細については、「[Application Load Balancer を使用してアプリケーションと HTTP トラフィックをルーティングする](alb-ingress.md)」および「[ネットワークロードバランサーを作成する](network-load-balancing.md#network-load-balancer)」を参照してください。
+ [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) がサポートされています。クラスター自動スケーラー Pod をデプロイする場合は、コマンドラインに `--aws-use-static-instance-list=true` が含まれていることを確認してください。詳細については、GitHub で[「静的インスタンス・リストを使用」](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#use-static-instance-list)を参照してください。ワーカーノード VPC には、AWS STS VPC エンドポイントと自動スケーリング VPC エンドポイントも含める必要があります。
+ 一部のコンテナソフトウェア製品では、AWS Marketplace Metering Service にアクセスする API コールを使用して、使用状況をモニタリングします。プライベートクラスターではこれらの呼び出しが許可されないため、これらのコンテナタイプはプライベートクラスターには使用できません。
# Karpenter と Cluster Autoscaler を使用したクラスターコンピューティングのスケーリング
自動スケーリングとは、需要の変化に合わせてリソースを自動的に増減させる機能です。これは Kubernetes の主要な機能であり、この機能がなければ、手動で実行するために膨大な人的リソースが必要になります。
## EKS Auto Mode
Amazon EKS Auto Mode は、クラスターコンピューティングリソースを自動的にスケールします。ポッドが既存のノードに収まらない場合、EKS Auto Mode は新しいノードを作成します。また、EKS Auto Mode はワークロードの統合とノードの削除も行います。EKS Auto Mode は Karpenter に基づいて構築されます。
詳細については、以下を参照してください。
+ [EKS Auto Mode を使用してクラスターインフラストラクチャを自動化する](automode.md)
+ [EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)
+ [Amazon EKS Auto Mode クラスターにサンプルの拡張ワークロードをデプロイする](automode-workload.md)
## その他のソリューション
Amazon EKS はさらに 2 つの自動スケーリング製品をサポートしています。
**Karpenter**
Karpenter は、アプリケーションの可用性とクラスターの効率の向上に役立つ柔軟で高性能な Kubernetes クラスターオートスケーラーです。Karpenter は、アプリケーションの負荷の変化に応じて、適切なサイズのコンピューティングリソース (Amazon EC2 インスタンスなど) を 1 分未満で起動します。Kubernetes と AWS との統合を通じて、Karpenter は、ワークロードの要件を正確に満たすジャストインタイムコンピューティングリソースをプロビジョンできます。Karpenter は、クラスターワークロードの具体的な要件に基づいて、新しいコンピューティングリソースを自動的にプロビジョンします。これには、コンピューティング、ストレージ、高速化、スケジューリングの各要件が含まれます。Amazon EKS は Karpenter を使用したクラスターをサポートしていますが、Karpenter は適合するいずれの Kubernetes クラスターでも動作します。詳細については、[Karpenter](https://karpenter.sh/docs/) のドキュメントを参照してください。
Karpenter は、AWS ユーザーが Kubernetes クラスターでインストール、設定、管理を行うオープンソースソフトウェアです。AWS は、Amazon EKS クラスターで互換性のあるバージョンを使用して Karpenter を変更せずに実行した場合にテクニカルサポートを提供します。他のカスタマーマネージドソフトウェアと同様に、お客様が Karpenter コントローラーの可用性とセキュリティ、および、Karpenter コントローラーやその実行中の Kubernetes クラスターをアップグレードするときの適切なテスト手順を維持することが重要です。Karpenter の AWS サービスレベルアグリーメント (SLA) はなく、お客様は Karpenter によって起動された EC2 インスタンスがビジネス要件を満たしていることを確認する必要があります。
**Cluster Autoscaler**
Kubernetes の Cluster Autoscalerは、ポッドが失敗したり、他のノードに再スケジュールされた場合に、クラスター内のノード数を自動的に調整します。Cluster Autoscaler は Auto Scaling グループを使用します。詳細については、「[AWS の Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)」を参照してください。
# Amazon EKS での Amazon Application Recovery Controller (ARC) のゾーンシフトの詳細
Kubernetes には、アベイラビリティーゾーン (AZ) のヘルスの低下や障害などのイベントに対するアプリケーションの回復力を高めるネイティブ機能があります。Amazon EKS クラスターでワークロードを実行する場合、[Amazon Application Recovery Controller (ARC) のゾーンシフト](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.html)または[ゾーンオートシフト](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.html)を使用して、アプリケーション環境の耐障害性とアプリケーション復旧をさらに改善できます。ARC ゾーンシフトは、ゾーンシフトが期限切れになるまで、またはキャンセルするまで、障害のある AZ からリソースのトラフィックを移動できる一時的な手段として設計されています。必要に応じてゾーンシフトを拡張できます。
EKS クラスターのゾーンシフトを開始することも、ゾーンオートシフトを有効にして AWS がトラフィックをシフトできるようにすることもできます。このシフトは、正常な AZ のワーカーノードで実行されているポッドのネットワークエンドポイントのみを使用するようにクラスター内の東西ネットワークトラフィックのフローを更新します。さらに、EKS クラスター内のアプリケーションの入力トラフィックを処理する ALB または NLB は、トラフィックを正常な AZ 内のターゲットに自動的にルーティングします。可用性を最大限に高めることを目標にしているお客様にとって、AZ で障害が発生した場合は、障害のある AZ が回復するまでその AZ からすべてのトラフィックを移動できることが重要です。そのためには、[ARC ゾーンシフト で ALB または NLB を有効にする](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html)こともできます。
## ポッド間の東西ネットワークトラフィックフローを理解する
次の図は、2 つのワークロードの例である Orders と Products を示しています。この例の目的は、さまざまな AZ でワークロードとポッドが通信する方法を示します。
![\[ネットワークトラフィックの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/zs-traffic-flow-before-1.png)
![\[ネットワークトラフィックの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/zs-traffic-flow-before-2.png)
1. Orders が Products と通信するには、まず Orders が送信先のサービスの DNS 名を解決する必要があります。Orders は CoreDNS と通信して、そのサービスの仮想 IP アドレス (クラスター IP) を取得します。Orders が Products のサービス名を解決すると、そのターゲット IP アドレスにトラフィックが送信されます。
1. kube-proxy はクラスター内のすべてのノードで実行され、サービス用の [EndpointSlices](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/) を継続的に監視します。サービスが作成されると、EndpointSlice コントローラーによってバックグラウンドで EndpointSlice が作成され、管理されます。各 EndpointSlice には、ポッドアドレスのサブセットと、それらが実行されているノードを含むエンドポイントのリストまたは表があります。kube-proxy は、ノードで `iptables` を使用して、これらのポッドエンドポイントごとにルーティングルールを設定します。また、kube-proxy は、基本的なロードバランシングも行います。サービスのクラスターの IP アドレス宛てのトラフィックを、ポッドの IP アドレスに直接送信するようリダイレクトします。kube-proxy は、送信接続の送信先 IP アドレスを書き換えることでこれを行います。
1. 次に、前の図に示されているように、ネットワークパケットは、各ノードの ENI を使用して AZ 2 の Products ポッドに送信されます。
### Amazon EKS での ARC ゾーンシフトについて
環境に AZ の障害がある場合は、EKS クラスター環境のゾーンシフトを開始できます。または、ゾーンオートシフトを使用して AWS がトラフィックのシフトを管理できます。ゾーンオートシフトでは、AWS は AZ の全体的なヘルスをモニタリングし、クラスター環境内の障害のある AZ からトラフィックを自動的に移動することで、潜在的な AZ 障害に対応します。
ARC で Amazon EKS クラスターのゾーンシフトを有効にすると、ARC コンソール、AWS CLI、またはゾーンシフト API やゾーンオートシフト API を使用して、ゾーンシフトをトリガーしたり、ゾーンオートシフトを有効にしたりできます。EKS ゾーンシフト中、次のことが自動的に行われます。
+ 影響を受ける AZ 内のすべてのノードが遮断されます。これにより、Kubernetes スケジューラーが異常な AZ のノードに新しいポッドをスケジューリングできなくなります。
+ [マネージドノードグループ](managed-node-groups.md)を使用している場合、[https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage)は停止され、Auto Scaling グループが更新され、新しい EKS データプレーンノードが正常な AZ でのみ起動されるようにします。
+ 異常な AZ のノードは終了されず、ポッドはこれらのノードから削除されません。これは、ゾーンシフトの有効期限が切れたりキャンセルされたりしたときに、トラフィックがフル容量で AZ に安全に戻ることができるようにするためです。
+ EndpointSlice コントローラーは、障害のある AZ 内のすべてのポッドエンドポイントを検索し、関連する EndpointSlices から削除します。これにより、正常な AZ のポッドエンドポイントのみがネットワークトラフィックの受信対象になります。ゾーンシフトがキャンセルまたは期限切れになると、EndpointSlice コントローラーは EndpointSlices を更新して、復元された AZ にエンドポイントを含めます。
以下の図は、EKS ゾーンシフトによって、クラスター環境で正常なポッドエンドポイントのみがターゲットにされる方法についての大まかな概要を示しています。
![\[ネットワークトラフィックの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/zs-traffic-flow-after-1.png)
![\[ネットワークトラフィックの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/zs-traffic-flow-after-2.png)
## EKS ゾーンシフトの要件
ゾーンシフトを EKS で正常に機能させるには、事前に AZ の障害に対する回復性を実現できるようにクラスター環境を設定する必要があります。以下は、回復性を確保するのに役立つ設定オプションのリストです。
+ 複数の AZ にクラスターのワーカーノードをプロビジョニングする
+ 1 つの AZ を削除しても対応できる十分なコンピューティング容量をプロビジョニングする
+ CoreDNS を含むポッドをすべての AZ でプリスケールする
+ すべての AZ に複数のポッドレプリカを分散して、単一の AZ から移動した場合でも十分な容量を確保できるようにする
+ 相互依存ポッドまたは関連ポッドを同じ AZ に配置する
+ AZ からのゾーンシフトを手動で開始することで、1 つの AZ がない状態でもクラスター環境が期待どおりに動作することをテストします。または、ゾーンオートシフトを有効にし、オートシフトの練習運用に頼ることもできます。手動または練習のゾーンシフトによるテストは、EKS でゾーンシフトを機能させるために必須ではありませんが、強くお勧めします。
### 複数のアベイラビリティーゾーンに EKS ワーカーノードをプロビジョニングする
AWS リージョンには、アベイラビリティーゾーン (AZ) と呼ばれる物理データセンターがある複数の別々の場所があります。AZ は、リージョン全体に影響を与える可能性のある同時障害を回避するために、互いに物理的に離れた場所に配置されています。EKS クラスターをプロビジョニングする場合は、リージョン内の複数の AZ にワーカーノードをデプロイすることをお勧めします。これにより、クラスター環境は 1 つの AZ の障害に対する回復力が向上し、他の AZ で実行されるアプリケーションの高可用性を維持できます。影響を受ける AZ からゾーンシフトを開始すると、クラスターの高可用性は維持するために、EKS 環境のクラスター内ネットワークは自動的に正常な AZ のみを使用するよう更新されます。
EKS 環境にマルチ AZ 設定を実施することで、システム全体の信頼性が向上します。ただし、マルチ AZ 環境は、アプリケーションデータの転送と処理方法に影響を与え、環境のネットワーク料金に影響します。特に、頻繁な egress クロスゾーントラフィック (AZ 間に分散されたトラフィック) は、ネットワーク関連のコストに大きな影響を与える可能性があります。さまざまな戦略を適用して、EKS クラスター内のポッド間のクロスゾーントラフィックの量を制御し、関連するコストを削減できます。高可用性 EKS 環境を実行するときにネットワークコストを最適化する方法の詳細については、[https://aws.github.io/aws-eks-best-practices/cost_optimization/cost_opt_networking/](https://aws.github.io/aws-eks-best-practices/cost_optimization/cost_opt_networking/)を参照してください。
次の図は、3 つの正常な AZ を持つ高可用性 EKS 環境を示しています。
![\[ネットワークの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/zs-ha-before-failure.png)
次の図は、3 つの AZ を持つ EKS 環境が AZ の障害に対して回復力があり、他の 2 つの正常な AZ が残っているために高可用性を維持する方法を示しています。
![\[ネットワークの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/zs-ha-after-failure.png)
### 1 つのアベイラビリティーゾーンの削除に耐えるのに十分なコンピューティング容量をプロビジョニングする
EKS データプレーンでコンピューティングインフラストラクチャのリソース使用率とコストを最適化するには、コンピューティング容量をワークロード要件に合わせることをお勧めします。ただし、**すべてのワーカーノードがフル容量**である場合、新しいポッドをスケジュールする前に、新しいワーカーノードを EKS データプレーンに追加する必要があります。重要なワークロードを実行する場合、通常、負荷の急増やノードのヘルスの問題などのシナリオに対処するために、冗長な容量をオンラインで運用することをお勧めします。ゾーンシフトを使用する予定がある場合は、障害が発生したときに AZ 全体の容量を削除することになります。そのため、いずれか 1 つの AZ がオフラインになっても負荷を十分に処理できるよう、冗長なコンピューティング容量を調整する必要があります。
コンピューティングリソースをスケールすると、EKS データプレーンに新しいノードを追加するプロセスには一定の時間がかかります。これは、特にゾーン障害が発生した場合に、アプリケーションのリアルタイムのパフォーマンスと可用性に影響を与える可能性があります。EKS 環境は、エンドユーザーやクライアントのエクスペリエンスが低下させることなく、1 つの AZ を失った場合の負荷を吸収できる必要があります。これは、新しいポッドが必要な時点からワーカーノードで実際にスケジュールされる時点までの遅延を最小限に抑えるか、排除することを意味します。
さらに、ゾーンの障害が発生した場合は、コンピューティング容量の制約に直面するリスクを軽減する必要があります。これにより、新しく必要なノードが正常な AZ の EKS データプレーンに追加されるのを防ぐことができます。
これらの潜在的な悪影響のリスクを軽減するために、各 AZ の一部のワーカーノードでコンピューティング容量を過剰にプロビジョニングすることをお勧めします。これにより、Kubernetes スケジューラには、新しいポッド配置に使用できる既存の容量が確保されます。これは、環境内でいずれか 1 つの AZ を失った場合に特に重要です。
### 複数のポッドレプリカを実行してアベイラビリティーゾーンに分散する
Kubernetes を使用すると、1 つのアプリケーションの複数のインスタンス (ポッドレプリカ) を実行してワークロードを事前スケールできます。アプリケーションに対して複数のポッドレプリカを実行すると、単一障害点がなくなり、単一のレプリカにかかるリソース負荷が軽減されることで、全体的なパフォーマンスが向上します。ただし、アプリケーションの高可用性と耐障害性向上を実現するには、トポロジドメインとも呼ばれる異なる障害ドメインにまたがってアプリケーションの複数のレプリカを分散させて実行することをお勧めします。このシナリオの障害ドメインはアベイラビリティーゾーンです。[トポロジの分散制約](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/)を使用することで、既存の静的安定性を持つようにアプリケーションをセットアップできます。その結果、AZ の障害が発生した場合でも、環境には正常な AZ に十分なレプリカがあり、トラフィックの急増やスパイクにすぐに対応できます。
下図は、すべての AZ が正常である場合の、東西トラフィックフローが発生している EKS 環境を示しています。
![\[ネットワークの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/zs-spread-constraints.png)
次の図は、1 つの AZ で障害が発生し、ゾーンシフトを開始した、東西トラフィックフローが発生している EKS 環境を示しています。
![\[ネットワークの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/zs-spread-constraints-2.png)
次のコードスニペットは、Kubernetes で複数のレプリカを使用してワークロードをセットアップする方法の例です。
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders
spec:
replicas: 9
selector:
matchLabels:
app:orders
template:
metadata:
labels:
app: orders
tier: backend
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: orders
```
最も重要なのは、DNS サーバーソフトウェア (CoreDNS/kube-dns) の複数のレプリカを実行し、それらがデフォルトで設定されていない場合は、同様のトポロジ分散制約を適用することです。これにより、単一の AZ 障害がある場合に、正常な AZ に十分な DNS ポッドがあり、クラスター内の他の通信ポッドのサービス検出リクエストを引き続き処理できます。[CoreDNS EKS アドオン](managing-coredns.md)には、複数の AZ に使用可能なノードがある場合に、CoreDNS ポッドがクラスターのアベイラビリティーゾーンに分散されるようにするデフォルト設定があります。必要に応じて、これらのデフォルト設定を独自のカスタム設定に置き換えることもできます。
[Helm で CoreDNS](https://github.com/coredns/helm/tree/master) をインストールする場合、[values.yaml ファイル](https://github.com/coredns/helm/blob/master/charts/coredns/values.yaml)で `replicaCount` を更新して、各 AZ に十分なレプリカを確保できます。さらに、これらのレプリカがクラスター環境内の異なる AZ に分散されるようにするには、同じ `values.yaml` ファイルで `topologySpreadConstraints` プロパティを更新してください。次のコードスニペットは、これを行うために CoreDNS を設定する方法を示しています。
**CoreDNS Helm の values.yaml**
```
replicaCount: 6
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
k8s-app: kube-dns
```
AZ の障害が発生した場合は、CoreDNS の自動スケーリングシステムを使用して CoreDNS ポッドの負荷の増加を吸収できます。必要な DNS インスタンスの数は、クラスターで実行されているワークロードの数によって異なります。CoreDNS は CPU バインドであり、[Horizontal Pod Autoscaler (HPA)](https://aws.github.io/aws-eks-best-practices/reliability/docs/application/#horizontal-pod-autoscaler-hpa) を使用して CPU に基づいてスケールできます。以下は、ニーズに合わせて変更できる例です。
```
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: coredns
namespace: default
spec:
maxReplicas: 20
minReplicas: 2
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: coredns
targetCPUUtilizationPercentage: 50
```
また、EKS は、CoreDNS の EKS アドオンバージョンで CoreDNS デプロイの自動スケーリングを管理できます。この CoreDNS オートスケーラーは、ノード数や CPU コア数など、クラスターの状態を継続的にモニタリングします。この情報に基づいて、コントローラーは EKS クラスター内の CoreDNS デプロイのレプリカ数を動的に調整します。
[CoreDNS EKS アドオンで自動スケーリング設定](coredns-autoscaling.md)を有効にするには、次の構成設定を使用します。
```
{
"autoScaling": {
"enabled": true
}
}
```
[NodeLocal DNS](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/) または[クラスター比例オートスケーラー](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler)を使用して CoreDNS をスケールすることもできます。詳細については、「[CoreDNS の水平スケーリング](https://aws.github.io/aws-eks-best-practices/scalability/docs/cluster-services/#scale-coredns-horizontally)」を参照してください。
### 同じアベイラビリティーゾーンで相互依存ポッドを同じ場所に配置する
通常、アプリケーションには、エンドツーエンドのプロセスを正常に完了するために相互に通信する必要がある、個別のワークロードがあります。これらの異なるアプリケーションが異なる AZ に分散しており、同じ AZ に配置されていない場合、単一の AZ の障害がエンドツーエンドのプロセスに影響を与える可能性があります。例えば、**アプリケーション A** が AZ 1 と AZ 2 に複数のレプリカを持ち、**アプリケーション B** が AZ 3 にすべてのレプリカを持つ場合、AZ 3 が失われると、**アプリケーション A** と**アプリケーション B** の 2 つのワークロード間のエンドツーエンドのプロセスに影響が生じます。トポロジの分散制約とポッドのアフィニティを組み合わせると、すべての AZ にポッドを分散することで、アプリケーションの回復力を高めることができます。さらに、これにより、特定のポッドがコロケーションされるようにするためのポッド間の関係が設定されます。
[ポッドのアフィニティのルール](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/)を使用すると、ワークロード間の関係を定義して Kubernetes スケジューラーの動作に影響を与え、同じワーカーノードまたは同じ AZ にポッドを配置できます。このスケジューリング制約をどの程度厳格にするかを設定することもできます。
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: products
namespace: ecommerce
labels:
app.kubernetes.io/version: "0.1.6"
spec:
serviceAccountName: graphql-service-account
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- orders
topologyKey: "kubernetes.io/hostname"
```
次の図は、ポッドアフィニティルールを使用して同じノードにコロケーションされた複数のポッドを示しています。
![\[ネットワークの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/zs-pod-affinity-rule.png)
### クラスター環境が AZ の損失を処理できることをテストする
前のセクションで説明した要件を完了したら、次のステップは、AZ の損失を処理するのに十分なコンピューティングとワークロード容量があることをテストすることです。これを行うには、EKS でゾーンシフトを手動で開始します。または、ゾーンオートシフトを有効にして練習実行を設定して、クラスター環境内の AZ を 1 つ減らしてアプリケーションが期待どおりに機能することをテストすることもできます。
## よくある質問
**この機能を使用する理由は何ですか?**
EKS クラスターで ARC ゾーンシフトまたはゾーンオートシフトを使用することで、クラスター内ネットワークトラフィックを障害のある AZ から移行する迅速な復旧プロセスを自動化することで、Kubernetes アプリケーションの可用性をより適切に維持できます。ARC を使用すると、障害のある AZ イベント中に回復期間を延長することがある、長く複雑なステップを回避できます。
**この機能は他の AWS サービスとどのように連携しますか?**
EKS は ARC と統合され、AWS で復旧オペレーションを実行するためのプライマリインターフェイスを提供します。クラスター内トラフィックが障害のある AZ から適切にルーティングされるように、EKS は Kubernetes データプレーンで実行されているポッドのネットワークエンドポイントのリストを変更します。クラスターへの外部トラフィックのルーティングに Elastic Load Balancing を使用している場合は、ロードバランサーを ARC に登録し、ゾーンシフトを開始して、トラフィックが機能低下した AZ に流れるのを防ぐことができます。ゾーンシフトは、EKS マネージド型ノードグループによって作成された Amazon EC2 Auto Scaling グループでも機能します。障害のある AZ が新しい Kubernetes ポッドまたはノードの起動に使用されるのを防ぐため、EKS は障害のある AZ を Auto Scaling グループから削除します。
**この機能はデフォルトの Kubernetes 保護とどのように異なりますか?**
この機能は、顧客のアプリケーションの回復力を高めるいくつかの Kubernetes 組み込み保護と連携して機能します。ポッドの準備状況とライブネスプローブを設定して、ポッドがいつトラフィックを取るかを決定できます。これらのプローブで障害が発生すると、Kubernetes はこれらのポッドをサービスのターゲットとして削除し、トラフィックはポッドに送信されなくなります。これは便利ですが、AZ が機能低下したときに障害が発生することが保証されるように、これらのヘルスチェックを設定するのは簡単ではありません。ARC ゾーンシフト機能には、Kubernetes のネイティブ保護が十分でない場合に、機能低下した AZ を完全に分離するのに役立つ追加のセーフティネットが用意されています。ゾーンシフトにはまた、アーキテクチャの運用準備状況と回復性を簡単にテストする方法も用意されています。
**AWS はユーザーに代わってゾーンシフトを開始できますか?**
はい。ARC ゾーンシフトを完全に自動化する方法が必要な場合は、ARC ゾーンオートシフトを有効にできます。ゾーンオートシフトでは、AWS を使用して EKS クラスターの AZ の状態を監視し、AZ の障害が検出されるとゾーンシフトを自動的に開始できます。
**この機能を使用し、ワーカーノードとワークロードが事前にスケーリングされていない場合はどうなりますか?**
ゾーンシフト中に事前スケールされておらず、追加のノードやポッドのプロビジョニングに依存している場合、復旧が遅れるリスクがあります。Kubernetes データプレーンに新しいノードを追加するプロセスには時間がかかるため、特にゾーンの障害が発生した場合に、アプリケーションのリアルタイムのパフォーマンスと可用性に影響を与える可能性があります。さらに、ゾーンの障害が発生した場合は、コンピューティング容量の制約により、新たに必要なノードが正常な AZ に追加できなくなる可能性があります。
ワークロードが事前にスケールされておらず、クラスター内のすべての AZ に分散されていない場合、ゾーンの障害により、影響を受ける AZ のワーカーノードでのみ実行されているアプリケーションの可用性に影響する可能性があります。アプリケーションの可用性が完全に停止するリスクを軽減するため、EKS にはフェイルセーフ機能があります。この機能により、ワークロードのすべてのエンドポイントが障害が発生している AZ にある場合でも、障害ゾーンのポッドエンドポイントにトラフィックを送信することが可能です。ただし、ゾーンの問題が発生した場合でも可用性を維持するために、アプリケーションを事前にスケールしてすべての AZ に分散することを強くお勧めします。
**ステートフルアプリケーションを実行している場合、これはどのように機能しますか?**
ステートフルアプリケーションを実行している場合は、ユースケースとアーキテクチャに基づいて、耐障害性を評価する必要があります。アクティブ/スタンバイのアーキテクチャまたはパターンがある場合、アクティブが障害のある AZ にある可能性があります。アプリケーションレベルでは、スタンバイがアクティブ化されていない場合、アプリケーションに問題が発生する可能性があります。また、正常な AZ で新しい Kubernetes ポッドを起動すると、障害のある AZ にバインドされた永続的なボリュームにアタッチできないため、問題が発生する可能性があります。
**この機能は Karpenter で機能しますか?**
Karpenter のサポートは現在、ARC ゾーンシフトと EKS のゾーンオートシフトでは利用できません。AZ に障害がある場合は、異常な AZ を削除して、関連する Karpenter NodePool 設定を調整し、新しいワーカーノードが他の AZ でのみ起動されるようにすることができます。
**この機能は EKS Fargate で機能しますか?**
この機能は EKS Fargate では機能しません。デフォルトでは、EKS Fargate がゾーンヘルスイベントを認識すると、ポッドは他の AZ での動作を優先します。
**EKS マネージド Kubernetes コントロールプレーンは影響を受けますか?**
いいえ。デフォルトでは、Amazon EKS は、複数の AZ で Kubernetes コントロールプレーンを実行およびスケールして、高可用性を実現します。ARC ゾーンシフトとゾーンオートシフトは、Kubernetes データプレーンでのみ動作します。
**この新機能に関連するコストはありますか?**
EKS クラスターでは、ARC ゾーンシフトとゾーンオートシフトを追加料金なしで使用できます。ただし、プロビジョニングされたインスタンスの料金は引き続きお支払いいただきます。この機能を使用する前に、Kubernetes データプレーンを事前にスケールすることを強くお勧めします。コストとアプリケーションの可用性のバランスを考慮する必要があります。
## その他のリソース
+ [ゾーンシフトの仕組み](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.how-it-works.html)
+ [ARC のゾーンシフトのベストプラクティス](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.zonal-shifts.html#zonalshift.route53-arc-best-practices.zonal-shifts)
+ [ゾーンシフトおよびゾーンオートシフトでサポートされているリソースとシナリオ](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html)
+ [Amazon EKS での回復力のあるワークロードの運用](https://aws.amazon.com/blogs/containers/operating-resilient-workloads-on-amazon-eks)
+ [ポッドの優先度とオーバープロビジョニングにより Kubernetes ノードスケーリングの遅延を排除する](https://aws.amazon.com/blogs/containers/eliminate-kubernetes-node-scaling-lag-with-pod-priority-and-over-provisioning)
+ [CoreDNS ポッドを高い DNS トラフィックにスケールする](coredns-autoscaling.md)
# EKS ゾーンシフトを有効にしてアベイラビリティーゾーンの障害を回避する
Amazon Application Recovery Controller (ARC) は、アベイラビリティーゾーン (AZ) 間でアプリケーションのリカバリを管理および調整し、Amazon EKS を含む多くのサービスと連携動作します。ARC ゾーンシフトの EKS サポートでは、クラスター内ネットワークトラフィックを障害のある AZ から移行できます。また、AWS に AZ の健全性を監視させ、異常な AZ から別の場所へ一時的にネットワークトラフィックを切り替える権限を付与することもできます。
**EKS ゾーンシフトの使用方法: **
1. Amazon Application Recovery Controller (ARC) で EKS クラスターを有効にします。これは、Amazon EKS コンソール、AWS CLI、CloudFormation、または eksctl を使用してクラスターレベルで行われます。
1. 有効にすると、ARC コンソール、AWS CLI、またはゾーンシフト API およびゾーンオートシフト API を使用して、ゾーンシフトまたはゾーンオートシフトを管理できます。
EKS クラスターを ARC に登録した後も、ARC を設定する必要があります。例えば、ARC コンソールを使用してゾーンオートシフトを設定できます。
EKS ゾーンシフトの仕組みと、障害のあるアベイラビリティーゾーンを処理するためのワークロードの設計方法についての詳細は、「[Amazon EKS での Amazon Application Recovery Controller (ARC) のゾーンシフトの詳細](zone-shift.md)」を参照してください。
## 考慮事項
+ EKS Auto Mode では Amazon Application Recovery Controller、ゾーンシフト、ゾーンオートシフトはサポートされていません。
+ 各リクエストが適切に処理されるため、ゾーンシフト操作の間に少なくとも 60 秒待つことをお勧めします。
ゾーンシフトを迅速に連続的に (60 未満の間隔で) 実行しようとすると、Amazon EKS サービスがすべてのシフトリクエストを適切に処理しない場合があります。これはクラスターのゾーン状態を更新する現在のポーリングメカニズムによるものです。複数のゾーンシフトを実行する必要がある場合、システムがすべての変更を処理するため、操作間に十分な時間間隔を確保してください。
## Amazon Application Recovery Controller とは
Amazon Application Recovery Controller (ARC) は、AWS 上で実行しているアプリケーションのリカバリ操作の準備や迅速な実行に役立ちます。ゾーンシフトを使用すると、サポートされているリソースのトラフィックを アベイラビリティーゾーン (AZ) から AWS リージョン内の正常な AZ に一時的に移動することで、AZ の障害からすばやく回復できます。
[Amazon Application Recovery Controller (ARC) の詳細はこちら](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
## ゾーンシフトとは
ゾーンシフトは ARC の機能であり、EKS クラスターや Elastic Load Balancer などのリソースのトラフィックを AWS リージョンのアベイラビリティーゾーンから移動できます。これにより、問題をすばやく軽減し、アプリケーションをすばやく回復できます。例えば、不適切なデプロイが原因でレイテンシーの問題が発生していたり、アベイラビリティーゾーンで障害が発生していたりする場合、トラフィックをシフトすることを選択できます。ゾーンシフトでは、事前設定手順は必要ありません。
[ARC ゾーンシフトの詳細はこちら](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.how-it-works.html)
## ゾーンオートシフトとは
ゾーンオートシフトは ARC の機能であり、有効にすると AWS がユーザーに代わってサポートされているリソースのトラフィックを AZ から AWS リージョンの正常な AZ に移動できます。AWS は、顧客に影響を与える可能性のある、リージョン内の AZ の障害が内部テレメトリによって示されると、オートシフトを開始します。内部テレメトリには、AWS ネットワーク、Amazon EC2、Elastic Load Balancing サービスなど、複数のソースからのメトリクスが組み込まれています。
AWS は、インジケータが問題や潜在的な問題がなくなったことを示すと、オートシフトを終了します。
[ARC ゾーンオートシフトの詳細はこちら](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.how-it-works.html)
## オートシフト中の EKS の動作
EKS は、障害のある AZ へのトラフィックを停止するようにネットワーク設定を更新します。さらに、マネージドノードグループを使用している場合、EKS はゾーンシフト中に正常な AZ にある新しいノードのみを起動します。シフトの有効期限が切れたりキャンセルされたりすると、以前に異常として検出された AZ を含めるようにネットワーク設定が復元されます。
[EKS ゾーンシフトの詳細はこちら](zone-shift.md)
## EKS クラスターを Amazon Application Recovery Controller (ARC) に登録する (AWS コンソール)
1. ARC に登録する EKS クラスターの名前とリージョンを見つけます。
1. そのリージョンの [EKS コンソール](https://console.aws.amazon.com/eks)に移動し、クラスターを選択します。
1. **[クラスター情報]** ページの **[概要]** タブを選択します。
1. **ゾーンシフト**の見出しで、**[管理]** ボタンを選択します。
1. *[EKS ゾーンシフト]* に **[有効]** または **[無効]** を選択します。
これで、EKS クラスターが ARC に登録されました。
AWS にアベイラビリティーゾーンの障害を検出して回避させるには、ARC ゾーンオートシフトを設定する必要があります。例えば、ARC コンソールで以下のことを行うことができます。
## 次のステップ
+ [ゾーンオートシフトを有効にする](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.start-cancel.html)方法について説明します。
+ 手動で[ゾーンシフトを開始する](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html)方法について説明します。