**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# クラスターのためにセルフマネージドノードを更新する
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)」を参照してください。