Amazon EKS의 Network Load Balancer에 대상이 비정상인 문제를 해결하려면 어떻게 해야 하나요?

간략한 설명

Network Load Balancer의 대상이 비정상인 경우, 보편적인 이유는 다음과 같습니다.

• 상태 확인이 잘못 구성되었습니다. 이 문제를 해결하려면 Amazon Virtual Private Cloud(Amazon VPC) 내에서 실행되는 호스트 시스템에서 상태 확인을 수동으로 시작해야 합니다.
• 포드에 예기치 못한 예외 사항이 있습니다. 이 문제를 해결하려면 포드에 예기치 못한 예외 사항이 있는지 확인 해결 섹션의 문제 해결 단계를 따릅니다.
• externalTrafficPolicy가 Local로 설정된(Kubernetes 웹 사이트에서) Network Load Balancer에 DHCP 옵션 세트의 사용자 지정 Amazon VPC DNS가 있습니다. 이 문제를 해결하려면 kube-proxy를 hostname 재정의 플래그로 패치해야 합니다.

참고: 서비스 주석 service.beta.kubernetes.io/aws-load-balancer-nlb-target-type이 있는지 확인해 대상 그룹 유형이 IP 주소인지 인스턴스인지 판단할 수 있습니다.

해결 방법

대상 그룹이 IP 주소인지 인스턴스인지 확인

다음 명령을 실행합니다.

kubectl get service service_name -o yaml

참고: service_name을 해당 서비스 이름으로 바꿔야 합니다. service.beta.kubernetes.io/aws-load-balancer-nlb-target-type 주석이 없는 경우, 기본 대상 유형은 인스턴스입니다.

상태 확인이 올바로 구성되었는지 확인

서비스에 구성된 Elastic Load Balancing(ELB) 주석(Kubernets 웹 사이트에서)이 무엇인지 확인:

`kubectl get service service_name -o yaml`

출력 예:

service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: "2"
# The number of successive successful health checks required for a backend to be considered healthy for traffic. Defaults to 2, must be between 2 and 10

service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3"
# The number of unsuccessful health checks required for a backend to be considered unhealthy for traffic. Defaults to 6, must be between 2 and 10

service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20"
# The approximate interval, in seconds, between health checks of an individual instance. Defaults to 10, must be between 5 and 300

service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5"
# The amount of time, in seconds, during which no response means a failed health check. This value must be less than the service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval value. Defaults to 5, must be between 2 and 60

service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: TCP
service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: traffic-port
# can be integer or traffic-port

service.beta.kubernetes.io/aws-load-balancer-healthcheck-path
# health check path.

앞선 주석이 잘못 구성된 경우, 대상이 비정상일 수 있습니다.

Amazon VPC 내에서 실행 중인 호스트 시스템에서 상태 확인 수동으로 시작

인스턴스 대상 유형의 경우, 다음과 같은 NodePort를 포함한 curl 명령 실행:

curl-ivk node_IP:NodePort

참고: node_IP를 해당하는 노드의 IP 주소로 바꿔야 합니다.

IP 주소 유형의 경우, 다음과 같은 curl 명령 실행:

curl -ivk pod_IP:pod_port

참고: pod_IP를 해당하는 포드의 IP 주소로, pod_port를 포드의 포트로 바꿔야 합니다.

포드에 예기치 못한 예외 사항이 있는지 확인

인스턴스 대상 유형

현재 상태 확인 구성 주석의 서비스 사양 확인(GitHub 웹 사이트에서):

kubectl get service service_name -o yaml

엔드포인트가 있는지 확인하여 서비스 뒤에 포드가 있는지 확인:

kubectl get endpoints service_name -o yaml

서비스에 엔드포인트가 없는 경우, 포드 레이블과 서비스 레이블이 일치하는지 확인:

kubectl describe service
kubectl describe pod pod_name or kubectl get pod --show-labels

참고: pod_name을 포드 이름으로 바꿔야 합니다.

포드가 실행 중(Running) 상태인지 확인:

kubectl get pod -o wide

포드 상태를 확인하여 포드가 다시 시작하지 않고 실행 중인지 확인:

kubectl get pods -o wide

다시 시작한 적이 있었던 경우, 포드 로그를 수집하여 원인 파악:

kubectl logs pod_name
kubectl logs pod_name --previous

노드와 통신할 수 있는 Amazon VPC 내 호스트 시스템으로 로그인합니다.

NodePort를 포함한 curl 명령을 사용하여 포드가 예상한 HTTP 상태 코드를 반환하는지 확인:

curl node_IP:NodePort

curl 명령이 예상한 HTTP 상태 코드를 반환하지 않은 경우, 백엔드 포드도 예상한 HTTP 상태 코드를 반환하지 않습니다.

포드의 IP 주소에 연결하는 데 사용한 것과 같은 호스트 시스템을 사용하여 포드가 올바로 구성되었는지 확인합니다.

curl pod_IP:pod_port

curl 명령이 예상한 HTTP 상태 코드를 반환하지 않은 경우, 포드가 올바로 구성되지 않은 것입니다.

참고: 서비스의 externalTrafficPolicy(Kubernetes 웹 사이트에서)가 Local로 설정된 경우, 서비스의 백엔드 포드가 실행 중인 노드만 정상 대상으로 표시됩니다.

IP 주소 대상 유형

현재 상태 확인 구성 주석의 서비스 사양 확인(GitHub 웹 사이트에서):

kubectl get service service_name -o yaml

Amazon VPC의 호스트 시스템에 로그인하여 curl 명령을 사용해 포드의 IP 주소와 통신:

curl pod_IP:pod_port

curl 명령이 예상한 HTTP 상태 코드를 반환하지 않은 경우, 포드가 올바로 구성되지 않은 것입니다.

kube-proxy를 hostname 재정의 플래그로 패치

kube-proxy 데몬 세트 사양 명령, arg와 env를 다음으로 수정:

---
spec:
  template:
    spec:
      containers:
      - name: kube-proxy
        command: [ "/bin/sh" ]
        args:
        - -c
        - |
          kube-proxy --v=2 --hostname-override=$(NODE_NAME) --config=/var/lib/kube-proxy-config/config
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.nodeName

인스턴스 대상 유형의 경우, externalTrafficPolicy가 Cluster 또는 Local로 설정된 경우 노드 보안 그룹의 NodePort에 대한 기본 수신 설정은 0.0.0.0/0입니다. 또한 externalTrafficPolicy가 Local로 설정된 경우 서브넷 CIDR IP 주소 범위를 허용하도록 추가 상태 확인 NodePort가 하나 더 구성되어 있습니다.

노드 보안 그룹에서 NodePort에 대한 소스 IP 주소를 관리하려면 사양에 loadBalancerSourceRanges를 추가하고 범위를 포함합니다.

spec:
loadBalancerSourceRanges:
- "143.231.0.0/16"
- "xx.yy.zz.zz/24"

참고: .spec.loadBalancerSourceRanges가 설정되지 않은 경우 Kubernetes는 0.0.0.0/0부터 노드 보안 그룹까지 트래픽을 허용합니다. 노드에 퍼블릭 IP 주소가 있는 경우, Network Load Balancer가 아닌 트래픽도 변경된 보안 그룹의 모든 인스턴스에 도달할 수 있습니다.

---