Container Service for Kubernetes:コンテナネットワークに関する FAQ

目次

Terway の共有 ENI モードと排他 ENI モードの違いは何ですか？

Terway には、Pod 向けの ENI 割り当てモードが 2 つあります。

• 共有 ENI モード：各ノードで複数の Pod が ENI を共有します。デフォルトであり、最もリソース効率が高いモードです。ネットワーク高速化 (DataPathv2 または IPvlan+eBPF) に必要です。

• 排他 ENI モード：各 Pod に専用の ENI が割り当てられます。最高のパフォーマンスと分離性を提供しますが、ENI リソースを大幅に消費します。

詳細については、Terway ネットワークプラグインの使用をご参照ください。

ACK クラスターが Terway の共有 ENI モードと排他 ENI モードのどちらを使用しているかを確認する方法はありますか？

Terway の共有 ENI モードが、ネットワーク高速化のために DataPathv2 とレガシーの IPvlan+eBPF のどちらを使用しているかを確認する方法はありますか？

共有 ENI モードのみがネットワーク高速化 (DataPathv2 または IPvlan+eBPF) をサポートします。DataPathv2 は Terway v1.8.0 以降で IPvlan+eBPF を置き換えました。新しいクラスターは DataPathv2 のみを使用します。

kube-system 名前空間の eni-config ConfigMap で、eniip_virtual_type の値を確認します。

1. 次のコマンドを実行して、eni-config ConfigMap のデータを取得します：

   kubectl get cm eni-config -n kube-system -o yaml

2. 出力で、eniip_virtual_type フィールドの値を確認します：

   • datapathv2: お使いのクラスターは、現在の DataPathv2 アクセラレーションを使用しています。

   • ipvlan: お使いのクラスターではレガシの IPvlan+eBPF アクセラレーションを使用しています。

   • フィールドが存在しない場合、ネットワーク高速化は無効になっています。

Terway のネットワーク高速化モード (DataPathv2 または IPvlan+eBPF) を使用する場合、トラフィックは IPVS をバイパスしますか？

はい、クラスター内の Pod からサービスへのトラフィックに対して、Terway の高速化モードは IPVS をバイパスします。

加速が有効な場合、Terway は eBPF を使用してサービスアドレスをバックエンド Pod の IP にカーネル内で直接変換し、kube-proxy IPVS とノードのネットワークスタックをバイパスして、レイテンシーの短縮とスループットの向上を実現します。

詳細については、「Terway ネットワークプラグイン」をご参照ください。

既存の ACK クラスターで CNI ネットワークプラグインを切り替えることは可能ですか？

いいえ、既存の Container Service for Kubernetes (ACK) クラスターで CNI ネットワークプラグイン (例：Flannel から Terway へ) を変更することはできません。

プラグインはクラスター作成時に設定されます。切り替えるには、新しいクラスターを作成し、ワークロードを移行する必要があります。

詳細については、「ACK マネージドクラスターの作成」をご参照ください。

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

新しい vSwitch にはインターネットへのルートがない可能性が高く、そのためその IP を使用する Pod はアウトバウンド接続を確立できません。

解決策

NAT Gateway を使用して、新しい vSwitch の CIDR ブロックに対して SNAT ルールを設定し、Pod にインターネットアクセスを許可します。

詳細については、「クラスターのインターネットアクセスを有効にする」をご参照ください。

クラスターを Kubernetes 1.16 以降にアップグレードした後、ノードが NotReady になりました。 Flannel の非互換性を修正するにはどうすればよいですか？

この問題は、Flannel イメージを手動で更新したものの、その CNI 設定を新しい Kubernetes バージョンと互換性があるように更新しなかったために発生します。

原因

Kubernetes 1.16 以降では、CNI 設定に cniVersion が必要です。古い Flannel の設定にはこのフィールドが欠落しているため、ノードが NotReady になります。

解決策

Flannel ConfigMap に cniVersion フィールドを追加します。

手順

1. ConfigMap kube-flannel-cfg を編集します：

   kubectl edit cm kube-flannel-cfg -n kube-system 

   net-conf.json データでは、構成オブジェクトに "cniVersion": "0.3.1" を追加します。

   "name": "cb0",   
   "cniVersion":"0.3.1",
   "type": "flannel",

2. Flannel の Pod を再起動します：

   kubectl delete pod -n kube-system -l app=flannel

   ノードが Ready 状態に遷移します。

Pod の起動直後に発生するネットワーク遅延の問題を修正するにはどうすればよいですか？

症状

新しく起動した Pod がネットワーク上で通信できるようになるまでに、数秒の顕著な遅延が発生します。

原因

Terway の NetworkPolicy エンジンが、新しい Pod 用の eBPF ルールまたは iptables エントリを計算して適用する際に、この遅延が発生します。

解決策

Network Policy を使用しない場合は、この機能を無効にすることで起動時の遅延をなくすことができます。

1. Terway eni-config ConfigMap を編集します：

   kubectl edit cm -n kube-system eni-config 

   data.eni_conf セクションに、disable_network_policy: "true" フラグを追加します。

   disable_network_policy: "true"

2. 任意：最新バージョンの Terway を使用していない場合は、コンソールでアップグレードしてください。

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

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

   3. アドオン管理 ページで、ネットワーク タブをクリックし、Terway アドオンの [アップグレード] をクリックします。

   4. 表示されるダイアログボックスで、プロンプトに従って設定を完了し、OK をクリックします。

3. Terway の Pod を再起動します：

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

Pod が自身を公開するサービスにアクセスしようとすると接続エラーが発生するのはなぜですか (ヘアピン)？

この問題は「ヘアピン」として知られ、Pod が自身にトラフィックをルーティングするサービスにアクセスしようとするときに発生します。この動作は、ご利用のネットワークプラグインに依存します。

原因

推奨される解決策

• ヘッドレスサービスの使用：ヘッドレスサービスには ClusterIP がなく、kube-proxy をバイパスします。DNS は Pod IP に直接解決されるため、ネットワークループが解消されます。

  詳細については、「ヘッドレスサービス」をご参照ください。

• Terway ネットワークプラグインを使用してクラスターを再作成します。

• Flannel の設定を変更し、Flannel プラグインと Pod を再作成します。

代替の解決策

• Flannel でヘアピンモードを有効にする (非推奨)：ヘアピンを手動で有効にできますが、アップグレードによってこの設定が上書きされる可能性があります。

1. kube-system 名前空間の kube-flannel-cfg ConfigMap を編集します。

kubectl edit cm kube-flannel-cfg -n kube-system

2. CNI 構成の delegate セクションに hairpinMode: true を追加します。

例：

cni-conf.json: |
    {
      "name": "cb0",
      "cniVersion":"0.3.1",
      "type": "flannel",
      "delegate": {
        "isDefaultGateway": true,
        "hairpinMode": true
      }
    }

3. すべての Flannel Pod を再起動し、その後アプリケーション Pod を再作成します。

kubectl delete pod -n kube-system -l app=flannel   

• Terway プラグインの使用：Terway ネットワークプラグインは、デフォルトでヘアピントラフィックを正しく処理します。これが重要な要件である場合は、Terway を使用して新しいクラスターを作成することを検討してください。

ACK Kubernetes クラスターにおける Terway と Flannel ネットワークプラグインの違いは何ですか？

適切なネットワークプラグインの選択は、特定の機能とパフォーマンス要件に依存します。

ACK クラスターのネットワークを計画する正しい方法は何ですか？

IP 枯渇やネットワークの競合を避けるためには、適切なネットワーク計画が不可欠です。クラスターを作成する前に、3 つの主要な CIDR ブロックを決定する必要があります：

1. VPC と vSwitch の CIDR：これは ECS ノードのアドレス空間です。現在および将来のノードに対して十分に大きいことを確認してください。

2. Pod CIDR ブロック：これはクラスター内のすべての Pod のアドレス空間です。

   • VPC CIDR や接続されているオンプレミスネットワークと重複してはなりません。

   • 予想される最大 Pod 数に合わせてブロックのサイズを決定してください。ブロックを小さくしすぎるのはよくある間違いです。

3. Service CIDR ブロック：これは Kubernetes サービス (ClusterIP) に割り当てられる仮想 IP のアドレス空間です。

   • VPC CIDR や Pod CIDR と重複してはなりません。

これらの範囲は事前に計画してください — 作成後に変更することはできません。

詳細については、「ACK マネージドクラスターのネットワーク計画」をご参照ください。

ACK は Pod の hostPort をサポートしていますか？

hostPort のサポートは、CNI ネットワークプラグインによって異なります。

• Flannel は hostPort をサポートしています。

• Terway： hostPort をサポートしません。

hostPort の使用は非推奨です。推奨される代替策:

• NodePort サービス: 各ノードの IP の静的ポートでサービスを公開します。

• LoadBalancer サービス: サービスへのトラフィックをルーティングする外部クラウドロードバランサーをプロビジョニングします。

Terway を使用すると、Pod は独自の IP アドレスによって VPC 内で直接アクセス可能になるため、VPC 内の通信では hostPort が不要になります。

クラスターで使用されているネットワークプラグインと vSwitch を特定するにはどうすればよいですか？

ACK コンソールを確認してください。

1. ネットワークプラグインを見つけるには：

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

• クラスターリスト ページで、クラスターの名前をクリックします。左側のナビゲーションウィンドウで、クラスター情報 をクリックします。

• [基本情報] タブをクリックします。

• [ネットワークプラグイン] フィールドには Flannel または Terway が表示されます。

2. ノード vSwitch を見つけるには：

• [ノード] > [ノードプール]に移動します。

• ノードプールの [詳細] をクリックします。

• [ノード vSwitch] フィールドに、ノードが配置されている vSwitch が表示されます。

3. Pod vSwitch を見つけるには (Terway のみ)：

• クラスターのページで [アドオン] に移動します。

• [terway-eniip] コンポーネントを見つけ、[設定] をクリックします。

• [PodVswitchId] フィールドには、Pod IP の割り当てに使用される vSwitch が一覧表示されます。(これは Flannel には適用されません)

ACK クラスターで使用されているクラウドリソースを表示するにはどうすればよいですか？

ACK クラスターで kube-proxy の設定を変更する正しい方法は何ですか？

kube-proxyのConfigMapを編集することで、モード (IPVS/iptables) や接続トラッキングなどの動作をカスタマイズできます。

手順

1. ConfigMap の特定：

   • ACK マネージドクラスターの場合、kube-proxy-worker のみを編集する必要があります。

   • ACK 専用 Kubernetes クラスターでは、kube-proxy-worker と kube-proxy-master の両方を編集する必要があります。

2. ConfigMap の編集：

   kube-system 名前空間で ConfigMap を見つけ、その YAML を編集します。構成は、標準の Kubernetes KubeProxyConfiguration API に従います。詳細については、「kube-proxy 構成」をご参照ください。

3. 変更の適用：

   保存後、kube-proxy Pod を再起動します。DaemonSet コントローラーが、更新された構成で Pod を自動的に再作成します。

ノードの Linux コネクショントラッキング (conntrack) の上限を引き上げるにはどうすればよいですか？

# kube-proxy config.conf のスニペット
conntrack:
  maxPerCore: 65536

kube-proxy の IPVS 負荷分散アルゴリズムを変更するにはどうすればよいですか？

DNS の遅延を修正するために、kube-proxy の IPVS モードで UDP セッションのタイムアウトを短縮するにはどうすればよいですか？

UDP バックエンド (CoreDNS など) が削除されると、IPVS モードの kube-proxy は、最大 300 秒間 (デフォルトのタイムアウト) トラフィックをブラックホール化し、ロールアウトや再起動中に DNS 遅延を引き起こすことがあります。

解決策

kube-proxy の構成で UDP タイムアウトを引き下げます。

Kubernetes v1.18 以降の場合：

1. kube-system 名前空間で、kube-proxy-worker (および専用クラスターの場合は kube-proxy-master) の ConfigMap を編集します。

2. ipvs.udpTimeout フィールドを追加または変更します。影響を最小限に抑えるための妥当な選択肢は、10s という値です。

3. kube-proxy Pod を再起動し、変更を適用します。

Kubernetes v1.16 以前の場合：

これらのバージョンは udpTimeout をサポートしていません。ipvsadm を使用して各ノードで設定を変更します。OOS (CloudOps Orchestration Service) を使用してコマンドをバッチで実行します。

# このコマンドは、TCP、TCP-FIN、および UDP のタイムアウトをそれぞれ設定します。
# 3 番目のパラメーター '10' は、UDP タイムアウトを 10 秒に設定します。
ipvsadm --set 900 120 10

IPv6 デュアルスタッククラスターの一般的な問題をトラブルシューティングするにはどうすればよいですか？

• 問題：kubectl get pod では、IPv4 アドレスのみが表示されます。

  • 解決策: Pod は複数の IP アドレスを持つことができます。JSONPath を使用すると、それらすべてを表示できます。podIPs リストに IPv6 アドレスが存在するはずです。

• 問題：kubectl get svc では IPv4 の CLUSTER-IP しか表示されません。

  • 解決策: サービス の ipFamilyPolicy が PreferDualStack または RequireDualStack に設定されていることを確認し、JSONPath を使用してすべてのクラスター IP を表示します:

• 問題：Pod に IPv6 アドレスでアクセスできません。

  • 原因: コンテナ内のアプリケーションが、IPv6 any-address (::) でリッスンしていない可能性があります。たとえば、一部の Web サーバーはデフォルトで 0.0.0.0 (IPv4 のみ) をリッスンします。

  • 解決策: ポッドに exec して netstat -anp を実行し、「Local Address」 列を確認します。tcp6 または udp6 のエントリが ::: でリッスンしている場合、IPv6 で正しくリッスンしていることを示します。そうでない場合は、アプリケーションを再設定する必要があります。

• 問題：Pod はクラスター内で IPv6 を介してアクセスできますが、インターネットからはアクセスできません。

  • 原因：Pod の IPv6 アドレスにパブリック帯域幅が設定されていません。

  • 解決策：Alibaba Cloud コンソールで、IPv6 ゲートウェイを介して IPv6 アドレスのパブリック帯域幅を有効にします。

• 問題：Pod は IPv6 経由でインターネットにアクセスできません。

  • 解決策：アウトバウンドの IPv6 インターネットアクセスを有効にするには、VPC に IPv6 ゲートウェイが設定されており、Pod にパブリック帯域幅が有効になっている IPv6 アドレスがあることを確認する必要があります。

ポッドが ContainerCreating 状態のままで "InvalidVSwitchId.IpNotEnough" エラーが発生します。IP アドレスを追加するにはどうすればよいですか？

Pod の IP に使用される vSwitch のアドレスが枯渇しています。新しい vSwitch を追加して IP プールを拡張してください。

手順

1. 新しい vSwitch の作成: VPC コンソールで、同じリージョンおよび AZ に、大きい CIDR ブロック (たとえば、/19 以下) を使用して vSwitch を作成します。

2. Terway 設定の更新: ACK コンソールで、[アドオン] > [terway-eniip] > [設定] に移動します。新しく作成した vSwitch の ID を PodVswitchId フィールドに追加します。

3. Terway Pod の再起動：Terway DaemonSet の Pod を再起動します。

4. 確認：新しい Pod が起動し、新しい vSwitch から IP を取得するはずです。

Terway の設定を更新した後も、Pod が古い vSwitch の CIDR ブロックから IP を取得するのはなぜですか？

ノード上の既存の ENI は古い vSwitch に関連付けられたままです。Terway は、新しい ENI を作成するときにのみ新しい vSwitch 設定を適用します。

原因

ノードにすでに ENI がある場合、新しい Pod はその ENI の IP プールを使い続け、更新された vSwitch 設定を無視します。これは、別のクラスターからノードを再利用した場合や、ノードをリサイクルせずに Terway の設定を変更した場合に発生します。

解決策

影響を受けるノードをローテーションして、新しい設定を強制的に適用します。

ノードをローテーションする手順

1. ドレインと削除：ワークロードを安全にドレインし、クラスターからノードを削除します。

2. ENI のデタッチ：ECS コンソールで、削除されたインスタンスから残っている ENI を手動でデタッチします。

3. ノードの再追加：インスタンスをクラスターに再度追加します。これで、インスタンスはまっさらな状態から開始され、現在の Terway 設定に基づいて新しい ENI が作成されます。

Terway の設定に新しい vSwitch を追加しましたが、Pod が IP を取得できません。なぜですか？

この問題は通常、ノードがその Elastic Compute Service (ECS) インスタンスタイプで許可されている最大 ENI アタッチクォータに達した場合に発生します。

原因

新しい vSwitch は設定されていますが、ノードがハードウェアの ENI アタッチメント制限に達しているため、Terway は新しい ENI を作成できません。既存の ENI は枯渇した vSwitch に関連付けられているため、新しい IP を割り当てることはできません。

解決策

影響を受けるノードをローテーションして、既存の ENI アタッチメントをクリアし、更新された設定で新しい ENI をアタッチできるようにします。

ノードをローテーションする手順

1. ドレインと削除：ワークロードを安全にドレインし、クラスターからノードを削除します。

2. ENI のデタッチ：ECS コンソールに移動し、インスタンスからすべての ENI を手動でデタッチします。

3. ノードの再追加：インスタンスをクラスターに再度追加します。これで、更新された vSwitch 設定を使用して新しい ENI をアタッチできるようになります。

既存の Terway IPvlan クラスターで ExternalIP および LoadBalancer サービスのクラスター内負荷分散を有効にするにはどうすればよいですか？

Pod が、トラフィックを内部でルーティングしつつ、外部 IP を介して LoadBalancer または ExternalIP サービスにアクセスできるようにします。新規の Terway IPvlan クラスター (v1.2.0 以降) ではデフォルトで有効になっていますが、既存のクラスターでは手動での有効化が必要です。

前提条件

• Terway v1.2.0 以降。

• クラスターは IPvlan モードで設定されている必要があります。

解決策

eni-config ConfigMap を編集して、この機能を有効にします。

手順

1. kube-system 名前空間の eni-config ConfigMap を編集します：

2. data.eni_conf セクションに、in_cluster_loadbalance: "true" フラグを追加します。

3. Terway の Pod を再起動します：

4. 新しい Terway Pod のログに enable-in-cluster-loadbalance=true があることを検証します。

IP ベースの許可リスト登録のために、Terway クラスター内の Pod を特定の vSwitch/CIDR ブロックに割り当てるにはどうすればよいですか？

ノードプールごとに Terway のデフォルト vSwitch 設定を上書きすることで、IP ベースの許可リスト登録のために Pod が特定の CIDR ブロックを使用するように強制します。

解決策

1. カスタム Terway ConfigMap の作成：

   kube-system 名前空間に、許可リストに登録された Pod 用の専用 vSwitch を指定する新しい ConfigMap (例: eni-config-fixed) を作成します。

   この例では vsw-2zem796p76viir02c**** と 10.2.1.0/24 を使用します。

   apiVersion: v1
   data:
     eni_conf: |
       {
          "vswitches": {"cn-beijing-h":["vsw-2zem796p76viir02c****"]},
          "security_group": "sg-bp19k3sj8dk3dcd7****",
          "security_groups": ["sg-bp1b39sjf3v49c33****","sg-bp1bpdfg35tg****"]
       }
   kind: ConfigMap
   metadata:
     name: eni-config-fixed
     namespace: kube-system
   
                           

2. ノードプールの設定：

   新しいノードプールを作成するか、既存のノードプールを使用します。そのノードに次のラベルを適用します： terway-config: eni-config-fixed

3. ノードセレクターと Toleration を使用した Pod のデプロイ：

   ステップ 2 のラベルと一致する nodeSelector と、Taint に対する toleration を設定して、アプリケーションをデプロイします。

   apiVersion: apps/v1 # 1.8.0 より前のバージョンの場合は、apps/v1beta1 を使用します。
   kind: Deployment
   metadata:
     name: nginx-fixed
     labels:
       app: nginx-fixed
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: nginx-fixed
     template:
       metadata:
         labels:
           app: nginx-fixed
       spec:
         tolerations:        # Toleration を追加します。
         - key: "fixed"
           operator: "Equal"
           value: "true"
           effect: "NoSchedule"
         nodeSelector:
           terway-config: eni-config-fixed
         containers:
         - name: nginx
           image: nginx:1.9.0 # 実際のイメージに置き換えてください <image_name:tags>。
           ports:
           - containerPort: 80

   検証

   このノードプールの Pod は、vsw-2zem796p76viir02c**** vSwitch からのみ IP を取得します。この vSwitch の CIDR ブロックを外部サービスの許可リストに追加してください。

Flannel クラスターで、Pod が一部の ECS インスタンスには ping できるのに、他のインスタンスにはできないのはなぜですか？

VPC ルートが Flannel オーバーレイネットワークに対して正しく設定されていると仮定すると、この問題はほぼ常にセキュリティグループルールが原因です。

• 原因 1：ECS インスタンスが同じ VPC 内にあるが、異なるセキュリティグループに属している。

  • 解決策：ターゲットの ECS インスタンスのセキュリティグループに、クラスターのノードのソース IP 範囲からのトラフィックを許可するインバウンドルールを追加します。より堅牢な解決策として、クラスターの Pod CIDR ブロックからのトラフィックを許可します。

• 原因 2：ECS インスタンスが異なる VPC に属している。

  • 解決策：Pod は ECS インスタンスにパブリック IP アドレス経由でアクセスする必要があります。ECS インスタンスのセキュリティグループに、クラスターのパブリック出力 IP アドレス (例：NAT Gateway の IP) からのトラフィックを許可するインバウンドルールを追加する必要があります。

Flannel クラスターで新しく追加されたノードに NodeNetworkUnavailable Taint が付与されるのはなぜですか？

この Taint は、ノードのネットワークが準備できていないことを意味します。cloud-controller-manager (CCM) は VPC ルートを設定してこの Taint を削除します。この Taint が永続化する場合、CCM の障害を示します。

一般的な原因

1. VPC ルートテーブルがいっぱいである：VPC ルートテーブルがクォータに達し、CCM が新しいノードの Pod CIDR ブロックの新しいルートを追加できません。

2. VPC に複数のルートテーブルが存在する：VPC が複数のルートテーブルを使用していますが、CCM がそれらを管理するように設定されていません。デフォルトでは、VPC のメインルートテーブルとのみ対話します。

解決策

1. ノードのイベントを調べて、CCM からのエラーメッセージを確認します：

2. ルートテーブルがいっぱいの場合、未使用のルートを削除してスペースを確保する必要があります。

3. 複数のルートテーブルを使用している場合は、関連するすべてのルートテーブル ID で CCM を設定します。詳細については、「VPC で複数のルートテーブルを使用する」をご参照ください。

エラー failed to allocate for range 0: no IP addresses available in range set が表示されて Pod の起動に失敗するのはなぜですか？

ノードが Pod の IP サブネットを使い果たしました。これは通常、IP リーク (Pod 削除後に IP が解放されないこと) が原因です。

IP リークの一般的な原因

• 古い Kubernetes バージョン (< 1.20)：Pod の急速な再起動や短命な CronJob は、競合状態により IP リークを引き起こす可能性があります。

• 古い Flannel のバージョン：IP 割り当てをディスク (/var/lib/cni/networks/) に保存するバージョンでは、予期しないシャットダウンの後に IP アドレスが割り当て済みとしてマークされたままになる場合があります。

長期的な解決策 (推奨)

1. クラスターのアップグレード：ACK クラスターを Kubernetes 1.20 以降のバージョンにアップグレードします。

2. Flannel のアップグレードと tmpfs の構成: Flannel をアップグレードし、kube-flannel-cfg ConfigMap を編集して IPAM データディレクトリを /var/run/cni/networks (再起動時にクリアされます) に設定します。構成後、ノードを再起動します。

一時的な回避策 (すぐにアップグレードできない場合)：

1. 影響を受けるノードをドレインします。

2. ノードにログインし、/var/lib/cni/networks/cb0/ 内の IP ファイルを実行中のコンテナ (docker ps または crictl pods) と比較して、存在しないコンテナのエントリを削除するクリーンアップスクリプトを実行します。

3. ノードの cordon を解除します。

既存の ACK クラスターの Pod CIDR、Service CIDR、またはノードあたりの IP 数を変更するにはどうすればよいですか？

ACK クラスターが作成された後、これらの基本的なネットワークパラメーターを変更することはできません。

Pod CIDR、Service CIDR、およびノードごとのサブネットサイズは、クラスター作成時に固定されます。これらを変更するには、正しいネットワークプランで新しいクラスターを作成する必要があります。

Flannel クラスターで複数のルートテーブルに対して cloud-controller-manager (CCM) を設定する必要があるのはどのような場合ですか？

Flannel クラスターで複数のルートテーブルを管理するために CCM を設定する必要があるのは、次のシナリオです：

• シナリオ 1：カスタムルートテーブルの使用

  クラスターノードがカスタムルートテーブル (メインではない) に関連付けられたサブネットに存在する場合、CCM はそのカスタムルートテーブルの ID で明示的に設定されない限り、Pod CIDR のルートを追加できません。

• シナリオ 2: CCM ログに表示される multiple route tables found エラー

  このエラーメッセージは、CCM が VPC 内に複数のルートテーブルを検出し、Pod ネットワークルートの管理にどれを使用すればよいかわからないことを明示的に示しています。

• シナリオ 3: 永続的に発生する NodeNetworkUnavailable 新しいノード上の Taint

  新しいノードが一貫してこの taint でスタックする場合、これは CCM がそのルートを設定できないことの強力な指標であり、多くの場合、未設定のカスタムルートテーブルが原因です。

ACK クラスターにサードパーティの CNI ネットワークプラグインをインストールすることは可能ですか？

いいえ、ACK クラスターはサードパーティのネットワークプラグインのインストールや設定をサポートしていません。

ACK は、VPC ルーティングと ENI 管理のために Terway と Flannel と深く統合されています。別の CNI プラグイン (Calico や Cilium など) をインストールすると、マネージドシステムと競合し、ネットワーク障害を引き起こします。

Flannel クラスターで no IP addresses available in range set エラーが発生するのはなぜですか？

このエラーは、ノードが指定された Pod CIDR サブネットから新しい Pod に割り当てる IP アドレスがなくなったことを意味します。

原因

これはハードリミットです。Flannel クラスターでは、Pod CIDR ブロック全体がより小さなサブネットに分割され、各ノードに 1 つのサブネットが割り当てられます。ノードのサブネットがいっぱいになると、それ以上 Pod を作成することはできません。この問題は、不適切なネットワーク計画から生じます。

解決策

• 短期的な対策：影響を受けるノード上の未使用の Pod を削除して IP を解放します。また、クラスターに新しいノードを追加することもでき、これにより新しい IP サブネットが割り当てられます。

• 長期的な対策：唯一の恒久的な修正は、より大きなPod CIDR ブロックでクラスターを再作成することです。予想されるノード数とノードあたりの Pod 数に対して十分な IP アドレスを割り当てるように、ネットワークを慎重に計画してください。

Terway クラスターにおけるノードあたりの最大 Pod 数は何によって決まりますか？

Terway クラスターにおけるノードあたりの最大 Pod 数は、基盤となる ECS インスタンスタイプの IP 容量によって決まります。

Terway は、ノードにアタッチされた ENI から IP を割り当てます。各 ECS インスタンスタイプには、以下の特定の制限があります：

1. アタッチできる ENI の最大数。

2. ENI あたりのプライベート IP アドレスの最大数。

利用可能な IP (したがって ポッド) の合計数は、(Number of ENIs) × (IPs per ENI) として計算されます。これらの上限値は、ご使用のインスタンスタイプに対応する Alibaba Cloud ECS ドキュメントで確認できます。

Terway の DataPath V2 モードとは何ですか？また、元の IPvlan モードとどう違いますか？

• DataPath V2 は、Terway のネットワーク高速化機能の次世代データプレーンであり、元の IPvlan+eBPF モードの拡張として機能します。

  キーポイント

  • 新しいクラスターのデフォルト：IPvlan 高速化が有効になっている Terway v1.8.0 以降で作成されたクラスターでは、DataPath V2 がデフォルトで使用されます。

  • 後方互換性：すでにレガシーの IPvlan モードを使用していた既存のクラスターは、Terway コンポーネントをアップグレードした後も引き続きそれを使用します。中断を防ぐため、データプレーンは自動的に移行されません。

  • メリット：DataPath V2 は、元の実装よりも改善された互換性とパフォーマンスを提供します。

Terway ネットワークにおいて、Pending や ContainerCreating などのポッドステータスは何を意味しますか？

Pod ステータスは、Terway 環境におけるネットワーク初期化の進捗を反映します。

• Pending：スケジューラはまだポッドをノードに割り当てていません。これは通常、リソース制約 (CPU、メモリ) またはスケジューリングルール (Taint、アフィニティ) が原因です。この段階では Terway はまだ関与していません。

• ContainerCreating: Pod がスケジュールされ、CNI プラグインがネットワークのセットアップ (ENI のアタッチ、IP の割り当て) を行っています。ここでの遅延は、多くの場合、vSwitch での IP の枯渇などのネットワークリソースの問題を示しています。

• Running: Pod 内のすべてのコンテナが作成され、Terway によってそのネットワークが正常に設定されています。これで Pod は運用可能で、到達可能な状態になっているはずです。

kubectl describe pod <pod-name> で詳細を確認します。

Terway コンポーネントのアップグレードが eip pool is not supported というエラーで失敗するのはなぜですか？

このエラーは、Elastic IP (EIP) プール機能が非推奨となり、Terway コンポーネントの最近のバージョンから削除されたために発生します。

解決策

アップグレードする前に、EIP の管理を Terway から、現在 Pod EIP の割り当てを担当する ack-extend-network-controller コンポーネントに移行してください。

Terway クラスターで can't found dev by mac というエラーが表示され、Pod の作成に失敗することがあるのはなぜですか？

エラー failed to do add; error parse config, can't found dev by mac... は、Terway がノード上で想定される MAC アドレスに一致する ENI を見つけられなかったことを意味します。

一般的な原因は 2 つあります：

1. 非同期の ENI アタッチ (一時的な問題)：

   • 説明：新しくアタッチされた ENI が OS で初期化されるまでには少し時間がかかります。このウィンドウ中に CNI プラグインがネットワークを設定しようとすると、デバイスを見つけられずに失敗します。

   • 解決策: これは一時的なタイミングの問題です。CNI プラグインは自動的に再試行します。Pod が Running 状態に達した場合は、これらのログエラーを無視してください。

2. ノードドライバーの障害 (永続的な問題)：

   • 説明：エラーが続く場合、高位メモリの不足により、ノードのドライバーが ENI の初期化に失敗した可能性があります。

   • 解決策：影響を受ける ECS インスタンスを再起動することで、通常このドライバーレベルの障害は解決します。

ACK クラスターにカスタムのクラスタードメインを設定する際に考慮すべきことは何ですか？

クラスタードメイン (デフォルト: cluster.local) は、すべてのクラスター内サービスの DNS サフィックスです。クラスター作成時にこれをカスタマイズする場合、DNS 名前解決の競合を避けるために、これらのルールに従う必要があります。

• 変更不可：クラスタードメインはクラスター作成時にのみ設定でき、後で変更することはできません。

• 一意であること：クラスタードメインは、使用する外部のパブリックドメインやプライベート DNS ゾーン (例：Alibaba Cloud DNS PrivateZone) と重複してはなりません。

なぜこれが重要なのか？

CoreDNS はすべてのクラスタードメインのクエリを内部で処理し、上流には転送しません (セキュリティとパフォーマンスのため)。

クラスタードメインが mycompany.com で、www.mycompany.com にパブリックサイトがある場合、CoreDNS は mycompany.com を内部専用ゾーンとして扱い、クエリの転送を拒否するため、Pod は www.mycompany.com を解決できません。