ネットワーキング問題

VPC環境で利用できます。

Ncloud Kubernetes Serviceを利用しながら、以下のような問題が発生することがあります。問題ごとの原因と解決方法を確認し、適切に対処してください。

作成していない Target Groupが存在

作成していない Target Groupが存在します。

原因

ALBとマッピングされた Ingress Manifest内の spec.defaultBackendが指定されていない場合、ワーカーノードグループの80ポートに設定された Target Groupが作成されます。この Target Groupは ALBの動作に影響を与えず意図した動作です。

解決方法

原因の説明の通り意図された動作なので、特に対策する必要はありません。

NetworkPolicyエラー

NetworkPolicyが正常に動作しません。

原因

Cilium CNIを使用する場合、NetworkPolicyの機能の中には既知の未対応機能があります。

解決方法

既知の未対応機能は、次の通りです。

• pod IPを利用した ipBlock
• SCTP Protocol
• Port範囲(endPort)

Ciliumの Connectivity Testに失敗

Ciliumの Connectivity Testに失敗します。

原因

Ciliumは、ネットワーク状態をテストするための Connectivity Testを提供します。Ncloud Kubernetes Serviceでこのテストセットをそのまま実行する場合、以下の2件のテストに失敗します。これは link-local ipにバインドされた node-local-dnsを使用する場合に発生する既知の不具合です。

解決方法

有効な DNSリゾルビングのために以下のように CiliumNetworkPolicyで toCIDR フィールドに node-local-dnsが使用する IPアドレス帯域を追加してください。

# pod-to-a-allowed-cnp
  egress:
  - toPorts:
    - ports:
      - port: "53"
        protocol: ANY
    toEndpoints:
    - matchLabels:
        k8s:io.kubernetes.pod.namespace: kube-system
        k8s:k8s-app: kube-dns
    toCIDR:
    - 169.254.25.10/32

# pod-to-external-fqdn-allow-google-cnp
  egress:
  - toPorts:
    - ports:
      - port: "53"
        protocol: ANY
      rules:
        dns:
        - matchPattern: '*'
    toEndpoints:
    - matchLabels:
        k8s:io.kubernetes.pod.namespace: kube-system
        k8s:k8s-app: kube-dns
    toCIDR:
    - 169.254.25.10/32

LoadBalancerタイプのサービスリソースの作成後、Pendingステータスを維持

LoadBalancerタイプのサービスリソースの作成後、Pendingステータスを維持しています。

原因

クラスタ作成時に選択した Load Balancerサブネットを削除したり、割り当て可能な IPアドレスがない場合、External-IPが割り当てられないために発生する問題です。

解決方法

デフォルトの Load Balancerサブネットを変更するか、他の Load Balancerサブネットを選択する必要があります。

デフォルトの Load Balancerサブネットを変更する方法は、次の通りです。

1. kube-system Namespaceで ncloud-config という名前を持つ configmapを確認します。

   $ kubectl --kubeconfig $KUBE_CONFIG get configmap ncloud-config -n kube-system
   $ kubectl --kubeconfig $KUBE_CONFIG get configmap ncloud-config -n kube-system -o yaml
   

2. 以下のコマンドを参照して kube-system Namespaceで ncloud-config という名前を持つ configmapを確認して変更します。

   $ kubectl --kubeconfig $KUBE_CONFIG get configmap ncloud-config -n kube-system
   NAME            DATA   AGE
   ncloud-config   9      131m
   
   $ kubectl --kubeconfig $KUBE_CONFIG get configmap ncloud-config -n kube-system -o yaml
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ncloud-config
     namespace: kube-system
   data:
     acgNo: "12345"
     apiUrl: https://nks.apigw.ntruss.com
     basePath: /ncloud-api/v1
     lbPublicSubnetNo: "98765"
     lbSubnetNo: "12345"
     regionCode: KR
     regionNo: "11"
     vpcNo: "12345"
     zoneNo: "110"
   

   • data.acgNo: ワーカーノードの eth0インタフェースに割り当てられた acgの instanceIDを入力
   • data.apiUrl: https://nks.apigw.ntruss.comを入力
   • data.basePath: /ncloud-api/v1を入力
   • data.lbPublicSubnetNo: ワーカーノードが割り当てられた VPC内の Load Balancer専用 Publicサブネットの SubnetIDを入力
   • data.lbSubnetNo: ワーカーノードが割り当てられた VPC内の Load Balancer専用 Privateサブネットの SubnetIDを入力
   • data.regionCode: ワーカーノードが位置するリージョンコードを入力(例: 「FKR」)
   • data.regionNo: ワーカーノードのリージョン番号を入力(例: 「11」)
   • data.vpcNo: ワーカーノードが割り当てられた VPCの VPC IDを入力
   • data.zoneNo: ワーカーノードが位置するゾーン番号を入力(例: 「110」)

3. 以下のコマンドを実行して Load Balancer専用のサブネットを変更します。

   $ kubectl --kubeconfig $KUBE_CONFIG -n kube-system patch configmap ncloud-config --type='json' -p='[{"op":"replace", "path":"/data/lbSubnetNo", "value": "94465"}]'
   

   • サンプルサブネット IDとして94465を使用したコマンドです。
   • Kubernetesワーカーノードを作成した VPC内の Load Balancer専用サブネットの SubnetIDを使用します。不正な SubnetIDを使用する場合、サブネットの変更後に Load Balancerは正常に作成できません。

4. 変更が完了したら、以下のコマンドを実行して configmapに変更事項が適用されたか確認します。

   $ kubectl --kubeconfig $KUBE_CONFIG get configmap ncloud-config -n kube-system -o yaml
   

Ingressに関連付けられた Application Load Balancer(ALB)エラー

Ingressに関連付けられた Application Load Balancer(ALB)が正常に作成されない、または動作しません。

原因

• ALB Ingress Controller Podが動作しないか、内部エラーがある可能性があります。
• ALB Ingress Controllerが存在しない場合、ALBは作成できません。
• Ingress Manifestにエラーがある場合、ALBや関連ルールを作成しません。
• コンソールや APIで作成された ALBを変更する場合、問題が発生する可能性があります。
• クラスタ構成のワーカーノードのステータスが運用中でない場合、問題が発生する可能性があります。

解決方法

リソースとログを照会
ALB Ingress Controllerで作成された ALBのステータスを点検してください。関連リソースとログを照会するコマンドは、次の通りです。

$ kubectl --kubeconfig $KUBE_CONFIG logs -n kube-system -l app.kubernetes.io/name=alb-ingress-controller
$ kubectl --kubeconfig $KUBE_CONFIG describe ingress [ingress-name]

ALB Ingress Controllerが存在しない
ALB Ingress Controllerが存在しない場合、ALBが作成されません。ALB Ingress Controller設定ガイドを参照して、ALB Ingress Controllerをクラスタにインストールしてください。

ALB Ingress Controllerのバージョン確認
Public LB Subnetを通じたパブリックロードバランサを作成する場合、サポートするバージョンは ALB Ingress Controller v0.8.0以上です。使用している Controllerのバージョンを確認し、新しいバージョンをインストールしてください。

Ingress Manifestエラー
Ingress Manifestにエラーがある場合、ALBや関連ルールを作成しません。ALB Ingress Controllerの Podログ照会により原因をご確認ください。

• Manifest内のルールと作成した ALBのルールが一致しない場合
• Manifestルールに記載されたサービスの名前とポートが間違えて記載されている場合
• ルールの順序が正しくない場合(最上段のルールを一番先に適用)
• 有効なアノテーションを使用していない場合
  • アノテーション設定時に誤字脱字や間違った記号がないか確認
  • Ingress Controllerの当該バージョンでサポートするアノテーションを使用したか確認

コンソールや APIで ALBを変更する場合
作成された ALBをコンソールまたは APIで変更する場合、問題が発生する可能性があります。ALB Ingress Controllerにより作成した ALBは、Kubernetesクラスタ内に登録した Ingressの Manifestと定期的に同期してください。コンソールや APIで ALBを変更するタスクは控えることを推奨し、変更タスク時には Manifestを再適用してステータス同期を実行してください。

クラスタのワーカーノードステータス問題
クラスタを構成するワーカーノードのステータスが「運用中」でない場合、正常に動作しない場合があります。ワーカーノードのステータスを点検した後、再試行してください。

Public LBを作成する場合
Public LB Subnetが登録されていないクラスタは、パブリックタイプのロードバランサを作成できません。Ncloud Kubernetes Serviceでパブリックロードバランサを作成する場合、クラスタに Public LB Subnetを登録してください。
Public LB Subnetの作成方法は、Subnet Managementをご参照ください。クラスタに Public LB Subnetを登録した後、再試行してください。

Private LBを作成する場合

• Kubernetesクラスタに Private LB Subnetが登録されているかご確認ください。
• 以下のアノテーションを利用しているかご確認ください。詳細は、ALB Ingress Controller設定をご参照ください。
  alb.ingress.kubernetes.io/network-type: "true

カーネルパラメータの変更後、クラスタでパケットドロップが発生

カーネルパラメータの変更後、クラスタでパケットドロップが発生します。

原因

Ncloud Kubernetes Serviceの CNIである Ciliumの起動時、動的に rp_filterを無効化します。Cilium設定と一致しない場合、パケットドロップが発生する場合があります。

解決方法

syctl.confファイルの変更および適用時に rp_filter関連設定の「net.ipv4.conf.all.rp_filter」を「0」に変更してください。
ワーカーノードの特定のカーネルパラメータを変更するために sysctl.confファイルを適用する場合、sysctl.confファイルの設定は変更しないようにご注意ください。判断が難しい場合は、NAVERクラウドプラットフォームポータルのカスタマーサポートにお問い合わせください。

Ingress証明書変更に失敗

Ingressで作成された Application LoadBalancerの証明書が変更されません。
Ingressで作成された Application LoadBalancerの証明書変更に失敗します。
Ingressで作成された Application LoadBalancerのマルチ証明書変更が適用されません。

原因

• アノテーションを間違えて設定した場合、問題が発生する可能性があります。
• 使用可能な証明書でない場合、問題が発生する可能性があります。
• コンソールで証明書を変更する場合、証明書が正常に変更されません。
• ALB Ingress Controllerがマルチ証明書アノテーションをサポートしていない場合、問題が発生する可能性があります。

解決方法

Ingressで作成された Application LoadBalancerはコンソールでのタスクを避け、証明書の変更はアノテーションで行います。設定したアノテーションをご確認ください。

• アノテーションに誤字脱字があるか、記号を正しく使用しているか確認
• ALB Ingress Controllerは0.8.0バージョンからマルチ証明書をサポートしています。使用している ALB Ingress Controllerのバージョンをご確認ください。

不正な Client IP

Client IPが正しくありません。実ユーザーの Client IPを確認したいです。

原因

Kubernetesはクラスタ内の Podにリクエストを送信する際に SNATを行います。この過程で、クライアントの実際の IPアドレスが変更される可能性があります。

解決方法

Kubernetes Serviceにより作成できるロードバランサは NetworkLoadBalancer(NLB)、NetworkProxyLoadBalancer(NPLB)、ApplicationLoadBalancer(ALB)です。ロードバランサの種類によって Client IPアドレスの確認方法が異なります。

• ALB: HTTP/HTTPSプロトコルを使用するため、アプリケーションで X-Forwarded-Forヘッダを通じてクライアント IPアドレスを確認できます。
• NPLB: proxy-protocolを有効にすることで、Client IPを確認できます。サービスの明細に関連アノテーションの記載が必要であり、アプリケーションでも proxy-protocol関連設定が有効になっている必要があります。例えば、nginx-ingress-controllerを使用する場合、nginx-ingress-controllerの proxy-protocol設定が有効になっている必要があります。
• NLB: NLBの場合はロードバランサで Client IPが表示されますが、クラスタ内部での設定が必要です。サービスの明細で「externalTrafficPolicy」を「Local」に変更することで、Client IPを確認できます。「externalTrafficPolicy」の設定については、公式ドキュメントをご参照ください。

ALB作成時にターゲットグループの設定を変更

ALB作成時にターゲットグループの設定を変更したいです。

原因

ALBのルールで指定した Serviceに関連内容が設定されていないため、問題が発生する可能性があります。

解決方法

Ingressのバックエンドとして指定される Serviceの明細を変更して設定することができます。アノテーションを使用すると、Serviceを通じて作成されるターゲットグループのロードバランシングアルゴリズム、Health Checkの設定が可能です。
例えば、以下の内容のように指定すると、「naver」 Serviceを通じて作成されたターゲットグループは、least-connectionアルゴリズムを通じてロードバランシングが行われます。

apiVersion: v1
kind: Service
metadata:
  annotations:
    alb.ingress.kubernetes.io/algorithm-type: "least-connection"
  name: naver

Service、Ingressで使用可能なアノテーションの場合、ALB Ingress Controller設定で確認できます。