Kubernetes 네트워킹 이해하기
Kubernetes 네트워크 모델, 서비스, DNS, NAT outgoing, 듀얼 스택 네트워킹 개념을 배경 지식으로 정리한 문서예요. Calico 배포를 이해하는 토대가 되는 내용을 다뤄요. Calico 고유의 기능이라기보다 네트워킹 일반 교육 자료라는 점을 알아 두세요.
출처: 문서
본문
SECONDARY: 이 가이드는 Calico에 국한되지 않는 선택적인 배경 교육 자료예요.
Kubernetes는 다양한 네트워킹 환경과 네트워크 구현에서 단순함과 일관성을 제공하는 네트워크 모델을 정의해요. Kubernetes 네트워크 모델은 Kubernetes 안에서 컨테이너, 파드, 서비스가 서로 어떻게 통신하는지 이해하는 기초를 제공해요. 이 가이드는 핵심 개념과 그 개념들이 서로 어떻게 맞물리는지 설명해요.
이 가이드에서 배우게 될 내용은 다음과 같아요:
- Kubernetes 네트워크 모델이 정의하는 근본적인 네트워크 동작
- Kubernetes가 다양한 네트워크 구현과 함께 동작하는 방식
- Kubernetes 서비스란 무엇인가
- Kubernetes 안에서 DNS가 동작하는 방식
- "NAT outgoing"이 무엇이고 언제 사용하면 좋은지
- "듀얼 스택"이란 무엇인가
Kubernetes 네트워크 모델
Kubernetes 네트워크 모델은 다음을 규정해요:
- 모든 파드는 자기만의 IP 주소를 받아요
- 파드 안의 컨테이너들은 파드 IP 주소를 공유하고 서로 자유롭게 통신할 수 있어요
- 파드는 파드 IP 주소를 사용해 클러스터의 다른 모든 파드와 통신할 수 있어요(NAT 없이)
- 격리(각 파드가 통신할 수 있는 대상 제한)는 네트워크 정책으로 정의해요
그 결과 파드는 VM이나 호스트와 아주 비슷하게 다뤄질 수 있고(모두 고유한 IP 주소를 갖죠), 파드 안의 컨테이너는 VM이나 호스트 안에서 실행되는 프로세스와 아주 비슷하게 다뤄질 수 있어요(같은 네트워크 네임스페이스에서 실행되고 IP 주소를 공유하죠). 이 모델 덕분에 애플리케이션을 VM과 호스트에서 Kubernetes가 관리하는 파드로 옮기기가 쉬워져요. 게다가 격리가 네트워크 구조가 아니라 네트워크 정책으로 정의되기 때문에, 네트워크는 이해하기 쉬운 단순한 상태를 유지해요. 이런 스타일의 네트워크를 흔히 "플랫 네트워크"라고 불러요.
아주 드물지만 필요한 경우에 대비해, Kubernetes는 호스트 포트를 파드로 매핑하거나, 파드를 호스트 네트워크 네임스페이스 안에서 직접 실행해 호스트의 IP 주소를 공유하는 기능도 지원한다는 점을 알아 두세요.
Kubernetes 네트워크 구현
Kubernetes 내장 네트워크 지원인 kubenet은 기본적인 네트워크 연결성을 제공할 수 있어요. 하지만 더 흔한 방식은 CNI(Container Network Interface) API를 사용해 Kubernetes에 연결되는 서드파티 네트워크 구현을 사용하는 거예요.
CNI 플러그인 종류는 매우 다양하지만, 크게 두 가지가 있어요:
- 네트워크 플러그인: 파드를 네트워크에 연결하는 역할을 해요
- IPAM(IP 주소 관리) 플러그인: 파드 IP 주소를 할당하는 역할을 해요
Calico는 네트워크 플러그인과 IPAM 플러그인을 모두 제공하고, AWS, Azure, Google 네트워크 CNI 플러그인, host-local IPAM 플러그인을 포함한 다른 CNI 플러그인과도 원활하게 통합해 함께 동작할 수 있어요. 이 유연성 덕분에 여러분의 요구 사항과 배포 환경에 맞는 최적의 네트워킹 옵션을 고를 수 있어요. 자세한 내용은 Calico 최적 네트워킹 옵션 결정 가이드에서 확인할 수 있어요.
Kubernetes 서비스
Kubernetes 서비스는 파드 그룹에 대한 접근을 네트워크 서비스로 추상화하는 방법을 제공해요. 파드 그룹은 보통 레이블 셀렉터로 정의해요. 클러스터 안에서 네트워크 서비스는 보통 가상 IP 주소로 표현되고, kube-proxy가 그 가상 IP로 들어오는 연결을 서비스를 지원하는 파드 그룹에 걸쳐 로드 밸런싱해요. 가상 IP는 Kubernetes DNS를 통해 찾을 수 있어요. DNS 이름과 가상 IP 주소는 서비스의 수명 동안 변하지 않아요. 서비스를 지원하는 파드가 만들어졌다 사라지고, 그 수가 시간에 따라 바뀌어도 그래요.
Kubernetes 서비스는 클러스터 밖에서 서비스에 접근하는 방법도 정의할 수 있어요. 예를 들면:
- 노드 포트: 모든 노드의 특정 포트를 통해 서비스에 접근할 수 있어요
- 로드 밸런서: 네트워크 로드 밸런서가 가상 IP 주소를 제공하고, 클러스터 밖에서 그 주소로 서비스에 접근할 수 있어요.
온프레미스 배포에서 Calico를 사용하면 서비스 IP 주소 광고도 할 수 있어요. 노드 포트나 로드 밸런서를 거치지 않고도 편하게 서비스에 접근할 수 있게 되죠.
Kubernetes DNS
모든 Kubernetes 클러스터는 DNS 서비스를 제공해요. 모든 파드와 모든 서비스는 Kubernetes DNS 서비스를 통해 찾을 수 있어요.
예를 들면:
- 서비스:
my-svc.my-namespace.svc.cluster-domain.example - 파드:
pod-ip-address.my-namespace.pod.cluster-domain.example - 배포가 만든 파드를 서비스로 노출한 경우:
pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example
DNS 서비스는 하나 이상의 DNS 서버 파드(보통 CoreDNS)에 매핑되는 Kubernetes 서비스로 구현돼요. 이 파드들은 다른 파드처럼 스케줄링돼요. 클러스터의 파드들은 DNS 서비스를 사용하도록 구성되어 있고, DNS 검색 목록에는 파드 자신의 네임스페이스와 클러스터 기본 도메인이 포함돼요.
이 말은 Kubernetes 네임스페이스 bar에 foo라는 이름의 서비스가 있다면, 같은 네임스페이스의 파드는 foo로, 다른 네임스페이스의 파드는 foo.bar로 그 서비스에 접근할 수 있다는 뜻이에요.
Kubernetes는 다양한 시나리오에서 DNS를 제어할 수 있는 풍부한 옵션을 지원해요. 자세한 내용은 Kubernetes 가이드 서비스와 파드를 위한 DNS에서 확인하세요.
NAT outgoing
Kubernetes 네트워크 모델은 파드가 파드 IP 주소로 서로 직접 통신할 수 있어야 한다고 규정해요. 하지만 파드 IP 주소가 클러스터 경계 너머까지 라우팅 가능해야 한다고까지는 요구하지 않아요. 많은 Kubernetes 네트워크 구현은 오버레이 네트워크를 사용해요. 이런 배포에서는 보통 파드가 클러스터 밖 IP 주소로 연결을 시작하면, 파드를 호스팅하는 노드가 패킷의 소스 주소를 파드 IP에서 노드 IP로 SNAT(소스 네트워크 주소 변환) 매핑해요. 덕분에 노드 IP는 라우팅 가능하기 때문에 연결이 네트워크의 나머지 부분을 통과해 목적지까지 라우팅될 수 있어요. 연결의 응답 패킷은 노드가 자동으로 다시 매핑해서, 파드에게 패킷을 포워딩하기 전에 노드 IP를 파드 IP로 되돌려 놓아요.
Calico를 사용하면 환경에 따라 오버레이 네트워크를 선호할지, 완전히 라우팅 가능한 파드 IP를 선호할지 일반적으로 선택할 수 있어요. 자세한 내용은 Calico 최적 네트워킹 옵션 결정 가이드를 참고하세요. Calico는 더 세밀한 제어가 필요하다면 특정 IP 주소 범위에 대해 아웃바운드 NAT를 구성할 수도 있게 해 줘요.
듀얼 스택
IPv4와 IPv6를 섞어 쓰고 싶다면 Kubernetes 듀얼 스택 모드를 활성화할 수 있어요. 활성화하면 모든 파드가 IPv4와 IPv6 주소를 모두 할당받고, Kubernetes 서비스는 IPv4로 노출될지 IPv6로 노출될지 지정할 수 있어요.
추가 리소스
더 알아보기 (Learn more)
Kubernetes 네트워크 모델은 "파드마다 고유 IP, NAT 없는 파드 간 통신, 정책 기반 격리"를 규정해요. 서비스는 가상 IP와 DNS 이름으로 파드 그룹을 추상화하고, 클러스터 밖 트래픽은 보통 SNAT를 거쳐요. 오버레이와 라우팅 가능 파드 IP 중 무엇을 택할지는 배포 환경에 따라 결정하세요.