Amazon EKS Hybrid Nodes 게이트웨이 운영
Amazon EKS Hybrid Nodes 게이트웨이 운영 (Amazon EKS Hybrid Nodes gateway operations)
이 페이지는 Amazon EKS Hybrid Nodes 게이트웨이의 day-2 운영을 다뤄요. 고가용성, 장애 조치 동작, 모니터링, 확장, VXLAN 터널 수명 주기를 포함해요. 설치 지침은 EKS Hybrid Nodes 게이트웨이 시작하기를 참고하세요.
출처: 문서
본문
고가용성 및 장애 조치 (High availability and failover)
Hybrid Nodes 게이트웨이는 Kubernetes Lease 기반 리더 선출과 함께 액티브-스탠바이(active-standby) 모델을 사용해요. 두 개의 게이트웨이 Pod가 Pod anti-affinity로 강제된 별도의 EC2 노드에서 실행돼요. 두 Pod 모두 시작 시 VXLAN 인터페이스를 만들고, 모든 하이브리드 노드에 대한 VTEP 항목을 유지하는 노드 reconciler를 실행해요. 리더 Pod만 VPC 라우팅 테이블과 CiliumVTEPConfig CRD를 관리해요. 스탠바이 Pod는 이미 완전한 터널 항목 세트를 가지고 있으므로 장애 조치 시 3~5초 내에 트래픽을 전달할 준비가 항상 되어 있어요.
장애 조치 시퀀스
액티브 게이트웨이 인스턴스에 장애가 발생하면 다음 시퀀스가 발생해요.
- 스탠바이 Pod가 리더 Lease가 만료되었음을 감지해요.
- 스탠바이 Pod가 Lease를 획득하고 새 리더가 돼요.
- 새 리더가 리더 설정 시퀀스를 실행해요.
- VPC 라우팅 테이블 항목을 업데이트해 하이브리드 Pod CIDR을 새 리더의 기본 ENI로 가리키게 해요.
- 새 리더의 노드 IP와 VXLAN MAC 주소로
CiliumVTEPConfig커스텀 리소스를 upsert해요. - 트래픽이 새 리더를 통해 다시 흐르기 시작해요.
두 Pod가 항상 VXLAN 인터페이스와 VTEP 항목을 유지하므로, 새 리더는 장애 조치 중 VXLAN 인터페이스를 다시 만들거나 터널 항목을 다시 프로그래밍할 필요가 없어요. VPC 라우팅 테이블과 CiliumVTEPConfig 업데이트만 필요해요.
예상 장애 조치 시간은 약 3~5초예요. 장애 조치 중 VPC와 하이브리드 Pod 사이의 트래픽은 중단돼요.
가용 영역 권장 사항
게이트웨이 노드를 두 개의 가용 영역에 분산 배치해 AZ 장애가 리더와 스탠바이를 모두 무너뜨리지 않도록 하세요. EKS Auto Mode를 사용할 때는 여러 AZ에 걸친 서브넷 선택기로 NodeClass를 구성하세요. 관리형 노드 그룹이나 자체 관리형 노드의 경우 레이블을 지정할 때 서로 다른 AZ의 노드를 선택하세요.
참고
게이트웨이와 VPC의 다른 리소스 사이의 교차 AZ 트래픽에는 표준 AWS 교차 AZ 데이터 전송 요금이 부과돼요.
리더 선출 매개변수
기본 리더 선출 매개변수는 빠른 장애 조치에 맞게 튜닝되어 있어요.
| 매개변수 | 기본값 | 설명 |
|---|---|---|
--leader-election-lease-duration |
3s |
리더가 갱신을 중지한 후 비리더가 리스를 획득하려 시도하기 전에 기다리는 시간. |
--leader-election-renew-deadline |
2s |
리더가 포기하기 전에 리스를 갱신하려 시도하는 시간. |
--leader-election-retry-period |
1s |
후보자가 리스 획득을 재시도하는 빈도. |
이 값을 낮추면 장애 조치 시간이 줄어들지만 네트워크 분할 시 가짜 장애 조치의 위험이 커져요. 대부분의 배포에서 기본값이 적절해요. 자세한 내용은 Amazon EKS Hybrid Nodes 게이트웨이 구성 참조를 참고하세요.
VPC 라우팅 테이블 관리 (VPC route table management)
게이트웨이는 하이브리드 Pod CIDR로 향하는 트래픽이 활성 게이트웨이 인스턴스에 도달하도록 VPC 라우팅 테이블 항목을 관리해요.
경로가 관리되는 방식
게이트웨이 Pod가 리더가 되면 구성된 각 VPC 라우팅 테이블에서 경로를 만들거나 교체해요. 각 경로는 대상 CIDR을 하이브리드 Pod CIDR로, 대상을 리더의 기본 ENI로 설정해요. 경로가 이미 존재하고 올바른 ENI를 가리키면 게이트웨이는 업데이트를 건너뛰어요.
장애 조치 중 새 리더는 기존 경로를 자신의 ENI를 가리키도록 교체해요. 이 메커니즘이 VPC 트래픽을 새 활성 게이트웨이로 리디렉션해요.
라우팅 테이블 항목 예시
게이트웨이가 경로를 구성한 후 VPC 라우팅 테이블에는 다음 항목과 유사한 항목이 포함돼요.
| 대상 | 대상 | 상태 |
|---|---|---|
10.0.0.0/16 |
local | active |
HYBRID_POD_CIDR |
eni-LEADER_ENI_ID |
active |
IAM 권한
게이트웨이는 라우팅 테이블을 관리하기 위해 다음 IAM 작업이 필요해요.
ec2:DescribeRouteTablesec2:CreateRouteec2:ReplaceRouteec2:DescribeInstances
게이트웨이 노드의 인스턴스 프로파일, Pod Identity, 또는 IRSA 구성과 연결된 IAM 역할에 이러한 권한을 연결하세요.
모니터링 (Monitoring)
상태 및 준비 엔드포인트
게이트웨이는 포트 8088에 상태 및 준비 엔드포인트를 노출해요.
| 엔드포인트 | 경로 | 설명 |
|---|---|---|
| 상태 확인(Health check) | /healthz |
게이트웨이 프로세스가 정상이면 HTTP 200을 반환. Kubernetes liveness 프로브에서 사용. |
| 준비 확인(Readiness check) | /readyz |
게이트웨이가 트래픽을 제공할 준비가 되면 HTTP 200을 반환. Kubernetes readiness 프로브에서 사용. |
진단을 위해 임시 디버그 컨테이너를 실행하거나 포트 포워딩으로 이러한 엔드포인트를 수동으로 쿼리할 수 있어요.
kubectl port-forward -n eks-hybrid-nodes-gateway POD_NAME 8088:8088 &
curl -s http://localhost:8088/healthz
curl -s http://localhost:8088/readyz
메트릭 엔드포인트
게이트웨이는 포트 10080의 /metrics 경로에 Prometheus 호환 메트릭을 노출해요. 표준 controller-runtime 메트릭 외에도 다음 커스텀 메트릭을 사용할 수 있어요.
게이트웨이 정보:
| 메트릭 | 유형 | 설명 |
|---|---|---|
hybrid_gateway_info |
Gauge | 게이트웨이 인스턴스에 대한 정적 정보. 항상 1. 레이블: node_ip, node_name, vxlan_interface, vpc_cidr, pod_cidr. |
하이브리드 노드:
| 메트릭 | 유형 | 설명 |
|---|---|---|
hybrid_gateway_hybrid_nodes_configured |
Gauge | VTEP 항목이 구성된 현재 하이브리드 노드 수. |
VTEP 작업:
| 메트릭 | 유형 | 설명 |
|---|---|---|
hybrid_gateway_vtep_add_total |
Counter | 성공한 VTEP 추가 작업 총계. |
hybrid_gateway_vtep_add_errors_total |
Counter | 실패한 VTEP 추가 작업 총계. |
hybrid_gateway_vtep_remove_total |
Counter | 성공한 VTEP 제거 작업 총계. |
hybrid_gateway_vtep_remove_errors_total |
Counter | 실패한 VTEP 제거 작업 총계. |
리더 선출 및 라우팅 테이블:
| 메트릭 | 유형 | 설명 |
|---|---|---|
hybrid_gateway_leader_is_active |
Gauge | 이 Pod가 활성 리더이면 1, 스탠바이이면 0. |
hybrid_gateway_leader_setup_duration_seconds |
Histogram | 리더 설정 작업(라우팅 테이블 + CiliumVTEPConfig)의 기간(초). |
hybrid_gateway_aws_route_table_update_total |
Counter | 성공한 AWS 라우팅 테이블 업데이트 작업 총계. |
hybrid_gateway_aws_route_table_update_errors_total |
Counter | 실패한 AWS 라우팅 테이블 업데이트 작업 총계. |
hybrid_gateway_aws_route_table_update_duration_seconds |
Histogram | AWS 라우팅 테이블 업데이트 작업의 기간(초). |
네트워크 통계(스크레이프당 온디맨드로 수집):
| 메트릭 | 유형 | 설명 |
|---|---|---|
hybrid_gateway_vxlan_rx_bytes_total |
Gauge | VXLAN 인터페이스에서 수신한 총 바이트. |
hybrid_gateway_vxlan_tx_bytes_total |
Gauge | VXLAN 인터페이스에서 전송한 총 바이트. |
hybrid_gateway_vxlan_rx_packets_total |
Gauge | VXLAN 인터페이스에서 수신한 총 패킷. |
hybrid_gateway_vxlan_tx_packets_total |
Gauge | VXLAN 인터페이스에서 전송한 총 패킷. |
hybrid_gateway_vxlan_rx_dropped_total |
Gauge | VXLAN 인터페이스가 수신 시 드롭한 총 패킷. |
hybrid_gateway_vxlan_tx_dropped_total |
Gauge | VXLAN 인터페이스가 전송 시 드롭한 총 패킷. |
hybrid_gateway_vxlan_rx_errors_total |
Gauge | VXLAN 인터페이스의 총 수신 오류. |
hybrid_gateway_vxlan_tx_errors_total |
Gauge | VXLAN 인터페이스의 총 전송 오류. |
hybrid_gateway_vxlan_interface_up |
Gauge | VXLAN 인터페이스가 UP이면 1, 그렇지 않으면 0. |
hybrid_gateway_vxlan_fdb_entries |
Gauge | VXLAN 인터페이스의 현재 FDB 항목 수. |
hybrid_gateway_vxlan_route_count |
Gauge | VXLAN 인터페이스를 통한 현재 경로 수. |
hybrid_gateway_primary_nic_rx_bytes_total |
Gauge | 기본 네트워크 인터페이스에서 수신한 총 바이트. |
hybrid_gateway_primary_nic_tx_bytes_total |
Gauge | 기본 네트워크 인터페이스에서 전송한 총 바이트. |
hybrid_gateway_primary_nic_rx_packets_total |
Gauge | 기본 네트워크 인터페이스에서 수신한 총 패킷. |
hybrid_gateway_primary_nic_tx_packets_total |
Gauge | 기본 네트워크 인터페이스에서 전송한 총 패킷. |
hybrid_gateway_primary_nic_rx_dropped_total |
Gauge | 기본 NIC가 수신 시 드롭한 총 패킷. |
hybrid_gateway_primary_nic_tx_dropped_total |
Gauge | 기본 NIC가 전송 시 드롭한 총 패킷. |
hybrid_gateway_primary_nic_rx_errors_total |
Gauge | 기본 NIC의 총 수신 오류. |
hybrid_gateway_primary_nic_tx_errors_total |
Gauge | 기본 NIC의 총 전송 오류. |
hybrid_gateway_primary_nic_info |
Gauge | 기본 NIC 이름. 항상 1. 레이블: interface_name. |
CloudWatch Observability 추가 기능
Amazon CloudWatch Observability 추가 기능을 사용해 게이트웨이 메트릭과 로그를 수집할 수 있어요. 추가 기능이 포트 10080의 게이트웨이 네임스페이스(eks-hybrid-nodes-gateway)를 스크레이프하도록 구성하세요. 올바른 구성 형식은 위에서 연결된 추가 기능 문서를 참고하세요.
확장 고려 사항 (Scaling considerations)
Hybrid Nodes 게이트웨이는 리더 선출이 있는 액티브-스탠바이 모델을 사용하므로, 주어진 시간에 하나의 Pod만 트래픽을 처리해요. 게이트웨이를 수평 확장(복제본 수 증가)하면 장애 조치 시 인계할 준비가 된 추가 스탠바이 Pod를 제공해 가용성을 개선할 수 있지만, 트래픽이 복제본에 분산되지 않으므로 성능이나 처리량은 개선되지 않아요. 성능을 확장하려면 트래픽 볼륨에 충분한 네트워크 대역폭을 가진 EC2 인스턴스 유형을 선택해 수직 확장하세요.
인스턴스 유형 지침
게이트웨이 처리량은 EC2 인스턴스 네트워크 성능으로 제한돼요. 인스턴스 유형을 선택할 때 다음을 고려하세요.
- 네트워크 대역폭 – 게이트웨이는 VPC와 하이브리드 Pod 사이의 모든 트래픽을 전달해요. 네트워크 대역폭이 최대 트래픽 요구사항을 충족하는 인스턴스 유형을 선택하세요.
- 초당 패킷 수(PPS) – VXLAN 캡슐화는 패킷당 오버헤드를 추가해요. 작은 패킷이 많은 워크로드(예: 요청률이 높은 마이크로서비스)는 더 높은 PPS 한도를 가진 인스턴스 유형에서 이점을 얻어요.
- 하이브리드 노드 수 – 각 하이브리드 노드는 게이트웨이가 트래픽을 전달하는 VXLAN 터널 엔드포인트를 추가해요. 하이브리드 노드 수가 확장됨에 따라 게이트웨이를 통한 집계 트래픽도 늘어나요. 클러스터의 최대 교차 네트워크 트래픽을 처리할 충분한 네트워크 대역폭을 가진 인스턴스 유형을 선택하세요.
권장 인스턴스 유형
프로덕션(10~100개 하이브리드 노드, 중간 트래픽) — 꾸준한 교차 네트워크 트래픽이 있는 표준 프로덕션 워크로드에 적합.
| 인스턴스 유형 | vCPU | 메모리 | 네트워크 | 참고 |
|---|---|---|---|---|
c6i.xlarge |
4 | 8 GiB | 최대 12.5 Gbps | 비용과 성능의 좋은 균형 |
c6in.xlarge |
4 | 8 GiB | 최대 30 Gbps | 네트워크 최적화; 프로덕션 권장 |
c7i.xlarge |
4 | 8 GiB | 최대 12.5 Gbps | 최신 세대 컴퓨팅 최적화 |
m6i.xlarge |
4 | 16 GiB | 최대 12.5 Gbps | 게이트웨이 노드에 다른 워크로드를 함께 배치하는 경우 적합 |
고처리량 프로덕션(100개 이상 하이브리드 노드, 과중 트래픽) — 데이터 집약적 워크로드나 많은 동시 연결 같은 상당한 교차 네트워크 대역폭 요구사항이 있는 환경용.
| 인스턴스 유형 | vCPU | 메모리 | 네트워크 | 참고 |
|---|---|---|---|---|
c6in.2xlarge |
8 | 16 GiB | 최대 40 Gbps | 고처리량 프로덕션 권장 |
c5n.2xlarge |
8 | 21 GiB | 최대 25 Gbps | 이전 세대 네트워크 최적화, 비용 효율적 |
c6in.4xlarge |
16 | 32 GiB | 최대 50 Gbps | 매우 과중한 워크로드를 위한 최대 처리량 |
c5n.4xlarge |
16 | 42 GiB | 최대 25 Gbps | 극단적 패킷 속도를 위한 높은 vCPU 수 |
게이트웨이 메트릭(메트릭 엔드포인트 참고)을 사용해 네트워크 사용률을 모니터링하고 필요에 따라 인스턴스 유형을 조정하세요.
VXLAN 터널 수명 주기 (VXLAN tunnel lifecycle)
게이트웨이는 하이브리드 노드가 클러스터에 조인하거나 떠날 때 VXLAN 터널을 자동으로 유지해요.
터널이 관리되는 방식
노드 컨트롤러가 클러스터의 CiliumNode 객체를 감시해요. 이 컨트롤러는 모든 게이트웨이 Pod(리더만이 아니라)에서 실행되어 리더와 스탠바이 모두 최신 터널 상태를 가지도록 해요. CiliumNode 이벤트가 발생하면 컨트롤러는 eks.amazonaws.com/compute-type: hybrid 레이블을 찾아 노드가 하이브리드 노드인지 확인해요.
하이브리드 노드가 클러스터에 조인할 때:
- 컨트롤러가 새
CiliumNode객체를 감지해요. CiliumNodespec에서 노드의 내부 IP 주소와 Pod CIDR을 추출해요.- VXLAN 인터페이스에 다음을 프로그래밍해요.
- VXLAN 인터페이스를 통해 노드의 IP로 가는 노드의 Pod CIDR 경로.
- 노드의 IP를 결정적 MAC 주소에 매핑하는 정적 ARP 항목.
- 캡슐화된 패킷을 노드의 IP로 보내라고 VXLAN 모듈에 알리는 FDB 항목.
하이브리드 노드가 클러스터를 떠날 때:
- 컨트롤러가
CiliumNode삭제를 감지해요. - 해당 노드에 대한 경로, ARP 항목, FDB 항목을 VXLAN 인터페이스에서 제거해요.
이 수명 주기는 완전히 자동이에요. 하이브리드 노드를 추가하거나 제거할 때 터널을 수동으로 구성할 필요가 없어요.
다음 단계
- Amazon EKS Hybrid Nodes 게이트웨이 구성 참조 – Helm 값, CLI 플래그, 리더 선출 매개변수 커스터마이징.
- Amazon EKS Hybrid Nodes 게이트웨이 문제 해결 – 일반적인 문제 진단 및 해결.
- Amazon EKS Hybrid Nodes 게이트웨이 – 개요 페이지로 돌아가기.