피드로 돌아가기
Dev.toInfrastructure
원문 읽기
ArgoCD Sync Wave와 EnvoyProxy CRD 제어로 EKS 내 Gateway API 인프라 자동화 구현
Deploying Envoy Gateway on AWS EKS: The Right Way
AI 요약
Context
GKE Autopilot의 관리형 Gateway API 환경에서 AWS EKS로 마이그레이션하며 발생한 인프라 제어권 상실 문제 해결 필요. 특히 CRD 생명주기 관리 부재와 AWS Load Balancer Controller와의 통합 설정 오류로 인한 Service Pending 상태 발생이 핵심 병목 지점임.
Technical Solution
- Gateway API CRD와 Envoy Gateway 전용 CRD, Controller를 3단계로 분리하여 배포함으로써 리소스 의존성 충돌 방지
- ArgoCD Sync Wave(-1, 0)를 적용하여 CRD 선행 설치 후 Controller가 배포되는 엄격한 순서 보장
- ServerSideApply=true 설정을 통한 필드 수준 소유권 관리로 다수 Application 간의 CRD 덮어쓰기 방지
- EnvoyProxy CRD 내 envoyService.annotations 설정을 통해 Classic Load Balancer 대신 NLB(Network Load Balancer) 강제 프로비저닝
- VPC CNI 기반의 nlb-target-type: ip 설정을 적용하여 kube-proxy 및 NodePort를 우회하는 트래픽 경로 최적화
- HTTPRoute 리소스를 개별 애플리케이션 팀에 위임하여 인프라 관리와 서비스 라우팅 설정의 관심사 분리
실천 포인트
- EKS 배포 시 Service가 Pending 상태라면 EnvoyProxy CRD의 annotations 내 aws-load-balancer-type이 external로 설정되었는지 확인 - GitOps 도입 시 리소스 간 의존성이 강한 CRD와 Controller는 Sync Wave를 통해 배포 순서를 명시적으로 제어 - 다수의 컨트롤러가 동일 CRD를 수정하는 환경에서는 ServerSideApply 옵션을 활성화하여 설정 충돌 방지 - 무중단 서비스 보장을 위해 HPA의 minReplicas를 2 이상으로 설정하는 방안 검토