Amazon EKS의 AWS Load Balancer Controller 오류를 해결하려면 어떻게 해야 합니까?

해결 방법

수신 객체 만들기 오류

수신 객체를 만들려고 하는데 웹후크 서비스를 잘못 구성했거나 서비스 인증서가 만료된 경우, 다음 중 한 가지 오류 메시지가 표시될 수 있습니다.

"Error from server (InternalError): error when creating "sample.yaml": Internal error occurred: failed calling webhook "mservice.elbv2.k8s.aws": failed to call webhook: Post "https://aws-load-balancer-webhook-service.default.svc:443/mutate-v1-service?timeout=10s": no endpoints available for service "aws-load-balancer-webhook-service""

"Internal error occurred: failed calling webhook "vingress.elbv2.k8s.aws ": Post "https://aws-load-balancer-webhook-service.kube-system.svc:443/validate-networking-v1beta1-ingress?timeout=10s ": x509: certificate has expired or is not yet valid"

이러한 문제를 해결하려면 AWS Load Balancer Controller 배포 상태를 확인하고 서비스 구성을 확인하고, 인증서 만료 날짜를 검증하십시오.

근본 원인을 찾아 오류를 해결하려면 다음 단계를 완료하십시오.

1. 다음 명령을 실행하여 aws-load-balancer 포드가 올바로 실행되는지 확인합니다.

   kubectl get pods -n kube-system | grep aws-load-balancer

   출력 예시:

   aws-load-balancer-controller-df9b89cf7-hbsrd    1/1       Running    0    26d

2. 다음 명령을 실행하여 aws-load-balancer-webhook-service가 존재하고 aws-load-balancer의 엔드포인트가 존재하는지 확인합니다.

   kubectl get svc -n kube-system

   출력 예시:

   NAME TYPE                           CLUSTER-IP                EXTERNAL-IP  PORT(S)    AGE
   aws-load-balancer-webhook-service   ClusterIP 10.100.219.187  "none"       443/TCP    86d

   출력에서 aws-load-balancer-webhook-service가 나열되어 있는지 확인하고, 유효한 CLUSTER-IP 주소를 할당했는지 확인하십시오. PORT에 웹후크 통신용으로 443/TCP가 표시되는지 확인합니다.

3. 다음 명령을 실행하여 서비스를 올바로 연결했는지 확인합니다.

   kubectl get ep -n kube-system

   출력 예시:

   NAME                                ENDPOINTS          AGE
   aws-load-balancer-webhook-service   172.31.3.28:9443    86d

   참고: 출력에서 aws-load-balancer-webhook-service에 ENDPOINTS 값이 있는지 확인하십시오. 엔드포인트 포트에 9443이 표시되어 웹후크 서비스가 올바로 구성되었다고 나타내야 합니다.

4. 다음 명령을 실행하여 인증서가 만료되었는지 확인합니다.

   kubectl get secret -n kube-system aws-load-balancer-webhook-tls -ojsonpath="{.data.ca\.crt}" | base64 -d | openssl x509 -noout -text

   출력 예시:

   Validity
           Not Before: [START_DATE]
           Not After : [END_DATE]

   참고: 현재 날짜가 Not Before 날짜와 Not After 날짜 사이여야 합니다. Not After 날짜가 지난 경우, 해당 인증서는 만료된 것입니다.

5. (선택 사항) 인증서가 만료되었으면, 다음 명령을 실행합니다.

   kubectl apply  --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.13.5/cert-manager.yaml

여전히 문제가 발생하는 경우, AWS Load Balancer Controller를 다시 설치하여 웹후크 구성, 서비스 엔드포인트 또는 인증서 관리 문제를 해결하십시오. 현재 설치된 AWS Load Balancer Controller를 제거한 다음 AWS Load Balancer Controller를 Helm으로 다시 설치합니다.

참고: AWS Load Balancer Controller를 삭제해도 수신 객체는 삭제되지 않습니다.

대상이 Network Load Balancer 또는 Application Load Balancer 오류를 인식하지 않음

대상이 Network Load Balancer 또는 Application Load Balancer가 존재한다는 것을 인식하지 못하면 AWS Load Balancer Controller를 설치했고 서비스가 배포되었더라도 오류가 발생할 수 있습니다.

다음 명령을 실행하여 대상 그룹 바인딩이 존재하는지 확인합니다.

kubectl get targetgroupbinding -A

대상 그룹 바인딩이 존재하는 경우, 네트워크 구성을 확인하여 대상과 ELB 간에 통신이 열려 있는지 확인하십시오.

대상 그룹 바인딩이 존재하지 않는 경우, 대상 그룹 바인딩을 만듭니다.

예:

apiVersion: elbv2.k8s.aws/v1beta1
kind: TargetGroupBinding
metadata:
  name: red-tgb
  namespace: red-ns
spec:
  serviceRef:
    name: red-service
    port: 80
  targetGroupARN: arn:aws:elasticloadbalancing:region:account-id:targetgroup/target-group-name/target-group-id

참고: region을 AWS 리전으로 바꾸십시오. account-id를 AWS 계정 ID로 바꿉니다. target-group-name을 대상 그룹 이름으로 바꿉니다. target-group-id를 대상 그룹 ID로 바꿉니다.

웹후크 서비스의 연결 문제

사용자 지정 리소스 정의 오류

AWS Load Balancer Controller에는 웹후크 서비스에 필요한 사용자 지정 리소스 정의(CRD)가 있어야 합니다. 자세한 내용은 Kubernetes 웹 사이트의 사용자 지정 리소스를 참조하십시오. 필수 CRD 없이 연결하려 하면 다음과 유사한 오류 메시지가 표시될 수 있습니다.

"Error from server (InternalError): error when creating "targetgroupbinding.yaml": Internal error occurred: failed calling webhook "mtargetgroupbinding.elbv2.k8s.aws":
failed to call webhook: Post "https://aws-load-balancer-webhook-service.kube-system.svc:443/mutate-elbv2-k8s-aws-v1beta1-targetgroupbinding?timeout=30s":
net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)"

이 문제를 해결하려면 다음 명령을 실행하여 클러스터에 CRD를 설치했는지 확인합니다.

kubectl get crds | grep target

출력 예시:

targetgroupbindings.elbv2.k8s.aws 2023-11-29T14:40:39Z

출력이 비어 있으면 CRD가 클러스터에 잘못 설치된 것입니다. CRD를 설치하려면 다음 명령을 실행합니다.

kubectl apply -f https://raw.githubusercontent.com/aws/eks-charts/master/stable/aws-load-balancer-controller/crds/crds.yaml

웹후크 서비스와의 내부 연결 검증

워커 노드 간 통신을 허용하는 것이 가장 좋습니다. 하지만, 보안 그룹에 웹후크 서비스와의 통신을 방지하는 제한적인 규칙이 있을 수 있습니다.

AWS Load Balancer Controller가 리소스를 만들고 수정하려면 리소스가 서비스와 통신할 수 있어야 합니다. 이 통신을 허용하려면 워커 노드의 보안 그룹에 다음 규칙이 포함되었는지 확인하십시오.

인바운드 규칙:

Port        Source                            
443         worker-node-security-group-id

참고: worker-node-security-group-id를 보안 그룹의 ID로 바꿉니다.

아웃바운드 규칙:

Port        Destination                            
443         worker-node-security-group-id

참고: worker-node-security-group-id를 보안 그룹의 ID로 바꿉니다.

워커 노드에서 ELB 서비스로의 연결 검증

VPC 엔드포인트를 사용하면 AWS Load Balancer Controller 워커 노드에서 ELB 서비스 엔드포인트로 통신할 수 있습니다. 프라이빗 Amazon EKS 클러스터가 인터넷에 연결되지 않은 경우, 가상 프라이빗 클라우드(VPC) 엔드포인트를 설정해야 합니다.

VPC 엔드포인트는 보안 그룹과 연결할 수 있는 탄력적 네트워크 인터페이스도 만듭니다. VPC 엔드포인트에 연결된 보안 그룹에 다음 수신 규칙이 포함되어야 합니다.

Port        Source                        
443         worker-node-security-group-id   

참고: worker-node-security-group-id를 보안 그룹의 ID로 바꿉니다.

잘못된 CreateTargetGroupInput.Port 파라미터 오류

기본적으로 컨트롤러는 인스턴스 모드에서 Application Load Balancer를 만듭니다. 인스턴스 모드는 NodePort 서비스와 호환되지만, 인스턴스 모드에는 노드 포트 할당이 필요하기 때문에 충돌할 수 있습니다. 자세한 내용은 Kubernetes 웹 사이트의 수신 주석을 참조하십시오. 포트 할당으로 인해 대상 그룹을 만들지 못하게 되는 경우, 다음과 같은 오류 메시지가 표시될 수 있습니다.

"Failed deploy model due to InvalidParameter: 1 validation error(s) found. - minimum field value of 1, CreateTargetGroupInput.Port."

이 문제를 해결하려면 Application Load Balancer의 적절한 모드에 따라 다음 단계를 완료합니다.

인스턴스 모드의 경우, 다음 단계를 완료합니다.

1. 유형을 NodePort로 설정:

   apiVersion: v1
   kind: Service
   metadata:
     name: service-name
     namespace: namespace-name
   spec:
     type: NodePort
     ports:
       - protocol: TCP
         port: 80
         targetPort: 80

   참고: service-name을 서비스 이름으로, namespace-name을 네임스페이스 이름으로 바꾸십시오.
2. 인스턴스 모드로 수신 만들기:

   alb.ingress.kubernetes.io/target-type: instance

IP 모드의 경우, 다음 단계를 완료합니다.

1. 유형을 ClusterIP로 구성:

   apiVersion: v1
   kind: Service
   metadata:
     name: service-name
     namespace: namespace-name
   spec:
     type: ClusterIP
     ports:
       - protocol: TCP
         port: 80
         targetPort: 80

   참고: service-name을 서비스 이름으로, namespace-name을 네임스페이스 이름으로 바꾸십시오.
2. 수신에 다음 주석 추가:

   alb.ingress.kubernetes.io/target-type: ip

AWS Load Balancer Controller 설치 오류

AWS Load Balancer Controller를 설치했는데 매니페스트에 잘못된 권한이 있는 경우, 다음과 유사한 오류 메시지가 표시될 수 있습니다.

"Warning Failed 8s (x8 over 88s) kubelet Error: container has runAsNonRoot and image will run as root (pod: "aws-load-balancer-controller-5c6c66fc48-49rm4_kube-system(924608a2-da7a-4786-ae74-051bb47ea84e)", container: controller)"

이 오류를 해결하려면 다음 단계를 완료하십시오.

1. 다음 명령을 실행하여 AWS Load Balancer Controller 배포를 편집합니다.

   kubectl edit deployment -n kube-system aws-load-balancer-controller

2. 배포 구성에서 컨테이너 섹션을 찾아 다음 securityContext 설정을 추가합니다.
   구성 예시:

   apiVersion: apps/v1
   kind: Deployment  
   spec:
     template:
       spec:
         containers:
         - name: aws-load-balancer-controller
           image: public.ecr.aws/eks/aws-load-balancer-controller:v2.13.3
           securityContext:  
             runAsNonRoot: true  
             runAsUser: 1000

배포를 편집하고 나면 새 포드가 새 구성 값으로 실행됩니다.