EKS : 서비스를 Network Load Balancer로 마이그레이션

사용 사례가 무엇이든(성능 향상, AWS 청구서 약간 감소 등) Kubernetes 클러스터용 Network Load Balancer로 전환하는 것이 좋은 경우가 많습니다. 트래픽을 수신하기 위해 보다 기본적인 계층(4 on OSI model )을 사용하므로 이 수준에서 좋은 성능 향상을 얻을 수 있습니다. 모든 라우팅 로직이 인그레스 컨트롤러 또는 Istio와 같은 서비스 메시를 통해 이미 적용 방식으로 수행되는 경우가 많다는 점을 고려하면 좋은 선택입니다.

예를 들어 내 사용 사례에서는 특히 Amazon Elastic IP 기능을 통해 내 Network Load Balancer에 고정 IP를 사용할 수 있는 가능성이 있었습니다.

몇 시간 동안의 테스트와 탐색 끝에 전환을 위한 좋은 시작이 될 수 있는 스니펫을 제안합니다. 실제로 새 서비스를 먼저 생성하여 현재 존재하는 서비스와 동일한 배포를 노출합니다. 그러면 두 개의 로드 밸런서에 도달할 수 있고 트래픽을 동일한 앱으로 전달할 수 있습니다. DNS를 통해 트래픽을 정상적으로 전환하고, 테스트하고, 필요한 경우 신속하게 롤백할 수 있는 것은 정말 유용합니다(300초의 TTL이 허용됨).

kind: Service
apiVersion: v1
metadata:
  name: public-ingress-nginx-nlb
  namespace: prod
  labels:
    app: public-ingress-nginx-nlb
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
    service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: '60'
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: 'true'
    service.beta.kubernetes.io/aws-load-balancer-type: 'nlb'
    service.beta.kubernetes.io/aws-load-balancer-eip-allocations: "eipalloc-AAA,eipalloc-BBB,eipalloc-CCC"
    service.beta.kubernetes.io/aws-load-balancer-subnets: "subnet-AAA,subnet-BBB,subnet-CCC"
    service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: proxy_protocol_v2.enabled=true
    # until you use the AWS Load Balancer Controller, this last option above needs to be activated manually in the Target groups / Attributes tab
spec:
  type: LoadBalancer
  selector:
    app: public-ingress-nginx
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: http
    - name: https
      port: 443
      protocol: TCP
      targetPort: https

메모 :

주석service.beta.kubernetes.io/aws-load-balancer-eip-allocations 및 service.beta.kubernetes.io/aws-load-balancer-subnets은 Network Load Balancer에 고정 IP를 연결하고 사용할 필요가 없는 경우 선택 사항입니다. 이 경우 먼저 EC2에 할당해야 합니다(계정에 있어야 하며 현재 사용 중이 아니어야 함). 3개가 필요하지 않습니다. 1개가 작동하지만 프로덕션 트래픽용인 경우 3개를 사용하는 것이 좋습니다. 중복성을 위해 AWS는 탄력적 IP당 1개의 퍼블릭 서브넷을 정의하도록 강제하며 각 서브넷은 사용 중인 지역의 다른 가용 영역에 있어야 합니다.

PROXY protocol을 올바르게 사용하려면 클러스터에서 AWS Load Balancer Controller을 설정하지 않은 경우 이 주석service.beta.kubernetes.io/aws-load-balancer-target-group-attributes이 작동하지 않습니다. 그동안 EC2를 통해 이 옵션을 활성화하는 것을 잊지 마십시오.Network Load Balancer의 각 대상 그룹을 편집하고 이 옵션을 선택해야 합니다.

며칠 또는 몇 주 후에 모든 것이 예상대로 작동하는 경우 원래 서비스를 삭제하는 것을 잊지 마십시오. 그러면 가동 중단 시간이나 연결된 현재 서비스에 영향을 주지 않고 사용하던 이전 클래식 또는 응용 로드 밸런서가 자동으로 해제됩니다.Network Load Balancer. 또한 DaemonSet 또는 배포 사양에서 관리하는 Nginx 수신 컨트롤러 컨테이너의 arg--publish-service를 업데이트하는 것을 잊지 마십시오.

이 페이지가 어떤 식으로든 도움이 되었거나 개선을 위한 제안이 있으면 알려주세요.

좋은 하루 되세요!