네트워킹 문제

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에서 해당 테스트셋을 그대로 실행할 경우, 다음 두 건의 테스트가 실패합니다. 이는 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 서브넷을 삭제하거나 할당 가능한 아이피가 없는 경우, 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와 연결된 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의 상태를 점검해 주십시오. 관련 리소스와 로그를 조회하는 명령어는 다음과 같습니다.

$ 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의 파드 로그 조회를 통해 원인을 확인해 주십시오.

• 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 파일 설정은 변경하지 않도록 주의해 주십시오. 판단이 어려운 경우, 네이버 클라우드 플랫폼 포털에서 고객 문의로 문의해 주십시오.

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" 설정 내용은 공식 문서를 참조해 주십시오.

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 설정에서 확인할 수 있습니다.

kube-proxy가 존재하지 않음

클러스터 조회 시 kube-system 네임스페이스에 kube-proxy가 존재하지 않습니다.

원인

KVM 타입의 Ncloud Kubernetes Service에서는 CNI (Container Network Interface)인 Cilium kube-proxy의 역할을 대신하여 네트워크 트래픽을 처리합니다.

해결 방법

원인에서 설명한 바와 같이 의도된 동작이므로 별도로 조치할 사항이 없습니다.