Container Service for Kubernetes:サービスFAQ

ACKクラスターでSLBインスタンスを使用するにはどうすればよいですか?

ACKクラスターの作成時にNGINX Ingressコントローラーがインストールされている場合、クラスターに対して2つのSLBインスタンスが自動的に作成されます。

次のセクションでは、SLBインスタンスの目的について説明します。

• APIサーバーSLB: SLBインスタンスは、クラスターのAPIサーバーを公開するために使用されます。 クラスターにアクセスするには、SLBインスタンスと通信する必要があります。 SLBインスタンスは、ポート6443でリッスンするTCPリスナーを使用します。 SLBインスタンスのバックエンドサーバーは、APIサーバーのポッド、またはマスターノードとして機能するElastic Compute Service (ECS) インスタンスです。

• NGINX Ingress controller SLB: SLBインスタンスは、リクエストを転送するためにkube-system名前空間のnginx-ingress-controller Serviceに関連付けられています。 vServerグループは、NGINX Ingressコントローラーのポッドに動的に関連付けられます。 SLBインスタンスは、ポート80と443でリッスンするTCPリスナーを使用します。

サービス、ローカル、またはクラスターを作成するときに使用する外部トラフィックポリシーはどれですか。

ローカルおよびクラスターの外部トラフィックポリシーの機能は、クラスターで使用されるネットワークプラグインによって異なります。 ローカル外部トラフィックポリシーとクラスター外部トラフィックポリシーの違いの詳細については、「外部トラフィックポリシー: ローカルとクラスター」をご参照ください。

サービスとSLBインスタンス間の同期中にイベントが収集されないのはなぜですか。

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

• CCMのバージョンがV1.9.3.276-g372aa98-aliyunより前の場合、サービスとSLBインスタンス間の同期にイベントは生成されません。 CCMのバージョンを更新することを推奨します。 CCMのバージョンを表示および更新する方法の詳細については、「CCMの手動更新」をご参照ください。

• CCMのバージョンがV1.9.3.276-g372aa98-aliyun以降の場合、チケットを起票します。

保留状態のままのSLBインスタンスを処理するにはどうすればよいですか。

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

2. イベントで報告されるエラーのトラブルシューティング。 イベントで報告されるエラーのトラブルシューティング方法の詳細については、「エラーと解決策」をご参照ください。

   イベントでエラーが報告されない場合は、サービスとSLBインスタンス間の同期中にイベントが収集されないのはなぜですか。

SLBインスタンスのvServerグループが更新されない場合はどうすればよいですか。

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

2. イベントで報告されるエラーのトラブルシューティング。 イベントで報告されるエラーのトラブルシューティング方法の詳細については、「エラーと解決策」をご参照ください。

   イベントでエラーが報告されない場合は、サービスとSLBインスタンス間の同期中にイベントが収集されないのはなぜですか。

サービスの注釈が有効にならない場合はどうすればよいですか?

1. 次の手順を実行して、エラーを表示します。

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

   2. イベントで報告されるエラーのトラブルシューティング。 イベントで報告されるエラーのトラブルシューティング方法の詳細については、「エラーと解決策」をご参照ください。

2. エラーが報告されない場合は、次のシナリオに基づいて問題を解決できます。

   • CCMバージョンが注釈の要件を満たしていることを確認してください。 アノテーションとCCMバージョンの相関関係の詳細については、「アノテーションを使用してCLBインスタンスを設定する」をご参照ください。

   • ACKコンソールにログインします。 [サービス] ページで、管理するサービスの名前をクリックし、そのサービスにアノテーションが設定されているかどうかを確認します。 アノテーションがサービスに設定されていない場合は、サービスのアノテーションを設定します。

     アノテーションの設定方法の詳細については、「アノテーションを使用してCLBインスタンスを設定する」をご参照ください。

     サービスの一覧を表示する方法の詳細については、「はじめに」をご参照ください。

   • アノテーションが有効であることを確認します。

SLBインスタンスの設定が変更されるのはなぜですか。

特定の条件が満たされると、CCMは宣言型APIを呼び出して、サービス設定に基づいてSLBインスタンスの設定を更新します。 SLBコンソールでSLBインスタンスの設定を変更すると、CCMが変更を上書きすることがあります。 アノテーションを使用してSLBインスタンスを設定することを推奨します。 SLBインスタンスのアノテーションを設定する方法の詳細については、「アノテーションを使用してCLBインスタンスを設定する」をご参照ください。

クラスターがSLBインスタンスのIPアドレスにアクセスできないのはなぜですか。

• シナリオ1: SLBインスタンスはプライベートIPアドレスを使用し、サービスに対して自動的に作成されません。 この場合、SLBインスタンスのバックエンドポッドとクライアントポッドは同じノードにデプロイされます。 そのため、クライアントポッドはSLBインスタンスのプライベートIPアドレスにアクセスできません。

  これは、レイヤー4 SLBでは、SLBインスタンスのバックエンドサーバーをクライアントとして使用してバックエンドサービスにアクセスすることができないためです。 その結果、クラスターはSLBインスタンスのプライベートIPアドレスにアクセスできません。 この問題を解決するには、次の方法を使用して、クライアントポッドとバックエンドポッドが同じノードにデプロイされないようにします。

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

  • SLBインスタンスを自動的に作成するサービスを作成します。 サービスを設定するときに、外部トラフィックポリシーをクラスターに設定します。 このように、クラスター内からのリクエストは、SLBインスタンスではなくkube-proxyによって転送されます。

• シナリオ2: アプリケーションの公開に使用されるサービスの外部トラフィックポリシーが [ローカル] に設定されています。 その結果、クラスター内のポッドはSLBインスタンスのIPアドレスにアクセスできません。

  問題の詳細と問題の解決方法については、「」をご参照ください。クラスターがLoadBalancerサービスによって公開されているSLBインスタンスのIPアドレスにアクセスできない場合はどうすればよいですか。

クラスターがLoadBalancerサービスによって公開されているSLBインスタンスのIPアドレスにアクセスできない場合はどうすればよいですか。

問題

ACKクラスターでは、externalTrafficPolicyがLocalに設定されているSLBインスタンスのIPアドレスにアクセスできるのは、特定のノードのみです。 Ingressを使用してSLBインスタンスにアクセスすると、アクセスエラーが発生します。

原因

externalTrafficPolicy: LocalがSLBインスタンスに設定されています。 ローカルモードでは、ポッドがローカルノード (SLBインスタンスを実行するノード) でプロビジョニングされている場合にのみ、SLBインスタンスのIPアドレスにアクセスできます。 SLBインスタンスのIPアドレスがACKクラスターの外部にあること。 ACKクラスター内のノードまたはポッドがセカンドホップを使用せずにIPアドレスにアクセスできない場合、要求はSLBインスタンスに到達できません。 その結果、SLBインスタンスのIPアドレスは、SLBインスタンスを使用するサービスの拡張IPアドレスと見なされます。 リクエストは、iptablesまたはIP仮想サーバー (IPVS) に基づくkube-proxyによって転送されます。

このシナリオでは、要求されたポッドがローカルノードでプロビジョニングされていない場合、接続の問題が発生します。 SLBインスタンスのIPアドレスは、要求されたポッドがローカルノードでプロビジョニングされている場合にのみアクセスできます。 詳細については、「」をご参照ください。kube-proxyが外部lbのアドレスをノードローカルiptablesルールに追加する理由?.

解決策

次のいずれかの方法を使用して問題を解決できます。 最初の方法を使用することを推奨します。

• ClusterIPサービスまたはIngress名を使用して、ACKクラスター内からSLBインスタンスのIPアドレスにアクセスします。 Ingress名はnginx-ingress-lb.kubeシステムです。

• LoadBalancerサービスのクラスターにexternalTrafficPolicyを設定します。 このメソッドは、リクエストがすべてのノードのポッドに転送されるようにします。 ただし、SNATが使用されているため、送信元IPアドレスは保持できません。 つまり、バックエンドアプリケーションはクライアントIPアドレスを取得できません。 次のコマンドを実行して、Ingressを変更します。

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

• クラスターのネットワークプラグインがTerwayに設定されていて、排他的または包括的ENIモードが選択されている場合、LoadBalancerサービスのクラスターにexternalTrafficPolicyを設定し、elastic network Interface (ENI) アノテーションを追加できます。 例: アノテーション: service.beta.kubernetes.io/backend-type: "eni" アノテーションにより、LoadBalancerサービスのバックエンドサーバーとしてENIが割り当てられたポッドが追加されます。 これにより、クライアントIPアドレスを保持し、クラスター内からSLBインスタンスのIPアドレスにアクセスできます。 詳細については、「アノテーションを使用した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

SLBインスタンスが自動的に削除されるのはいつですか。

サービスを削除すると、サービスに関連付けられているSLBインスタンスは自動的に削除されますか?

SLBインスタンスが再利用された場合、サービスとともに削除されることはありません。 SLBインスタンスが再利用されていない場合、削除されます。 サービスにService. beta.kubernetes.io/alibaba-cloud-loadbalancer-id: {your-slb-id} という注釈が含まれている場合、対応するSLBインスタンスは再利用されます。

サービスのタイプをLoadBalancerからNodePortに変更した場合、CCMによってSLBインスタンスが作成されると、SLBインスタンスは自動的に削除されます。

誤ってSLBインスタンスを削除した場合はどうすればよいですか?

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

  削除されたSLBインスタンスは復元できません。 新しいSLBインスタンスを作成する必要があります。 詳細については、「ACK Proクラスターの作成」をご参照ください。

• シナリオ2: IngressのSLBインスタンスを削除するとどうすればよいですか?

  SLBインスタンスを再作成するには、次の手順を実行します。

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

  2. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、[ネットワーク] > [サービス] を選択します。

  3. [サービス] ページで、[名前空間] ドロップダウンリストから [kube-system] を選択します。 次に、[サービス] リストで [nginx-ingress-lb] を見つけてクリックします。

     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

  4. サービスの [操作] 列で、[YAMLの編集] をクリックし、[ステータス] フィールドの内容を削除し、[更新] をクリックします。 このようにして、CCMは新しいSLBインスタンスを作成します。

• シナリオ3: ワークロードを処理するように設定されているSLBインスタンスを削除する場合、どうすればよいですか。

  • SLBインスタンスに関連付けられているサービスが不要になった場合は、サービスを削除します。

  • サービスを維持する場合は、次の手順を実行します。

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

    2. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、[ネットワーク] > [サービス] を選択します。

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

    4. サービスの [操作] 列で、[YAMLの編集] をクリックし、[ステータス] フィールドの内容を削除し、[更新] をクリックします。 このようにして、CCMは新しいSLBインスタンスを作成します。

CCMバージョンがV1.9.3.10以前の場合、SLBインスタンスの名前を変更するにはどうすればよいですか。

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

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. SLBコンソールにログインし、SLBインスタンスがデプロイされているリージョンを選択し、手順2で返されたIPアドレスに基づいて、指定されたSLBインスタンスを見つけます。

5. 手順3で生成されたタグをSLBインスタンスに追加します。 上の図のCallout 1はタグキー、callout 2はタグ値です。 詳細については、「タグの管理」をご参照ください。

CCMはローカルモードでノードの重みをどのように計算しますか?

この例では、app=nginxラベルのポッドが3つのECSインスタンスにデプロイされています。 次の図では、externalTrafficPolicyがLocalに設定されている場合、ポッドはサービスAを使用して外部ユーザーにサービスを提供します。

クラスター内のすべてのSLBインスタンスのIPアドレス、名前、およびアドレスタイプを照会するにはどうすればよいですか。

1. クラスターのkubeconfigファイルを取得し、kubectlを使用してクラスターに接続します。

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を使用して、接続ドレインを設定できます。 サービスからバックエンドを削除した後、drain-timeout期間中、LoadBalancerは既存の接続を処理し続けます。 詳細については、「リスナーの接続ドレインの設定」をご参照ください。

システムが既存のSLBインスタンスを複数のサービスに使用できないのはなぜですか?

• CCMのバージョンを確認してください。バージョンがv1.9.3.105-gfd4e547-aliyunより前の場合、CCMは複数のサービスに対して既存のSLBインスタンスを使用できません。 CCMのバージョンを表示および更新する方法の詳細については、「CCMの手動更新」をご参照ください。

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

• SLBインスタンスがAPIサーバーによって使用されているかどうかを確認します。 SLBインスタンスは、APIサーバーで使用されている場合は再利用できません。

• SLBインスタンスが内部対応のSLBインスタンスの場合、SLBインスタンスとクラスターが同じ仮想プライベートクラウド (VPC) にデプロイされているかどうかを確認します。 異なるVPCにデプロイされている場合、SLBインスタンスは再利用できません。

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

CCM更新の失敗のトラブルシューティング方法?

CCM更新の失敗のトラブルシューティング方法の詳細については、 CCMを更新する前に発生するチェックの失敗をトラブルシューティングするにはどうすればよいですか。

サービスでエラーが発生した場合はどうすればよいですか?

NodePortサービスのリスナーを構成する方法を教えてください。

CCMを使用して、LoadBalancerサービスのリスナーのみを設定できます。 したがって、サービスのタイプをNodePortからLoadBalancerに変更する必要があります。

NodePortサービスにアクセスするにはどうすればよいですか。

• クラスター内からNodePortサービスにアクセスするには、ClusterIP + PortまたはNode IP + NodePort Serviceポートにリクエストを送信します。 NodePortサービスによって公開されるデフォルトのポート番号は30000より大きい。

• クラスターの外部からNodePortサービスにアクセスするには、ノードIP + NodePortサービスポートにリクエストを送信します。 NodePortサービスによって公開されるデフォルトのポート番号は30000より大きい。

• インターネットまたはクラスターが存在するVPC以外のVPCを介してNodePortサービスにアクセスする場合は、LoadBalancerサービスを作成し、LoadBalancerサービスの外部エンドポイントを使用してNodePortサービスを公開する必要があります。

  説明

  サービスの外部トラフィックポリシーが [ローカル] に設定されている場合、サービスがデプロイされているノードでサービスのバックエンドポッドが少なくとも1つ実行されていることを確認します。 サービスでサポートされている外部トラフィックポリシーの詳細については、「外部トラフィックポリシー: ローカルとクラスター」をご参照ください。

適切なノードポート範囲を設定するにはどうすればよいですか?

Kubernetes APIサーバーでは、-- service-node-port-rangeパラメーターを設定して、ノードのNodePortサービスまたはLoadBalancerサービスのポート範囲を指定できます。 デフォルトのポート範囲は32767に30000されています。 ACK Proクラスターでは、制御プレーンコンポーネントのパラメーターを設定することで、カスタムポート範囲を指定できます。 詳細については、「ACK Proクラスターの制御プレーンコンポーネントのパラメーターのカスタマイズ」をご参照ください。

• カスタムノードのポート範囲を指定する場合は注意してください。 ノードのポート範囲が、クラスター内のノードのLinuxのnet.ipv4.ip_local_port_rangeカーネルパラメーターで指定されたポート範囲と重複しないようにします。 ノードのip_local_port_rangeカーネルパラメーターは、ノード上のすべてのLinuxプログラムのローカルポート範囲を指定します。 ip_local_port_rangeのデフォルト値は60999に32768されています。

• -- service-node-port-rangeとip_local_port_rangeのデフォルト値は重複しません。 どちらかを変更した後に2つのポート範囲が重複すると、ノードでネットワークエラーが発生することがあります。 さらに、アプリケーションのヘルスチェックが実行されず、ノードがクラスターから切断される可能性があります。 この場合、パラメーターをデフォルト値にリセットするか、パラメーター値を変更してポート範囲が重ならないようにすることをお勧めします。

• ノードポート範囲を変更した後も、一部の既存のNodePortまたはLoadBalancerサービスは、ip_local_port_rangeカーネルパラメーターで指定された範囲に属するポートを使用する可能性があります。 この場合、NodePortまたはLoadBalancerサービスで使用されるポートを変更する必要があります。 kubectl edit <service-name> コマンドを実行し、spec.ports.nodePortパラメーターの値をアイドルノードポートに変更します。