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

간략한 설명

---

Network Load Balancer의 대상이 비정상적인 이유는 일반적으로 다음과 같습니다.

• 상태 확인이 잘못 구성되었습니다.
• 포드에서 예상치 못한 예외가 발생했습니다.
• DHCP에서 사용자 지정 Amazon VPC DNS 옵션이 설정되었으며 externalTrafficPolicy가 적용된 로컬 설정 Network Load Balancer. 

해결 방법

대상 그룹이 IP 주소 또는 인스턴스인지 확인하세요.

다음 명령을 실행합니다.

kubectl get service service_name -o yaml

참고: service_name을 사용자의 서비스 명칭으로 바꾸세요.

service.beta.kubernetes.io/aws-load-balancer-nlb-target-type 주석이 없는 경우 기본 대상 유형은 인스턴스입니다.

상태 확인이 올바르게 구성되었는지 확인하세요

서비스에 어떤 Elastic Load Balancing(ELB) 주석이 구성되어 있는지 확인하세요. 주석에 대한 자세한 내용은 Kubernetes 웹사이트에서 서비스를 참조하세요.

다음 명령을 실행하여 주석 목록을 가져오세요.

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 for HTTP(S) protocols

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

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를 애플리케이션이 컨테이너 내에서 수신하는 포트의 이름으로 바꾸세요.

포드에서 예상치 못한 예외가 발생했는지 확인하세요

인스턴스 대상 유형

1. 서비스 사양에서 현재 상태 확인 구성 주석을 확인하세요. 전체 목록은 GitHub 웹사이트에서 상태 확인 구성 주석을 참조하세요.

   kubectl get service service_name -o yaml

2. 엔드포인트가 있는지 확인하여 서비스의 뒤에 포드가 있는지 확인하세요.

   kubectl get endpoints service_name -o yaml

3. 서비스에 대한 엔드포인트가 없는 경우 포드 레이블과 서비스 레이블이 일치하는지 확인하세요.

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

   참고: pod_name을 포드 이름으로 바꾸세요.

4. 포드가 실행 중 상태인지 확인하세요.

   kubectl get pod -o wide

5. 포드 상태를 확인하여 재시작하지 않고 포드를 실행할 수 있는지 확인하세요.

   kubectl get pods -o wide

6. 재시작이 이루어진 경우 포드 로그를 수집하여 원인을 파악하세요.

   kubectl logs pod_namekubectl logs pod_name --previous

7. 노드와 통신할 수 있는 Amazon VPC의 호스트 머신에 로그인하세요. 그런 다음 curl 명령을 NodePort와 함께 사용하여 포드가 예상 HTTP 상태 코드를 반환하는지 확인하세요.

   curl node_IP:NodePort

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

8. 동일한 호스트 머신을 사용하여 포드의 IP 주소에 연결하고 포드가 올바르게 구성되었는지 확인하세요.

   curl pod_IP:pod_port

   curl 명령이 예상 HTTP 상태 코드를 반환하지 않으면 포드가 제대로 구성되지 않은 것입니다.

**참고:**서비스의 externalTrafficPolicy(Kubernetes 웹사이트 출처)가 Local로 설정된 경우, 서비스의 백엔드 포드가 실행되는 노드만 정상적인 대상으로 간주됩니다.

IP 주소 대상 유형

1. 서비스 사양에서 현재 상태 확인 구성 주석을 확인하세요. 목록을 확인하려면 GitHub 웹사이트에서 상태 확인 구성 주석을 참조하세요.

   kubectl get service service_name -o yaml

2. Amazon VPC의 호스트 머신에 로그인하고 curl 명령을 사용하여 포드의 IP 주소와 통신하세요.

   curl pod_IP:pod_port

   curl 명령이 예상 HTTP 상태 코드를 반환하지 않으면 포드가 제대로 구성되지 않은 것입니다.