클라우드와 컨테이너 네트워크
VPC·서브넷·보안 그룹·NACL의 경계를 익히고 Docker와 Kubernetes가 컨테이너 통신을 구성하는 방식을 이해합니다.
현대 서비스는 대부분 클라우드 위에서 운영됩니다.
AWS, GCP, Azure 같은 클라우드 환경에서 네트워크를 구성하는 방법은 물리 네트워크와 개념은 같지만, 가상화라는 추상화 계층이 추가됩니다.
Docker와 Kubernetes 같은 컨테이너 환경은 또 다른 네트워크 추상화를 제공합니다.
AWS VPC 기본 구성
VPC를 생성할 때 CIDR 블록을 지정합니다.
10.0.0.0/16이라면 65,536개의 IPv4 주소 범위를 가진 가상 네트워크가 만들어집니다.
실제 EC2에 할당 가능한 주소 수는 서브넷마다 AWS가 예약하는 주소가 있기 때문에 CIDR 전체 개수와 정확히 같지는 않습니다.
VPC 안에 서브넷을 만듭니다.
퍼블릭 서브넷은 라우팅 테이블에 인터넷 게이트웨이로 가는 경로가 있는 서브넷입니다.
여기에 있는 인스턴스가 실제로 인터넷에서 접근 가능하려면 퍼블릭 IPv4 또는 IPv6 주소, 보안 그룹/NACL 허용 규칙도 필요합니다.
프라이빗 서브넷은 인터넷 게이트웨이로 직접 나가는 경로가 없는 서브넷입니다.
웹 진입점이나 로드 밸런서는 퍼블릭에, 데이터베이스는 프라이빗에 배치하는 것이 일반적입니다.
인터넷 게이트웨이(IGW)는 VPC를 인터넷에 연결합니다.
0.0.0.0/0 → IGW는 외부 IPv4 목적지로 가는 경로를 제공합니다. 인스턴스의 퍼블릭 주소와 보안 규칙 등 앞의 조건이 충족되어야 실제 통신이 가능합니다.
인터넷 출구로 구성한 퍼블릭 NAT 게이트웨이는 프라이빗 인스턴스가 시작한 IPv4 통신과 그 응답을 전달합니다. 인터넷에서 그 인스턴스로 새 연결을 시작하는 것은 허용하지 않습니다. 내부망 연결에 쓰는 private NAT와는 용도를 구분합니다.
zonal NAT를 사용한다면 AZ별 NAT와 라우팅을 분리해 장애 범위를 줄일 수 있습니다. AWS는 자동 다중 AZ 확장을 제공하는 regional NAT 게이트웨이도 제공하므로 모든 구성에 AZ별 수동 배치를 요구하는 것은 아닙니다.
보안 그룹과 NACL
| 구분 | 정책과 반환 트래픽 |
|---|---|
| 보안 그룹 | ENI 수준의 stateful 허용 규칙을 합칩니다. 추적되는 연결의 반환 트래픽은 별도의 반대 방향 허용 규칙 없이 통과합니다. |
| NACL | 서브넷 수준에서 번호가 작은 규칙부터 첫 일치를 적용하는 stateless 허용·거부 목록입니다. 응답 방향과 ephemeral port 범위도 허용해야 합니다. |
| 초기 규칙 | 기본 SG의 인바운드 허용은 같은 SG가 연결된 자원 범위이며 VPC 전체가 아닙니다. 기본 outbound는 허용입니다. 기본 NACL은 허용, 새 custom NACL은 규칙 추가 전 거부입니다. |
일반적으로 보안 그룹으로 주요 접근 제어를 하고, NACL은 서브넷 레벨의 추가 방어벽으로 사용합니다.
NACL은 stateless라서 응답 트래픽의 ephemeral port 범위까지 고려해야 하며, 규칙 번호를 10, 20, 30처럼 여유 있게 두면 나중에 중간 규칙을 넣기 쉽습니다.
Docker 네트워크
일반적인 bridge 모드의 Docker 컨테이너는 격리된 네트워크 네임스페이스를 사용합니다. host 모드는 호스트의 네트워크 네임스페이스를 공유하는 예외입니다.
컨테이너 안에서는 자기만의 인터페이스, 라우팅 테이블, DNS 설정이 있는 것처럼 보이고, 호스트는 bridge, NAT, port publishing 같은 장치로 외부와 연결합니다.
| 드라이버 | 연결 범위와 용도 |
|---|---|
| bridge | 단일 호스트의 가상 브리지에 연결하고 NAT·포트 게시로 외부와 통신합니다. |
| host | 호스트 네트워크 네임스페이스를 공유합니다. 별도 네트워크 격리나 포트 게시를 전제로 하지 않습니다. |
| none | 외부 연결 없이 loopback만 남깁니다. 다른 종류의 자원 격리까지 보장한다는 뜻은 아닙니다. |
| overlay | 여러 Docker 호스트 사이의 가상 네트워크로 Swarm 등의 통신을 구성합니다. |
| macvlan | 별도 MAC을 가진 호스트처럼 물리 L2 네트워크에 연결합니다. 네트워크 장비의 지원 조건을 확인합니다. |
기본 bridge보다 사용자 정의 bridge 네트워크를 만드는 편이 보통 더 낫습니다.
컨테이너 이름 기반 DNS, 네트워크별 격리, 명시적인 연결 관리가 쉬워지기 때문입니다.
Kubernetes 네트워크 모델
Kubernetes는 Docker보다 한 단계 높은 추상화를 제공합니다.
핵심 네트워크 모델은 다음과 같습니다.
- 일반 Pod는 클러스터 안에서 고유한 IP를 갖고, 한 Pod 안의 컨테이너는 네트워크를 공유합니다.
hostNetworkPod는 노드 네트워크를 사용하는 예외입니다. - Pod 간에는 주소 변환 없이 통신할 수 있는 네트워크 모델을 제공합니다. 실제 허용 범위는 NetworkPolicy 등 정책으로 제한될 수 있습니다.
- 노드의 에이전트(kubelet 등)가 필요한 Pod 통신을 할 수 있도록 구성해야 합니다.
일반적인 Kubernetes 런타임은 CNI(Container Network Interface) 플러그인을 통해 Pod 네트워크를 구성합니다.
플러그인은 인터페이스·라우팅을 구성하고 IPAM에 주소 할당을 위임할 수 있습니다. NetworkPolicy·암호화·eBPF 관측성 지원은 구현과 활성화 설정에 따라 다릅니다.
| 구현 예 | 기능을 비교할 지점 |
|---|---|
| Calico | 라우팅·BGP와 네트워크 정책의 구성 방식을 확인합니다. |
| Flannel | Pod 간 네트워크 전송 백엔드를 제공하며 정책 기능은 별도 구성을 확인합니다. |
| Cilium | eBPF 데이터 경로와 보안·관측 기능의 활성화 조건을 확인합니다. |
| AWS VPC CNI | VPC 주소와 ENI를 사용하는 Pod 네트워크의 주소·인스턴스 한도를 확인합니다. |
일반적인 ClusterIP Service는 자체 수명 동안 안정된 이름과 가상 IP로 엔드포인트를 연결합니다. 선택자가 있는 Service의 Pod 주소·준비 상태는 EndpointSlice로 관리되며, 이것이 요청을 중계하는 프록시라는 뜻은 아닙니다.
일반적인 ClusterIP Service에서 선택자에 맞는 Pod의 엔드포인트가 EndpointSlice로 관리되는 관계입니다. 연결·흐름은 데이터 경로 구현이 선택한 사용 가능한 엔드포인트로 전달됩니다. EndpointSlice는 요청이 통과하는 프록시가 아니며 headless·ExternalName·선택자 없는 Service는 제외합니다.
선택은 보통 연결·흐름 단위로 이루어집니다. HTTP keep-alive의 요청마다 새 Pod를 선택한다고 보장하지 않으며, 데이터 경로·세션 고정 설정에 따라 달라집니다.
| Service | 주소와 접근 조건 |
|---|---|
| ClusterIP | 클러스터 내부 가상 IP를 제공합니다. headless(clusterIP: None)는 이 가상 IP 없이 DNS로 엔드포인트를 찾는 별도 방식입니다. |
| NodePort | 노드 IP와 지정 포트를 접점으로 제공합니다. 외부 접근에는 실제 라우트·방화벽·노드 주소 조건이 필요합니다. |
| LoadBalancer | 지원하는 컨트롤러·클라우드 구현이 LB를 마련합니다. 자원 선언만으로 모든 환경에서 외부 LB가 생기지는 않습니다. |
| ExternalName | DNS CNAME을 반환하며 ClusterIP나 프록시를 만들지 않습니다. HTTP Host·TLS 이름 불일치도 확인합니다. |
Ingress는 외부 HTTP/HTTPS 트래픽을 클러스터 내부 서비스로 라우팅하는 규칙입니다.
실제 동작에는 AWS Load Balancer Controller 같은 해당 환경의 Ingress Controller가 필요합니다. Kubernetes community의 Ingress NGINX는 2026년 3월 유지보수 종료 대상으로 공지되었으므로 현재 운영 예시로 그대로 선택하면 안 됩니다. 같은 이름이 포함된 다른 공급자의 컨트롤러와도 구분해야 합니다.
최근에는 더 표현력이 높은 Gateway API도 함께 사용됩니다.
결국 VPC의 서브넷, Docker의 브리지 네트워크, Kubernetes의 Service 모두 앞서 배운 네트워크 기본 개념 — IP 주소, 서브넷, NAT, 라우팅, 로드 밸런싱 — 의 가상화된 적용입니다.
문제를 좁힐 때는 VPC 라우트·SG/NACL, Pod 주소·정책, Service 선택자·EndpointSlice, 외부 진입 컨트롤러를 구분해 확인합니다. 추상화 계층의 설정 성공이 실제 데이터 경로의 성공을 대신하지는 않습니다.
다음 장에서는 네트워크 문제를 체계적으로 진단하는 트러블슈팅 방법론과 도구를 다루겠습니다.