--- title: "네트워킹 문제" slug: "k8s-troubleshoot-lb" updated: 2026-07-23T09:02:32Z published: 2026-07-23T09:02:32Z canonical: "guide-fin.ncloud-docs.com/k8s-troubleshoot-lb" --- > ## Documentation Index > Fetch the complete documentation index at: https://guide-fin.ncloud-docs.com/llms.txt > Use this file to discover all available pages before exploring further. # 네트워킹 문제 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){target="\_blank"}이 있습니다. #### 해결 방법 알려진 미지원 기능은 다음과 같습니다. - [pod IP 를 이용한 ipBlock](https://github.com/cilium/cilium/issues/9209){target="\_blank"} - [SCTP Protocol](https://github.com/cilium/cilium/issues/5719){target="\_blank"} - [Port 범위 (endPort)](https://github.com/cilium/cilium/issues/16622){target="\_blank"} ## Cilium의 Connectivity Test 실패 Cilium의 Connectivity Test에 실패합니다. #### 원인 Cilium은 네트워크 상태를 테스트하기 위한 [Connectivity Test](https://github.com/cilium/cilium/tree/master/examples/kubernetes/connectivity-check){target="\_blank"}셋을 제공합니다. Ncloud Kubernetes Service에서 해당 테스트셋을 그대로 실행할 경우, 다음 두 건의 테스트가 실패합니다. 이는 link-local ip에 바인딩된 node-local-dns를 사용할 경우, 발생하는 [이미 알려진 이슈](https://github.com/cilium/cilium/issues/18644){target="\_blank"}입니다. #### 해결 방법 정상적인 DNS 리졸빙을 위해 다음과 같이 `CiliumNetworkPolicy`에서 `toCIDR` 필드에 node-local-dns 가 사용하는 IP 대역을 추가해 주십시오. ```yaml # 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 서브넷을 삭제하거나 할당 가능한 아이피가 없는 경우, External-IP를 할당받지 못해서 발생하는 문제입니다. #### 해결 방법 기본 Load Balancer 서브넷을 변경하거나 다른 Load Balancer 서브넷을 선택해야 합니다. 기본 Load Balancer 서브넷을 변경하는 방법은 다음과 같습니다. 1. `kube-system` Namespace에서 `ncloud-config` 이름을 가지는 `configmap`을 확인해 주십시오. ```bash $ 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`을 확인한 후 수정해 주십시오. ```bash $ 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 전용 서브넷을 변경해 주십시오. ```bash $ 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`에 변경 사항이 적용되었는지 확인해 주십시오. ```bash $ kubectl --kubeconfig $KUBE_CONFIG get configmap ncloud-config -n kube-system -o yaml ``` ## Ingress와 연결된 ALB(Application Load Balancer) 오류 Ingress와 연결된 ALB (Application Load Balancer)가 정상적으로 생성되지 않거나, 동작하지 않습니다. #### 원인 - ALB Ingress Controller 파드가 동작하지 않거나, 내부 오류가 있을 수 있습니다. - ALB Ingress Controller가 존재하지 않는 경우, ALB가 생성되지 않습니다. - Ingress Manifest에 오류가 있는 경우 ALB가 생성되지 않거나 관련 룰이 생성되지 않습니다. - 콘솔 또는 API로 생성된 ALB를 변경하는 경우, 문제가 발생할 수 있습니다. - 클러스터 구성 워커노드의 상태가 운영중이 아닌 경우, 문제가 발생할 수 있습니다. #### 해결 방법 **리소스 및 로그 조회** ALB Ingress Controller를 통해 생성된 ALB의 상태를 점검해 주십시오. 관련 리소스와 로그를 조회하는 명령어는 다음과 같습니다. :::(Info) (참고) - 하이퍼바이저가 KVM인 클러스터는 ALB Ingress Controller가 기본으로 포함되어 있습니다. - 컨트롤러가 사용자에게 노출되지 않으므로 Ingress 리소스 조회를 통해 에러 확인이 필요합니다. ::: ```bash $ 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/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의 파드 로그 조회를 통해 원인을 확인해 주십시오. - 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/networking-vpc-vpcdetailedsubnet)를 참조해 주십시오. 클러스터에 Public LB Subnet 을 등록한 다음 다시 시도해주시기 바랍니다. **Private LB 생성 시** - Kubernetes 클러스터에 Private LB Subnet가 등록되어 있는지 확인해 주십시오. - 다음 어노테이션을 이용하고 있는지 확인해 주십시오. 더 자세한 내용은 [ALB Ingress Controller 설정](/docs/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 파일 설정은 변경하지 않도록 주의해 주십시오. 판단이 어려운 경우, 네이버 클라우드 플랫폼 포털에서 [고객 문의](https://www.ncloud.com/support/question/service){target="_blank"}로 문의해 주십시오. ## 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는 클러스터 내의 파드로 요청을 전송할 때 SNAT를 진행합니다. 이 과정에서 클라이언트의 실제 IP가 변경될 수 있습니다. #### 해결 방법 Ncloud 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/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip){target="\_blank"}를 참조해 주십시오. ## ALB 생성 시 타깃 그룹의 설정 변경 ALB 생성 시 타깃 그룹의 설정이 변경되지 않습니다. #### 원인 ALB의 룰로 지정한 Service에 관련 내용이 설정되어 있지 않아 문제가 발생할 수 있습니다. #### 해결 방법 Ingress의 백엔드로 지정되는 Service의 명세를 변경하여 설정할 수 있습니다. 어노테이션을 사용하면 Service를 통해 생성되는 타깃 그룹의 로드밸런싱 알고리즘, Health Check 설정이 가능합니다. 예를 들어 다음 내용처럼 지정하면 "naver" Service를 통해 생성된 타 그룹은 least-connection 알고리즘을 통해 로드밸런싱이 진행됩니다. ```yaml apiVersion: v1 kind: Service metadata: annotations: alb.ingress.kubernetes.io/algorithm-type: "least-connection" name: naver ``` Service, Ingress에서 사용 가능한 어노테이션의 경우 [ALB Ingress Controller 설정](/docs/k8s-k8suse-albingress)에서 확인할 수 있습니다. ## kube-proxy가 존재하지 않음 클러스터 조회 시 kube-system 네임스페이스에 kube-proxy가 존재하지 않습니다. #### 원인 KVM 타입의 Ncloud Kubernetes Service에서는 CNI (Container Network Interface)인 Cilium kube-proxy의 역할을 대신하여 네트워크 트래픽을 처리합니다. #### 해결 방법 원인에서 설명한 바와 같이 의도된 동작이므로 별도로 조치할 사항이 없습니다. :::(Info) (참고) 이 가이드에서 필요한 정보를 찾지 못했거나 추가로 필요한 정보가 있으신 경우, 언제든지 아래의 피드백 아이콘을 클릭하여 의견을 보내 주십시오. 전달해 주신 의견을 참고하여 더 유용한 정보를 제공하겠습니다. :::