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

ACK クラスターにおける SLB インスタンスの具体的な目的

Kubernetes クラスターを作成する際に [Nginx Ingress] コンポーネントをインストールすると、クラスターはデフォルトで 2 つの SLB インスタンスを作成します。

2 つの SLB インスタンスは、次の目的を果たします。

• API Server SLB: この SLB インスタンスは、API Server のアクセスエンドポイントです。クラスターへのすべてのアクセスリクエストは、この SLB インスタンスを通過する必要があります。TCP ポート 6443 でリッスンします。バックエンドサーバーは API Server Pod またはマスター ECS インスタンスです。

• Nginx Ingress Controller SLB: この SLB インスタンスは、kube-system 名前空間の nginx-ingress-controller サービスに関連付けられています。vServer グループは、Nginx Ingress Controller Pod に動的にバインドされ、外部リクエストを負荷分散して転送します。TCP でポート 80 と 443 をリッスンします。

サービスの作成時に Local と Cluster の外部トラフィックポリシーをどのように選択するか

Local と Cluster の外部トラフィックポリシーは、異なるネットワークプラグインに対して異なる機能を提供します。Local と Cluster の外部トラフィックポリシーの違いの詳細については、「外部トラフィックポリシー」をご参照ください。

サービスと LoadBalancer の同期プロセスのイベントが表示されないのはなぜですか？

kubectl -n {your-namespace} describe svc {your-svc-name} コマンドを実行してもイベント情報が表示されない場合は、CCM コンポーネントのバージョンを確認してください。

• v1.9.3.276-g372aa98-aliyun より前のバージョン: CCM コンポーネントは、サービスと LoadBalancer の同期に関するイベントを表示しません。コンポーネントをアップグレードしてください。CCM のバージョンを確認してアップグレードする方法の詳細については、「CCM コンポーネントのアップグレード」をご参照ください。

• v1.9.3.276-g372aa98-aliyun 以降のバージョンでは、チケットを送信できます。

SLB インスタンスが作成中に保留状態のままになる場合の対処方法

1. kubectl -n {your-namespace} describe svc {your-svc-name} コマンドを実行してイベント情報を表示します。

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

   エラーメッセージが表示されない場合は、「サービスと LoadBalancer の同期プロセスのイベントが表示されないのはなぜですか？」をご参照ください。

SLB vServer グループが更新されない場合の対処方法

1. kubectl -n {your-namespace} describe svc {your-svc-name} コマンドを実行してイベント情報を表示します。

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

   エラーメッセージが表示されない場合は、「サービスと LoadBalancer の同期プロセスのイベントが表示されないのはなぜですか？」をご参照ください。

サービスのアノテーションが有効にならない場合の対処方法

1. エラーメッセージを確認します。

   1. kubectl -n {your-namespace} describe svc {your-svc-name} コマンドを実行してイベント情報を表示します。

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

2. エラーメッセージが表示されない場合は、次のいずれかのシナリオに基づいて問題を解決します。

   • CCM のバージョンがアノテーションのバージョン要件を満たしていることを確認してください。アノテーションと CCM バージョンのマッピングの詳細については、「アノテーションを使用して Classic Load Balancer (CLB) インスタンスを構成する」をご参照ください。

   • Container Service Management Console にログインします。[サービス] ページで、ターゲットサービスの名前をクリックし、サービスに対応するアノテーションがあることを確認します。サービスにアノテーションがない場合は、構成します。

     アノテーションを追加する方法の詳細については、「アノテーションを使用して Classic Load Balancer (CLB) インスタンスを構成する」をご参照ください。

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

   • アノテーションが正しく構成されているかどうかを確認します。

SLB インスタンスの構成が変更されたのはなぜですか？

CCM は宣言型 API を使用し、特定の条件下でサービス構成に基づいて SLB 構成を自動的に更新します。SLB コンソールで変更した構成は、上書きされるリスクがあります。アノテーションを使用して SLB インスタンスを構成することをお勧めします。アノテーションの使用方法の詳細については、「アノテーションを使用して Classic Load Balancer (CLB) インスタンスを構成する」をご参照ください。

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

• シナリオ 1: サービスによって作成されていない SLB インスタンスにプライベート IP アドレスを使用している場合、クラスター内からのアクセスが失敗することがあります。この障害は、SLB インスタンスにアクセスしている Pod がバックエンド Pod と同じノードにある場合に発生します。

  レイヤー 4 のロードバランシングサービスでは、ECS インスタンスはバックエンドサーバーとサービスにアクセスするクライアントの両方として機能することはできません。この問題を解決し、クライアントと宛先が同じノード上にあることを防ぐには、次のいずれかの方法を使用します。

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

  • サービスを使用して SLB インスタンスを作成し、外部トラフィックポリシーを Cluster に設定します。この場合、kube-proxy はクラスター内から SLB インスタンスに送信されるトラフィックをインターセプトし、SLB の制限をバイパスします。

• シナリオ 2: サービスを公開するときに外部トラフィックポリシーを Local に設定しました。これにより、クラスター内から SLB の IP アドレスへのアクセスが失敗します。

  この問題の原因と解決策の詳細については、「LoadBalancer サービスによって公開された SLB アドレスに Kubernetes クラスター内からアクセスできない問題を解決するにはどうすればよいですか？」をご参照ください。

LoadBalancer サービスによって公開された SLB アドレスに Kubernetes クラスター内からアクセスできない問題を解決するにはどうすればよいですか？

SLB インスタンスはいつ自動的に削除されますか？

サービスを削除すると SLB インスタンスも削除されますか？

既存の SLB インスタンスを再利用する場合 (サービスに service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: {your-slb-id} アノテーションがある場合)、サービスを削除しても SLB インスタンスは削除されません。それ以外の場合、サービスを削除すると、対応する SLB インスタンスも削除されます。

サービスタイプを変更した場合 (たとえば、LoadBalancer から NodePort へ)、CCM によって自動的に作成された対応する SLB インスタンスも削除されます。

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

• シナリオ 1: 誤って API Server SLB インスタンスを削除してしまった場合の対処方法

  インスタンスは回復できません。クラスターを再作成する必要があります。詳細については、「ACK Pro マネージドクラスターの作成」をご参照ください。

• シナリオ 2: 誤って Ingress SLB インスタンスを削除してしまった場合の対処方法

  次の手順では、Nginx Ingress を例として、SLB インスタンスを再作成する方法を示します。

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

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

  3. [サービス] ページの上部で、[名前空間] ドロップダウンリストから [kube-system] を選択します。

     1. サービスリストで、ターゲットサービス nginx-ingress-lb を見つけ、[アクション] 列の [YAML 編集] をクリックし、status.loadBalancer フィールドとその内容を削除してから、[OK] をクリックして CCM に SLB の再構築をトリガーさせます。

     2. サービスリストに nginx-ingress-lb が表示されない場合は、ページの左上隅にある [YAML から作成] をクリックし、次のテンプレートを使用して nginx-ingress-lb という名前のサービスを作成します。

        apiVersion: v1
        kind: Service
        metadata:
          labels:
            app: nginx-ingress-lb
          name: nginx-ingress-lb
          namespace: kube-system
        spec:
          externalTrafficPolicy: Local
          ports:
          - name: http
            port: 80
            protocol: TCP
            targetPort: 80
          - name: https
            port: 443
            protocol: TCP
            targetPort: 443
          selector:
            app: ingress-nginx
          type: LoadBalancer

• シナリオ 3: 誤ってアプリケーション固有の SLB インスタンスを削除してしまった場合の対処方法

  • SLB インスタンスに対応するサービスが不要になった場合は、サービスを削除します。

  • 対応するサービスがまだ使用中の場合は、次の手順を実行します。

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

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

    3. [サービス] ページの上部にある [名前空間] ドロップダウンリストから、[すべての名前空間] をクリックし、サービスリストでサービスを見つけます。

    4. ターゲットサービスの [アクション] 列で、[YAML 編集] をクリックし、[status] の内容を削除して、[更新] をクリックして CCM に SLB の再構築を許可します。

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

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

2. kubectl get svc -n ${namespace} ${service} コマンドを実行して、サービスタイプと IP アドレスを表示します。

   説明

   namespace と service をクラスターの名前空間とサービス名に置き換えてください。

3. 次のコマンドを実行して、SLB インスタンスに必要なタグを生成します。

   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)}'

   

4. Server Load Balancer コンソールにログインします。ステップ 2 で取得した IP アドレスに基づいて、対応するリージョンで SLB インスタンスを検索します。

5. ステップ 3 で生成されたキーと値を使用して、SLB インスタンスにタグを追加します。キーと値は、前の図の 1 と 2 に対応します。詳細については、「CLB インスタンスの作成と管理」をご参照ください。

Local モードでノードの重みはどのように自動設定されますか？

このセクションでは、アプリケーション Pod (app=nginx) が 3 つの ECS インスタンスにデプロイされ、サービス A を介して公開されるシナリオを使用して、Local モードでのノードの重みの計算方法を説明します。

クラスター内のすべての SLB インスタンスの IP アドレス、名前、タイプを照会する方法?

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

2. 次のコマンドを実行して、すべての名前空間にある各 LoadBalancer サービスの名前、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"
   }

LoadBalancer サービスのバックエンドサーバーが置き換えられたときに、LoadBalancer が既存の接続を正常に閉じるようにする方法?

service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain および service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain-timeout アノテーションを使用して、接続ドレインを構成できます。バックエンドサーバーがサービスから削除された後、LoadBalancer は drain-timeout 期間内に既存の接続を処理し続けます。詳細については、「リスナーの接続ドレインを有効にする」をご参照ください。

既存の SLB インスタンスの再利用に失敗するのはなぜですか？

• CCM のバージョンを確認してください。v1.9.3.105-gfd4e547-aliyun より前の CCM バージョンは、SLB インスタンスの再利用をサポートしていません。CCM のバージョンを確認してアップグレードする方法の詳細については、「CCM コンポーネントのアップグレード」をご参照ください。

• 再利用したい SLB インスタンスがクラスターによって作成されたものかどうかを確認してください。クラスターによって作成された SLB インスタンスは再利用できません。

• SLB インスタンスが API Server 用の SLB インスタンスであるかどうかを確認してください。API Server 用の SLB インスタンスは再利用できません。

• プライベート向け SLB インスタンスを再利用したい場合は、SLB インスタンスとクラスターが同じ VPC にあることを確認してください。VPC をまたいで SLB インスタンスを再利用することはできません。

既存の SLB インスタンスを再利用する際にリスナーが構成されないのはなぜですか？

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

CCM コンポーネントのアップグレードに失敗した場合の解決方法の詳細については、「Cloud Controller Manager (CCM) のアップグレードチェックが失敗する」をご参照ください。

サービスのエラーメッセージと解決策

NodePort サービスのリスナーを構成する方法

CCM は LoadBalancer サービスのリスナーの構成のみをサポートしています。サービスタイプを NodePort から LoadBalancer に変更する必要があります。

NodePort サービスにアクセスする方法

• クラスター内 (クラスターノード上) からサービスにアクセスするには、ClusterIP + Port または Node IP + Service NodePort を使用できます。NodePort サービスによって公開されるデフォルトのポート番号は 30000 より大きいです。

• クラスター外 (クラスターノード外) からサービスにアクセスするには、ノードの IP アドレスとサービスの NodePort を使用できます。NodePort サービスによって公開されるデフォルトのポート番号は 30000 より大きいです。

• VPC の外部 (別の VPC またはインターネットから) からサービスにアクセスするには、LoadBalancer サービスを公開し、その外部エンドポイントを介してサービスにアクセスする必要があります。

  説明

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

NodePort の範囲を正しく構成する方法

Kubernetes では、API Server は ServiceNodePortRange パラメーター ( --service-node-port-range コマンドラインパラメーター) を提供します。このパラメーターは、NodePort または LoadBalancer サービスがリッスンできる NodePort の範囲を制限します。デフォルト値は 30000 から 32767 です。ACK Pro マネージドクラスターでは、コントロールプレーンのパラメーターをカスタマイズすることで、このポート範囲を変更できます。詳細については、「ACK Pro マネージドクラスターのコントロールプレーンのパラメーターをカスタマイズする」をご参照ください。

• NodePort の範囲を変更する際は、細心の注意を払う必要があります。NodePort の範囲が、クラスターノード上の net.ipv4.ip_local_port_range カーネルパラメーターで指定されたポート範囲と競合しないことを確認してください。ip_local_port_range カーネルパラメーターは、Linux システム上の任意のアプリケーションが使用できるローカルポート番号の範囲を制御します。ip_local_port_range のデフォルト値は 32768 から 60999 です。

• ACK クラスターのデフォルト構成では、ServiceNodePortRange パラメーターと ip_local_port_range パラメーターは競合しません。以前にこれらのパラメーターのいずれかを調整してポート制限を増やし、それらの範囲が重複するようになった場合、ノードで散発的なネットワーク例外が発生する可能性があります。深刻な場合、これはビジネスのヘルスチェックの失敗やクラスターノードのオフラインにつながる可能性があります。デフォルト値に戻すか、両方のポート範囲を調整してまったく重複しないようにすることをお勧めします。

• ポート範囲を調整した後、クラスター内の一部の NodePort または LoadBalancer サービスが、ip_local_port_range パラメーターの範囲内のポートを NodePort として使用し続けている可能性があります。競合を避けるために、これらのサービスを再構成する必要があります。kubectl edit <service-name> コマンドを実行して、spec.ports.nodePort フィールドの値を未使用の NodePort に直接変更できます。

ACK 専用クラスターで CCM コンポーネントを新しいバージョンにアップグレードする際に必要な権限を追加する方法

パフォーマンスを向上させるために、CCM の新しいバージョンでは、追加の RAM 権限を必要とする Alibaba Cloud API が徐々に導入されています (たとえば、Flannel ネットワークのルート管理用の v2.11.2 や NLB のバッチ管理用の v2.12.1)。

したがって、ACK 専用クラスターでコンポーネントを v2.11.2 以降にアップグレードする場合は、アップグレード前にその RAM ロールに必要な権限を付与して、コンポーネントが期待どおりに動作するようにする必要があります。

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

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

3. [基本情報] タブをクリックします。[クラスターリソース] エリアで、[マスター RAM ロール] のロール名をクリックします。

4. Resource Access Management コンソールのロール詳細ページで、[権限管理] をクリックし、ポリシーリストで k8sMasterRolePolicy-Ccm- で始まるカスタムポリシーを見つけ、ポリシー名をクリックしてアクセスポリシー管理ページに移動します。

   以前に作成されたクラスターの場合、ポリシーが存在しない可能性があります。k8sMasterRolePolicy- で始まる名前のカスタムポリシーを選択できます。

5. [ポリシーの編集] をクリックし、NLB 権限に nlb:ListAsynJobs 権限を追加します。

   

Flannel クラスターを使用している場合は、VPC 関連の権限に vpc:CreateRouteEntries と vpc:DeleteRouteEntries 権限も追加する必要があります。

権限を追加した後、ページ上のプロンプトに従ってポリシーを送信します。変更が保存されたら、CCM コンポーネントをアップグレードできます。