--- title: "ネットワーキング問題" slug: "k8s-troubleshoot-lb" updated: 2026-09-17T09:31:49Z published: 2026-09-17T09:31:49Z canonical: "guide.ncloud-docs.com/k8s-troubleshoot-lb" stale: true --- > ## Documentation Index > Fetch the complete documentation index at: https://guide.ncloud-docs.com/llms.txt > Use this file to discover all available pages before exploring further. # ネットワーキング問題 VPC環境で利用できます。 Ncloud Kubernetes Serviceを利用しながら、以下のような問題が発生することがあります。問題ごとの原因と解決方法を確認し、適切に対処してください。 ## 作成していない Target Groupが存在 作成していない Target Groupが存在します。 #### 原因 ALBとマッピングされた Ingress Manifest内の spec.defaultBackendが指定されていない場合、ワーカーノードグループの80ポートに設定された Target Groupが作成されます。この Target Groupは ALBの動作に影響を与えず意図した動作です。 #### 解決方法 原因の説明の通り意図された動作なので、特に対策する必要はありません。 ## NetworkPolicyエラー NetworkPolicyが正常に動作しません。 #### 原因 Cilium CNIを使用する場合、NetworkPolicyの機能の中には[既知の未対応機能](https://docs.cilium.io/en/latest/network/kubernetes/policy/#networkpolicy-state)があります。 #### 解決方法 既知の未対応機能は、次の通りです。 - [pod IPを利用した ipBlock](https://github.com/cilium/cilium/issues/9209) - [SCTP Protocol](https://github.com/cilium/cilium/issues/5719) - [Port範囲(endPort)](https://github.com/cilium/cilium/issues/16622) ## Ciliumの Connectivity Testに失敗 Ciliumの Connectivity Testに失敗します。 #### 原因 Ciliumは、ネットワーク状態をテストするための [Connectivity Test](https://github.com/cilium/cilium/tree/master/examples/kubernetes/connectivity-check)を提供します。Ncloud Kubernetes Serviceでこのテストセットをそのまま実行する場合、以下の2件のテストに失敗します。これは link-local ipにバインドされた node-local-dnsを使用する場合に発生する[既知の不具合](https://github.com/cilium/cilium/issues/18644)です。 #### 解決方法 有効な 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のステータスを点検してください。関連リソースとログを照会するコマンドは、次の通りです。 参考 - ハイパーバイザが KVMであるクラスタには、ALB Ingress Controllerが基本的に含まれています。 - コントローラがユーザーに公開されないため、Ingressリソース照会によるエラーの確認が必要です。 ``` $ 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設定ガイド](/docs/ja/k8s-k8suse-albingress)を参照して、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](/docs/ja/vpc-subnetmanage-vpc)をご参照ください。クラスタに Public LB Subnetを登録した後、再試行してください。 **Private LBを作成する場合** - Kubernetesクラスタに Private LB Subnetが登録されているかご確認ください。 - 以下のアノテーションを利用しているかご確認ください。詳細は、[ALB Ingress Controller設定](/docs/ja/k8s-k8suse-albingress)をご参照ください。 `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クラウドプラットフォームポータルの[カスタマーサポート](https://www.ncloud.com/support/question/service)にお問い合わせください。 ## 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」の設定については、[公式ドキュメント](https://kubernetes.io/docs/ja/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)をご参照ください。 ## 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設定](/docs/ja/k8s-k8suse-albingress)で確認できます。 参考 本ガイドで必要な情報が見つからない場合やさらに必要な情報がある場合は、いつでも以下のフィードバックアイコンをクリックして、ご意見をお寄せください。いただいたご意見を参照して、より有益な情報を提供できるよう努力してまいります。