안녕하세요! 오늘은 클라우드 네이티브 환경을 다루다 보면 한 번쯤 마주치게 되는 "낯선 IP 대역"들에 대해 이야기해보려 합니다.
쿠버네티스를 운영하다 보면 가끔 "어? 우리 회사 VPC 대역은 10.0.0.0/16인데, 왠 34.x.x.x가 찍히지?" 또는 "AWS EKS 파드 IP가 왜 100.64.x.x지?" 라는 의문을 갖게 됩니다.
이 두 가지 케이스는 서로 다른 이유로 탄생했지만, 결국 클라우드 네트워크의 구조적 한계와 IP 자원 관리라는 공통된 주제를 가지고 있습니다. GKE와 EKS가 각각 네트워크를 어떻게 다루는지 상세히 파헤쳐 보겠습니다! 🚀
1. GKE (Google Kubernetes Engine)와 34.x.x.x 대역의 비밀 🇬
"내 클러스터는 Private인데 왜 마스터 노드는 공인 IP를 쓸까?"
GKE를 생성하고 kubectl cluster-info를 쳐보면 마스터(Control Plane)의 주소가 34.118.x.x와 같은 구글 공인 IP로 잡히는 것을 볼 수 있습니다.
🏗️ 구조적 이유: 관리 영역의 분리
GKE는 아키텍처가 독특합니다.
- User VPC (워커 노드): 우리가 돈을 내고 제어하는 영역입니다. 여기에 실제 파드(Pod)들이 뜹니다.
- Google Managed VPC (컨트롤 플레인): 구글이 관리하는 별도의 프로젝트/VPC에 마스터 노드가 존재합니다.
이 두 네트워크는 서로 물리적으로 격리되어 있으며, 통신을 위해 VPC Peering(피어링)으로 연결됩니다.
🧐 왜 하필 공인 IP(34.x)인가?
여기서 딜레마가 생깁니다. 만약 구글이 마스터 노드에 10.x나 192.168.x 같은 사설 IP를 쓴다면 어떨까요?
사용자가 자신의 VPC를 똑같은 10.x 대역으로 만들었을 때 IP 충돌(Overlap)이 발생하여 피어링 자체가 불가능해집니다.
그래서 구글은 "전 세계 어디서도 겹치지 않는 IP"인 공인 IP(Public IP) 대역(구글 소유의 34.x 등)을 마스터 노드에 할당해버린 것입니다.
💡 핵심 요약
- 충돌 방지: 사용자 VPC가 어떤 사설 대역을 쓰든 상관없이 연결하기 위함입니다.
- 접근성: 개발자가 외부(인터넷)에서 kubectl 명령을 날릴 수 있는 엔드포인트 역할을 합니다.
- 보안: Private Cluster 옵션을 켜더라도, 마스터와 워커 노드 간의 터널링 등을 위해 이 공인 IP 대역은 내부적으로 라우팅에 사용됩니다.
2. AWS EKS와 100.64.x.x (Secondary CIDR)의 정체 🅰️
"VPC IP가 부족해! 파드를 위한 전용 대역이 필요해!"
AWS EKS를 운영하다 보면 파드 IP가 100.64.x.x 대역으로 잡히는 경우를 자주 봅니다. 이는 AWS VPC CNI 플러그인의 특성과 밀접한 관련이 있습니다.
😱 문제점: IP 고갈 (IP Exhaustion)
AWS VPC CNI는 파드 하나하나에 VPC의 실제 IP를 할당합니다. 성능은 최고지만, IP 소모가 엄청납니다.
예를 들어, 10.0.0.0/16 (65,536개)으로 VPC를 만들었어도, 서브넷을 쪼개고 EC2, ELB, RDS 등을 띄우다 보면 파드 수천 개를 띄울 IP가 부족해집니다.
🛠️ 해결책: Secondary CIDR 추가
이때 사용하는 기법이 VPC에 보조 IP 대역(Secondary CIDR)을 붙이는 것입니다. 이때 가장 많이 권장되는 대역이 바로 100.64.0.0/10 대역입니다.
🧐 100.64.x.x는 무엇인가? (CGNAT)
이 대역은 RFC 6598 표준에 정의된 CGNAT(Carrier Grade NAT) 대역입니다.
- 공인 IP가 아님: 인터넷에서 라우팅되지 않습니다.
- 일반 사설 IP(10.x, 192.168.x)도 아님: 기업 내부망에서 흔히 쓰는 대역과 겹칠 확률이 매우 낮습니다.
즉, "사설망 확장을 위해 쓰기 딱 좋은, 충돌 없는 예비 대역"인 셈입니다. EKS는 이 대역을 파드 전용으로 할당하여, 노드(EC2)가 쓰는 IP 대역과 파드가 쓰는 IP 대역을 분리하고 IP 부족 문제를 해결합니다.
💡 핵심 요약
- IP 확보: 기존 VPC 대역폭의 한계를 넘어 파드를 무한히(?) 생성할 수 있습니다.
- 관리 용이성: 노드 IP와 파드 IP가 명확히 구분되어 관리가 편합니다.
- 표준 준수: 사설 IP 충돌을 피하기 위해 CGNAT 대역을 활용합니다.
🥊 한눈에 비교하기
| 구분 | GKE (Google) | EKS (AWS) |
|---|---|---|
| 관찰되는 IP | 34.118.x.x (예시) | 100.64.x.x |
| IP 종류 | Public IP (공인 IP) | CGNAT IP (Shared Address) |
| 대상 리소스 | Control Plane (Master Node) | Pod (Worker Node 내부) |
| 사용 목적 | 사용자 VPC와의 IP 충돌 방지 및 외부 접근 | VPC IP 고갈 해결 및 파드 전용 대역 확보 |
| 네트워크 구조 | 구글 관리 VPC ↔ 사용자 VPC 피어링 | 하나의 VPC 내 Secondary CIDR 확장 |
📝 결론
클라우드를 쓰다 보면 "내가 설정하지 않은 IP"가 튀어나와 당황스러울 때가 있습니다. 하지만 그 이면에는 충돌 방지와 확장성을 위한 클라우드 제공사(CSP)들의 깊은 고민이 담겨 있습니다.
- GKE의 34.x: 구글이 관리하는 영역이니 "아, 마스터 노드구나!" 하고 안심하세요.
- EKS의 100.64.x: 파드 IP 부족을 해결하기 위한 "확장 슬롯"이구나 생각하면 됩니다.
이 차이를 이해하면, 하이브리드 클라우드나 멀티 클라우드 네트워크를 설계할 때 훨씬 더 유연하게 대처할 수 있습니다! 👍
도움이 되셨다면 공감 부탁드립니다! 👏
'클라우드 > 쿠버네티스' 카테고리의 다른 글
| 🚀 마이크로서비스로 가는 가장 안전한 징검다리: 왜 '모듈러 모놀리스'를 거쳐야 할까? (0) | 2025.12.20 |
|---|---|
| [Kubernetes] "내 파드의 신분증이 바뀌었다?" Service Account와 Projected Volume 완벽 해부 🆔 (0) | 2025.12.19 |
| [Kubernetes] 파드를 3개나 띄웠는데 왜 한 노드에만 몰릴까? (스케줄러의 비밀) 🧐 (0) | 2025.12.19 |
| 🏗️ [쿠버네티스] 파드에 디스크를 직접 연결하면 안 되는 이유 (PV, PVC, SC의 필요성) (0) | 2025.12.11 |
| 📦 그림 한 장으로 끝내는 쿠버네티스 볼륨(Volume) 구조와 원리 (0) | 2025.12.11 |
