**このページの改善にご協力ください** このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。 # セルフマネージドノードでノードを自分自身で維持する クラスターには、Pod がスケジュールされている Amazon EC2 ノードが 1 つ以上含まれています。Amazon EKS ノードは AWS アカウントで実行され、クラスター API サーバーエンドポイントを介してクラスターのコントロールプレーンに接続します。Amazon EC2 料金に基づいて請求されます。詳細については「[Amazon EC2 料金](https://aws.amazon.com/ec2/pricing/)」を参照してください。 クラスターには、複数のノードグループを含めることができます。各ノードグループには、[Amazon EC2 Auto Scaling グループ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html)にデプロイされる 1 つ以上のノードが含まれます。グループ内のノードのインスタンスタイプは、[Karpenter](https://karpenter.sh/) による[属性ベースのインスタンスタイプの選択](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)を使用するときなどに、異なる場合があります。ノードグループ内のすべてのインスタンスは、[Amazon EKS ノードの IAM ロール](create-node-role.md)を使用する必要があります。 Amazon EKS は、Amazon EKS 最適化 AMI と呼ばれる特殊な Amazon マシンイメージ (AMI) を提供します。AMI は Amazon EKS と連携するように設定されています。そのコンポーネントには `containerd`、`kubelet`、および AWS IAM Authenticator が含まれます。また、AMI にはクラスターのコントロールプレーンを自動的に検出して接続を許可する、特別な[ブートストラップスクリプト](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh)も含まれます。 CIDR ブロックを使用してクラスターのパブリックエンドポイントへのアクセスを制限する場合は、プライベートエンドポイントアクセスも有効にすることをお勧めします。これは、ノードがクラスターと通信できるようにするためです。プライベートエンドポイントが有効になっていない場合、パブリックアクセスに指定する CIDR ブロックに、VPC からの出力ソースを含める必要があります。詳細については、「[クラスター API サーバーエンドポイント](cluster-endpoint.md)」を参照してください。 Amazon EKS クラスターにセルフマネージド型ノードを追加するには、次のトピックを参照してください。セルフマネージドノードを手動で起動する場合は、各ノードに次のタグを追加すると共に、`` がクラスターに一致することを確認します。詳細については、「[個々のリソースでのタグの追加と削除](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags)」を参照してください。このガイドの手順に従うと、必要なタグがノードに自動的に追加されます。 | キー | 値 | | --- | --- | | `kubernetes.io/cluster/` | `owned` | **重要** Amazon EC2 インスタンスメタデータサービス (IMDS) のタグは、EKS ノードと互換性がありません。インスタンスメタデータタグを有効にすると、タグ値でのスラッシュ (「/」) の使用が防止されます。この制限により、特に Karpenter や Cluster Autoscaler などのノード管理ツールを使用する場合、インスタンスの起動が失敗する可能性があります。これらのサービスは、スラッシュを含むタグに依存して適切に機能しているためです。 Kubernetes の一般的な視点から見たノードの詳細については、Kubernetes のドキュメントの「[Nodes](https://kubernetes.io/docs/concepts/architecture/nodes/)」を参照してください。 **Topics** + [セルフマネージド Amazon Linux ノードを作成する](launch-workers.md) + [セルフマネージド Bottlerocket ノードの作成](launch-node-bottlerocket.md) + [セルフマネージド Microsoft Windows ノードの作成](launch-windows-workers.md) + [セルフマネージドの Ubuntu Linux ノードを作成する](launch-node-ubuntu.md) + [クラスターのためにセルフマネージドノードを更新する](update-workers.md) # セルフマネージド Amazon Linux ノードを作成する このトピックでは、Amazon EKS クラスターに登録されている Linux ノードの Auto Scaling グループを起動する方法を説明します。ノードがクラスターに参加したら、それらのノードに Kubernetes アプリケーションをデプロイ可能になります。`eksctl` または AWS マネジメントコンソールを使用して、セルフマネージド型の Amazon Linux ノードを起動することもできます。AWS アウトポスト でノードを起動する必要がある場合は「[AWS Outposts で Amazon Linux ノードを作成する](eks-outposts-self-managed-nodes.md)」を参照してください。 + 既存の Amazon EKS クラスター。デプロイするには「[Amazon EKS クラスターを作成します。](create-cluster.md)」を参照してください。AWS アウトポスト、AWS 波長、または AWS ローカルゾーンs が有効になっている AWS リージョンにサブネットがある場合はクラスターの作成時にそれらのサブネットが渡されるべきではありません。 + ノードが使用する既存の IAM 役割。作成する場合は「[Amazon EKS ノードの IAM ロール](create-node-role.md)」を参照してください。この役割に VPC CNI のポリシーがどちらも含まれていない場合、VPC CNI ポッドには以下の別の役割が必要です。 + (オプションですが推奨) 必要な IAM ポリシーがアタッチされた独自の IAM ロールで構成された Amazon VPC CNI plugin for Kubernetes アドオン。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。 + 「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」に記載されている考慮事項に精通していること。選択したインスタンスタイプによってはクラスターと VPC に関する追加の前提条件がある場合もあります。 セルフマネージド Linux ノードは次のいずれかを使用して起動できます。 + [`eksctl`](#eksctl_create_managed_amazon_linux) + [AWS マネジメントコンソール](#console_create_managed_amazon_linux) ## `eksctl` **`eksctl` を使用してセルフマネージド型の Linux ノードを起動する** 1. デバイスまたは AWS クラウドシェル にインストールされている `eksctl` コマンドラインツールのバージョン `0.215.0` 以降をインストールします。`eksctl` をインストールまたはアップグレードするには`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。 1. (オプション) **[AmazonEKS\$1CNI\$1Policy]** マネージド IAM ポリシーが [Amazon EKS ノードの IAM ロール](create-node-role.md)にアタッチされている場合は、代わりに Kubernetes `aws-node` サービスアカウントに関連付けた IAM ロールに割り当てることをお勧めします。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。 1. 次のコマンドは既存のクラスターにノードグループを作成します。*al-nodes* を、ノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。*マイクラスター* の部分は自分のクラスター名に置き換えます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前はクラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。残りの*サンプル値*は独自の値に置き換えます。デフォルトでは、ノードはコントロールプレーンと同じ Kubernetes バージョンで作成されます。 `--node-type` の値を選択する前に、[「最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を確認してください。 *my-key* を Amazon EC2 キーペアまたはパブリックキーの名前に置き換えます。このキーは起動後のノードに SSH 接続するために使用されます。Amazon EC2 キーペアをまだ持っていない場合はAWS マネジメントコンソール で作成できます。詳細については「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。 次のコマンドを使用して、ノードグループを作成します。 **重要** ノードグループを AWS アウトポスト、波長、または ローカルゾーンs サブネットにデプロイする場合、追加の考慮事項があります。 クラスターを作成したときに、サブネットが渡されていない必要があります。 ノードグループはサブネットと ` [volumeType](https://eksctl.io/usage/schema/#nodeGroups-volumeType): gp2` を指定する設定ファイルを使用して作成する必要があります。詳細については「`eksctl` ドキュメント」の「[設定ファイルからノードグループを作成する](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file)」と「[設定ファイルのスキーマ](https://eksctl.io/usage/schema/)」を参照してください。 ``` eksctl create nodegroup \ --cluster my-cluster \ --name al-nodes \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --ssh-access \ --managed=false \ --ssh-public-key my-key ``` 次のノードグループをデプロイするには + デフォルト設定よりもはるかに多くの IP アドレスを Pod に割り当てることができるノードグループについては、「[プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md)」を参照してください。 + インスタンスのブロックとは異なる CIDR ブロックから `IPv4` アドレスを Pod に割り当てることができるノードグループについては、「[カスタムネットワーキングを使用して代替サブネットに Pod をデプロイする](cni-custom-network.md)」を参照してください。 + Pod とサービスに `IPv6` アドレスを割り当てることができるノードグループについては、「[クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md)」を参照してください。 + アウトバウンドインターネットアクセスがない場合は「[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)」を参照してください。 すべての使用可能なオプションとデフォルト値の一覧を表示するには次のコマンドを入力してください。 ``` eksctl create nodegroup --help ``` ノードがクラスターに参加できない場合はトラブルシューティングの章にある「[ノードをクラスターに結合できません](troubleshooting.md#worker-node-fail)」を参照してください。 出力例は次のとおりです。ノードの作成中に、複数の行が出力されます。出力の最後の行は次のサンプル行が表示されます。 ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (オプション) [サンプルアプリケーション](sample-deployment.md)をデプロイして、クラスターと Linux ノードをテストします。 1. 次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。 + IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。 + クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。 詳細については「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。 ## AWS マネジメントコンソール **ステップ 1: AWS マネジメントコンソール を使用してセルフマネージド型の リナックス ノードを起動する**` 1. AWS クラウドフォーメーション テンプレートの最新バージョンをダウンロードします。 ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-26/amazon-eks-nodegroup.yaml ``` 1. クラスターステータスが `ACTIVE` と表示されるまで待ちます。クラスターがアクティブになる前にノードを起動した場合、ノードはクラスターへの登録に失敗し、再起動する必要があります。 1. [AWS クラウドフォーメーション コンソール](https://console.aws.amazon.com/cloudformation/)を開きます。 1. **[スタックの作成]** を選択し、**[新しいリソースを使用 (標準)]** を選択してください。 1. **[テンプレートの指定]** で、**[テンプレートファイルのアップロード]** を選択し、**[ファイルを選択]** を選択してください。 1. ダウンロードした `amazon-eks-nodegroup.yaml` ファイルを選択してください。 1. **[次へ]** を選択してください。 1. **[スタックの詳細の指定]** ページで、必要に応じて次のパラメータを入力し、**[次へ]** を選択してください。 + **スタック名**: AWS クラウドフォーメーション スタックのスタック名を選択してください。例えば、*マイクラスター-nodes* という名前にすることができます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前はクラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。 + **[クラスター名]**: Amazon EKS クラスターの作成時に使用した名前を入力してください。この名前はクラスター名と同じにする必要があります。同じでない場合、ノードはクラスターに参加できません。 + [**クラスター制御プレーンセキュリティグループ**]: [VPC](creating-a-vpc.md) の作成時に生成した AWS クラウドフォーメーション 出力の [**セキュリティグループs**] 値を選択してください。 次のステップでは該当するグループを取得する 1 つのオペレーションを説明します。 1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。 1. クラスターの名前を選択してください。 1. **[ネットワーキング]** タブを選択してください。 1. **[クラスター制御プレーンセキュリティグループ]** ドロップダウンリストから選択する場合は**[追加のセキュリティグループ]** の値をリファレンスとして使用します。 + **[ApiServerEndpoint]**: EKS クラスターの API サーバーエンドポイントを入力します。これは EKS クラスターコンソールの [詳細] セクションにあります。 + **[CertificateAuthorityData]**: base64 でエンコードされた認証機関データを入力します。これは、EKS クラスターコンソールの [詳細] セクションにもあります。 + **[ServiceCidr]**: クラスター内の Kubernetes サービスに IP アドレスを割り当てるために使用される CIDR 範囲を入力します。これは、EKS クラスターコンソールの [ネットワーク] タブにあります。 + **[AuthenticationMode]**: EKS クラスターコンソール内の [アクセス] タブを確認して、EKS クラスターで使用されている認証モードを選択します。 + **[ノードグループ名]**: ノードグループの名前を入力してください。この名前はノードに対して作成される自動スケーリングノードグループを識別するために後で使用できます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。 + **[ノードオートスケーリンググループ最小サイズ]**: ノードの 自動スケーリング グループがスケールインできる最小ノード数を入力してください。 + **ノード自動スケーリンググループ希望容量**: スタック作成時にスケーリングする必要のあるノード数を入力してください。 + **[NodeAutoScalingGroupMaxSize]**: ノードの 自動スケーリング グループがスケールアウトできる最大ノード数を入力してください。 + **[ノードインスタンス型]**: ノードのインスタンスタイプを選択してください。詳細については、「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を参照してください。 + **[NodeImageIdSSMParam]**: 最新の Amazon EKS 最適化 Amazon Linux 2023 AMI の Amazon EC2 Systems Manager のパラメータが、可変 Kubernetes バージョン用に事前設定されています。Amazon EKS でサポートされている別の Kubernetes マイナーバージョンを使用するには、*1.XX* を別の[サポートされているバージョン](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)に置き換えます。クラスターと同じ Kubernetes バージョンを指定することをお勧めします。 *アマゾンリナックス-2023* を別の AMI タイプに置き換えることもできます。詳細については、「[推奨 Amazon Linux AMI ID を取得する](retrieve-ami-id.md)」を参照してください。 **注記** Amazon EKS ノード AMI は Amazon リナックス をベースとしています。[Amazon Linux セキュリティセンター](https://alas.aws.amazon.com/alas2023.html)で Amazon Linux 2023 のセキュリティイベントまたはプライバシーイベントを追跡するか、関連する [RSS フィード](https://alas.aws.amazon.com/AL2023/alas.rss)をサブスクライブします。セキュリティおよびプライバシーイベントには問題の概要、影響を受けるパッケージ、および問題を修正するためにインスタンスを更新する方法などがあります。 + **ノードイメージId**: (オプション) (Amazon EKS 最適化 AMI の代わりに) 独自のカスタム AMI を使用している場合はAWS リージョンのノード AMI ID を入力してください。ここで値を指定すると、**[ノードイメージIdSSMParam]** フィールドの値はすべて上書きされます。 + **[ノードボリュームサイズ]**: ノードのルートボリュームのサイズを GiB 単位で指定します。 + **[ノードボリューム型]**: ノードのルートボリュームタイプを指定します。 + **[キー名]**: 起動後に、SSH を使用してノードに接続するときに使用できる Amazon EC2 SSH キーペアの名前を入力してください。Amazon EC2 キーペアをまだ持っていない場合はAWS マネジメントコンソール で作成できます。詳細については「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。 + **[VpcId]**: 作成した [VPC](creating-a-vpc.md) の ID を入力してください。 + **[Subnets]**: VPC 用に作成したサブネットを選択してください。「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」で説明されている手順で VPC を作成した場合は起動するノードの VPC 内のプライベートサブネットのみを指定します。クラスターの **[ネットワーキング]** タブから、各サブネットリンクを開き、プライベートのサブネットを確認できます。 **重要** いずれかのサブネットがパブリックサブネットである場合はパブリック IP アドレスの自動割り当て設定を有効にする必要があります。この設定がパブリックサブネットに対して有効になっていない場合、そのパブリックサブネットにデプロイするノードにはパブリック IP アドレスが割り当てられず、クラスターやその他の AWS のサービスと通信できなくなります。2020 年 3 月 26 日以前に、[Amazon EKS AWS クラウドフォーメーション VPC テンプレート](creating-a-vpc.md)を使用して、または `eksctl` を使用してサブネットがデプロイされた場合、パブリックサブネットではパブリック IP アドレスの自動割り当てが無効になります。サブネットのパブリック IP アドレス割り当てを有効にする方法については「[サブネットのパブリック IPv4 アドレス属性の変更](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)」を参照してください。ノードがプライベートサブネットにデプロイされている場合、NAT ゲートウェイを介してクラスターや他の AWS のサービスと通信できます。 サブネットにインターネットアクセスがない場合は「[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)」の考慮事項と追加の手順を確認してください。 AWS アウトポスト、波長、または ローカルゾーンs サブネット を選択する場合はクラスターの作成時にサブネットを渡さないようにします。 1. **[スタックオプションの設定]** ページで、希望する設定を選択し、**[次へ]** を選択してください。 1. **[AWS クラウドフォーメーション が IAM リソースを作成する可能性を認識しています]** の左にあるチェックボックスを選択して、**[スタックの作成]** を選択してください。 1. スタックの作成が完了したら、コンソールで選択し、**[出力]** を選択してください。`EKS API` または `EKS API and ConfigMap` 認証モードを使用している場合は、これが最後のステップです。 1. `ConfigMap` 認証モードを使用している場合は、作成されたノードグループの **NodeInstanceRole** を記録します。 **ステップ 2: ノードを有効にしてクラスターに参加する** **注記** 次の 2 つのステップは、EKS クラスター内で Configmap 認証モードを使用している場合にのみ必要です。さらに、アウトバウンドのインターネットアクセスのないプライベート VPC でノードを起動する場合はノードが VPC 内からクラスターに参加できるようにしてください。 1. `aws-auth` `ConfigMap` がすでにあるかどうかを確認します。 ``` kubectl describe configmap -n kube-system aws-auth ``` 1. `aws-auth` `ConfigMap` が表示されている場合は必要に応じて更新してください。 1. 編集する `ConfigMap` を開きます。 ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. 必要に応じて新しい `mapRoles` エントリを追加します。`rolearn` 値を、前の手順で記録した **[ノードインスタンス役割]** 値に設定します。 ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes [...] ``` 1. ファイルを保存し、テキストエディタを終了します。 1. 「`Error from server (NotFound): configmaps "aws-auth" not found`」というエラーが表示されたら、ストック `ConfigMap` を適用してください。 1. 設定マップをダウンロードします。 ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml ``` 1. `aws-auth-cm.yaml` ファイルで、`rolearn` 値を前の手順で記録した **[ノードインスタンス役割]** 値に設定します。これを行うにはテキストエディタを使用するか、*マイノードインスタンス役割* を置き換えて次のコマンドを実行してください。 ``` sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml ``` 1. 設定を適用します。このコマンドが完了するまで数分かかることがあります。 ``` kubectl apply -f aws-auth-cm.yaml ``` 1. ノードのステータスを監視し、`Ready` ステータスになるまで待機します。 ``` kubectl get nodes --watch ``` `Ctrl`\$1`C` を入力して、シェルプロンプトに戻ります。 **注記** 認可またはリソースタイプのエラーが発生した場合はトラブルシューティングトピックの「[許可されていないか、アクセスが拒否されました (`kubectl`)](troubleshooting.md#unauthorized)」を参照してください。 ノードがクラスターに参加できない場合はトラブルシューティングの章にある「[ノードをクラスターに結合できません](troubleshooting.md#worker-node-fail)」を参照してください。 1. (GPU ノードのみ) GPU インスタンスタイプと Amazon EKS 最適化アクセラレーション AMI を選択した場合はクラスター上の DaemonSet として [Kubernetes 用の NVIDIA デバイスプラグイン](https://github.com/NVIDIA/k8s-device-plugin)を適用する必要があります。次のコマンドを実行する前に、*vX.X.X* を必要となる [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin/releases) バージョンに置き換えます。 ``` kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml ``` **ステップ 3: その他のアクション** 1. (オプション) [サンプルアプリケーション](sample-deployment.md)をデプロイして、クラスターと Linux ノードをテストします。 1. (オプション) **AmazonEKS\$1CNI\$1Policy** マネージド IAM ポリシー (`IPv4` クラスターがある場合) または *AmazonEKS\$1CNI\$1IPv6\$1Policy* (`IPv6` クラスターがある場合には[ユーザー自身が作成した](cni-iam-role.md#cni-iam-role-create-ipv6-policy)もの) が [Amazon EKS ノードの IAM ロール](create-node-role.md)にアタッチされている場合、代わりに Kubernetes `aws-node` サービスアカウントに関連付けた IAM ロールに割り当てることをお勧めします。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。 1. 次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。 + IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。 + クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。 詳細については「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。 # セルフマネージド Bottlerocket ノードの作成 **注記** マネージド型ノードグループでは、ユースケースにいくつかの利点がある場合があります。詳細については、「[マネージドノードグループを使用してノードライフサイクルを簡素化する](managed-node-groups.md)」を参照してください。 このトピックでは、Amazon EKS クラスターに登録する [Bottlerocket](https://aws.amazon.com/bottlerocket/) ノードの Auto Scaling グループを起動する方法について説明します。Bottlerocket は AWS が提供する Linux ベースのオープンソースのオペレーティングシステムで、仮想マシンやベアメタルホスト上でコンテナを実行するために使用できます。ノードがクラスターに参加したら、それらのノードに Kubernetes アプリケーションをデプロイ可能になります。Botttlerocket の詳細については、GitHub の [Using a Bottlerocket AMI with Amazon EKS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-EKS.md) と `eksctl` ドキュメント内の [Custom AMI support](https://eksctl.io/usage/custom-ami-support/) を参照してください。 インプレースアップグレードについて詳しくは、GitHub の [Bottlerocket Update Operator](https://github.com/bottlerocket-os/bottlerocket-update-operator) を参照してください。 **重要** Amazon EKS ノードは標準の Amazon EC2 インスタンスであり、通常の Amazon EC2 インスタンス価格に基づいて請求されます。詳細については「[Amazon EC2 料金](https://aws.amazon.com/ec2/pricing/)」を参照してください。 AWS Outposts 上の Amazon EKS 拡張クラスターで Bottlerocket ノードを起動できますが、AWS Outposts 上のローカルクラスターでは起動できません。詳細については、「[AWS Outposts を使用して Amazon EKS をオンプレミスにデプロイする](eks-outposts.md)」を参照してください。 `x86` または Arm プロセッサを使用して Amazon EC2 インスタンスにデプロイできます。ただし、Inferentia チップがあるインスタンスにデプロイすることはできません。 Bottlerocket は、AWS CloudFormation と互換性があります。ただし、Amazon EKS の Bottlerocket ノードをデプロイするためにコピーできる公式の CloudFormation テンプレートはありません。 Bottlerocket のイメージには、SSH サーバーやシェルは付属していません。SSH で管理者コンテナを有効にし、ユーザーデータとともにブートストラップの設定ステップを渡すために、帯域外のアクセス方式を使用できます。詳細については、GitHub の「[bottleRocket readme.md](https://github.com/bottlerocket-os/bottlerocket)」のセクションを参照してください。 [探査](https://github.com/bottlerocket-os/bottlerocket#exploration) [管理者コンテナ](https://github.com/bottlerocket-os/bottlerocket#admin-container) [Kubernetes 設定](https://github.com/bottlerocket-os/bottlerocket#kubernetes-settings) この手順には、`eksctl` バージョン `0.215.0` 以降が必要です。お使いのバージョンは、以下のコマンドを使用して確認できます。 ``` eksctl version ``` `eksctl` のインストールまたはアップグレードの手順については、 `eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。注意: この手順は、`eksctl` で作成されたクラスターでのみ機能します。 1. 次のコンテンツをデバイスにコピーします。*マイクラスター* の部分は自分のクラスター名に置き換えます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前は、クラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。*ng-bottlerocket* をノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。Arm インスタンスにデプロイするには、*m5.large* を Arm インスタンスタイプに置き換えます。*my-ec2-keypair-name* を、起動後に、SSH を使用してノードに接続するときに使用できる Amazon EC2 SSH キーペアの名前に置き換えます。Amazon EC2 キーペアをまだ持っていない場合は、AWS マネジメントコンソール で作成できます。詳細については*「アマゾン EC2 ユーザーガイド」*の「[アマゾン EC2 キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。残りのサンプル値はすべて独自の値に置き換えます。置き換えが完了したら、変更したコマンドを実行して `bottlerocket.yaml` ファイルを作成します。 Arm Amazon EC2 インスタンスタイプを指定する場合は、デプロイする前に「[Amazon EKS 最適化 Arm Amazon Linux AMI](eks-optimized-ami.md#arm-ami)」の考慮事項を確認してください。カスタム AMI を使用したデプロイの手順については、GitHub の [Building Bottlerocket](https://github.com/bottlerocket-os/bottlerocket/blob/develop/BUILDING.md) と、`eksctl` ドキュメントの [Custom AMI support](https://eksctl.io/usage/custom-ami-support/) を参照してください。マネージド型ノードグループをデプロイするには、起動テンプレートを使用してカスタム AMI をデプロイします。詳細については、「[起動テンプレートを使用してマネージドノードをカスタマイズする](launch-templates.md)」を参照してください。 **重要** ノードグループを AWS Outposts、AWS Wavelength、または AWS Local Zone サブネットにデプロイする場合、クラスターの作成時に AWS Outposts、AWS Wavelength、または AWS Local Zone サブネットは渡さないでください。次の例では、サブネットを指定する必要があります。詳細については、`eksctl` ドキュメントの「[設定ファイルからノードグループを作成する](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file)」と「[Config ファイルのスキーマ](https://eksctl.io/usage/schema/)」を参照してください。*region-code* を、クラスターのある AWS リージョンに置き換えます。 ``` cat >bottlerocket.yaml < このトピックでは、Amazon EKS クラスターに登録されている Windows ノードの Auto Scaling グループの起動方法について説明します。ノードがクラスターに参加したら、それらのノードに Kubernetes アプリケーションをデプロイ可能になります。 **重要** Amazon EKS ノードは標準の Amazon EC2 インスタンスであり、通常の Amazon EC2 インスタンス価格に基づいて請求されます。詳細については「[Amazon EC2 料金](https://aws.amazon.com/ec2/pricing/)」を参照してください。 AWS Outposts 上の Amazon EKS 拡張クラスターで Windows ノードを起動できますが、AWS Outposts 上のローカルクラスターでは起動できません。詳細については、「[AWS Outposts を使用して Amazon EKS をオンプレミスにデプロイする](eks-outposts.md)」を参照してください。 クラスターに対して Windows サポートを有効にします。Windows ノードグループを起動する前に、重要な考慮事項を確認することをお勧めします。詳細については、「[Windows サポートを有効にする](windows-support.md#enable-windows-support)」を参照してください。 次のいずれかを使用して、セルフマネージド型の Windows ノードを起動できます。 + [`eksctl`](#eksctl_create_windows_nodes) + [AWS マネジメントコンソール](#console_create_windows_nodes) ## `eksctl` **`eksctl` <2> を使用して自己管理型 Windows ノードを起動します。** この手順では`eksctl` をインストール済みで、お使いの `eksctl` バージョンが `0.215.0` 以上であることが必要です。お使いのバージョンは以下のコマンドを使用して確認できます。 ``` eksctl version ``` `eksctl` のインストールまたはアップグレードの手順については`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。 **注記** この手順は`eksctl` で作成されたクラスターに対してのみ機能します。 1. (オプション) **AmazonEKS\$1CNI\$1Policy** マネージド IAM ポリシー (`IPv4` クラスターがある場合) または *AmazonEKS\$1CNI\$1IPv6\$1Policy* (`IPv6` クラスターがある場合には[ユーザー自身が作成した](cni-iam-role.md#cni-iam-role-create-ipv6-policy)もの) が [Amazon EKS ノードの IAM ロール](create-node-role.md)にアタッチされている場合、代わりに Kubernetes `aws-node` サービスアカウントに関連付けた IAM ロールに割り当てることをお勧めします。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。 1. この手順では既存のクラスターがあることを前提としています。Windows ノードグループの追加先となる Amazon EKS クラスターと Amazon Linux ノードグループがまだ存在しない場合は、[Amazon EKS – `eksctl` の使用を開始する](getting-started-eksctl.md) に従うことをお勧めします。このガイドはAmazon Linux ノードで Amazon EKS クラスターを作成する方法についての完全なチュートリアルを提供します。 次のコマンドを使用して、ノードグループを作成します。*地域コード* を、クラスターのある AWS リージョンに置き換えます。*マイクラスター* の部分は自分のクラスター名に置き換えます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前はクラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。*ng-windows* をノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。*2019* を `2022` に置き換えて Windows Server 2022 を使用するか、もしくは `2025` に置き換えて Windows Server 2025 を使用できます。残りのサンプル値は独自の値に置き換えます。 **重要** ノードグループを AWS Outposts、AWS 波長、または AWS ローカルゾーン サブネットにデプロイする場合、クラスターの作成時に AWS Outposts、波長、または ローカルゾーン サブネットは渡さないでください。AWS Outposts、波長、または ローカルゾーンサブネットを指定した設定ファイルを使用して、ノードグループを作成します。詳細については`eksctl` ドキュメントの「[設定ファイルからノードグループを作成する](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file)」と「[設定ファイルのスキーマ](https://eksctl.io/usage/schema/)」を参照してください。 ``` eksctl create nodegroup \ --region region-code \ --cluster my-cluster \ --name ng-windows \ --node-type t2.large \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false \ --node-ami-family WindowsServer2019FullContainer ``` **注記** ノードがクラスターに参加できない場合はトラブルシューティングガイドの「[ノードをクラスターに結合できません](troubleshooting.md#worker-node-fail)」を参照してください。 `eksctl` コマンドで使用可能なオプションを表示するには次のコマンドを入力してください。 ``` eksctl command -help ``` 出力例は次のとおりです。ノードの作成中に、複数の行が出力されます。出力の最後の行は次のサンプル行が表示されます。 ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (オプション) [サンプルアプリケーション](sample-deployment.md)をデプロイして、クラスターと Windows ノードをテストします。 1. 次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。 + IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。 + クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。 詳細については、「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。 ## AWS マネジメントコンソール **前提条件** + 既存の Amazon EKS クラスターと Linux ノードグループ。これらのリソースがない場合は[Amazon EKS の使用を開始する](getting-started.md) のガイドのいずれかに従って作成することをお勧めします。これらのガイドでは、Linux ノードで Amazon EKS クラスターを作成する方法について説明しています。 + Amazon EKS クラスターの要件を満たす、既存の VPC およびセキュリティグループ。詳細については[VPC とサブネットの Amazon EKS ネットワーキング要件を表示する](network-reqs.md)および[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)を参照してください。[Amazon EKS の使用を開始する](getting-started.md) のガイドでは要件を満たす VPC を作成します。または「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」に従って手動で作成することもできます。 + Amazon EKS クラスターの要件を満たす VPC およびセキュリティグループを使用している、既存の Amazon EKS クラスター。詳細については「[Amazon EKS クラスターを作成します。](create-cluster.md)」を参照してください。AWS Outposts、AWS 波長、または AWS ローカルゾーンが有効になっている AWS リージョンにサブネットがある場合はクラスターの作成時にそれらのサブネットが渡されるべきではありません。 **ステップ 1: AWS マネジメントコンソール を使用してセルフマネージド型の Windows ノードを起動する** 1. クラスターステータスが `ACTIVE` と表示されるまで待ちます。クラスターがアクティブになる前にノードを起動した場合、ノードはクラスターへの登録に失敗し、再起動が必要になります。 1. [AWS クラウドフォーメーション コンソール](https://console.aws.amazon.com/cloudformation/)を開きます 1. **[スタックの作成]** を選択してください。 1. **[テンプレートを指定]** で、**[Amazon S3 URL]** を選択してください。 1. 次の URL をコピーして、**[Amazon S3 URL]** に貼り付けます。 ``` https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-02-09/amazon-eks-windows-nodegroup.yaml ``` 1. **[次へ]** を 2 回選択してください。 1. **[スタックのクイック作成]** ページで、必要に応じて以下のパラメータを入力してください。 + **スタック名**: AWS クラウドフォーメーション スタックのスタック名を選択してください。例えば、`my-cluster-nodes` という名前にすることができます。 + **[クラスター名]**: Amazon EKS クラスターの作成時に使用した名前を入力してください。 **重要** この名前は「[ステップ 1: Amazon EKS クラスターを作成する](getting-started-console.md#eks-create-cluster)」で使用した名前と完全に一致する必要があります。そうしないと、ノードはクラスターに参加できません。 + **クラスター制御プレーンセキュリティグループ**: [VPC](creating-a-vpc.md) を作成する際に生成した AWS クラウドフォーメーション 出力からセキュリティグループを選択してください。次のステップでは該当するグループを取得する 1 つの方法を説明します。 1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。 1. クラスターの名前を選択してください。 1. **[ネットワーキング]** タブを選択してください。 1. **[クラスター制御プレーンセキュリティグループ]** ドロップダウンリストから選択する場合は**[追加のセキュリティグループ]** の値をリファレンスとして使用します。 + **[ノードグループ名]**: ノードグループの名前を入力してください。この名前はノードに対して作成される自動スケーリングノードグループを識別するために後で使用できます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。 + **[ノードオートスケーリンググループ最小サイズ]**: ノードの 自動スケーリング グループがスケールインできる最小ノード数を入力してください。 + **ノード自動スケーリンググループ希望容量**: スタック作成時にスケーリングする必要のあるノード数を入力してください。 + **[NodeAutoScalingGroupMaxSize]**: ノードの 自動スケーリング グループがスケールアウトできる最大ノード数を入力してください。 + **[ノードインスタンス型]**: ノードのインスタンスタイプを選択してください。詳細については、「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を参照してください。 **注記** 最新バージョンの [Amazon VPC CNI plugin for Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) でサポートされているインスタンスタイプは、GitHub 上の [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) にリストされています。サポートされている最新のインスタンスタイプを利用するには、CNI のバージョンを更新することが必要になる場合があります。詳細については、「[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md)」を参照してください。 + **[NodeImageIdSSMParam]**: 現在推奨されている Amazon EKS 最適化 Windows Core AMI ID の Amazon EC2 Systems Manager パラメータが事前設定されています。Windows の通常版を使用する場合は、*Core* を `Full` に置き換えます。 + **ノードイメージId**: (オプション) (Amazon EKS 最適化 AMI の代わりに) 独自のカスタム AMI を使用している場合はAWS リージョンのノード AMI ID を入力してください。このフィールドに値を指定すると、**[ノードイメージIdSSMParam]** フィールドの値はすべて上書きされます。 + **[ノードボリュームサイズ]**: ノードのルートボリュームのサイズを GiB 単位で指定します。 + **[キー名]**: 起動後に、SSH を使用してノードに接続するときに使用できる Amazon EC2 SSH キーペアの名前を入力してください。Amazon EC2 キーペアをまだ持っていない場合はAWS マネジメントコンソール で作成できます。詳細については「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 キーペア](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html)」を参照してください。 **注記** ここでキーペアを指定しないと、AWS クラウドフォーメーション スタックの作成は失敗します。 + [**ブートストラップ引数**]: `kubelet` を使用して、`-KubeletExtraArgs` の追加引数など、ノードブートストラップスクリプトに渡すオプションの引数を指定します。 + **[無効IMDSv1]**: 各ノードはデフォルトでインスタンスメタデータサービスバージョン 1 (IMDSv1) および IMDSv2 をサポートします。IMDSv1 は無効にできます。今後ノードグループのノードおよび Pod が MDSv1 を使用しないようにするには、**DisableIMDSv1** を **true** に設定します。IDMS の詳細については「[インスタンスメタデータサービスの設定](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)」を参照してください。 + **[VpcId]**: 作成した [VPC](creating-a-vpc.md) の ID を選択します。 + **[NodeSecurityGroups]**: [VPC](creating-a-vpc.md) の作成時に Linux ノードグループ用に作成したセキュリティグループを選択します。Linux ノードに複数のセキュリティグループがアタッチされている場合、それらのすべてを指定します。これは、たとえば、Linux ノードグループが `eksctl` を使用して作成された場合に行います。 + **[Subnets]**: 作成したサブネットを選択してください。「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」で説明されている手順で VPC を作成した場合は起動するノードの VPC 内のプライベートサブネットのみを指定します。 **重要** いずれかのサブネットがパブリックサブネットである場合はパブリック IP アドレスの自動割り当て設定を有効にする必要があります。この設定がパブリックサブネットに対して有効になっていない場合、そのパブリックサブネットにデプロイするノードにはパブリック IP アドレスが割り当てられず、クラスターやその他の AWS のサービスと通信できなくなります。2020 年 3 月 26 日以前に、[Amazon EKS AWS クラウドフォーメーション VPC テンプレート](creating-a-vpc.md)を使用して、または `eksctl` を使用してサブネットがデプロイされた場合、パブリックサブネットではパブリック IP アドレスの自動割り当てが無効になります。サブネットのパブリック IP アドレス割り当てを有効にする方法については「[サブネットのパブリック IPv4 アドレス属性の変更](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)」を参照してください。ノードがプライベートサブネットにデプロイされている場合、NAT ゲートウェイを介してクラスターや他の AWS のサービスと通信できます。 サブネットにインターネットアクセスがない場合は「[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)」の考慮事項と追加の手順を確認してください AWS Outposts、波長、またはローカルゾーンサブネット を選択する場合はクラスターの作成時にサブネットを渡さないようにします。 1. スタックが IAM リソースを作成する可能性があることを確認し、**[スタックの作成]** を選択してください。 1. スタックの作成が完了したら、コンソールで選択し、**[出力]** を選択してください。 1. 作成されたノードグループの [**NodeInstanceRole**] を記録します。これは、Amazon EKS Windows ノードを設定するときに必要になります。 **ステップ 2: ノードを有効にしてクラスターに参加する** 1. `aws-auth` `ConfigMap` がすでにあるかどうかを確認します。 ``` kubectl describe configmap -n kube-system aws-auth ``` 1. `aws-auth` `ConfigMap` が表示されている場合は必要に応じて更新してください。 1. 編集する `ConfigMap` を開きます。 ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. 必要に応じて新しい `mapRoles` エントリを追加します。`rolearn` 値を、前の手順で記録した **[ノードインスタンス役割]** の値に設定します。 ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - eks:kube-proxy-windows [...] ``` 1. ファイルを保存し、テキストエディタを終了します。 1. 「`Error from server (NotFound): configmaps "aws-auth" not found`」というエラーが表示されたら、ストック `ConfigMap` を適用してください。 1. 設定マップをダウンロードします。 ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml ``` 1. `aws-auth-cm-windows.yaml` ファイルで、`rolearn` 値を、前の手順で記録した該当する **[ノードインスタンス役割]** 値に設定します。これを行うにはテキストエディタを使用するか、このサンプル値を置き換えて次のコマンドを実行してください。 ``` sed -i.bak -e 's||my-node-linux-instance-role|' \ -e 's||my-node-windows-instance-role|' aws-auth-cm-windows.yaml ``` **重要** このファイルの他の行は変更しないでください。 Windows ノードと Linux ノードの両方に同じ IAM ロールを使用しないでください。 1. 設定を適用します。このコマンドが完了するまで数分かかることがあります。 ``` kubectl apply -f aws-auth-cm-windows.yaml ``` 1. ノードのステータスを監視し、`Ready` ステータスになるまで待機します。 ``` kubectl get nodes --watch ``` `Ctrl`\$1`C` を入力して、シェルプロンプトに戻ります。 **注記** 認可またはリソースタイプのエラーが発生した場合はトラブルシューティングトピックの「[許可されていないか、アクセスが拒否されました (`kubectl`)](troubleshooting.md#unauthorized)」を参照してください。 ノードがクラスターに参加できない場合はトラブルシューティングの章にある「[ノードをクラスターに結合できません](troubleshooting.md#worker-node-fail)」を参照してください。 **ステップ 3: その他のアクション** 1. (オプション) [サンプルアプリケーション](sample-deployment.md)をデプロイして、クラスターと Windows ノードをテストします。 1. (オプション) **AmazonEKS\$1CNI\$1Policy** マネージド IAM ポリシー (`IPv4` クラスターがある場合) または *AmazonEKS\$1CNI\$1IPv6\$1Policy* (`IPv6` クラスターがある場合には[ユーザー自身が作成した](cni-iam-role.md#cni-iam-role-create-ipv6-policy)もの) が [Amazon EKS ノードの IAM ロール](create-node-role.md)にアタッチされている場合、代わりに Kubernetes `aws-node` サービスアカウントに関連付けた IAM ロールに割り当てることをお勧めします。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。 1. 次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。 + IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。 + クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。 詳細については「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。 # セルフマネージドの Ubuntu Linux ノードを作成する **注記** マネージド型ノードグループでは、ユースケースにいくつかの利点がある場合があります。詳細については、「[マネージドノードグループを使用してノードライフサイクルを簡素化する](managed-node-groups.md)」を参照してください。 このトピックでは、[Amazon Elastic Kubernetes Service (EKS) ノード上で Ubuntu](https://cloud-images.ubuntu.com/aws-eks/) の Auto Scaling グループを起動するか、あるいは Amazon EKS クラスターに登録される [Amazon Elastic Kubernetes Service (EKS) ノード上で Ubuntu Pro](https://ubuntu.com/blog/ubuntu-pro-for-eks-is-now-generally-available) の Auto Scaling グループを起動する方法について説明します。EKS で動作する Ubuntu と Ubuntu Pro は、公式の Ubuntu Minimal LTS に基づいており、AWS と共同で開発されているカスタム AWS カーネルを搭載し、これまで特に EKS 向けに構築されています。Ubuntu Pro は、EKS 延長サポート期間、カーネルライブパッチ、FIPS の遵守、および無制限の Pro コンテナを実行する機能をサポートすることで、さらなるセキュリティの強化も図っています。 ノードがクラスターに参加したら、それらのノードにコンテナ化したアプリケーションをデプロイできるようになります。詳細については、「[Ubuntu on AWS](https://documentation.ubuntu.com/aws/en/latest/)」のドキュメントおよび `eksctl` ドキュメントの「[Custom AMI support](https://eksctl.io/usage/custom-ami-support/)」を参照してください。 **重要** Amazon EKS ノードは標準の Amazon EC2 インスタンスであり、通常の Amazon EC2 インスタンス価格に基づいて請求されます。詳細については「[Amazon EC2 料金](https://aws.amazon.com/ec2/pricing/)」を参照してください。 AWS Outposts 上の Amazon EKS 拡張クラスターで Ubuntu ノードを起動できますが、AWS Outposts 上のローカルクラスターでは起動できません。詳細については、「[AWS Outposts を使用して Amazon EKS をオンプレミスにデプロイする](eks-outposts.md)」を参照してください。 `x86` または Arm プロセッサを使用して Amazon EC2 インスタンスにデプロイできます。ただし、インスタンスに Inferentia チップがある場合は、先に [Neuron SDK](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/) をインストールしておく必要があります。 この手順には、`eksctl` バージョン `0.215.0` 以降が必要です。お使いのバージョンは、以下のコマンドを使用して確認できます。 ``` eksctl version ``` `eksctl` のインストールまたはアップグレードの手順については、 `eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。注意: この手順は、`eksctl` で作成されたクラスターでのみ機能します。 1. 次のコンテンツをデバイスにコピーします。`my-cluster` を自分のクラスター名に置き換えます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字はアルファベット文字である必要があります。また、100 文字より長くすることはできません。`ng-ubuntu` をノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。Arm インスタンスにデプロイするには、`m5.large` を Arm インスタンスタイプに置き換えます。`my-ec2-keypair-name` を、起動後に、SSH を使用してノードに接続するときに使用できる Amazon EC2 SSH キーペアの名前に置き換えます。Amazon EC2 キーペアをまだ持っていない場合は、AWS マネジメントコンソール で作成できます。詳細については、「Amazon EC2 ユーザーガイド」の「[Amazon EC2 キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。残りのサンプル値はすべて独自の値に置き換えます。置き換えが完了したら、変更したコマンドを実行して `ubuntu.yaml` ファイルを作成します。 **重要** ノードグループを AWS Outposts、AWS Wavelength、または AWS Local Zone サブネットにデプロイする場合、クラスターの作成時に AWS Outposts、AWS Wavelength、または AWS Local Zone サブネットは渡さないでください。次の例では、サブネットを指定する必要があります。詳細については、`eksctl` ドキュメントの「[設定ファイルからノードグループを作成する](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file)」と「[Config ファイルのスキーマ](https://eksctl.io/usage/schema/)」を参照してください。*region-code* を、クラスターのある AWS リージョンに置き換えます。 ``` cat >ubuntu.yaml < Amazon EKS に最適化された最新の AMI がリリースされたら、セフルマネージド型ノードグループのノードを新しい AMI に置き換えることを検討してください。同様に、Amazon EKS クラスターの Kubernetes バージョンを更新した場合は、ノードを更新して、同じ Kubernetes バージョンのノードを使用します。 **重要** このトピックでは、セルフマネージド型ノードのノードの更新について説明します。[マネージドノードグループ](managed-node-groups.md)を使用している場合は、「[クラスターのためにマネージドノードグループを更新する](update-managed-node-group.md)」を参照してください。 クラスター内のセルフマネージド型ノードグループを更新して新しい AMI を使用するには、2 つの基本的な方法があります。 **[アプリケーションを新しいノードグループに移行する](migrate-stack.md)** 新しいノードグループを作成し、Pod をそのグループに移行します。新しいノードグループへの移行は、既存の AWS CloudFormation スタックで AMI ID を単に更新するよりも適切です。これは、移行プロセスが古いノードグループを `NoSchedule` として[テイント](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)に設定し、新しいスタックが既存の Pod ワークロードを受け入れる準備ができた後にそのノードをドレインするためです。 **[AWS CloudFormation ノードスタックを更新する](update-stack.md)** 既存のノードグループの AWS CloudFormation スタックを更新して、新しい AMI が使用されるようにします。この方法は、`eksctl` を使用して作成されたノードグループではサポートされていません。 # アプリケーションを新しいノードグループに移行する このトピックは、新しいノードグループを作成し、既存のアプリケーションを新しいグループに適切に移行し、クラスターから古いノードグループを削除する方法について説明します。新しいノードグループに移行するには、`eksctl` または AWS マネジメントコンソール を使用します。 + [`eksctl`](#eksctl_migrate_apps) + [AWS マネジメントコンソール および AWS CLI](#console_migrate_apps) ## `eksctl` **`eksctl` を使用してアプリケーションを新しいノードグループに移行する** eksctl を移行に使用する方法の詳細については、`eksctl` ドキュメントの「[管理対象外のノードグループ](https://eksctl.io/usage/nodegroup-unmanaged/)」を参照してください。 この手順には、`eksctl` バージョン `0.215.0` 以降が必要です。お使いのバージョンは、以下のコマンドを使用して確認できます。 ``` eksctl version ``` `eksctl` のインストールまたはアップグレードの手順については、`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。 **注記** この手順は、`eksctl` で作成されたクラスターとノードグループに対してのみ機能します。 1. *my-cluster* をクラスター名に置き換えて、既存のノードグループの名前を取得します。 ``` eksctl get nodegroups --cluster=my-cluster ``` 出力例は次のとおりです。 ``` CLUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID default standard-nodes 2019-05-01T22:26:58Z 1 4 3 t3.medium ami-05a71d034119ffc12 ``` 1. 次のコマンドを使用して、`eksctl` で新しいノードグループを起動します。コマンドのすべての*サンプル値*を独自の値に置き換えます。バージョン番号をお使いのコントロールプレーンの Kubernetes バージョンよりも新しいものにすることはできません。また、コントロールプレーンの Kubernetes バージョンより 3 つ以上前のマイナーなバージョンにすることもできません。コントロールプレーンと同じバージョンを使用することをお勧めします。 次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。 + IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。 + クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。 詳細については「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。 Pod から IMDS へのアクセスをブロックするには、次のコマンドに `--disable-pod-imds` オプションを追加します。 **注記** 使用可能なフラグとその説明については、「https://eksctl.io/」を参照してください。 ``` eksctl create nodegroup \ --cluster my-cluster \ --version 1.35 \ --name standard-nodes-new \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false ``` 1. 前のコマンドが完了したら、次のコマンドを使用して、すべてのノードが `Ready` 状態になったことを確認します。 ``` kubectl get nodes ``` 1. 次のコマンドを使用して、元のノードグループを削除します。このコマンドで、すべての*サンプル値*を自分のクラスター名とノードグループ名に置き換えます。 ``` eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old ``` ## AWS マネジメントコンソール および AWS CLI **AWS マネジメントコンソール と AWS CLI を使用してアプリケーションを新しいノードグループに移行する** 1. 新しいノードグループを起動するには、「[セルフマネージド Amazon Linux ノードを作成する](launch-workers.md)」で説明されている手順に従います。 1. スタックの作成が完了したら、コンソールで選択し、**[出力]** を選択してください。 1. 作成されたノードグループの **NodeInstanceRole** を記録します。Amazon EKS ノードをクラスターに追加するには、これが必要です。 **注記** 追加の IAM ポリシーを古いノードグループの IAM ロールにアタッチした場合は、この同じポリシーを新しいノードグループの IAM ロールにアタッチして、新しいグループでその機能を管理します。これは、たとえば、Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) のアクセス許可を追加した場合に適用されます。 1. 相互通信できるように、両方のノードグループのセキュリティグループを更新します。詳細については、「[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)」を参照してください。 1. 両方のノードグループのセキュリティグループ ID を記録します。これは、AWS CloudFormation スタックからの出力に、**NodeSecurityGroup** の値として表示されます。 次の AWS CLI コマンドを使用して、スタック名からセキュリティグループ ID を取得します。これらのコマンドで、`oldNodes` は、古いノードスタックの AWS CloudFormation スタック名、`newNodes` は、移行先のスタックの名前です。各*サンプル値*は独自の値に置き換えます。 ``` oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) ``` 1. 互いにトラフィックを受け入れるように、各ノードのセキュリティグループに進入ルールを追加します。 以下の AWS CLI コマンドでは、他のセキュリティグループからのすべてのプロトコルのトラフィックをすべて許可するインバウンドルールを各セキュリティグループに追加します。この設定により、ワークロードを新しいグループに移行している際に、各ノードグループ内の Pod が相互に通信できるようになります。 ``` aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 authorize-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1 ``` 1. `aws-auth` configmap を編集して、新しいノードインスタンスロールを RBAC にマッピングします。 ``` kubectl edit configmap -n kube-system aws-auth ``` 新しいノードグループの新しい `mapRoles` エントリを追加します。 ``` apiVersion: v1 data: mapRoles: | - rolearn: ARN of instance role (not instance profile) username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> - rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes ``` *インスタンスロールの ARN (インスタンスプロファイルではない)* スニペットを、[前の手順](#node-instance-role-step)で記録した **NodeInstanceRole** の値に置き換えます。次に、更新された configmap を適用するには、ファイルを保存して閉じます。 1. ノードのステータスを監視し、新しいノードがクラスターに結合され、`Ready` ステータスになるまで待機します。 ``` kubectl get nodes --watch ``` 1. (オプション) [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) を使用している場合は、スケーリングアクションの競合を回避するために、デプロイをゼロ (0) レプリカにスケールダウンします。 ``` kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system ``` 1. 以下のコマンドを使用して、`NoSchedule` で削除する各ノードをテイントに設定します。その目的は、ノードを置き換えたときにそのノードで新しい Pod がスケジュールまたは再スケジュールされないようにすることです。詳細については、Kubernetes ドキュメントの「[テイントと容認](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)」を参照してください。 ``` kubectl taint nodes node_name key=value:NoSchedule ``` ノードを新しい Kubernetes バージョンにアップグレードする場合は、次のコードスニペットを使用して、特定の Kubernetes バージョン (この場合は `1.33`) のすべてのノードを識別してテイントに設定できます。バージョン番号をお使いのコントロールプレーンの Kubernetes バージョンよりも新しいものにすることはできません。また、コントロールプレーンの Kubernetes バージョンより 3 つ以上前のマイナーなバージョンにすることもできません。コントロールプレーンと同じバージョンを使用することをお勧めします。 ``` K8S_VERSION=1.33 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Tainting $node" kubectl taint nodes $node key=value:NoSchedule done ``` 1. クラスターの DNS プロバイダーを決定します。 ``` kubectl get deployments -l k8s-app=kube-dns -n kube-system ``` 出力例は次のとおりです。このクラスターでは、DNS 解決に CoreDNS を使用していますが、クラスターからは `kube-dns` が返される場合もあります。 ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. 現在のデプロイメントで実行しているレプリカが 2 つ未満の場合は、そのデプロイメントを 2 つのレプリカにスケールアウトします。前のコマンドの出力が kubedns を返していた場合は、*coredns* を `kubedns` に置き換えます。 ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. 次のコマンドを使用して、クラスターから削除する各ノードをドレーンします。 ``` kubectl drain node_name --ignore-daemonsets --delete-local-data ``` ノードを新しい Kubernetes バージョンにアップグレードする場合は、次のコードスニペットを使用して、特定の Kubernetes バージョン (この場合は *1.33*) のすべてのノードを識別してドレインします。 ``` K8S_VERSION=1.33 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Draining $node" kubectl drain $node --ignore-daemonsets --delete-local-data done ``` 1. 古いノードのドレーンが完了したら、以前承認したセキュリティグループのインバウンドルールを取り消します。次に、AWS CloudFormation スタックを削除してインスタンスを終了してください。 **注記** さらに IAM ポリシーを古いノードグループの IAM ロールにアタッチした場合 ([Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) に対するアクセス許可を追加する場合など) は、ロールからその追加ポリシーをデタッチしてから、AWS CloudFormation スタックを削除できます。 1. 先ほどノードのセキュリティグループ用に作成したインバウンドルールを取り消します。これらのコマンドで、`oldNodes` は、古いノードスタックの AWS CloudFormation スタック名、`newNodes` は、移行先のスタックの名前です。 ``` oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 revoke-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1 ``` 1. [AWS CloudFormation コンソール](https://console.aws.amazon.com/cloudformation/)を開きます。 1. 古いノードスタックを選択します。 1. **[削除]** を選択します。 1. **[スタックの削除]** 確認ダイアログボックスで、**[スタックを削除]** をクリックします。 1. `aws-auth` configmap を編集して、RBAC から古いノードインスタンスロールを削除します。 ``` kubectl edit configmap -n kube-system aws-auth ``` 古いノードグループの `mapRoles` エントリを削除します。 ``` apiVersion: v1 data: mapRoles: | - rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: arn:aws:iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> ``` 更新された configmap を適用するには、ファイルを保存して閉じます。 1. (オプション) Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) を使用している場合は、デプロイのスケーリングを 1 レプリカに戻します。 **注記** 必要に応じて、新しい Auto Scaling グループにタグ (`k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster` など) を付け、新しくタグ付けした Auto Scaling グループを参照するように、Cluster Autoscaler デプロイのコマンドを更新する必要があります。詳細については、「[AWS の Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-release-1.3/cluster-autoscaler/cloudprovider/aws)」を参照してください。 ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (オプション) 最新バージョンの [Amazon VPC CNI Plugin for Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) を使用していることを確認します。サポートされている最新のインスタンスタイプを利用するにはCNI のバージョンを更新することが必要になる場合があります。詳細については、「[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md)」を参照してください。 1. クラスターが DNS 解決 ([[migrate-determine-dns-step]](#migrate-determine-dns-step) を参照) に `kube-dns` を使用している場合は、`kube-dns` デプロイを 1 レプリカにスケールインします。 ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` # AWS CloudFormation ノードスタックを更新する このトピックは、新しい AMI を使用して既存の AWS CloudFormation セルフマネージド型ノードスタックを更新する方法について説明します。この手順を使用して、クラスターの更新後にノードを新しいバージョンの Kubernetes に更新することができます。それ以外の場合は、Kubernetes の既存バージョン用の Amazon EKS に最適化された最新の AMI に更新することができます。 **重要** このトピックでは、セルフマネージド型ノードのノードの更新について説明します。「[マネージドノードグループを使用してノードライフサイクルを簡素化する](managed-node-groups.md)」方法の詳細については、「[クラスターのためにマネージドノードグループを更新する](update-managed-node-group.md)」を参照してください。 最新のデフォルトの Amazon EKS ノード AWS CloudFormation テンプレートは、古い AMI を一度に 1 つずつ削除する前に、新しい AMI を使用してインスタンスをクラスターに起動するように設定されています。この設定により、ローリング更新中にクラスター内で Auto Scaling グループのアクティブなインスタンスが常に必要数確保されるようになります。 **注記** この方法は、`eksctl` を使用して作成されたノードグループではサポートされていません。`eksctl` を使用してクラスターまたはノードグループを作成した場合は、「[アプリケーションを新しいノードグループに移行する](migrate-stack.md)」を参照してください。 1. クラスターの DNS プロバイダーを決定します。 ``` kubectl get deployments -l k8s-app=kube-dns -n kube-system ``` 出力例は次のとおりです。このクラスターでは、DNS 解決に CoreDNS を使用していますが、クラスターからは `kube-dns` が返される場合があります。使用しているバージョンの `kubectl` によって、出力が異なる場合があります。 ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. 現在のデプロイメントで実行しているレプリカが 2 つ未満の場合は、そのデプロイメントを 2 つのレプリカにスケールアウトします。前のコマンドの出力が kubedns を返していた場合は、*coredns* を `kube-dns` に置き換えます。 ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. (オプション) [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) を使用している場合は、スケーリングアクションの競合を回避するために、デプロイをゼロ (0) レプリカにスケールダウンします。 ``` kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system ``` 1. 現在のノードグループのインスタンスタイプと必要なインスタンス数を決定します。グループの AWS CloudFormation テンプレートを更新する場合は、後でこれらの値を入力します。 1. Amazon EC2 コンソールの https://console.aws.amazon.com/ec2/ を開いてください。 1. 左ナビゲーションペインの **[Launch Configurations]** (起動設定) を選択し、既存のノードの起動設定のインスタンスタイプを書き留めます。 1. 左ナビゲーションペインの **[Auto Scaling]** (グループ) を選択し、既存の Auto Scaling グループのノードの、インスタンスの **[Desired]** (必要) 数を書き留めます。 1. [AWS CloudFormation コンソール](https://console.aws.amazon.com/cloudformation/)を開きます。 1. ノードグループスタックを選択し、[**更新**] を選択します。 1. **[Replace current template]** (現在のテンプレートを置き換える) を選択し、**Amazon S3 URL** を選択します。 1. **Amazon S3 URL** で、ノードの AWS CloudFormation テンプレートの最新バージョンを使用していることを確認するために以下の URL をテキストエリアに貼り付けます。続いて、**[次へ]** を選択します。 ``` https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml ``` 1. **[Specify stack details]** (スタックの詳細の指定) ページで、以下のパラメータを指定し、**[Next]** (次へ) を選択します。 + **[NodeAutoScalingGroupDesiredCapacity]** – [前のステップ](#existing-worker-settings-step)で記録した必要なインスタンス数を入力します。または、スタック更新時にスケーリングする必要のある新しいノード数を入力します。 + **NodeAutoScalingGroupMaxSize** - ノードの Auto Scaling グループがスケールアウトする最大ノード数を入力します。この値は、必要な容量よりも少なくとも 1 ノード多い必要があります。これは、更新時にノード数を減らさずにノードのローリング更新を実行できるようにするためです。 + **NodeInstanceType** — [前のステップ](#existing-worker-settings-step)で記録したインスタンスタイプを選択します。または、ノードに別のインスタンスタイプを選択します。異なるインスタンスタイプを選択する前に、「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を確認してください。各 Amazon EC2 インスタンスタイプは最大数の Elastic Network Interface (ネットワークインターフェイス) をサポートし、各ネットワークインターフェイスは最大数の IP アドレスをサポートします。ワーカーノードと Pod には、それぞれ IP アドレスが割り当てられています。そのため、各 Amazon EC2 ノードで実行する Pod の最大数をサポートするインスタンスタイプを選択することが重要です。インスタンスタイプごとにサポートされるネットワークインターフェイスと IP アドレスのリストについては、「[各インスタンスタイプのネットワークインターフェイスごとの IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI)」を参照してください。例えば、`m5.large` インスタンスタイプは、ワーカーノードと Pod に対して最大 30 の IP アドレスをサポートします。 **注記** 最新バージョンの [Amazon VPC CNI plugin for Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) でサポートされているインスタンスタイプは、GitHub 上の [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) に示されています。サポートされている最新のインスタンスタイプを利用するには、Amazon VPC CNI Plugin for Kubernetes のバージョンを更新することが必要になる場合があります。詳細については、「[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md)」を参照してください。 **重要** AWS リージョンによっては利用できないインスタンスタイプがあります。 + [**NodeImageIdSSMParam**]: 更新する AMI ID の Amazon EC2 Systems Manager パラメータです。次の値では、Kubernetes バージョン `1.35` 用の最新の Amazon EKS 最適化 AMI が使用されています。 ``` /aws/service/eks/optimized-ami/1.35/amazon-linux-2/recommended/image_id ``` *1.35* は、同一の [platform-version](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) に置き換えることができます。または、コントロールプレーンで実行されている Kubernetes バージョンより 1 つ前までのバージョンである必要があります。ノードは、コントロールプレーンと同じバージョンにしておくことをお勧めします。*amazon-linux-2* を別の AMI タイプに置き換えることもできます。詳細については、「[推奨 Amazon Linux AMI ID を取得する](retrieve-ami-id.md)」を参照してください。 **注記** Amazon EC2 Systems Manager パラメータを使用すると、AMI ID を検索して指定することなく、後でノードを更新できます。AWS CloudFormation スタックがこの値を使用している場合、スタックの更新によって常に、指定された Kubernetes バージョンで推奨される最新の Amazon EKS 最適化 AMI が起動されます。これは、テンプレートの値を変更しない場合も同様です。 + **NodeImageId** - 独自のカスタム AMI を使用するには、使用する AMI の ID を入力します。 **重要** この値は、**NodeImageIdSSMParam** に指定されたすべての値を上書きします。**NodeImageIdSSMParam** 値を使用する場合は、 **NodeImageId** の値が空白であることを確認します。 + **[DisableIMDSv1]** – 各ノードは、デフォルトでインスタンスメタデータサービスバージョン 1 (IMDSv1) および IMDSv2 をサポートします。ただし、IMDSv1 を無効にできます。ノードグループでスケジュールされているノードまたは Pod で IMDSv1 を使用しない場合は、**[true]** を選択します。IDMS の詳細については「[インスタンスメタデータサービスの設定](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)」を参照してください。サービスアカウントの IAM ロールを実装した場合は、AWS のサービスへのアクセスを必要とするすべての Pod に対し、必要なアクセス許可を直接割り当てます。これにより、クラスター内の Pod は、現在の AWS リージョンの取得など、その他の理由で IMDS へのアクセスを必要としません。次に、ホストネットワークを使用しない Pod の IMDSv2 へのアクセスを無効にすることもできます。詳細については、[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node) を参照してください。 1. (オプション) **オプション** ページで、スタックリソースをタグ付けします。[**次へ**] を選択します。 1. [**確認**] ページで情報を確認し、スタックで IAM リソースを作成することを承認して、[**スタックの更新**] を選択します。 **注記** クラスター内の各ノードの更新には数分かかります。すべてのノードの更新が完了するのを待ってから、次の手順を実行します。 1. クラスターの DNS プロバイダーが `kube-dns` の場合は、`kube-dns` デプロイを 1 レプリカにスケールインします。 ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` 1. (オプション) Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) を使用している場合は、デプロイのスケーリングを目的のレプリカ数に戻します。 ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (オプション) 最新バージョンの [Amazon VPC CNI Plugin for Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) を使用していることを確認します。サポートされている最新のインスタンスタイプを利用するには、Amazon VPC CNI Plugin for Kubernetes のバージョンを更新することが必要になる場合があります。詳細については、「[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md)」を参照してください。