このページの改善にご協力ください
本ユーザーガイドの改善にご協力いただけませんか? このページの下部までスクロールし、[GitHub でこのページの編集] を選択します。皆さまにご協力いただくことで、あらゆる人々に使いやすいユーザーガイドになります。
アプリケーションを新しいノードグループに移行する
このトピックは、新しいノードグループを作成し、既存のアプリケーションを新しいグループに適切に移行し、クラスターから古いノードグループを削除する方法について説明します。新しいノードグループに移行するには、eksctl
または AWS Management Console を使用します。
- eksctl
-
eksctl
を使用してアプリケーションを新しいノードグループに移行するにはeksctl を移行に使用する方法の詳細については、
eksctl
ドキュメントの「管理対象外のノードグループ」を参照してください。 この手順には、
eksctl
バージョン0.187.0
以降が必要です。お使いのバージョンは、以下のコマンドを使用して確認できます。eksctl version
eksctl
のインストールまたはアップグレードの手順については、eksctl
ドキュメントの「インストール」を参照してください。 注記
この手順は、
eksctl
で作成されたクラスターとノードグループに対してのみ機能します。-
をクラスター名に置き換えて、既存のノードグループの名前を取得します。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
-
次のコマンドを使用して、
eksctl
で新しいノードグループを起動します。コマンドのすべての
を独自の値に置き換えます。バージョン番号は、お使いのコントロールプレーンの Kubernetes バージョンよりも新しいものにすることはできません。また、コントロールプレーンの Kubernetes バージョンより 3 つ以上前のマイナーなバージョンにすることもできません。コントロールプレーンと同じバージョンを使用することをお勧めします。example value
次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。
すべての Kubernetes サービスアカウントに IAM ロールを割り当てて、Pods が必要最小限のアクセス許可のみを持つように計画しています。
クラスター内の Pods が、現在の AWS リージョン の取得といったその他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていません。
詳細については、「ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する
」を参照してください。 IMDS への Pod アクセスをブロックするには、次のコマンドに
--disable-pod-imds
オプションを追加します。注記
使用可能なフラグとその説明については、「https://eksctl.io/
」を参照してください。 eksctl create nodegroup \ --cluster
my-cluster
\ --version1.30
\ --namestandard-nodes-new
\ --node-typet3.medium
\ --nodes3
\ --nodes-min1
\ --nodes-max4
\ --managed=false -
前のコマンドが完了したら、次のコマンドを使用して、すべてのノードが
Ready
状態になったことを確認します。kubectl get nodes
-
次のコマンドを使用して、元のノードグループを削除します。このコマンドで、すべての
を自分のクラスター名とノードグループ名に置き換えます。example value
eksctl delete nodegroup --cluster
my-cluster
--namestandard-nodes-old
-
- AWS Management Console and AWS CLI
-
AWS Management Console と AWS CLI を使用してアプリケーションを新しいノードグループに移行するには
-
新しいノードグループを起動するには、セルフマネージド Amazon Linux ノードを作成するの手順に従います。
-
スタックの作成が完了したら、コンソールで選択し、[出力] を選択します。
-
作成されたノードグループの [NodeInstanceRole] を記録します。Amazon EKS ノードをクラスターに追加するには、これが必要です。
注記
追加の IAM ポリシーを古いノードグループの IAM ロールにアタッチした場合は、この同じポリシーを新しいノードグループの IAM ロールにアタッチして、新しいグループでその機能を管理します。これは、例えば、Kubernetes Cluster Autoscaler
のアクセス許可を追加した場合に適用されます。 -
相互通信できるように、両方のノードグループのセキュリティグループを更新します。詳細については、「」を参照してくださいAmazon EKS セキュリティグループの要件および考慮事項
-
両方のノードグループのセキュリティグループ ID を記録します。これは、AWS CloudFormation スタックからの出力に、NodeSecurityGroup の値として表示されます。
次の AWS CLI コマンドを使用して、スタック名からセキュリティグループ ID を取得します。これらのコマンドで、
oldNodes
は、古いノードスタックの AWS CloudFormation スタック名、newNodes
は、移行先のスタックの名前を表します。
をすべて自分の値に置き換えてください。example value
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 CLI コマンドでは、他のセキュリティグループからのすべてのプロトコルのトラフィックをすべて許可するインバウンドルールを各セキュリティグループに追加します。この設定により、ワークロードを新しいグループに移行している間に、各ノードグループ内の Pods は相互に通信できるようになります。
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
-
-
aws-auth
configmap を編集して、新しいノードインスタンスロールを RBAC にマッピングします。kubectl edit configmap -n kube-system aws-auth
新しいノードグループの新しい
mapRoles
エントリを追加します。クラスターが AWS GovCloud (米国東部) または AWS GovCloud (米国東部) の AWS リージョン にある場合は、arn:aws:
をarn:aws-us-gov:
に置き換えます。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
スニペットを、前の手順で記録した [NodeInstanceRole] 値に置き換えます。次に、更新された configmap を適用するには、ファイルを保存して閉じます。ARN of instance role (not instance profile)
-
ノードのステータスを監視し、新しいノードがクラスターに結合され、
Ready
ステータスになるまで待機します。kubectl get nodes --watch
-
(オプション) Kubernetes Cluster Autoscaler
を使用している場合は、スケーリングアクションの競合を回避するために、デプロイメントを 0 (ゼロ) レプリカにスケールダウンします。 kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system
-
以下のコマンドを使用して、
NoSchedule
で削除する各ノードをテイントに設定します。これは、置き換えるノード上で新しい Pods がスケジュールまたは再スケジュールされないようにするためです。詳細については、Kubernetes ドキュメントの「テイントと容認」を参照してください。 kubectl taint nodes
node_name
key=value:NoScheduleノードを新しい Kubernetes バージョンにアップグレードする場合は、次のコードスニペットを使用して、特定の Kubernetes バージョン (この場合は
1.28
) のすべてのノードを識別してテイントに設定できます。バージョン番号は、お使いのコントロールプレーンの Kubernetes バージョンよりも新しいものにすることはできません。また、コントロールプレーンの Kubernetes バージョンより 3 つ以上前のマイナーなバージョンにすることもできません。コントロールプレーンと同じバージョンを使用することをお勧めします。K8S_VERSION=
1.28
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 -
クラスターの 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
-
現在のデプロイメントで実行しているレプリカが 2 つ未満の場合は、そのデプロイメントを 2 つのレプリカにスケールアウトします。前のコマンドで、その出力が返された場合は、
をcoredns
に置き換えます。kubedns
kubectl scale deployments/
coredns
--replicas=2 -n kube-system -
次のコマンドを使用して、クラスターから削除する各ノードをドレーンします。
kubectl drain
node_name
--ignore-daemonsets --delete-local-dataノードを新しい Kubernetes バージョンにアップグレードする場合は、次のコードスニペットを使用して、特定の Kubernetes バージョン (この場合は
) のすべてのノードを識別してドレーンします。1.28
K8S_VERSION=
1.28
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 -
古いノードのドレーンが完了したら、以前承認したセキュリティグループのインバウンドルールを取り消します。次に、AWS CloudFormation スタックを削除してインスタンスを終了してください。
注記
さらに IAM ポリシーを古いノードグループの IAM ロールにアタッチした場合 (Kubernetes Cluster Autoscaler
に対するアクセス許可を追加する場合など) は、ロールからその追加ポリシーをデタッチしてから、AWS CloudFormation スタックを削除します。 -
先ほどノードのセキュリティグループ用に作成したインバウンドルールを取り消します。これらのコマンドで、
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 https://console.aws.amazon.com/cloudformation
で AWS CloudFormation コンソール を開きます。 -
古いノードスタックを選択します。
-
[削除] をクリックします。
-
[スタックの削除] 確認ダイアログボックスで、[スタックを削除] をクリックします。
-
-
aws-auth
configmap を編集して、RBAC から古いノードインスタンスロールを削除します。kubectl edit configmap -n kube-system aws-auth
古いノードグループの
mapRoles
エントリを削除します。クラスターが AWS GovCloud (米国東部) または AWS GovCloud (米国東部) の AWS リージョン にある場合は、arn:aws:
をarn:aws-us-gov:
に置き換えます。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 を適用するには、ファイルを保存して閉じます。
-
(オプション) Kubernetes Cluster Autoscaler
を使用している場合は、デプロイメントのスケーリングを 1 レプリカに戻します。 注記
必要に応じて、新しい Auto Scaling グループにタグ (
k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/
など) を付け、新しくタグ付けした Auto Scaling グループを参照するように、Cluster Autoscaler デプロイメントのコマンドを更新する必要があります。詳細については、「AWS の Cluster Autoscalermy-cluster
」を参照してください。 kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system
-
(オプション) 最新バージョンの Amazon VPC CNI Plugin for Kubernetes
を使用していることを確認します。サポートされている最新のインスタンスタイプを利用するには、CNI のバージョンを更新することが必要になる場合があります。詳細については、「Amazon VPC CNI plugin for Kubernetes Amazon EKS アドオンの使用」を参照してください。 -
クラスターの DNS 解決 (前のステップを参照) に
kube-dns
を使用している場合は、kube-dns
デプロイメントを 1 レプリカにスケーリングしてください。kubectl scale deployments/kube-dns --replicas=1 -n kube-system
-