Amazon EKS에서 로드 밸런서의 상태 확인에 실패하는 문제를 해결하려면 어떻게 해야 하나요?

해결 방법

Amazon EKS의 로드 밸런서 상태 확인 문제를 해결하려면 다음 섹션에 안내된 단계를 따르세요.

포드 상태 확인

포드가 실행 중이고 포드 내 컨테이너가 준비 상태인지 확인합니다.

$ kubectl get pod -n YOUR_NAMESPACE

참고: YOUR_NAMESPACE을 내 Kubernetes 네임스페이스로 바꾸세요.

출력 예시:

NAME                           READY   STATUS    RESTARTS   AGEpodname                        1/1     Running   0          16s

포드 상태의 애플리케이션 컨테이너가 실행 중이 아니면 로드 밸런서 상태 확인에 응답이 없고 확인이 실패합니다.

포드 및 서비스 레이블 선택기 확인

포드 레이블의 경우 다음 명령을 실행하세요.

$ kubectl get pod -n YOUR_NAMESPACE --show-labels

출력 예시:

NAME                           READY   STATUS    RESTARTS   AGE     LABELSalb-instance-6cc5cd9b9-prnxw   1/1     Running   0          2d19h   app=alb-instance,pod-template-hash=6cc5cd9b9

Kubernetes Service가 포드 레이블을 사용하는지 확인하려면 다음 명령을 실행해해 출력이 포드 레이블과 일치하는지 확인하세요.

$ kubectl get svc SERVICE_NAME -n YOUR_NAMESPACE -o=jsonpath='{.spec.selector}{"\n"}'

참고: SERVICE_NAME을 내 Kubernetes 서비스로 바꾸고 YOUR_NAMESPACE를 내 Kubernetes 네임스페이스로 바꾸세요.

출력 예시:

{"app":"alb-instance"}

엔드포인트가 누락되었는지 확인

서비스 선택기용 Kubernetes 컨트롤러는 선택기와 일치하는 포드를 지속적으로 스캔하고 엔드포인트 개체 업데이트를 게시합니다. 잘못된 레이블을 선택한 경우 엔드포인트가 나타나지 않습니다.

다음 명령을 실행하세요.

$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE

출력 예시:

Name:                     alb-instanceNamespace:                default
Labels:                   <none>
Annotations:              <none>
Selector:                 app=alb-instance-1      
Type:                     NodePort
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.100.44.151
IPs:                      10.100.44.151
Port:                     http  80/TCP
TargetPort:               80/TCP
NodePort:                 http  32663/TCP
Endpoints:                <none>                 
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

엔드포인트가 누락되었는지 확인하세요.

$ kubectl get endpoints SERVICE_NAME -n YOUR_NAMESPACE

출력 예시:

NAME           ENDPOINTS                                AGEalb-instance   <none>                                   2d20h

서비스 트래픽 정책과 클러스터 보안 그룹에 Application Load Balancers 관련 문제가 있는지 확인합니다.

Application Load Balancer 대상 그룹에 정상적이지 않은 대상이 있을 경우 보통 다음 두 가지 이유로 발생합니다.

• 서비스 트래픽 정책인 spec.externalTrafficPolicy가 클러스터가 아니라 로컬로 설정되어 있습니다.
• 클러스터의 노드 그룹에는 다른 클러스터 보안 그룹이 연결되어 있으며 노드 그룹 간에 트래픽이 자유롭게 흐르지 않습니다.

트래픽 정책이 올바르게 구성되었는지 확인하세요.

$ kubectl get svc SERVICE_NAME -n YOUR_NAMESPACE -o=jsonpath='{.spec.externalTrafficPolicy}{"\n"}'

출력 예시:

Local

설정을 클러스터로 변경하세요.

$ kubectl edit svc SERVICE_NAME -n YOUR_NAMESPACE

클러스터 보안 그룹 확인

다음 단계를 완료하세요.

1. Amazon EC2 콘솔을 엽니다.
2. 정상 인스턴스를 선택합니다.
3. 보안 탭을 선택하고 보안 그룹 수신 규칙을 확인하세요.
4. 비정상 인스턴스를 선택하세요.
5. 보안 탭을 선택하고 보안 그룹 수신 규칙을 확인하세요.
   각 인스턴스의 보안 그룹이 다른 경우 보안 그룹 콘솔에서 보안 그룹 수신 규칙을 수정해야 합니다.
   보안 탭에서 보안 그룹 ID를 선택합니다.
   수신 규칙 편집을 선택하고 수신 규칙을 수정하세요.
   클러스터의 다른 노드 그룹에서 오는 트래픽을 허용하는 인바운드 규칙을 추가합니다.

서비스가 targetPort에 맞게 구성되어 있는지 확인합니다.

내 TargetPort가 서비스가 트래픽을 보내는 포드의 containerPort와 일치해야 합니다.

TargetPort의 구성을 확인하려면 다음 명령을 실행하세요.

$ kubectl get svc  SERVICE_NAME -n YOUR_NAMESPACE -o=jsonpath="{.items[*]}{.metadata.name}{'\t'}{.spec.ports[].targetPort}{'\t'}{.spec.ports[].protocol}{'\n'}"

출력 예시:

alb-instance    8080    TCP

출력 예시에서 targetPort가 8080으로 구성되어 있습니다. 그러나 containerPort가 80으로 설정되어 있기 때문에 targetPort를 80으로 구성해야 합니다.

AWS Load Balancer Controller에 올바른 권한이 있는지 확인

AWS Load Balancer Controller에 보안 그룹을 업데이트할 수 있는 올바른 권한이 있어야 로드 밸런서에서 인스턴스나 포드로 향하는 트래픽을 허용할 수 있습니다. 컨트롤러에 올바른 권한이 없으면 오류가 발생합니다.

AWS Load Balancer Controller 배포 로그에 오류가 있는지 확인하세요.

$ kubectl logs deploy/aws-load-balancer-controller -n kube-system

개별 컨트롤러 포드 로그에서 오류 확인:

$ kubectl logs CONTROLLER_POD_NAME -n YOUR_NAMESPACE

참고:****CONTROLLER_POD_NAME을 내 컨트롤러 포드 이름으로 바꾸고 YOUR_NAMESPACE을 내 Kubernetes 네임스페이스로 바꾸세요.

수신 주석에서 Application Load Balancer와 관련한 문제가 있는지 확인

Application Load Balancer와 관련한 문제는 Kubernetes 수신 주석을 확인하세요.

$ kubectl describe ing INGRESS_NAME -n YOUR_NAMESPACE

참고:****INGRESS_NAME을 내 Kubernetes Ingress로 바꾸고 YOUR_NAMESPACE를 내 Kubernetes 네임스페이스로 변경하세요.

출력 예시:

Name:             alb-instance-ingressNamespace:        default
Address:          k8s-default-albinsta-fcb010af73-2014729787.ap-southeast-2.elb.amazonaws.com
Default backend:  alb-instance:80 (192.168.81.137:8080)
Rules:
  Host          Path  Backends
  ----          ----  --------
  awssite.cyou
                /   alb-instance:80 (192.168.81.137:8080)
Annotations:    alb.ingress.kubernetes.io/scheme: internet-facing        
                kubernetes.io/ingress.class: alb                         
Events:
  Type    Reason                  Age                  From     Message
  ----    ------                  ----                 ----     -------
  Normal  SuccessfullyReconciled  25m (x7 over 2d21h)  ingress  Successfully reconciled

내 사용 사례에 맞는 수신 주석을 찾으려면 Kubernetes 웹 사이트에서 Ingress 주석을 참고하세요.

Network Load Balancer와 관련한 문제는 Kubernetes Service를 확인하세요.

Network Load Balancer와 관련한 문제는 Kubernetes Service 주석을 확인하세요.

$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE

출력 예시:

Name:                     nlb-ipNamespace:                default
Labels:                   <none>
Annotations:              service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip              
                          service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing          
                          service.beta.kubernetes.io/aws-load-balancer-type: external                   
Selector:                 app=nlb-ip
Type:                     LoadBalancer
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.100.161.91
IPs:                      10.100.161.91
LoadBalancer Ingress:     k8s-default-nlbip-fff2442e46-ae4f8cf4a182dc4d.elb.ap-southeast-2.amazonaws.com
Port:                     http  80/TCP
TargetPort:               80/TCP
NodePort:                 http  31806/TCP
Endpoints:                192.168.93.144:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

**참고:**추후 단계에서 상태 확인 명령을 실행하기 위해 APPLICATION_POD_IP 값을 기록해 두세요.

내 사용 사례에 맞는 Kubernetes Service 주석을 찾으려면 Kubernetes 웹 사이트의 Service 주석을 참고하세요.

상태 확인을 수동으로 테스트

애플리케이션 포드 IP 주소 확인:

$ kubectl get pod -n YOUR_NAMESPACE -o wide

클러스터에서 수동으로 상태 확인을 테스트하려면 테스트 포드를 실행하세요.

$ kubectl run -n YOUR_NAMESPACE troubleshoot -it --rm --image=amazonlinux -- /bin/bash

그리고 HTTP 상태 검사를 실행하세요.

# curl -Iv APPLICATION_POD_IP/HEALTH_CHECK_PATH

참고: APPLICATION_POD_IP을 내 애플리케이션 포드 IP 주소로 바꾸고 APPLICATION_POD_IP를 Application Load Balancer 대상 그룹 상태 확인 경로로 바꾸세요.

명령 예시:

# curl -Iv 192.168.81.137

출력 예시:

* Trying 192.168.81.137:80...* Connected to 192.168.81.137 (192.168.81.137) port 80 (#0)
> HEAD / HTTP/1.1
> Host: 192.168.81.137
> User-Agent: curl/7.78.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: nginx/1.21.3
Server: nginx/1.21.3
< Date: Tue, 26 Oct 2021 05:10:17 GMT
Date: Tue, 26 Oct 2021 05:10:17 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 615
Content-Length: 615
< Last-Modified: Tue, 07 Sep 2021 15:21:03 GMT
Last-Modified: Tue, 07 Sep 2021 15:21:03 GMT
< Connection: keep-alive
Connection: keep-alive
< ETag: "6137835f-267"
ETag: "6137835f-267"
< Accept-Ranges: bytes
Accept-Ranges: bytes

<
* Connection #0 to host 192.168.81.137 left intact

HTTP 응답 상태 코드를 확인하세요. 응답 상태 코드가 200 OK인 경우 애플리케이션이 상태 확인 경로에 바르게 응답한 것입니다.

HTTP 응답 상태 코드가 3xx나 4xx인 경우 상태 확인 경로를 변경하세요. 다음 주석의 경우200 OK로 응답합니다.

alb.ingress.kubernetes.io/healthcheck-path: /ping

-또는-

성공적인 상태 확인 응답 상태 코드 범위를 추가하려면 수신 리소스에 다음 주석을 사용하세요.

alb.ingress.kubernetes.io/success-codes: 200-399

TCP 상태 확인의 경우 다음 명령을 사용해 netcat 명령을 설치하세요.

# yum update -y && yum install -y nc

TCP 상태 확인 테스트:

# nc -z -v APPLICATION_POD_IP CONTAINER_PORT_NUMBER

참고: APPLICATION_POD_IP를 내 애플리케이션 포드 IP 주소로 바꾸고 CONTAINER_PORT_NUMBER를 내 컨테이너 포트로 바꾸세요.

명령 예시:

# nc -z -v 192.168.81.137 80

출력 예시:

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.81.137:80.Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.

네트워킹 확인

네트워킹 문제의 경우 다음을 확인하세요.

• EKS 클러스터에 있는 여러 노드 그룹이 서로 자유롭게 통신합니다.
• 포드가 실행되는 서브넷과 연결된 네트워크 액세스 제어 목록(네트워크 ACL)이 로드 밸런서 서브넷 CIDR 범위의 트래픽을 허용합니다.
• 로드 밸런서 서브넷과 연결된 네트워크 ACL이 포드가 실행되는 서브넷의 임시 포트 범위에서 트래픽을 반환할 수 있도록 허용합니다.
• 라우팅 테이블이 VPC CIDR 범위 내의 로컬 트래픽을 허용합니다.

kube-proxy 다시 시작

각 노드에서 실행되는 kube-proxy가 제대로 작동하지 않으면 kube-proxy가 서비스 및 엔드포인트의 iptables 규칙을 업데이트하지 못할 수 있습니다. kube-proxy를 다시 시작해 강제로 iptables 규칙을 다시 확인하고 업데이트하도록 합니다.

kubectl rollout restart daemonset.apps/kube-proxy -n kube-system

출력 예시:

daemonset.apps/kube-proxy restarted

관련 정보

Amazon EKS에서 Amazon EC2 노드 그룹의 AWS 로드 밸런서 컨트롤러를 통해 Application Load Balancer를 설정하려면 어떻게 해야 하나요?

Amazon EKS에서 Kubernetes 서비스 컨트롤러를 이용해 생성한 로드 밸런서 문제를 해결하려면 어떻게 해야 하나요?

Amazon EKS에서 Application Load Balancer가 사용하는 서브넷을 자동으로 검색하려면 어떻게 해야 하나요?