Container Service for Kubernetes:サービスのよくある質問

ACK クラスターがデフォルトで作成する CLB インスタンス

クラスターの作成時に Nginx Ingress Controller アドオンがインストールされている場合、クラスターは 2 つの CLB インスタンスを作成します。

• API サーバー CLB：API サーバーのエンドポイントです。すべてのクラスターリクエストは、TCP ポート 6443 でこのインスタンスを経由します。バックエンドは API サーバー Pod またはマスター ECS インスタンスです。

• Nginx Ingress Controller CLB：kube-system の nginx-ingress-controller Service に関連付けられています。外部リクエストの負荷分散のために、Ingress Controller Pod に動的にバインドされます。TCP ポート 80 と 443 をリッスンします。

外部トラフィックポリシー (Local モードと Cluster モード) の選択

Local モードと Cluster モードの外部トラフィックポリシーは、ネットワークプラグインによって異なります。詳細については、「外部トラフィックポリシー：Local と Cluster」をご参照ください。

CLB 設定が変更される理由

CCM は宣言型 API を使用し、Service 定義に基づいて CLB 設定を自動的に更新します。CLB コンソールで直接行った変更は上書きされる可能性があります。

Local モードにおけるノードの重みの計算方法

次の例では、3 つの ECS インスタンスにデプロイされたアプリケーション Pod (app=nginx) を Service を通じて公開します。

v1.9.3.276-g372aa98-aliyun 以降

CCM は、ノードの重みをそのノード上の Pod 数と等しく設定します。たとえば、3 つの ECS インスタンスがそれぞれ 1、2、3 個の Pod をホストしている場合、それらの重みは 1、2、3 になります。トラフィックは 1:2:3 の比率で分散され、Pod 全体で負荷が均等になります。

計算式：

v1.9.3.164-g2105d2e-aliyun から v1.9.3.276-g372aa98-aliyun の間

CCM は Pod 数に基づいて重みを計算します。同じ 3 つの ECS インスタンスの場合、計算された重みは 16、33、50 となり、おおよそ 1:2:3 のトラフィック比率になります。

計算式：

v1.9.3.164-g2105d2e-aliyun より前

すべてのバックエンドサーバーの重みは 100 であり、Pod 数に関係なく、ECS インスタンス全体にトラフィックが均等に分散されます。これにより、Pod 全体で負荷が不均衡になります。Pod 数が少ないノードは、Pod あたりのトラフィックが不釣り合いに多くなります。

LoadBalancer Service でコネクションドレイニングを有効にする方法

Service に次のアノテーションを追加します。バックエンドサーバーが削除された後、CLB インスタンスはドレインタイムアウト期間中、既存の接続の処理を継続します。

• service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain

• service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain-timeout

詳細については、「リスナーのコネクションドレイニングの有効化」をご参照ください。

クラスター内のすべての CLB インスタンスを一覧表示する方法

1. kubectl を使用してクラスターに接続します。

2. すべての LoadBalancer Service の名前、namespace、IP アドレス、アドレスタイプを取得します。出力例：

      kubectl get services -A -ojson | jq '.items[] | select(.spec.type == "LoadBalancer") | {name: .metadata.name, namespace: .metadata.namespace, ip: .status.loadBalancer.ingress[0].ip, lb_type: .metadata.annotations."service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type"}'

      {
        "name": "test",
        "namespace": "default",
        "ip": "192.168.*.*",
        "lb_type": "intranet"
      }
      {
        "name": "nginx-ingress-lb",
        "namespace": "kube-system",
        "ip": "47.97.*.*",
        "lb_type": "null"
      }

古い CCM バージョンで CLB の名前変更を有効にする方法

CCM v1.9.3.10 以降では、CLB インスタンスに自動的にタグが付けられ、名前変更がサポートされます。それ以前の CCM バージョンで作成された CLB インスタンスの場合は、手動でタグを追加してください。

この手順は、CCM v1.9.3.10 以前で作成された CLB インスタンスにのみ適用されます。Service タイプは LoadBalancer である必要があります。

1. クラスターのマスターノードに接続します。詳細については、「kubectl を使用した ACK クラスターへの接続」をご参照ください。

2. Service タイプと IP アドレスを確認します。${namespace} と ${service} を実際の namespace と Service 名に置き換えてください。

      kubectl get svc -n ${namespace} ${service}

   # kubectl get svc -n ${namespace} ${service}
   nginx-local   LoadBalancer   172.19.xxx.xxx   47.111.xxx.xxx   8900:31598/TCP   33d

3. CLB インスタンスのタグを生成します。

      kubectl get svc -n ${namespace} ${service} -o jsonpath="{.metadata.uid}"|awk -F "-" '{print "kubernetes.do.not.delete: "substr("a"$1$2$3$4$5,1,32)}'

   # kubectl get svc -n ${namespace} ${service} -o jsonpath="{.metadata.uid}"|awk -F "-" '{print "ku
   kubernetes.do.not.delete: xxx

4. CLB コンソールにログオンします。手順 2 の IP アドレスを使用して、対応するリージョンで CLB インスタンスを検索します。

5. 手順 3 のキーと値を使用して、CLB インスタンスにタグを追加します。詳細については、「CLB インスタンスの作成と管理」をご参照ください。

クラスター内から CLB の IP アドレスにアクセスできないのはなぜですか？

この問題は、主に 2 つのシナリオで発生します。

シナリオ 1：Service で作成されていないプライベート CLB

Pod が Service で作成されていないプライベート CLB インスタンスにアクセスする際、Pod とバックエンドサーバーが同じノード上にある場合、アクセスは失敗します。これはレイヤー 4 の制限によるものです。ECS インスタンスは、同じ CLB インスタンスに対してバックエンドサーバーとクライアントの両方になることはできません。

この問題を解決するには、次のいずれかの方法を試してください。

• CLB の IP アドレスをパブリック IP アドレスに変更します。

• Service を通じて CLB インスタンスを作成し、externalTrafficPolicy を Cluster に設定します。これにより、kube-proxy がクラスター内からの CLB へのトラフィックをインターセプトし、制限を回避します。

シナリオ 2：externalTrafficPolicy: Local による内部アクセスのブロック

サービスで externalTrafficPolicy: Local を使用すると、バックエンド Pod がないノードから CLB IP への内部アクセスは失敗します。CLB アドレスは外部アクセス用です。内部トラフィックは kube-proxy によってインターセプトされ、ローカルにルーティングされます (iptables または IPVS)。ノードにローカルのバックエンド Pod がない場合、接続は失敗します。

詳細については、「kube-proxy adds external-lb address to local node iptables rules」をご参照ください。

解決策 (推奨順)：

1. ClusterIP またはサービス名で、サービスに内部からアクセスします。たとえば、Ingress サービス名は nginx-ingress-lb.kube-system です。これは推奨される方法です。

2. externalTrafficPolicy を Cluster に変更すると、トラフィックはすべてのノードに転送されますが、SNAT が有効になるため、バックエンドは実際のクライアント IP を取得できません。

      kubectl edit svc nginx-ingress-lb -n kube-system

3. Terway クラスターで Elastic Network Interface (ENI) パススルーを使用します。 externalTrafficPolicy を Cluster に設定し、service.beta.kubernetes.io/backend-type: "eni" アノテーションを追加します。 これにより、内部アクセスを許可しながら送信元 IP が保持されます。 詳細については、「アノテーションを使用して Classic Load Balancer (CLB) インスタンスを設定する」をご参照ください。

      apiVersion: v1
      kind: Service
      metadata:
        annotations:
          service.beta.kubernetes.io/backend-type: eni
        labels:
          app: nginx-ingress-lb
        name: nginx-ingress-lb
        namespace: kube-system
      spec:
        externalTrafficPolicy: Cluster

CLB インスタンスが削除されるタイミング

削除の動作は、CCM が CLB インスタンスを作成したかどうか、および Service への関連付け方法によって異なります。

Service に service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: {your-slb-id} アノテーションが付けられており、既存の CLB インスタンスを再利用する場合、Service を削除しても CLB インスタンスは削除されません。それ以外の場合、Service を削除すると CLB インスタンスも削除されます。

誤って CLB インスタンスを削除した場合の対処法

シナリオ 1：Ingress CLB が削除された場合

以下の手順では、Nginx Ingress を例として使用します。

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

2. [クラスター] ページで、目的のクラスターを見つけてその名前をクリックします。左側のナビゲーションペインで、[ネットワーク] > [サービス] を選択します。

3. [名前空間] ドロップダウンリストから [kube-system] を選択します。

   • リストに [nginx-ingress-lb] が表示されている場合は、[アクション] 列の [YAML の編集] をクリックします。status.loadBalancer フィールドとその内容を削除し、[OK] をクリックします。CCM が CLB インスタンスを再構築します。

   • [nginx-ingress-lb] が表示されない場合は、[YAML から作成] をクリックし、以下のテンプレートを使用します: yaml apiVersion: v1 kind: Service metadata: labels: app: nginx-ingress-lb name: nginx-ingress-lb namespace: kube-system spec: externalTrafficPolicy: Local ports: selector: app: ingress-nginx type: LoadBalancer

     • name: http port: 80 protocol: TCP targetPort: 80

     • name: https port: 443 protocol: TCP targetPort: 443

シナリオ 2：アプリケーション固有の CLB が削除された場合

• Service が不要になった場合は、削除してください。

• Service がまだ必要な場合：

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

  2. [クラスター] ページで、目的のクラスターを見つけ、その名前をクリックします。左側のナビゲーションペインで、[ネットワーク] > [サービス] を選択します。

  3. [名前空間] ドロップダウンリストから [すべての名前空間] をクリックして、対象のサービスを探します。

  4. [アクション] 列で、[YAML の編集] をクリックします。status.loadBalancer の内容を削除し、[OK] をクリックします。CCM が CLB インスタンスを再構築します。

既存の CLB インスタンスの再利用が失敗する原因

次の項目を順に確認してください。

1. CCM バージョン： v1.9.3.105-gfd4e547-aliyun より前のバージョンでは、CLB インスタンスの再利用はサポートされていません。アップグレード手順については、「CCM コンポーネントのアップグレード」をご参照ください。

2. インスタンスのオリジン：クラスターが作成した CLB インスタンスは再利用できません。

3. API サーバー CLB：API サーバーの CLB インスタンスは再利用できません。

4. VPC の不一致：プライベート CLB インスタンスは、クラスターと同じ仮想プライベートクラウド (VPC) 内にある必要があります。クロス VPC の再利用はサポートされていません。

既存の CLB インスタンスを再利用する際にリスナーが作成されない原因

service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners アノテーションが "true" であることを確認してください。このアノテーションがない場合、リスナーは作成されません。

デフォルトでは、CCM は既存の CLB インスタンスのリスナーを上書きしません。

アクティブなリスナーを上書きすると、サービスが中断される可能性があります。

CCM は、限定的なバックエンド設定のみをサポートしています。複雑な設定の場合は、CLB コンソールでリスナーを作成してください。ポートが使用されなくなった場合にのみ、リスナーの強制オーバーライドを実行してください。

CLB インスタンスが保留中状態のままになっている場合はどうすればよいですか？

1. kubectl -n {your-namespace} describe svc {your-svc-name} を実行して、イベントメッセージを確認します。

2. イベントで報告されたエラーを解決します。詳細については、「Service のエラーメッセージと解決策」をご参照ください。

イベントが表示されない場合は、「Service と LoadBalancer の同期でイベントが表示されないのはなぜですか？」をご参照ください。

vServer グループが更新されない場合はどうすればよいですか？

1. kubectl -n {your-namespace} describe svc {your-svc-name} を実行して、イベントメッセージを確認します。

2. イベントで報告されたエラーを解決します。詳細については、「Service のエラーメッセージと解決策」をご参照ください。

イベントが表示されない場合は、「Service と LoadBalancer の同期でイベントが表示されないのはなぜですか？」をご参照ください。

Service アノテーションが有効にならない場合はどうすればよいですか？

1. kubectl -n {your-namespace} describe svc {your-svc-name} を実行して、エラーイベントを確認します。エラーがある場合は、「Service のエラーメッセージと解決策」をご参照ください。

2. エラーが表示されない場合は、次の点を確認してください。

   • CCM バージョン：CCM のバージョンがアノテーションをサポートしていることを確認してください。詳細については、「アノテーションを使用したクラシックロードバランサー (CLB) インスタンスの設定」をご参照ください。

   • アノテーションの存在: ACK コンソールにログインします。 [サービス] ページで Service 名をクリックし、アノテーションが存在することを確認します。 存在しない場合は、追加します。 詳細については、「アノテーションを使用して Classic Load Balancer (CLB) インスタンスを設定する」をご参照ください。

   • アノテーションの構文：アノテーションのキーと値が正しいことを確認してください。

サービスリストを表示するには、「サービスの管理」をご参照ください。

Service と LoadBalancer の同期でイベントが表示されないのはなぜですか？

kubectl -n {your-namespace} describe svc {your-svc-name} でイベントが表示されない場合は、CCM のバージョンを確認してください。

• v1.9.3.276-g372aa98-aliyun より前：イベントはサポートされていません。CCM をアップグレードしてください。アップグレード手順については、「CCM コンポーネントのアップグレード」をご参照ください。

• v1.9.3.276-g372aa98-aliyun 以降：チケットを送信し、さらに調査を依頼してください。

クォータとリソースのエラー

設定エラー

ネットワークエラー

CLB の再利用エラー

課金エラー

NodePort Service へのアクセス方法

• クラスター内から (クラスターノード上)：ClusterIP とポート、またはノード IP と Service の NodePort を使用します。デフォルトの NodePort の範囲は 30000～32767 です。

• クラスター外から (同じ VPC 内)：ノード IP アドレスと Service の NodePort を使用します。

• VPC 外から (別の VPC またはインターネットから)：Service を LoadBalancer タイプとして公開し、その外部エンドポイント経由でアクセスします。

外部トラフィックポリシーが Local の場合、アクセスするノードが Service のバックエンド Pod をホストしていることを確認してください。詳細については、「外部トラフィックポリシー：Local と Cluster」をご参照ください。

NodePort Service リスナーの設定方法

CCM は LoadBalancer Service のリスナー設定のみをサポートしています。Service タイプを NodePort から LoadBalancer に変更してください。

NodePort 範囲の設定方法

API サーバーの--service-node-port-range パラメーター (ServiceNodePortRange) は、NodePort および LoadBalancer Service のポート範囲を制御します。デフォルトの範囲は 30000～32767 です。ACK Pro クラスターでは、コントロールプレーンのパラメーターをカスタマイズしてこの範囲を調整できます。詳細については、「ACK Pro クラスターのコントロールプレーンパラメーターのカスタマイズ」をご参照ください。

次の点に注意してください。

• ポート範囲の競合を回避してください。NodePort 範囲は、net.ipv4.ip_local_port_range カーネルパラメーターと重複しないようにしてください。このパラメーターは、ノード上のアプリケーションが使用できるローカルポート番号を制御します。デフォルトの ip_local_port_range は 32768～60999 です。

• デフォルトの範囲は安全です。デフォルトの ACK 設定では、ServiceNodePortRange (30000-32767) と ip_local_port_range (32768-60999) は重複しません。いずれかの範囲が拡張されて現在重複している場合、散発的なネットワーク例外が発生する可能性があります。深刻な場合、ヘルスチェックが失敗し、ノードがオフラインになります。デフォルト値に戻すか、重複を解消するために両方の範囲を調整してください。

• 変更後に既存の Service を再設定してください。ポート範囲を調整した後、一部の NodePort または LoadBalancer Service は、ip_local_port_range 範囲内のポートを引き続き使用している可能性があります。kubectl edit <service-name> を実行し、spec.ports.nodePort フィールドを未使用の NodePort に変更してください。

CCM アップグレードが失敗した場合の対処法

「Cloud Controller Manager (CCM) のアップグレードチェックが失敗する」をご参照ください。

ACK 専用クラスターで CCM アップグレードに必要な権限の追加方法

新しい CCM バージョンでは、追加の Resource Access Management (RAM) 権限を必要とする Alibaba Cloud API が導入されています。たとえば、v2.11.2 では Flannel ネットワークのルート管理が追加され、v2.12.1 では Network Load Balancer (NLB) のバッチ管理が追加されています。

ACK 専用クラスターで v2.11.2 以降にアップグレードする前に、クラスター RAM ロールに必要な権限を付与してください。

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

2. [クラスター] ページで、目的のクラスターを見つけ、その名前をクリックします。左側のナビゲーションペインで、[クラスター情報] をクリックします。

3. [基本情報] タブをクリックし、次に [マスター RAM ロール] のロール名をクリックします。

4. RAM コンソールで、左側のナビゲーションペインで [権限] > [ポリシー] をクリックします。k8sMasterRolePolicy-Ccm- で始まるカスタムポリシーを見つけ、ポリシー名をクリックします。

   古いクラスターの場合、このポリシーが存在しない可能性があります。代わりに、k8sMasterRolePolicy- で始まるカスタムポリシーを選択してください。

5. [ポリシードキュメントの編集] をクリックし、NLB 権限に nlb:ListAsynJobs 権限を追加します。 Flannel クラスターの場合は、VPC 権限に vpc:CreateRouteEntries および vpc:DeleteRouteEntries 権限も追加します。

   "nlb:ListServerGroupServers",
           "nlb:GetJobStatus",
           "nlb:LoadBalancerLeaveSecurityGroup",
           "nlb:LoadBalancerJoinSecurityGroup",
           "nlb:ListAsynJobs"
         ],
         "Resource": "*",
         "Effect": "Allow"
       },

   },
   {
     "Action": [
       "vpc:Describe*",
       "vpc:DeleteRouteEntry",
       "vpc:CreateRouteEntry",
       "vpc:CreateRouteEntries",
       "vpc:DeleteRouteEntries"
     ],
     "Resource": "*",
     "Effect": "Allow"
   }
   ]
   }

6. 変更を送信し、CCM アップグレードを続行します。