Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

Amazon EKS ノードのセカンダリネットワークインターフェイスをカスタマイズする

フォーカスモード
Amazon EKS ノードのセカンダリネットワークインターフェイスをカスタマイズする - アマゾン EKS

このページの改善にご協力ください

本ユーザーガイドの改善にご協力いただけませんか? すべてのページの右側のペインにある GitHub リンクで、このページの編集を選択してください。皆さまにご協力いただくことで、あらゆる人々に使いやすいユーザーガイドになります。

このページの改善にご協力ください

本ユーザーガイドの改善にご協力いただけませんか? すべてのページの右側のペインにある GitHub リンクで、このページの編集を選択してください。皆さまにご協力いただくことで、あらゆる人々に使いやすいユーザーガイドになります。

このチュートリアルを開始する前に以下を完了してください:

  • 考慮事項を確認する

  • Amazon VPC CNI plugin for Kubernetes がセカンダリネットワークインターフェイスを作成し、IP アドレスを Pods に割り当てる方法に精通していること。詳細についてはGitHub の「ENI アロケーション」(ENI 割り当て 参照してください。

  • ご使用のデバイスまたは AWS クラウドシェル で、バージョン 2.12.3 以降、または AWS コマンドラインインターフェイス (AWS CLI のバージョン 1.27.160 以降がインストールおよび設定されていること。現在のバージョンを確認するには「aws --version | cut -d / -f2 | cut -d ' ' -f1」を参照してください。macOS の yumapt-get、または Homebrew などのパッケージマネージャーはAWS CLI の最新バージョンより数バージョン遅れることがあります。最新バージョンをインストールするには「AWS コマンドラインインターフェイスユーザーガイド」の「インストール」および「aws configure を使用したクイック設定」を参照してください。AWS クラウドシェル にインストールされている AWS CLI バージョンも最新バージョンより数バージョン遅れることがあります。更新するには「AWS クラウドシェル ユーザーガイド」の「ホームディレクトリへの AWS CLI のインストール」を参照してください。

  • デバイスまたは AWS クラウドシェル に、kubectl コマンドラインツールがインストールされていること。バージョンはご使用のクラスターの Kubernetes バージョンと同じか、1 つ前のマイナーバージョン以前、あるいはそれより新しいバージョンが使用できます。例えば、クラスターのバージョンが 1.29 である場合、kubectl のバージョン 1.281.29、または 1.30 が使用できます。kubectl をインストールまたはアップグレードする方法については「kubectl および eksctl のセットアップ」を参照してください。

  • このトピック内のステップはBash シェル内で実行することが推奨されます。Bash シェルを使用していない場合、行継続文字や、変数の設定と使用に関する方法など、一部のスクリプトコマンドのためにシェルの調整が必要となります。さらに、シェルの引用規則とエスケープ規則は異なる場合があります。詳細については「AWS コマンドラインインターフェイスのユーザーガイド」の「AWS CLI での文字列への引用符の使用」を参照してください。

このチュートリアルでは置き換えが必要だと明記されている場合を除き、サンプル値をそのまま使用することをお勧めします。本番向けクラスター向けにステップを完了する際には例値 を任意の値に置き換えることができます。すべてのステップは同一のターミナルで実行することをお勧めします。設定された変数はステップ全体で使用され、また、これらは異なるターミナルには存在しないためです。

このトピックのコマンドは「AWS CLI 使用例を使用する」に記載されている規則に従ってフォーマットされています。使用している AWS CLI プロファイルで定義されているデフォルトの AWS リージョンとは異なる AWS リージョンにあるリソースに対してコマンドラインからコマンドを実行する場合はコマンドに --region region-code を追加する必要があります。

カスタムネットワーキングを本番用クラスターにデプロイする場合は「ステップ 2: VPC を設定する」にスキップします。

ステップ 1: テスト VPC およびクラスターを作成する

次の手順により、テスト VPC とクラスターを作成し、そのたクラスターのためにカスタムネットワークを構成できます。本番向けのクラスターで必要になるいくつかの機能で、このトピックに関連のないものについては説明していません。そのため、本番ワークロード向けに、このテストクラスターを使用することはお勧めしません。詳細については「アマゾン EKS クラスターを作成します。」を参照してください。

  1. cluster_name および account_id 変数を定義します。

    export cluster_name=my-custom-networking-cluster account_id=$(aws sts get-caller-identity --query Account --output text)
  2. VPC を作成します。

    1. テストシステムにデプロイする場合はアマゾン EKS AWS クラウドフォーメーション テンプレートを使用して VPC を作成します。

      aws cloudformation create-stack --stack-name my-eks-custom-networking-vpc \ --template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-vpc-private-subnets.yaml \ --parameters ParameterKey=VpcBlock,ParameterValue=192.168.0.0/24 \ ParameterKey=PrivateSubnet01Block,ParameterValue=192.168.0.64/27 \ ParameterKey=PrivateSubnet02Block,ParameterValue=192.168.0.96/27 \ ParameterKey=PublicSubnet01Block,ParameterValue=192.168.0.0/27 \ ParameterKey=PublicSubnet02Block,ParameterValue=192.168.0.32/27

      AWS クラウドFormation スタックが作成されるまで数分かかります。次のコマンドを実行して、スタックのデプロイステータスを確認します。

      aws cloudformation describe-stacks --stack-name my-eks-custom-networking-vpc --query Stacks\[\].StackStatus --output text

      コマンドの出力が「CREATE_COMPLETE」になるまで、次のステップに進まないでください。

    2. テンプレートによって作成された、プライベートサブネット ID の値により変数を定義します。

      subnet_id_1=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \ --query "StackResources[?LogicalResourceId=='PrivateSubnet01'].PhysicalResourceId" --output text) subnet_id_2=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \ --query "StackResources[?LogicalResourceId=='PrivateSubnet02'].PhysicalResourceId" --output text)
    3. 前のステップで取得した、サブネットのアベイラビリティーゾーンを使用して変数を定義します。

      az_1=$(aws ec2 describe-subnets --subnet-ids $subnet_id_1 --query 'Subnets[*].AvailabilityZone' --output text) az_2=$(aws ec2 describe-subnets --subnet-ids $subnet_id_2 --query 'Subnets[*].AvailabilityZone' --output text)
  3. クラスターの IAM ロールを作成します。

    1. IAM 信頼ポリシー用の JSON ファイルを作成するには次のコマンドを実行してください。

      cat >eks-cluster-role-trust-policy.json <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } EOF
    2. アマゾン EKS クラスター の IAM ロールを作成します。必要に応じて、eks-cluster-role-trust-policy.json の前に、ステップでファイルの書き込み先となったコンピュータ上のパスを追加します。このコマンドは前のステップで作成した信頼ポリシーをロールに関連付けます。IAM ロールを作成するにはロールを作成する IAM プリンシパルiam:CreateRole アクション (許可) を割り当てる必要があります。

      aws iam create-role --role-name myCustomNetworkingAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
    3. アマゾンEKSクラスターポリシー という名前の アマゾン EKS マネージド型ポリシーをロールにアタッチします。IAM ポリシーを IAM プリンシパルにアタッチするにはポリシーのアタッチを行っているプリンシパルに、次のいずれかの IAM アクション (許可) を割り当てる必要があります: iam:AttachUserPolicy または iam:AttachRolePolicy

      aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy --role-name myCustomNetworkingAmazonEKSClusterRole
  4. アマゾン EKS クラスターを作成し、このクラスターとデバイスの間の通信を設定します。

    1. クラスターを作成する。

      aws eks create-cluster --name my-custom-networking-cluster \ --role-arn arn:aws:iam::$account_id:role/myCustomNetworkingAmazonEKSClusterRole \ --resources-vpc-config subnetIds=$subnet_id_1","$subnet_id_2
      注記

      リクエストで指定したアベイラビリティーゾーンのいずれかに、アマゾン EKS クラスターの作成に十分な容量がない場合にはエラーが表示されることがあります。このエラー出力には新しいクラスターをサポートできるアベイラビリティーゾーンが表示されます。アカウント向けにサポートされているアベイラビリティーゾーンにある 2 つ以上のサブネットを使用して、クラスターを作成します。詳細については「容量不足」を参照してください。

    2. クラスターが作成されるまでに数分かかります。次のコマンドを実行して、クラスターのデプロイステータスを確認します。

      aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status

      コマンドの出力が「"ACTIVE"」になるまで、次のステップに進まないでください。

    3. クラスターと通信するために kubectl を設定します。

      aws eks update-kubeconfig --name my-custom-networking-cluster

ステップ 2: VPC を設定する

このチュートリアルでは「ステップ 1: テスト VPC とクラスターを作成する」で作成された VPC が必要です。本番向けクラスターの場合は値の例 をすべて実際の値に置き換えて、VPC に合うように各ステップを調整します。

  1. 現在インストールされている Amazon VPC CNI plugin for Kubernetes のバージョンが最新であることを確認します。アマゾン EKS アドオンタイプの最新バージョンを確認し、そのバージョンに更新するには「アマゾン EKS アドオンを更新する」を参照してください。セルフマネージドアドオンタイプの最新バージョンを確認し、そのバージョンに更新するには「アマゾン VPC CNI を使用してPodsに IP を割り当てる」を参照してください。

  2. クラスター VPC の ID を取得し、後のステップで使用するために変数に格納します。本番向けクラスターの場合はmy-custom-networking-cluster を自分のクラスター名に置き換えます

    vpc_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query "cluster.resourcesVpcConfig.vpcId" --output text)
  3. 追加の Classless Inter-Domain Routing (CIDR ブロックを、クラスターの VPC に関連付けます。CIDR ブロックは既存の関連付けられた CIDR ブロックと重複することはできません。

    1. 現在 VPC に関連付けられている CIDR ブロックを表示します。

      aws ec2 describe-vpcs --vpc-ids $vpc_id \ --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table

      出力例は次のとおりです。

      ---------------------------------- | DescribeVpcs | +-----------------+--------------+ | CIDRBlock | State | +-----------------+--------------+ | 192.168.0.0/24 | associated | +-----------------+--------------+
    2. 追加の CIDR ブロックを VPC に関連付けます。詳細については「アマゾン VPC ユーザーガイド」の「追加の IPv4 CIDR ブロックと VPC の関連付け」を参照してください。

      aws ec2 associate-vpc-cidr-block --vpc-id $vpc_id --cidr-block 192.168.1.0/24
    3. 新しいブロックが関連付けられていることを確認します。

      aws ec2 describe-vpcs --vpc-ids $vpc_id --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table

      出力例は次のとおりです。

      ---------------------------------- | DescribeVpcs | +-----------------+--------------+ | CIDRBlock | State | +-----------------+--------------+ | 192.168.0.0/24 | associated | | 192.168.1.0/24 | associated | +-----------------+--------------+

    新しい CIDR ブロックの Stateassociated に遷移するまで、次のステップには進まないでください。

  4. 既存のサブネットが存在する各アベイラビリティーゾーン内で、使用するサブネットを必要な数だけ作成します。前のステップで VPC に関連付けた、CIDR ブロック内にある CIDR ブロックを指定します。

    1. 新しいサブネットを作成します。サブネットは既存のサブネットが置かれているものとは異なる VPC CIDR ブロックの中に作成する必要があり、作成するアベイラビリティーゾーンは既存のサブネットと同じにする必要があります。この例では現在のプライベートサブネットが存在する各アベイラビリティーゾーンにある新しい CIDR ブロックの中に、1 つのサブネットが作成されます。作成されたサブネットの ID は後のステップで使用するために変数に格納されます。Name の値は前のステップで アマゾン EKS VPC テンプレートを使用して作成されたサブネットに、割り当てられている値と一致します。名前は必須ではありません。名前には異なる値を使用できます。

      new_subnet_id_1=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_1 --cidr-block 192.168.1.0/27 \ --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet01},{Key=kubernetes.io/role/internal-elb,Value=1}]' \ --query Subnet.SubnetId --output text) new_subnet_id_2=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_2 --cidr-block 192.168.1.32/27 \ --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet02},{Key=kubernetes.io/role/internal-elb,Value=1}]' \ --query Subnet.SubnetId --output text)
      重要

      デフォルトで新しいサブネットはVPC のメインルートテーブルに暗黙的に関連付けられます。このルートテーブルにより、その VPC にデプロイされているすべてのリソース間の通信が可能になります。ただし、VPC に関連付けられた CIDR ブロックの外部にある IP アドレスが割り当てられたリソースとの通信は許可されません。この動作を変更するには独自のルートテーブルをサブネットに関連付けます。詳細については「アマゾン VPC ユーザーガイド」の「サブネットルートテーブル」を参照してください。

    2. 使用している VPC の現在のサブネットを表示します。

      aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" \ --query 'Subnets[*].{SubnetId: SubnetId,AvailabilityZone: AvailabilityZone,CidrBlock: CidrBlock}' \ --output table

      出力例は次のとおりです。

      ---------------------------------------------------------------------- | DescribeSubnets | +------------------+--------------------+----------------------------+ | AvailabilityZone | CidrBlock | SubnetId | +------------------+--------------------+----------------------------+ | us-west-2d | 192.168.0.0/27 | subnet-example1 | | us-west-2a | 192.168.0.32/27 | subnet-example2 | | us-west-2a | 192.168.0.64/27 | subnet-example3 | | us-west-2d | 192.168.0.96/27 | subnet-example4 | | us-west-2a | 192.168.1.0/27 | subnet-example5 | | us-west-2d | 192.168.1.32/27 | subnet-example6 | +------------------+--------------------+----------------------------+

      作成した 192.168.1.0 CIDR ブロック内のサブネットが、192.168.0.0 CIDR ブロック内のサブネットと同じアベイラビリティーゾーンに置かれていることが確認できます。

ステップ 3: Kubernetes リソースを設定する

  1. aws-node DaemonSet で AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG 環境変数を true に設定します。

    kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
  2. クラスターのセキュリティグループの ID を取得し、次のステップで使用するために変数に格納します。このセキュリティグループはクラスターの作成時に アマゾン EKS により自動的に作成されます。

    cluster_security_group_id=$(aws eks describe-cluster --name $cluster_name --query cluster.resourcesVpcConfig.clusterSecurityGroupId --output text)
  3. Pods をデプロイするサブネットごとに ENIConfig カスタムリソースを作成します。

    1. 各ネットワークインターフェイス設定に固有のファイルを作成します。

      + 次のコマンドでは前のステップで作成した 2 つのサブネットのそれぞれに、個別の ENIConfig ファイルが作成されます。name の値は一意である必要があります。これらの名前はサブネットが存在するアベイラビリティーゾーンと同じものが付けられます。クラスターセキュリティグループはENIConfig に割り当てられます。

      +

cat >$az_1.yaml <<EOF
apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata:
  name: $az_1
spec:
  securityGroups:
    - $cluster_security_group_id
  subnet: $new_subnet_id_1
EOF
cat >$az_2.yaml <<EOF apiVersion: crd.k8s.amazonaws.com/v1alpha1 kind: ENIConfig metadata: name: $az_2 spec: securityGroups: - $cluster_security_group_id subnet: $new_subnet_id_2 EOF

+ 本番向けのクラスターでは前のコマンドに次の変更を行います:

+ * $cluster_security_group_idENIConfig で使用する既存のセキュリティグループの ID に置き換えます。* 可能な限り、ENIConfig が使用されるアベイラビリティーゾーンと同じ名前を、ENIConfigs に付けることをお勧めします。いくつかの理由から、ENIConfigs に対して、アベイラビリティーゾーンとは異なる名前を使用する必要が生じることがあります。例えば、同じアベイラビリティーゾーンに 3 つ以上のサブネットがあり、そのすべてでカスタムネットワーキングを使用したい場合は同一のアベイラビリティーゾーンに複数の ENIConfigs が必要になります。各 ENIConfig には一意の名前が必要であるため、複数の ENIConfigs に対しアベイラビリティーゾーンの名前を使用することはできません。

+ ENIConfig の中で、アベイラビリティーゾーンと異なる名前を持つものについては前のコマンドで $az_1$az_2 を独自の名前に置き換えます。さらに、この後のチュートリアルで ENIConfig でノードをアノテーションします。

+ 本番向けクラスターで使用するために有効なセキュリティグループを指定しておらず、かつ:

  • Amazon VPC CNI plugin for Kubernetes のバージョン 1.8.0 以降を使用する場合はノードのプライマリ エラスティックネットワークインターフェイス に関連付けられたセキュリティグループが使用されます。

  • 1.8.0 より前のバージョンの Amazon VPC CNI plugin for Kubernetes を使用している場合はVPC のデフォルトのセキュリティグループが、セカンダリネットワークインターフェースに割り当てられます。

    重要:

  • AWS_VPC_K8S_CNI_EXTERNALSNAT=false はKubernetes 用の アマゾン VPC CNI プラグインの設定のデフォルト設定です。デフォルト設定を使用している場合、VPC に関連付けられた CIDR ブロックのいずれにもない IP アドレスに向けて送信されたトラフィックにはノードのプライマリネットワークインターフェイスでの、セキュリティグループとサブネットが使用されます。セカンダリネットワークインターフェイスを作成するために使用された、ENIConfigs で定義されているサブネットとセキュリティグループはこのトラフィックでは使用されません。この設定の詳細については「Podsのアウトバウンドインターネットアクセスを有効にする」を参照してください。

  • また、Pods でもセキュリティグループを使用する場合、そのセキュリティグループは SecurityGroupPolicy で指定されたものとなり、ENIConfigs で指定されたものは使用されません。詳細については「個々の Pods にセキュリティグループを割り当てる」を参照してください。

    1. 以下のコマンドを使用して、作成したカスタムリソースファイルをそれぞれクラスターに適用します。

      kubectl apply -f $az_1.yaml kubectl apply -f $az_2.yaml
      1. ENIConfigs が作成されたことを確認します。

        kubectl get ENIConfigs

        出力例は次のとおりです。

        NAME AGE us-west-2a 117s us-west-2d 105s
      2. 本番向けのクラスターで、カスタムネットワーキングを有効にしており、ENIConfigs の名前を使用されているアベイラビリティーゾーンとは異なるものにした場合は次のステップに移り、アマゾン EC2 ノードをデプロイします。

        クラスターで作成された任意の新しい アマゾン EC2 ノードに対し、Kubernetes がアベイラビリティーゾーン用の ENIConfig を自動的に適用することを許可します。

    2. このチュートリアルでのテスト用クラスターの場合はこのまま次のステップに移動します。

      実稼働クラスターの場合は ENI_CONFIG_ANNOTATION_DEF 環境変数用のキー k8s.amazonaws.com/eniConfig を使用する annotation が、aws-node DaemonSet のためのコンテナ仕様内に存在することを確認します。

      kubectl describe daemonset aws-node -n kube-system | grep ENI_CONFIG_ANNOTATION_DEF

      出力が返される場合はアノテーションが存在します。出力が返されない場合、その変数は設定されていません。本番向けクラスターの場合にはここでの設定と、以降のステップで示す設定のどちらも使用可能です。ここでの設定を使用すると、以降のステップの設定は上書きされます。このチュートリアルではこの後のステップでの設定を使用します。

    3. クラスター内に作成された任意の新しい アマゾン EC2 ノードに対し、自動的にアベイラビリティーゾーンのための ENIConfig を適用するように、aws-node DaemonSet を更新します。

      kubectl set env daemonset aws-node -n kube-system ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone

ステップ 4: アマゾン EC2 ノードをデプロイする

  1. ノードの IAM ロールを作成します。

    1. IAM 信頼ポリシー用の JSON ファイルを作成するには次のコマンドを実行してください。

      cat >node-role-trust-relationship.json <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } EOF
    2. 次のコマンドを実行して、ロール名の変数を設定します。マイカスタムネットワーキングノード役割 は任意の名前に置き換えることができます。

      export node_role_name=myCustomNetworkingNodeRole
    3. IAM ロールを作成し、返された アマゾン リソースネーム (ARN) を、後のステップで使用するために変数に格納します。

      node_role_arn=$(aws iam create-role --role-name $node_role_name --assume-role-policy-document file://"node-role-trust-relationship.json" \ --query Role.Arn --output text)
    4. IAM ロールに、3 つの必須な IAM マネージドポリシーをアタッチします。

      aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \ --role-name $node_role_name aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \ --role-name $node_role_name aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \ --role-name $node_role_name
      重要

      分かりやすくするため、このチュートリアルではアマゾンEKS_CNI_Policy ポリシーはノードの IAM ロールにアタッチされています。ただし、本番向けクラスターの場合はAmazon VPC CNI plugin for Kubernetes のみで使用される IAM ロールに、個別にポリシーをアタッチすることをお勧めします。詳細については「IRSA を使用するように アマゾン VPC CNI プラグインを設定する」を参照してください。

  2. 次のいずれかのタイプのノードグループを作成します。デプロイするインスタンスタイプを確認するには「最適な Amazon EC2 ノードインスタンスタイプを選択する」を参照してください。このチュートリアルのために、マネージド型、および起動テンプレートを使用しない、または AMI ID が指定されていない起動テンプレートを使用するオプションを完了します。本番ワークロードでノードグループを使用する場合はそのグループをデプロイする前に、マネージド型ノードグループ クラスターのマネージドノードグループを作成する およびセルフマネージド型ノードグループ セルフマネージドノードでノードを自分自身で維持する のすべてのオプションについて理解しておくことをお勧めします。

    • マネージド型 — 次のいずれかのオプションを使用して、ノードグループをデプロイします:

      • 起動テンプレートを使用しない、または AMI ID が指定されていない起動テンプレートを使用する — 次のコマンドを実行してください。このチュートリアルではサンプルの値を使用します。本番向けのノードグループの場合はすべてのサンプルの値を、実際の値に置き換えてください。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。

        aws eks create-nodegroup --cluster-name $cluster_name --nodegroup-name my-nodegroup \ --subnets $subnet_id_1 $subnet_id_2 --instance-types t3.medium --node-role $node_role_arn
      • 指定された AMI ID を持つ起動テンプレートを使用::

        1. そのトピックのステップ 3 までの アマゾン EKS の推奨最大値 Pods `for your nodes. Follow the instructions in Amazon EKS recommended maximum Pods for each Amazon EC2 instance type, adding `--cni-custom-networking-enabled を決定します。後のステップで使用するために、この出力を書き留めます。

        2. 起動テンプレートで、アマゾン EKS 最適化 AMI ID を指定するか、アマゾン EKS 最適化 AMI から構築されたカスタム AMI を指定します。その後、起動テンプレートを使用してノードグループをデプロイし、さらに、起動テンプレートにある次のユーザーデータを指定します。このユーザーデータは引数を bootstrap.sh ファイルに渡します。ブートストラップファイルの詳細についてはGitHub の bootstrap.sh を参照してください。20 の部分は前のステップで使用した値 (推奨) または独自の値に置き換えることができます。

          /etc/eks/bootstrap.sh my-cluster --use-max-pods false --kubelet-extra-args '--max-pods=20'

          アマゾン EKS 最適化 AMI から構築されていないカスタム AMI を作成した場合は自分で設定をカスタム作成する必要があります。

    • セルフマネージド型::

      1. アマゾン EKS で推奨される、ノードでの Pods の最大数を決定します。「各 アマゾン EC2 インスタンスタイプの アマゾン EKS の推奨最大ポッド数」の指示に従い、そのトピックのステップ 3 で --cni-custom-networking-enabled を追加します。後のステップで使用するために、この出力を書き留めます。

      2. セルフマネージド アマゾンリナックス ノードを作成する」の手順に従い、ノードグループをデプロイします。ブートストラップ引数 パラメータに、以下のテキストを指定します。20 の部分は前のステップで使用した値 (推奨) または独自の値に置き換えることができます。

        --use-max-pods false --kubelet-extra-args '--max-pods=20'
        注記

        本番クラスター内のノードで非常に多くの Pods をサポートさせたい場合はアマゾン EC2 インスタンスタイプごとに アマゾン EKS 推奨最大ポッドのスクリプトを再実行してください。また、このコマンドには --cni-prefix-delegation-enabled オプションを追加します。たとえば、m5.large インスタンスタイプの場合は110 が返されます。この機能を有効化する方法については「プレフィックスを使用して アマゾン EKS ノードに割り当てる IP アドレスを増やす」を参照してください。この機能はカスタムネットワーキングで使用できます。

        ノードグループの作成には数分かかります。次のコマンドを使用すると、マネージド型のノードグループ作成のステータスを確認できます。

        aws eks describe-nodegroup --cluster-name $cluster_name --nodegroup-name my-nodegroup --query nodegroup.status --output text

        出力が「ACTIVE」を返すまで、次のステップに進まないでください。

  3. このチュートリアルではこのステップをスキップできます。

    本番向けのクラスターにおいて、ENIConfigs の名前を、それが使用されているアベイラビリティーゾーンと同じにしなかった場合にはノードに対し、そのノードで使用すべき ENIConfig の名前をアノテーションします。各アベイラビリティーゾーンにサブネットが 1 つしかなく、ENIConfigs にアベイラビリティーゾーンと同じ名前を付けている場合にはこのステップは必要ありません。前のステップで機能を有効化してあるのなら、Amazon VPC CNI plugin for Kubernetes が適切な ENIConfig をノードに対し自動的に関連付けるためです。

    1. クラスター内のノードのリストを取得します。

      kubectl get nodes

      出力例は次のとおりです。

      NAME STATUS ROLES AGE VERSION ip-192-168-0-126.us-west-2.compute.internal Ready <none> 8m49s v1.22.9-eks-810597c ip-192-168-0-92.us-west-2.compute.internal Ready <none> 8m34s v1.22.9-eks-810597c
    2. 各ノードが属するアベイラビリティーゾーンを決定します。前のステップで返された各ノードに対し 次のコマンドを実行してください。

      aws ec2 describe-instances --filters Name=network-interface.private-dns-name,Values=ip-192-168-0-126.us-west-2.compute.internal \ --query 'Reservations[].Instances[].{AvailabilityZone: Placement.AvailabilityZone, SubnetId: SubnetId}'

      出力例は次のとおりです。

      [ { "AvailabilityZone": "us-west-2d", "SubnetId": "subnet-Example5" } ]
    3. 各ノードを、サブネット ID とアベイラビリティーゾーンのために作成した ENIConfig でアノテーションします。各ノードのアノテーションに使用できる ENIConfig は 1 つだけです。ただし、複数のノードに対し同じ ENIConfig でアノテーションすることは可能です。値の例 は実際に使用する値に置き換えます。

      kubectl annotate node ip-192-168-0-126.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName1 kubectl annotate node ip-192-168-0-92.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName2
  4. カスタムネットワーキング機能の使用に切り替える前に、ノードを使用している本番向けクラスター内で Pods を実行していた場合には以下のタスクを完了してください:

    1. カスタムネットワーク機能を使用しているノードが、使用可能であることを確認します。

    2. ノードを遮断およびドレインして、Pods をスムーズにシャットダウンします。詳細については「Kubernetes ドキュメント」の「Safely Drain a Node」(ノードを安全にドレインする 参照してください。

    3. ノードを終了します。ノードが既存のマネージド型ノードグループ内にある場合はそのノードグループを削除できます。デバイスに沿ったコマンドをコピーします。必要に応じてコマンドに次の変更を加え、変更したコマンドを実行してください:

      • マイクラスター の部分は自分のクラスター名に置き換えます。

      • マイノードグループ を、ノードグループの名前に置き換えます。

        aws eks delete-nodegroup --cluster-name my-cluster --nodegroup-name my-nodegroup

    カスタムネットワーク機能はk8s.amazonaws.com/eniConfig ラベルで登録されている新しいノードでのみ使用されます。

  5. Pods に、前のステップで作成したサブネットの 1 つに関連付けられた CIDR ブロックから、 IP アドレスが割り当てられていることを確認します。

    kubectl get pods -A -o wide

    出力例は次のとおりです。

    NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES kube-system aws-node-2rkn4 1/1 Running 0 7m19s 192.168.0.92 ip-192-168-0-92.us-west-2.compute.internal <none> <none> kube-system aws-node-k96wp 1/1 Running 0 7m15s 192.168.0.126 ip-192-168-0-126.us-west-2.compute.internal <none> <none> kube-system coredns-657694c6f4-smcgr 1/1 Running 0 56m 192.168.1.23 ip-192-168-0-92.us-west-2.compute.internal <none> <none> kube-system coredns-657694c6f4-stwv9 1/1 Running 0 56m 192.168.1.28 ip-192-168-0-92.us-west-2.compute.internal <none> <none> kube-system kube-proxy-jgshq 1/1 Running 0 7m19s 192.168.0.92 ip-192-168-0-92.us-west-2.compute.internal <none> <none> kube-system kube-proxy-wx9vk 1/1 Running 0 7m15s 192.168.0.126 ip-192-168-0-126.us-west-2.compute.internal <none> <none>

    VPC に追加した 192.168.1.0 CIDR ブロックからの IP アドレスが、coredns Pods に割り当てられていることが確認できます。カスタムネットワーキングを使用していない場合はここに 192.168.0.0 CIDR ブロックからのアドレスが割り当てられています。この CIDR ブロックが、元々 VPC に関連付けられている唯一のブロックであるためです。

    Pod’s spechostNetwork=true を含む場合にはノードのプライマリ IP アドレスが割り当てられます。追加したサブネットのアドレスは割り当てられません。デフォルトではこの値は false に設定されます。この値はクラスターで実行されている kube-proxy および Amazon VPC CNI plugin for Kubernetes(aws-node)Pods に対して true に設定されます。これが、kube-proxy とプラグインの aws-node Pods に、前の出力にある 192.168.1.x アドレスが割り当てられない理由です。Pod’s hostNetwork の設定の詳細については「Kubernetes API リファレンス」の「PodSpec v1 core」を参照してください。

ステップ 5: チュートリアルでのリソースを削除する

このチュートリアル完了後は作成したリソースを削除することをお勧めします。その後、ここでのステップを調整して、本番向けクラスターのカスタムネットワーキングを有効化することができます。

  1. 作成したノードグループが完全にテスト向けである場合はそれを削除してください。

    aws eks delete-nodegroup --cluster-name $cluster_name --nodegroup-name my-nodegroup

    AWS CLI から、クラスターが削除済みだと出力された場合でも、実際にはその削除プロセスが完了していない場合があります。削除のプロセスには数分かかります。次のコマンドを実行して、処理の完了を確認します。

    aws eks describe-nodegroup --cluster-name $cluster_name --nodegroup-name my-nodegroup --query nodegroup.status --output text

    次のように出力されるまで、次に進まないでください。

    An error occurred (ResourceNotFoundException) when calling the DescribeNodegroup operation: No node group found for name: my-nodegroup.
  2. 作成したノードグループが完全にテスト向けである場合はノードの IAM ロールを削除します。

    1. ロールからポリシーをデタッチします。

      aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
    2. ロールを削除します。

      aws iam delete-role --role-name myCustomNetworkingNodeRole
  3. クラスターを削除します。

    aws eks delete-cluster --name $cluster_name

    以下のコマンドを使用して、クラスターが削除されたことを確認します。

    aws eks describe-cluster --name $cluster_name --query cluster.status --output text

    次のような出力が返された場合はクラスターが正常に削除されています。

    An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-cluster.
  4. クラスターの IAM ロールを削除します。

    1. ロールからポリシーをデタッチします。

      aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSClusterRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
    2. ロールを削除します。

      aws iam delete-role --role-name myCustomNetworkingAmazonEKSClusterRole
  5. 前のステップで作成したサブネットを削除します。

    aws ec2 delete-subnet --subnet-id $new_subnet_id_1 aws ec2 delete-subnet --subnet-id $new_subnet_id_2
  6. 作成した VPC を削除します。

    aws cloudformation delete-stack --stack-name my-eks-custom-networking-vpc
プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.