すべてのプロダクト
Search

このプロダクト

    Container Service for Kubernetes:Pod の vSwitch の変更

    ドキュメントセンター

    Container Service for Kubernetes:Pod の vSwitch の変更

    最終更新日:Mar 07, 2026

    Terway ネットワークモードでは、既存の vSwitch の IP リソースが不足した場合や、Pod の CIDR ブロックに新しい vSwitch を追加する必要がある場合に、vSwitch をスケールアウトする必要があります。このトピックでは、vSwitch を追加して、ご利用の Container Service for Kubernetes (ACK) クラスターにさらに多くの IP アドレスを提供する方法について説明します。

    制限事項

    • 追加する vSwitch がノードと同じゾーンにあることを確認してください。リスト内の vSwitch がノードのゾーンをカバーしていない場合、Terway はプライマリ Elastic Network Interface (ENI) に関連付けられた vSwitch を使用します。

    • 既存の ENI の vSwitch 構成は変更できません。Pod の vSwitch を更新した後、新しいノードを追加して更新された構成を利用してください。

    Pod の vSwitch の変更が有効になるタイミング

    既存のノード

    Terway は、新しい ENI を作成する場合にのみ、新しい vSwitch 設定を適用します。したがって、次のような場合、既存のノードでは新しい設定はすぐには有効になりません。

    1. ENI が使用中です。Pod がまだその上で実行されている場合、またはそれがトランク ENI である場合、Terway は ENI を削除したり置き換えたりしません。

    2. ENI の上限に達しています。ノードのインスタンスタイプがサポートする ENI の最大数に達しており、これ以上 ENI を作成できません。

    新しいノード

    更新後にクラスターに追加されたノードの場合、Terway は現在の構成 (クラスター、ノード、または Pod レベル) に基づいて vSwitch を選択し、それに応じて ENI を作成します。新しい設定はすぐに有効になります。

    vSwitch 選択戦略と IP リソースの分散

    シングルゾーンに複数の vSwitch が設定されている場合、Terway は異なる vSwitch 選択戦略を使用して、ENI 作成時の vSwitch の割り当てを制御します。構成オプションの詳細については、「Terway 構成パラメーターのカスタマイズ」をご参照ください。

    デフォルト戦略： ordered

    • Terway は、残りの IP 数で vSwitch を降順にソートし、利用可能な IP アドレスが最も多い vSwitch を最初に選択します。この戦略は、ほとんどのシナリオでうまく機能します。

    • エッジケース： Pod 作成のバースト中にバッチで ENI が作成されると、すべての新しい ENI が最も多くの IP アドレスを持つ同じ vSwitch に割り当てられる可能性があります。これにより、IP の分散が不均一になり、その vSwitch の IP プールが枯渇する可能性があります。

    ソリューション

    複数の vSwitch 間で IP の消費を分散させるには、次のいずれかの方法を使用します。

    ソリューション 1： random 戦略への切り替え

    • vSwitch の選択戦略を random に変更します。

    • Terway は、各 ENI を作成するために、利用可能なリストからランダムに vSwitch を選択します。これにより、IP アドレスの使用率が均等に分散されます。

    ソリューション 2： ノードプールごとの vSwitch の割り当て

    • ノードを個別のノードプールにグループ化するために、ノードレベルのネットワーク構成を使用できます。

    • 各ゾーンについて、各ノードプールに一意の Pod vSwitch をバインドします。

    vSwitch の IP リソース不足の兆候

    Terway ネットワークモードでは、vSwitch の IP リソースが不足すると、次の兆候が現れます。

    • Pod の起動に失敗し、ContainerCreating 状態のままである場合、次のコマンドを実行して、Pod がスケジュールされているノードの Terway ログを確認できます。

      kubectl logs --tail=100 -f terway-eniip-***** -n kube-system -c terway

      出力に以下のようなエラーが含まれている場合、そのノードで Terway が使用している vSwitch に利用可能な IP アドレスがありません。その結果、IP リソースの不足により、Pod は ContainerCreating 状態のままになります。

      time="20**-03-17T07:03:40Z" level=warning msg="Assign private ip address failed: Aliyun API Error: RequestId: 2095E971-E473-4BA0-853F-0C41CF52651D Status Code: 403 Code: InvalidVSwitchId.IpNotEnough Message: The specified VSwitch \"vsw-***\" has not enough IpAddress., retrying"

    • Virtual Private Cloud (VPC) コンソールにログインします。左側のナビゲーションウィンドウで、vSwitch をクリックし、vSwitch の 利用可能な IP アドレス を確認します。数が 0 の場合、利用可能な IP アドレスはありません。

    Pod の vSwitch の変更

    コンソールを介して vSwitch を追加する方が、kubectl を使用するよりも簡単です。Terway アドオンを最新バージョンにアップグレードしてから、コンソールで Pod の vSwitch を構成することを推奨します。

    • Terway v1.4.4 以降では、コンソールと kubectl の両方の方法で Pod の vSwitch を構成できます。

    • v1.4.4 より前の Terway バージョンでは、kubectl メソッドのみがサポートされています。

    コンソールメソッド

    1. VPC コンソール で新しい vSwitch を作成できます。新しい vSwitch は、IP アドレスが不足している vSwitch と同じリージョンにある必要があります。手順については、「vSwitch の作成と管理」をご参照ください。

      説明

      Pod の密度は増加し続けています。増大する IP アドレスの需要に対応するため、/19 以下のサブネットマスクで Pod 用の vSwitch を作成してください。これにより、CIDR ブロックごとに少なくとも 8,192 個の IP アドレスが確保されます。

    2. ACK コンソール にログインします。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。

    3. クラスターリスト ページで、クラスターの名前をクリックします。左側のナビゲーションウィンドウで、アドオン管理 をクリックします。

    4. アドオン管理 ページで、ネットワーク タブをクリックします。アップグレードしたい Terway アドオンを選択し、アップグレード をクリックします。アップグレードが完了したら、設定 をクリックします。

      アップグレード ボタンが表示されない場合、Terway アドオンはすでに最新バージョンです。

      説明

      他の方法でデプロイされたアドオンに加えられた変更は、アドオンが再デプロイされる際に上書きされます。

      配置

    5. terway-eniip の パラメーター ページで、PodVswitchId セクションで目的の vSwitch を選択します。他のすべてのパラメーターはデフォルト値のままにします。

    6. パラメーターの設定が完了したら、OK をクリックします。

    kubectl での操作

    1. VPC コンソール で新しい vSwitch を作成できます。新しい vSwitch は、IP アドレスが不足している vSwitch と同じリージョンにある必要があります。手順については、「vSwitch の作成と管理」をご参照ください。

      説明

      Pod の密度は増加し続けています。増大する IP アドレスの需要に対応するため、/19 以下のサブネットマスクで Pod 用の vSwitch を作成してください。これにより、CIDR ブロックごとに少なくとも 8,192 個の IP アドレスが確保されます。

    2. 次のコマンドを実行して、Terway の ConfigMap 構成に vSwitch を追加します。

      kubectl edit cm eni-config -n kube-system

      次の例のように、新しい vSwitch を追加します。

      eni_conf: |
  {
    "version": "1",
    "max_pool_size": 25,
    "min_pool_size": 10,
    "vswitches": {"cn-shanghai-f":["vsw-AAA", "vsw-BBB"]},
    "service_cidr": "172.21.0.0/20",
    "security_group": "sg-CCC"
  }

      この例では、vsw-BBB が vswitches セクションに追加されています。vsw-AAA は、IP リソースが不足している既存の vSwitch です。

    3. 次のコマンドを実行して、すべての Terway Pod を削除できます。システムは自動的にそれらを再作成します。

      • ENI マルチ IP シナリオの場合、次のコマンドを実行してすべての Terway Pod を削除できます。

        kubectl delete -n kube-system pod -l app=terway-eniip

      • ENI シングル IP シナリオの場合、次のコマンドを実行してすべての Terway Pod を削除できます。

        kubectl delete -n kube-system pod -l app=terway-eni

    4. 次のコマンドを実行して、すべての Terway Pod が実行中であることを確認できます。

      kubectl get pod -n kube-system  | grep terway

    5. Pod を作成し、新しく追加された vSwitch から IP アドレスが割り当てられることを確認できます。

      説明

      vSwitch 構成を変更した後、新しい設定は新しく作成された ENI にのみ適用されます。既存の ENI は元の構成を引き続き使用します。すべてのノードに新しい設定を適用するには、ノードのローリングリスタートを実行してください。

    よくある質問

    Terway モードで vSwitch を追加した後、Pod がインターネットにアクセスできないのはなぜですか？

    問題： Pod の IP リソースが不足していたため、手動で vSwitch を追加しました。vSwitch を追加した後、クラスターはインターネットにアクセスできなくなりました。

    原因： Pod の IP アドレスに割り当てられた vSwitch がパブリックネットワークアクセスをサポートしていません。

    解決策: NAT Gateway の SNAT 機能を使用して、vSwitch 用にパブリック SNAT ルールを設定できます。 詳細については、「クラスターのインターネットアクセスを有効にする」をご参照ください。

    Pod に割り当てられた IP アドレスが、構成された vSwitch の CIDR ブロックの範囲外です。どうすればよいですか？

    問題： Terway モードで、Pod に割り当てられた IP アドレスが、構成された vSwitch の CIDR ブロックの範囲外になります。

    原因： Pod の IP アドレスは VPC のアドレス空間から取得され、ENI を介して割り当てられます。vSwitch は、新しい ENI を作成するときにのみ指定できます。ENI が存在すると、その上の後続のすべての Pod は、関連付けられた vSwitch から IP アドレスを受け取ります。この問題は、一般的に次の 2 つのシナリオで発生します。

    • クラスターにノードを追加しましたが、そのノードは以前に別のクラスターで使用されていました。前のクラスターからノードを削除したときに、Pod をドレインしませんでした。その結果、前のクラスターからの残りの ENI がノードに残っています。

    • Terway の vSwitch 構成を手動で追加または変更しました。既存の ENI はまだ古い構成を使用しているため、新しい Pod は引き続きそれらの ENI から IP アドレスを受け取る可能性があります。

    ソリューション： 新しいノードを追加するか、既存のノードのローリングリスタートを実行して、新しい構成が新しいノードで有効になるようにすることができます。

    複数の vSwitch を構成した後、vSwitch 間で IP の消費が不均衡になるのはなぜですか？

    問題： Terway モードで、同じゾーンに複数の Pod vSwitch が構成されている場合、IP アドレスの消費が非常に不均衡になります。一部の vSwitch は IP アドレスを使い果たし、他の vSwitch には未使用の IP アドレスが多数あります。

    原因： Terway は ENI を作成するときにのみ vSwitch を選択します。一度作成されると、ENI はその vSwitch にバインドされたままになります。その ENI 上の将来のすべての Pod IP アドレスは、同じ vSwitch から取得されます。

    デフォルトでは、Terway は ordered 戦略を使用します。これは、残りの IP アドレスが最も多い vSwitch を選択します。ただし、多数のノードやレプリカを同時にデプロイする場合など、急速なスケーリング中に、複数の ENI 作成リクエストがほぼ同時に選択ロジックを実行する可能性があります。残りの IP 数はまだ大幅に変化していないため、すべてのリクエストが同じ vSwitch を選択し、不均衡を引き起こす可能性があります。

    ソリューション： シナリオに基づいて戦略を選択できます。

    1. IP アドレスの使用が不均衡で、vSwitch が枯渇に近い既存のノードプールの場合：

      • 既存のノードの一部を手動でロール (ローリングリスタート) して、ENI を解放します。

      • ENI を解放すると、その IP アドレスが vSwitch に返され、使用量のバランスをとるのに役立ちます。

    2. 新しいノードまたは新しいデプロイメントの場合：

      Terway vSwitch 選択ポリシー vswitch_selection_policy を ordered から random に変更します。これにより、Terway は各 ENI の作成時に vSwitch をランダムに選択するようになり、ホットスポットの発生を防ぐのに役立ちます。詳細については、「Terway 構成パラメーターのカスタマイズ」をご参照ください。

    3. 決定論性と隔離の実現
      ネットワークリソース割り当てを厳密に制御する必要がある場合、各ノードプールに対して個別にノードレベルのネットワーク構成を設定することで、各ゾーン内で 1 つの Pod vSwitch のみが関連付けられるようにできます。これにより、vSwitch とノードプールの間に 1 対 1 のマッピングが作成され、IP アドレス割り当ての競合を完全に回避します。