Container Service for Kubernetes:サービス障害のトラブルシューティング

CLB バックエンド間での負荷分散が不均等

原因： CLB のスケジューリングアルゴリズムがトラフィックパターンに適していません。

症状： リクエスト負荷がバックエンドサーバー間で不均等に分散されています。

解決策：

• externalTrafficPolicy: Local を使用するサービスの場合、重み付きラウンドロビンスケジューリングを使用するために、service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler:"wrr" アノテーションを追加します。

• 接続保持を使用するサービスの場合、重み付き最小接続スケジューリングを使用するために、service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler:"wlc" アノテーションを追加します。これにより、長時間の接続が過度なトラフィックを受けることが防げます。

アプリケーション更新時の 503 エラー

原因： CLB リスナーで接続ドレインが設定されていない、または Pod でグレースフルターミネーションが設定されていません。ローリングアップデート中に、CLB が既にシャットダウンを開始している Pod にトラフィックをルーティングすることがあります。

症状： アプリケーション更新中に CLB インスタンスにアクセスすると、503 エラーが返されます。

解決策：

1. CLB リスナーで接続ドレインを設定するため、service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain アノテーションを追加します。リスナーのアノテーション一覧については、「リスナー管理の一般的な操作」をご参照ください。

2. Pod で readinessProbe および preStop を設定します。例としての Pod 構成を以下に示します。

   • `readinessProbe`：Pod は readiness probe を通過した後のみ、サービスの Endpoint に追加されます。ACK が Endpoint の変更を検出すると、ノードが CLB バックエンドにアタッチされます。プローブの頻度、遅延、失敗しきい値は、アプリケーションの起動時間に合わせて設定してください。タイムアウトが短すぎると、Pod が繰り返し再起動する可能性があります。

   • `preStop` および `terminationGracePeriodSeconds`：preStop には、アプリケーションが進行中のリクエストをドレインするために必要な時間を設定します。terminationGracePeriodSeconds には、preStop より少なくとも 30 秒長い時間を設定します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx
     namespace: default
   spec:
     containers:
     - name: nginx
       image: nginx
       # Liveness probe
       livenessProbe:
         failureThreshold: 3
         initialDelaySeconds: 30
         periodSeconds: 30
         successThreshold: 1
         tcpSocket:
           port: 5084
         timeoutSeconds: 1
       # Readiness probe
       readinessProbe:
         failureThreshold: 3
         initialDelaySeconds: 30
         periodSeconds: 30
         successThreshold: 1
         tcpSocket:
           port: 5084
         timeoutSeconds: 1
       # Graceful termination
       lifecycle:
         preStop:
           exec:
             command:
             - sleep
             - 30
     terminationGracePeriodSeconds: 60

クラスター内から CLB にアクセスできない

原因： サービスで externalTrafficPolicy: Local が設定されています。この設定では、kube-proxy はリクエストの発信元と同じノード上で実行されている Pod にのみトラフィックを転送します。リクエストを受け取るノードに該当サービスのバックエンド Pod がない場合、接続は失敗します。これは、CLB アドレスにルーティングされるクラスター内トラフィックに影響を与えます。詳細については、「kube-proxy adds external-lb address to node-local iptables rule」をご参照ください。

症状： CLB インスタンスはクラスター外からアクセス可能ですが、クラスター内からは接続できません。

解決策： 以下のいずれかの方法をご利用ください。

• ClusterIP またはサービス名を使用したアクセス（クラスター内アクセスに推奨）： クラスター内では、CLB アドレスの代わりにサービスの ClusterIP または DNS 名を使用します。Ingress サービスの場合、サービス名は nginx-ingress-lb.kube-system です。

• `externalTrafficPolicy: Cluster` への切り替え： この設定では、Pod の配置に関係なくクラスター内トラフィックがサービスに到達しますが、クライアントの元のソース IP は保持されません。Ingress サービスを変更するには：

  Ingress CLB インスタンスを使用している場合、Pod は Ingress ポッドが実行されているノードからのみ、Ingress または CLB 経由で公開されたサービスにアクセスできます。

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

• ENI パススルー（Terway のみ）を伴う `externalTrafficPolicy: Cluster` の使用： クラスターで ENI を使用する Terway または ENI ごとの複数 IP を使用している場合、externalTrafficPolicy: Cluster を設定し、service.beta.kubernetes.io/backend-type: "eni" アノテーションを追加します。これにより、ソース 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

クラスター外から CLB にアクセスできない

原因： アクセス制御リスト (ACL) がクライアント IP をブロックしている、CLB vServer グループにバックエンドサーバーがない、または CLB のヘルスチェックが失敗していることです。

症状： CLB インスタンスがクラスター外から到達できません。

解決策：

1. サービスのエラーイベントを確認し、解決します。「サービスのエラーイベントと解決策」をご参照ください。

   kubectl -n {your-namespace} describe svc {your-svc-name}

2. CLB インスタンスに ACL が設定されているか確認します。設定されている場合、クライアント IP アドレスからのインバウンドトラフィックが許可されていることを確認します。ACL の設定方法については、「リソースアクセス管理」をご参照ください。

3. CLB vServer グループが空かどうか確認します。空の場合、アプリケーション Pod がサービスに関連付けられており、期待通りに実行されていることを確認します。Pod が不健全な場合は、まず Pod の問題を解決します。「Pod 障害のトラブルシューティング」をご参照ください。

4. CLB リスナーのヘルスチェックが成功しているか確認します。失敗している場合、アプリケーション Pod が正しく応答していることを確認します。ヘルスチェックのトラブルシューティングについては、「CLB ヘルスチェック FAQ」をご参照ください。

バックエンドの HTTPS サービスに接続できない

原因： CLB リスナーに証明書が設定されている場合、CLB が TLS を終端し、復号された HTTP トラフィックをバックエンド Pod に転送します。targetPort が HTTPS ポート（例：443）に設定されていると、Pod は HTTPS ポートで HTTP リクエストを受信し、「The plain HTTP request was sent to HTTPS port」として拒否します。

症状： CLB リスナーで HTTPS を設定した後に、バックエンドサービスへの接続が失敗します。

解決策： HTTPS リスナーのポートに対する targetPort を、バックエンド Pod がリッスンしている HTTP ポートに設定します。たとえば、Nginx が内部で HTTPS ポート 443 をリッスンしている場合、targetPort を 80 に設定します。

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "https:443"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cert-id: "${YOUR_CERT_ID}"
  name: nginx
  namespace: default
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  - port: 443
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: LoadBalancer