AWS CloudFormation ノードスタックを更新する - Amazon EKS

AWS CloudFormation ノードスタックを更新する

このトピックは、新しい AMI を使用して既存の AWS CloudFormation セルフマネージド型ノードスタックを更新する方法について説明します。この手順を使用して、クラスターの更新後にノードを新しいバージョンの Kubernetes に更新することができます。それ以外の場合は、Kubernetes の既存バージョン用の Amazon EKS に最適化された最新の AMI に更新することができます。

重要

このトピックでは、セルフマネージド型ノードのノードの更新について説明します。「マネージドノードグループを使用してノードライフサイクルを簡素化する」方法の詳細については、「クラスターのためにマネージドノードグループを更新する」を参照してください。

最新のデフォルトの Amazon EKS ノード AWS CloudFormation テンプレートは、古い AMI を一度に 1 つずつ削除する前に、新しい AMI を使用してインスタンスをクラスターに起動するように設定されています。この設定により、ローリング更新中にクラスター内で Auto Scaling グループのアクティブなインスタンスが常に必要数確保されるようになります。

注記

この方法は、eksctl を使用して作成されたノードグループではサポートされていません。eksctl を使用してクラスターまたはノードグループを作成した場合は、「アプリケーションを新しいノードグループに移行する」を参照してください。

  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

  2. 現在のデプロイメントで実行しているレプリカが 2 つ未満の場合は、そのデプロイメントを 2 つのレプリカにスケールアウトします。前のコマンドの出力が kube-dns を返していた場合は、coredns を kube-dns に置き換えます。

    kubectl scale deployments/coredns --replicas=2 -n kube-system

  3. (オプション) Kubernetes Cluster Autoscaler を使用している場合は、スケーリングアクションの競合を回避するために、デプロイメントを 0 (ゼロ) レプリカにスケールダウンします。

    kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system

  4. 現在のノードグループのインスタンスタイプと必要なインスタンス数を決定します。グループの AWS CloudFormation テンプレートを更新する場合は、後でこれらの値を入力します。

    1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

    2. 左ナビゲーションペインの [Launch Configurations] (起動設定) を選択し、既存のノードの起動設定のインスタンスタイプを書き留めます。

    3. 左ナビゲーションペインの [Auto Scaling] (グループ) を選択し、既存の Auto Scaling グループのノードの、インスタンスの [Desired] (必要) 数を書き留めます。

  5. AWS CloudFormation コンソールを開きます。

  6. ノードグループスタックを選択し、[更新] を選択します。

  7. [Replace current template] (現在のテンプレートを置き換える) を選択し、Amazon S3 URL を選択します。

  8. Amazon S3 URL で、ノードの AWS CloudFormation テンプレートの最新バージョンを使用していることを確認するために以下の URL をテキストエリアに貼り付けます。続いて、[次へ] を選択します。

    https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml

  9. [Specify stack details] (スタックの詳細の指定) ページで、以下のパラメータを指定し、[Next] (次へ) を選択します。

    • [NodeAutoScalingGroupDesiredCapacity] – 前のステップで記録した必要なインスタンス数を入力します。または、スタック更新時にスケーリングする必要のある新しいノード数を入力します。

    • NodeAutoScalingGroupMaxSize - ノードの Auto Scaling グループがスケールアウトする最大ノード数を入力します。この値は、必要な容量よりも少なくとも 1 ノード多い必要があります。これは、更新時にノード数を減らさずにノードのローリング更新を実行できるようにするためです。

    • NodeInstanceType — 前のステップで記録したインスタンスタイプを選択します。または、ノードに別のインスタンスタイプを選択します。異なるインスタンスタイプを選択する前に、「最適な Amazon EC2 ノードインスタンスタイプを選択する」を確認してください。各 Amazon EC2 インスタンスタイプは最大数の Elastic Network Interface (ネットワークインターフェイス) をサポートし、各ネットワークインターフェイスは最大数の IP アドレスをサポートします。ワーカーノードと Pod には、それぞれ IP アドレスが割り当てられています。そのため、各 Amazon EC2 ノードで実行させたい Pods の最大数をサポートするインスタンスタイプを選択することが重要です。インスタンスタイプごとにサポートされるネットワークインターフェイスと IP アドレスのリストについては、「各インスタンスタイプのネットワークインターフェイスごとの IP アドレス」を参照してください。例えば m5.large インスタンスタイプは、ワーカーノードと Pods に対して最大 30 の IP アドレスをサポートします。

      注記

      最新バージョンの Amazon VPC CNI plugin for Kubernetes でサポートされているインスタンスタイプは、GitHub の vpc_ip_resource_limit.go に示されています。サポートされている最新のインスタンスタイプを使用するため、Amazon VPC CNI plugin for Kubernetes のバージョンを更新することが必要になる場合があります。詳細については、「Amazon VPC CNI」を参照してください。

      重要

      AWS リージョンによっては利用できないインスタンスタイプがあります。

    • NodeImageIdSSMParam - 更新する AMI ID の Amazon EC2 Systems Manager パラメータです。次の値では、Kubernetes バージョン 1.30 用の Amazon EKS に最適化された最新の AMI が使用されています。

      /aws/service/eks/optimized-ami/1.30/amazon-linux-2/recommended/image_id

      1.30 は、同一のサポートされている Kubernetes バージョンに置き換えることができます。または、コントロールプレーンで実行されている Kubernetes バージョンより 1 つ前までのバージョンである必要があります。ノードは、コントロールプレーンと同じバージョンにしておくことをお勧めします。amazon-linux-2 を別の AMI タイプに置き換えることもできます。詳細については、「推奨 Amazon Linux AMI ID を取得する」を参照してください。

      注記

      Amazon EC2 Systems Manager パラメータを使用すると、AMI ID を検索して指定することなく、後でノードを更新できます。AWS CloudFormation スタックがこの値を使用している場合、スタックの更新によって常に、指定された Kubernetes バージョンで推奨される最新の Amazon EKS 最適化 AMI が起動されます。これは、テンプレートの値を変更しない場合も同様です。

    • NodeImageId - 独自のカスタム AMI を使用するには、使用する AMI の ID を入力します。

      重要

      この値は、NodeImageIdSSMParam に指定されたすべての値を上書きします。NodeImageIdSSMParam 値を使用する場合は、 NodeImageId の値が空白であることを確認します。

    • [DisableIMDSv1] – 各ノードは、デフォルトでインスタンスメタデータサービスバージョン 1 (IMDSv1) および IMDSv2 をサポートします。ただし、IMDSv1 を無効にできます。ノードグループでスケジュールされているノードまたは Pods で IMDSv1 を使用しない場合は、[true] を選択します。IDMS の詳細については、「インスタンスメタデータサービスの設定」を参照してください。サービスアカウントの IAM ロールを実装し、AWS のサービスへのアクセスを必要とするすべての Pods に対し、必要なアクセス許可を直接割り当てた場合。これにより、クラスター内の Pods は、現在の AWS リージョンの取得など、その他の理由で IMDS へのアクセスを必要としません。次に、ホストネットワークを使用しない Pods の IMDSv2 へのアクセスを無効にすることもできます。詳細については、ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する を参照してください。

  10. (オプション) オプション ページで、スタックリソースをタグ付けします。[Next] を選択します。

  11. [確認] ページで情報を確認し、スタックで IAM リソースを作成することを承認して、[スタックの更新] を選択します。

    注記

    クラスター内の各ノードの更新には数分かかります。すべてのノードの更新が完了するのを待ってから、次の手順を実行します。

  12. クラスターの DNS プロバイダーが kube-dns の場合は、kube-dns デプロイを 1 レプリカにスケールインします。

    kubectl scale deployments/kube-dns --replicas=1 -n kube-system

  13. (オプション) Kubernetes Cluster Autoscaler を使用している場合は、デプロイメントのスケーリングを目的のレプリカ数に戻します。

    kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system

  14. (オプション) 最新バージョンの Amazon VPC CNI Plugin for Kubernetes を使用していることを確認します。サポートされている最新のインスタンスタイプを使用するため、Amazon VPC CNI plugin for Kubernetes のバージョンを更新することが必要になる場合があります。詳細については、「Amazon VPC CNI」を参照してください。