내용 x
      Kubernetes Service 문제 해결
        • 인쇄
        • PDF
        내용

        Kubernetes Service 문제 해결

          • 인쇄
          • PDF
          Article Summary

          VPC 환경에서 이용 가능합니다.

          Kubernetes Service를 이용하면서 사용자가 만날 수 있는 문제 상황과 원인 및 해결 방법을 안내합니다. 하지만 일부 문제 상황은 다음 안내를 숙지하여도 사용자가 직접 해결하기 어려운 과제일 수 있습니다. 이러한 사용자의 어려움을 효율적으로 해결하고자 네이버 클라우드 플랫폼은 다양한 문제 해결 창구도 함께 제공하고 있습니다.

          Kubernetes Service 구성 관련

          Q. Kubernetes Service의 Control Plane(마스터) 노드의 스펙이 궁금합니다.
          A. Kubernetes Service는 Control Plane HA를 지원하고 있습니다. Control Plane 노드는 총 3대로 구성되며 스펙은 클러스터의 최대 노드수에 따라 정해집니다.

          최대 노드 수스펙개수
          102vCPU / 8GB Memory / 50GB SSD3EA
          504vCPU / 16GB Memory / 50GB SSD3EA

          Q. Kubernetes Service를 통해 클러스터 구성 시 파드, 서비스 대역이 궁금합니다.
          A. Kubernetes Service는 클러스터 네트워크로 아래 대역을 제공합니다.

          이름CIDR
          파드198.18.0.0/16
          서비스198.19.128.0/17

          Q. Kubernetes Service를 통해 클러스터 구성 시 사용할 수 있는 노드 포트 대역이 궁금합니다.
          A. Kubernetes Service는 노드포트 대역으로 기본 대역인 30000-32767를 제공합니다.

          Q. Kubernetes Service의 워커노드로 GPU 노드를 사용하고 싶습니다.
          A. Kubernetes Service에서 GPU 타입의 워커노드를 사용할 수 있습니다. 하지만 클러스터의 기본 요소의 실행을 위하여 GPU 노드가 포함 된 노드 풀 이외에 일반 노드풀이 존재해야 합니다.

          Q. Kubernetes Service의 노드에게 특정 아이피를 부여하고 싶습니다.
          A. Kubernetes Service 구성 노드의 아이피는 내부 규칙을 통해 부여됩니다. 별도 아이피는 부여할 수 없습니다.

          Q. Kubernetes Service 구성 시 선택한 클러스터 최대 노드 수를 변경하고 싶습니다.
          클러스터 생성 시 선택한 최대 노드 수의 변경은 불가능합니다. 클러스터 생성 시 신중하게 클러스터 최대 노드 수를 선택하여야 합니다.

          클러스터 관련

          Q. Kubernetes Service의 클러스터가 오랜 시간 동안 작업 중을 유지합니다.
          A. Kubernetes Service가 신규 클러스터 생성 및 삭제, 워커 노드 스케일 인아웃, 업그레이드 중 오랜 시간 동안 작업 중 상태이면 네이버클라우드플랫폼 포털의 고객 문의로 문의해 주십시오.

          Q. Kubernetes Service의 워커노드가 Not Ready 상태를 보이고 있습니다.
          A. 워커노드가 Not Ready 인 경우 다양한 원인을 가지고 있습니다. 그 중 대부분은 워커노드의 높은 리소스 사용량으로 인해 발생합니다. 워커 노드의 리소스 사용량 확인 이후 워커 노드에 위치한 파드를 다른 워커노드로 스케줄링하거나 스케일을 줄여 리소스 사용량을 감소시킵니다. 이후 워커노드를 재기동하여 상태가 Ready로 변경되는지 확인합니다.
          높은 리소스 사용량으로 인해 워커노드에 문제가 생기는 것을 방지하기 위하여 아래 Kubernetes 기능 사용을 권장합니다.

          Q. Evict 상태를 가진 파드가 생성되었거나 생성되고 있습니다.
          A. Kubernetes의 컴포넌트인 kubelet은 노드의 자원을 모니터링 합니다. 모니터링 대상 노드 자원이 임계치에 도달하는 경우 kubelet은 파드를 능동적으로 중단시켜 자원을 회수합니다. Evict 상태의 경우 kubelet이 파드를 중단시킨 상태를 뜻합니다. 파드가 Evict 상태인 경우 노드의 자원을 모니터링하여 임계치 아래로 떨어뜨려야 합니다. Kubernetes Service의 임계값은 Kubernetes의 기본 설정을 따릅니다. 기타 자세한 내용은 아래의 공식 문서를 참고해 주십시오.

          Q. Kubernetes Service의 클러스터 생성 이후 Cilium-Operator 파드가 Pending 상태입니다.
          A. Kubernetes Service는 CNI인 Cilium의 안정적인 동작을 위하여 Operator의 개수가 2개로 설정되어 있습니다. 따라서 워커노드가 1개인 클러스터의 경우 한 개의 Cilium Operator가 Pending 상태를 가지게 됩니다. 이는 의도된 바이며 실제 Cilium의 동작에 영향을 끼치지 않습니다.

          Q. Cluster AutoScaler를 설정하였지만 Scale Up/Down이 발생하지 않습니다.
          A. Kubernetes Service에서 제공하는 Cluster Autoscaler 클러스터 내에 리소스 부족으로 인해 스케줄링되지 못한 파드가 존재할 때 노드를 증가시키며, 일정 시간 동안 특정 노드의 사용률이 저조한 경우 노드를 감소합니다. Cluster Autoscaler는 다양한 원인으로 동작하지 않을 수 있습니다.

          • 사용하고 있는 파드에 Resource Request, Limit 설정이 존재하지 않는 경우 동작하지 않습니다. 반드시 Resource Request&Limit 설정이 필요합니다.
          • HPA(Horizontal Pod Autoscaling)의 설정이 없는 경우 동작하지 않습니다. HPA를 통해 파드가 증가하며 생성된 파드의 리소스 요청량을 통해 Cluster Autoscaler가 동작합니다. HPA 설정을 통해 Cluster Autoscaler를 동작할 수 있습니다.
          • 노드 감소 예외 사항이 존재하는 경우 노드의 감소가 이루어지지 않을 수 있습니다. 아래와 같은 예외 사항이 존재합니다.
            • Controller(예: Deployment, StatefulSet .. )에 의해 제어되지 않는 경우
            • Local Storage가 설정되어 있는 경우
            • 다른 노드로 파드가 이동할 수 없는 경우
            • Annotation "cluster-autoscaler.kubernetes.io/safe-to-evict": "false"이 설정되어 있는 경우
            • 기타 예외 사항에 대해서는 공식 문서를 참고하십시오.

          Q. 파드 생성 시 ImagePullBackOff 상태가 발생합니다.
          A. ImagePullBackOff 상태는 파드가 사용할 이미지를 가져오지 못해 발생합니다. 아래 내용을 통해 원인을 파악한 이후 해결할 수 있습니다.

          • 이미지 명 및 태그가 잘못된 경우 이미지를 가져올 수 없습니다.
          • 프라이빗 레지스트리에서 이미지를 받아오는 경우 적합한 인증을 진행하지 못할 때 이미지를 가져올 수 없습니다. 알맞은 imagePullSecrets을 사용하였는지 확인이 필요합니다. Container Registry 상품을 사용하는 경우 사용 가이드를 통해 imagePullSecrets을 생성할 수 있습니다.
          • Private Subnet을 사용하는 Kubernetes Cluster의 경우 외부 이미지를 사용하기 위해 아웃바운드 트래픽이 활성화 되어 있어야 합니다. 활성화되어 있지 않은 경우 아래 과정을 통해 진행할 수 있습니다.
            • NAT Gateway (Old) 의 경우
              • 콘솔 > VPC > NAT Gateway (Old) 메뉴로 이동 후 NAT Gateway를 생성
              • 콘솔 > Products & Services > Networking > VPC > Route Table 메뉴로 이동
              • 인터넷 통신이 필요한 Private Subnet의 라우트 테이블을 선택하고, [Routes 설정] 버튼을 클릭
              • 외부 통신을 위한 라우트 규칙을 추가
                • Destination: 목적지 공인 IP 주소를 CIDR 형태로 입력 (예를 들어 인터넷 전체가 통신 대상이라면 0.0.0.0/0으로 입력)
                • Target Type: 목적지와 통신하기 위한 다음 Hop 타입을 선택 (NAT Gateway)
                • Target Name: 생성한 NAT Gateway 이름을 선택
                • [+생성] 버튼을 클릭하여 정상적으로 규칙 추가 및 반영
            • NAT Gateway (New)의 경우
              • 콘솔 > VPC > Nat Gateway (New) 메뉴로 이동 후 공인 NAT Gateway를 생성
              • 콘솔 > VPC > Route Table 메뉴로 이통 후 NAT Gateway 를 통해 통신할 네트워크 경로 설정
          • DockerHub 이미지 다운로드 정책에 의해 제한되었을 경우 이미지를 정상적으로 이용할 수 없습니다. 대량 이용을 위한 지불 계정을 사용하시거나 프라이빗 레지스트리를 이용해야 합니다.

          Q. kubectl drain 명령어가 수행되지 않습니다.
          A. kubectl drain 명령어는 대상 워커 노드의 파드가 아래 경우에 속하는 경우 동작하지 않으며, 각 원인에 따른 해결 방법은 아래와 같습니다.

          • emptyDir를 사용하여 로컬 데이터를 저장하는 파드가 해당 워커 노드에 있는 경우, 이 파드를 삭제하면 해당 로컬 데이터 또한 삭제되므로 명령어가 실행되지 않습니다. 해당 파드가 제거되어도 문제가 없다면 --delete-local-data 플래그를 drain 명령어에 추가하여 실행하십시오.
          • DaemonSet에 속한 파드가 해당 워커 노드에서 구동되고 있는 경우 kubectl drain 명령이 수행되지 않습니다. DaemonSet 컨트롤러는 unschedulable 상태를 무시하고 노드에 파드를 스케줄하여 배치할 수 있습니다. --ignore-daemonsets 플래그를 추가하여 DaemonSet에 속한 파드들을 축출 대상에서 제외하십시오.
          • Deployment, Statefulset, DaemonSet, ReplicaSet, Job 등 컨트롤러가 관리하지 않는 파드가 해당 워커 노드에 있는 경우, 해당 파드를 보호하기 위해 kubectl drain 명령어가 동작되지 않습니다. kubectl drain 명령어를 --force 옵션을 통해 실행하여 해당 파드를 클러스터에서 제거하십시오. 제거된 해당 파드들은 다시 스케줄링되지 않습니다.

          Q. Kubernetes Service에서 HELM을 사용하고 싶습니다.
          HELM 3을 통해 사용 중인 Kubernetes Cluster에 패키지 관리를 진행할 수 있습니다. 설치 및 이용 방법은 HELM 공식 문서를 참고하십시오.

          • https://helm.sh/docs

          Q. ncp-iam-authenticator를 통해 Kubernetes Cluster에 접근 할 수 없습니다.
          ncp-iam-authenticator의 이용 도중 발생하는 에러 메시지를 통해 원인 분석이 가능합니다.

          • Cluster is undefined (400) : 올바르지 않은 클러스터 UUID가 입력되는 경우 발생합니다.
          • Authentication Failed (200) : 올바르지 않은 인증키 값을 사용할 때 발생합니다. ncp-iam-authenticator은 ~/.ncloud/configure 이하의 인증키 값을 사용하며 만료된 인증키, 삭제된 인증키, 사용 중지 된 인증키, 잘못 기재된 인증키 아닌지 확인이 필요합니다.
          • Not Found Exception (404) : ncloud_api_url 과 region 값의 확인이 필요합니다.
          • You must be logged in to the server (Unauthorized) : 계정(서브어카운트)이 클러스터에 관련 권한을 가지고 있지 않을 때 발생합니다. 클러스터 생성 시 메인 계정, 클러스터 생성 계정은 system:masters 그룹으로 자동설정되나 이외 계정은 별도 권한 설정이 필요합니다. IAM 인증 사용자 관리를 통해 접근 계정에 대해 권한 설정을 진행하십시오.

          Q. Kubernetes Service 클러스터 워커노드에 NTP 설정을 하고 싶습니다.
          Kubernetes Service의 워커 노드는 시간 동기화를 위해 NTP 서버를 설정할 수 있습니다. 자세한 내용은 FAQ 문서를 참고하시기 바랍니다.

          Q. Kubernetes Service를 통해 생성 된 클러스터에서 스토리지를 사용하고 싶습니다.
          Kubernetes Service는 네이버 클라우드 플랫폼의 Block Storage, NAS 상품과 연동이 가능한 CSI를 기본 제공하고 있습니다. 클러스터 생성 이후 별도 설정 진행 없이 스토리지 상품의 이용이 가능합니다. 자세한 사용 방법은 각 가이드 문서를 참고해 주십시오.

          Q. NAS CSI 사용 시 ACL 설정 방법이 궁금합니다.
          Kubernetes Service는 NAS CSI를 기본 제공하고 있습니다. NAS CSI는 동적으로 NAS ACL에 워커노드를 등록해주므로 수동으로 설정하지 않아도 됩니다.

          Q. 클러스터에서 미사용 중인 스토리지가 블록스토리지에 존재합니다.
          다음 3가지 원인으로 인해 사용하지 않는 'pvc-*'로 시작하는 블록 스토리지가 존재할 수 있습니다. 아래 내용을 확인하시고, 해당 원인에 따른 적절한 조치를 진행하시기 바랍니다.

          • 클러스터 내부에 미사용 중인 PVC 가 존재하는 경우 : 파드 및 스토리지를 생성하신 이후 관련 파드는 삭제되었으나 PVC는 삭제되지 않은 경우 블록 스토리지는 "사용 가능" 상태로 남아 있습니다. StorageClass의 relcaimpolicy가 "Delete"인 경우 PVC가 삭제될 때 PV 및 연결된 블록스토리지가 같이 삭제됩니다. 해당 PVC를 사용하지 않는 경우 PVC 삭제를 통해 블록스토리지의 삭제가 가능합니다.
          • 반납한 클러스터에서 사용 했던 스토리지인 경우 : 클러스터 반납 시 관련 리소스를 함께 반납하지 않으므로 클러스터 반납 이전/이후 PVC 및 스토리지의 확인이 필요합니다. 해당 리소스는 다시 사용하지 않으시는 경우 삭제 하시면 됩니다.
          • PV가 PVC 보다 먼저 삭제 된 경우: PVC 삭제 이전 PV가 삭제되는 경우 스토리지가 정상 반납되지 않습니다. reclaimpolicy 정책 설정에 따라 PVC 삭제 시 자동으로 스토리지의 반납을 진행하지만 PV가 먼저 삭제되는 경우 스토리지의 반납이 이루어지지 않습니다. 해당 리소스는 다시 사용하지 않으시는 경우 삭제 하시면 됩니다.

          로드밸런서 관련

          Q. Kubernetes Service에서 로드밸런서를 사용하고 싶습니다.
          A. Kubernetes Service는 Service 리소스의 타입이 LoadBalancer 인 경우 기본적으로 Network Proxy LoadBalancer를 생성하며, 어노테이션을 통해 Network LoadBalancer를 생성할 수 있습니다.

          Application LoadBalancer의 경우 Application LoadBalancer Controller의 설치가 필요하며 Ingress 타입의 리소스 생성 시 1:1 매칭으로 생성됩니다.
          자세한 내용은 관련 가이드 문서 참고바랍니다.

          Q. LoadBalancer 타입의 서비스 리소스 생성 이후 Pending 상태를 유지하고 있습니다.
          A. 클러스터 생성 시 선택한 로드밸런서 서브넷을 삭제하시거나 할당 가능한 아이피가 없는 경우 External-IP를 할당받지 못합니다. 아래 과정을 통해 기본 로드밸런서 서브넷을 변경하거나 다른 로드밸런서 서브넷을 선택할 수 있습니다.

          • 기본 로드밸런서 서브넷을 변경할 수 있습니다.
            • 아래 명령어를 실행하여 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
            • 아래를 참고하여 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
    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.lbSubnetNo: 워커 노드가 할당된 VPC 내 Load Balancer 전용 서브넷의 SubnetID를 입력하십시오.
            • data.regionCode: 워커 노드가 위치한 리전 코드를 입력하십시오. (예: "FKR")
            • data.regionNo: 워커 노드의 리전 번호를 입력하십시오. (예: "11")
            • data.vpcNo: 워커 노드가 할당된 VPC의 VPC ID를 입력하십시오.
            • data.zoneNo: 워커 노드가 위치한 존 번호를 입력하십시오. (예: "110")
            • 아래 명령어를 실행하여 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가 정상적으로 생성되지 않습니다.
            • 변경 완료 후 아래 명령어를 실행하여 configmap에 변경 사항이 적용되었는지 확인해 주십시오.
            $ kubectl --kubeconfig $KUBE_CONFIG get configmap ncloud-config -n kube-system -o yaml

          Q. Ingress와 연결된 ALB(ApplicationLoadBalancer)가 정상적으로 생성되지 않거나, 동작하지 않습니다.
          A. 아래 해결 방법은 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가 생성되지 않습니다. ALB Ingress Controller 설정 가이드의 참고를 통해 ALB Ingress Controller를 클러스터에 설치할 수 있습니다.
          • Ingress Manifest에 에러가 있는 경우 ALB가 생성되지 않거나 관련 룰이 생성되지 않습니다. ALB Ingress Controller의 파드 로그 조회를 통해 원인을 확인할 수 있습니다.
            • Manifest 내의 룰과 생성된 ALB의 룰이 일치하지 않는 경우
            • 올바른 어노테이션을 사용하지 않는 경우
            • Manifest 룰에 기재된 서비스의 이름과 포트가 잘못 기재된 경우
            • 룰 순서가 올바르지 않은 경우 (최상단의 룰이 가장 먼저 적용)
          • 생성된 ALB를 콘솔 혹은 API를 통해 변경하는 경우 문제가 발생할 수 있습니다. ALB Ingress Controller를 통해 생성된 ALB의 경우 Kubernetes 클러스터 내에 등록된 Ingress의 Manifest와 주기적으로 동기화를 진행합니다. 가급적 콘솔 및 API를 통한 변경을 지양하여야 하며 변경 시 Manifest의 재적용을 통해 상태 동기화를 진행하여야 합니다.

          Q. 생성하지 않은 Target Group이 존재합니다.
          A. ALB와 매핑 된 Ingress Manifest 내의 spec.defaultBackend 가 지정되지 않은 경우 워커노드 그룹의 80 포트로 설정된 Target Group 이 생성됩니다. 해당 Target Group은 ALB의 동작에 영향을 주지 않으며 의도 된 동작입니다.

          Q. 고정된 로드밸런서 아이피를 사용하고 싶습니다.
          A. Kubernetes Service는 현재 로드밸런서 아이피 고정 기능을 제공하고 있지 않습니다. 로드밸런서와 연결 된 서비스, 인그레스의 수정을 통해 로드밸런서를 삭제하지 않고 사용할 수 있습니다. 해당 기능은 추후 제공 될 예정입니다.

          Q. Kubernetes Service 클러스터를 통해 생성된 로드밸런서의 삭제가 진행되지 않습니다.
          Global DNS에 로드밸런서를 등록한 경우 로드밸런서의 삭제가 진행되지 않습니다. Global DNS에서 해당 로드밸런서의 등록 여부를 확인 후 설정 해제 시 해당 로드밸런서의 삭제가 진행됩니다.

          네트워크 관련

          Q. NetworkPolicy 가 정상적으로 작동하지 않습니다.
          Cilium CNI 를 사용하는 경우 NetworkPolicy 의 기능 중 아래와 같이 알려진 미지원 기능들이 있습니다.

          Q. Cilium 의 Connectivity Test 가 실패합니다.
          Cilium 은 network 상태를 테스트하기 위한 Connectivity Test셋을 제공하고 있습니다. Kubernetes Service 에서 해당 테스트 셋을 그대로 실행할 경우 아래 두 건의 테스트가 실패합니다.
          image.png
          이는 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
          이 문서가 도움이 되었습니까?
          What's Next