Amazon EKS で複数の CIDR 範囲を使用する方法を教えてください。

簡単な説明

Amazon EKS で複数の CIDR 範囲を使用するには、次の手順を実行します。

1. 追加の CIDR 範囲を割り当て、仮想プライベートクラウド (VPC) ネットワークを拡張します。
2. 新しい CIDR 範囲でサブネットを作成します。
3. 新しいサブネットをルートテーブルに関連付けます。
4. Amazon Virtual Private Cloud (Amazon VPC) の Container Network Interface (CNI) プラグインを設定し、新しい CIDR 範囲を使用します。

注: キャリアグレード用の NAT 範囲 (例: 100.64.0.0/10、198.19.0.0/16) にある CIDR (/16) を使用することをおすすめします。任意の有効な VPC 範囲をカスタムネットワークのセカンダリ CIDR 範囲として使用できます。ただし、これらの範囲は企業環境における使用には最適ではありません。カスタムネットワーク要件の詳細については、「考慮事項」を参照してください。

解決策

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI で発生したエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

前提条件: 次の構成が必要です。

• 実行中の Amazon EKS クラスター
• Amazon VPC の管理用の AWS Identity and Access Management (IAM) アクセス許可
• カスタムリソースを作成し、デーモンセットを編集する権限を含む kubectl
• システムにインストールされている jq のバージョン
  注: jq のダウンロードとインストール方法については、jq のウェブサイトで「jq のダウンロード」を参照してください。
• Bash シェルを備えた UNIX ベースのシステム
• 設定済みの VPC

追加の CIDR 範囲を割り当て、VPC ネットワークを拡張する

次の手順を実行します。

1. クラスター VPC の ID を取得して変数に保存するには、次の AWS CLI コマンド describe-cluster を実行します。

   VPC_ID=$(aws eks describe-cluster --name CLUSTER_NAME --region REGION_CODE --query "cluster.resourcesVpcConfig.vpcId" --output text)

   注: CLUSTER_NAME を使用するクラスター名に、REGION_CODE をクラスターをデプロイした AWS リージョンに置き換えてください。
2. 100.64.0.0/16 の範囲にある別の CIDR ブロックを VPC に関連付けるには、次の associate-vpc-cidr-block コマンドを実行します。

   aws ec2 associate-vpc-cidr-block --vpc-id $VPC_ID --cidr-block 100.64.0.0/16

新しい CIDR 範囲でサブネットを作成する

次の手順を実行します。

1. リージョン内のすべてのアベイラビリティーゾーンを一覧表示するには、次の describe-availability-zones コマンドを実行します。

   aws ec2 describe-availability-zones --region REGION_CODE --query 'AvailabilityZones[*].ZoneName'

   注: REGION_CODE をリソースをデプロイしたリージョンに置き換えてください。
2. 既存のサブネットを配置した各アベイラビリティーゾーンで使用するサブネットを作成します。新しい CIDR 範囲内で、VPC に新しいサブネットを作成するには、次の create-subnet コマンドを実行します。

   CUST_SNET1=$(aws ec2 create-subnet --cidr-block 100.64.0.0/19 --vpc-id $VPC_ID --availability-zone AZ1 | jq -r .Subnet.SubnetId)
   CUST_SNET2=$(aws ec2 create-subnet --cidr-block 100.64.32.0/19 --vpc-id $VPC_ID --availability-zone AZ2 | jq -r .Subnet.SubnetId)
   CUST_SNET3=$(aws ec2 create-subnet --cidr-block 100.64.64.0/19 --vpc-id $VPC_ID --availability-zone AZ3 | jq -r .Subnet.SubnetId)

   注: AZ1、AZ2、AZ3 を既存のサブネットのアベイラビリティーゾーンに置き換えます。
3. (オプション) キーと値のペアを設定してサブネットに名前タグを追加する場合は、次の create-tags コマンドを実行します。

   aws ec2 create-tags --resources $CUST_SNET1 --tags Key=KEY,Value=VALUE
   aws ec2 create-tags --resources $CUST_SNET2 --tags Key=KEY,Value=VALUE
   aws ec2 create-tags --resources $CUST_SNET3 --tags Key=KEY,Value=VALUE

   注: KEY をタグキーに、VALUE をタグの値に置き換えます。

新しいサブネットをルートテーブルに関連付ける

デフォルトでは、Amazon VPC は新しいサブネットを VPC のメインルートテーブルに関連付けます。このルートテーブルでは、その VPC にデプロイされたリソース間の通信のみが許可されます。VPC の CIDR ブロック範囲外の IP アドレスと通信できるようにするには、サブネットに独自のルートテーブルを作成する必要があります。

Amazon VPC CNI プラグインで新しい CIDR 範囲を使用する設定を行う

次の手順を実行します。

1. 使用する Kubernetes のバージョンに合ったプラグインバージョンを実行する必要があります。バージョンを確認するには、次のコマンドを実行します。

   kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2

   プラグインのバージョンが適切でない場合は、Amazon VPC CNI を更新します。

2. Amazon VPC CNI プラグインでカスタムネットワーク設定を有効にするには、次のコマンドを実行します。

   kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true

3. ワーカーノードを識別するための ENIConfig ラベルを追加するには、次のコマンドを実行します:

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

4. すべてのサブネットとアベイラビリティーゾーンに ENIConfig カスタムリソースを作成するには、次のコマンドを実行します。

   cat <<EOF  | kubectl apply -f -apiVersion: crd.k8s.amazonaws.com/v1alpha1
   kind: ENIConfig
   metadata:
    name: $AZ1
   spec:
     securityGroups:
       - cluster_security_group_id
     subnet: $CUST_SNET1
   EOF
   
   cat <<EOF | kubectl apply -f -
   apiVersion: crd.k8s.amazonaws.com/v1alpha1
   kind: ENIConfig
   metadata:
    name: $AZ2
   spec:
     securityGroups:
       - cluster_security_group_id
     subnet: $CUST_SNET2
   EOF
   
   cat <<EOF | kubectl apply -f -
   apiVersion: crd.k8s.amazonaws.com/v1alpha1
   kind: ENIConfig
   metadata:
    name: $AZ3
   spec:
     securityGroups:
       - cluster_security_group_id
     subnet: $CUST_SNET3
   EOF

   注: cluster_security_group_id を各 ENIConfig リソースで使用する既存のセキュリティグループ ID に置き換えてください。ENIConfig のリソース名は、新しいサブネットを作成したアベイラビリティーゾーンと同じです。

5. セルフマネージドノードグループを使用する場合は、セルフマネージドワーカーノードを起動すると、プラグインはそのノードに IP アドレスを割り当てられます。Subnet には、ENIConfig リソースで使用した新しいサブネットではなく、クラスターの作成時に選択した元のサブネットを指定します。マネージドノードグループと起動テンプレートを使用してノードを起動することもできます。いずれの場合も、インスタンスタイプに適した、正しい max-pods 値を特定する必要があります。Amazon EKS のカスタムネットワークでは、ポッドの配置にプライマリネットワークインターフェイスを使用しないため、この設定が必要です。max-pods-calculator.sh スクリプトの実行時には、--cni-custom-networking-enabled パラメータを追加する必要があります。
   次に、以下のコマンドを実行してセルフマネージドノードに max-pods 値を指定します。

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

   注: 20 を計算した max-pods 値に置き換えてください。
   マネージドノードグループでは、次のスクリプトを User data に追加します。

   #!/bin/bash
   /etc/eks/bootstrap.sh my-cluster-name --use-max-pods false --kubelet-extra-args '--max-pods=20'

   注: my-cluster-name を使用するクラスター名に、20 を計算した max-pods 値に置き換えてください。Amazon EKS 最適化 Amazon マシンイメージ (AMI) ID、または Amazon EKS 最適化 AMI からビルドしたカスタム AMI を起動テンプレートで指定します。Amazon Linux 2023 (AL2023) AMI は、nodeadm プロセスを使用します。このプロセスによる User data 構成の変更については、「Amazon Linux 2 から Amazon Linux 2023 へのアップグレード」を参照してください。
   使用するマネージドノードグループでは起動テンプレートを使用しない場合、または AMI ID が指定されていない場合は、マネージドノードグループは max-pods 値を自動計算します。

6. 新しいノードを準備した後、以前のノードをドレインすると、ポッドを正常にシャットダウンできます。詳細については、Kubernetes のウェブサイトで「ノードを安全にドレインする」を参照してください。ノードが既存のマネージドノードグループに属している場合は、次のコマンドを実行してそのノードグループを削除します。

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

   注: CLUSTER_NAME をクラスター名に、my-nodegroup をノードグループ名に置き換えてください。

7. 新しいデプロイを起動して設定をテストするには、次のコマンドを実行します。

   kubectl create deployment nginx-test --image=nginx --replicas=10   
   kubectl get pods -o wide --selector=app=nginx-test

   注: 上記のコマンドでは、10 個の新しいポッドが追加されます。ポッドは、新しいワーカーノード上の新しい CIDR 範囲にスケジュールされます。

重要: クラスターが VPC に関連付けた新しい CIDR ブロックを認識して許可リストに登録するまでには、最大 5 時間かかる場合があります。その間、Amazon EKS コントロールプレーンは新しいサブネットで起動したポッドと通信できません。api-server がウェブフック、kubectl logs コマンド、または kubectl exec コマンドを使用してポッドに接続する際、次のエラーメッセージが表示される場合があります。

"failed calling webhook "linkerd-proxy-injector.linkerd.io": failed to call webhook: Post "https://linkerd-proxy-injector.linkerd.svc:443/?timeout=10s": Address is not allowed"