서비스·네트워킹 (Services/Networking)
서비스·네트워킹 (Services/Networking)
Kubernetes 안에서 네트워킹을 담당하는 개념과 리소스에 대한 안내예요.
Kubernetes 네트워크 모델
Kubernetes 네트워크 모델은 몇 가지 조각으로 이루어져 있어요.
- 클러스터 안의 각 pod은 클러스터 전체에서 유일한 자체 IP 주소를 가져요.
- pod은 자기만의 사설 네트워크 네임스페이스를 갖는데, 이 네임스페이스는 pod 안의 모든 컨테이너가 함께 공유해요. 같은 pod의 서로 다른 컨테이너에서 실행 중인 프로세스는
localhost를 통해 서로 통신할 수 있죠.
- pod은 자기만의 사설 네트워크 네임스페이스를 갖는데, 이 네임스페이스는 pod 안의 모든 컨테이너가 함께 공유해요. 같은 pod의 서로 다른 컨테이너에서 실행 중인 프로세스는
- pod 네트워크(클러스터 네트워크라고도 불러요)는 pod 간 통신을 처리해요. (의도적인 네트워크 분할이 없다면) 다음을 보장하죠.
- 모든 pod는 같은 노드에 있든 다른 노드에 있든 다른 모든 pod와 통신할 수 있어요. pod는 프록시나 주소 변환(NAT) 없이 서로 직접 통신할 수 있어요.
Windows에서는 호스트 네트워크를 쓰는 pod에는 이 규칙이 적용되지 않아요.
- 노드의 에이전트(시스템 데몬이나 kubelet처럼요)는 그 노드의 모든 pod와 통신할 수 있어요.
- Service API를 쓰면 하나 이상의 백엔드 pod가 구현하는 서비스에 안정적인(오래 유지되는) IP 주소나 호스트네임을 제공할 수 있어요. 이때 서비스를 구성하는 개별 pod는 시간이 지나면서 바뀔 수 있어요.
- Kubernetes는 EndpointSlice 객체를 자동으로 관리해서 Service를 현재 뒷받침하고 있는 pod에 대한 정보를 제공해요.
- 서비스 프록시 구현체는 Service와 EndpointSlice 객체의 집합을 감시하면서, 운영체제나 클라우드 제공자의 API를 이용해 패킷을 가로채거나 다시 써서 서비스 트래픽을 백엔드로 라우팅하도록 데이터 플레인을 프로그래밍해요.
- Gateway API(또는 그 전신인 Ingress)를 쓰면 클러스터 바깥의 클라이언트가 Service에 접근할 수 있게 만들 수 있어요.
- 더 단순하지만 덜 설정 가능한 클러스터 인그레스 수단은, 지원되는 클라우드 제공자를 쓸 때 Service API의
type: LoadBalancer로 쓸 수 있어요.
- 더 단순하지만 덜 설정 가능한 클러스터 인그레스 수단은, 지원되는 클라우드 제공자를 쓸 때 Service API의
- NetworkPolicy는 pod 간, 또는 pod와 바깥 세상 사이의 트래픽을 제어할 수 있게 해주는 Kubernetes 내장 API예요.
옛날 컨테이너 시스템에서는 서로 다른 호스트에 있는 컨테이너 간에 자동 연결이 없어서, 컨테이너 사이에 링크를 명시적으로 만들거나 컨테이너 포트를 호스트 포트로 매핑해야 다른 호스트의 컨테이너가 접근할 수 있었어요. Kubernetes에서는 그럴 필요가 없어요. Kubernetes의 모델은, 포트 할당·이름 짓기·서비스 디스커버리·로드 밸런싱·애플리케이션 구성·마이그레이션이라는 관점에서 pod를 VM이나 물리 호스트처럼 취급할 수 있다는 거예요.
이 모델 중 Kubernetes 자신이 구현하는 부분은 일부뿐이에요. 나머지 부분은 Kubernetes가 API를 정의하지만, 해당 기능은 외부 컴포넌트가 제공하며 일부는 선택적이에요.
- pod 네트워크 네임스페이스 설정은 Container Runtime Interface를 구현하는 시스템 수준 소프트웨어가 처리해요.
- pod 네트워크 자체는 pod 네트워크 구현체가 관리해요. Linux에서는 대부분의 컨테이너 런타임이 Container Networking Interface(CNI)를 써서 pod 네트워크 구현체와 상호작용하므로, 이런 구현체를 흔히 CNI 플러그인이라고 불러요.
- Kubernetes는 서비스 프록싱의 기본 구현체로 kube-proxy를 제공하지만, 일부 pod 네트워크 구현체는 대신 나머지 구현과 더 긴밀하게 통합된 자체 서비스 프록시를 쓰기도 해요.
- NetworkPolicy도 일반적으로 pod 네트워크 구현체가 함께 구현해요. (더 단순한 일부 pod 네트워크 구현체는 NetworkPolicy를 구현하지 않거나, 관리자가 NetworkPolicy 지원 없이 pod 네트워크를 구성하기로 선택할 수도 있어요. 이 경우 API는 여전히 존재하지만 아무 효과가 없어요.)
- Gateway API 구현체는 다양해요. 특정 클라우드 환경에 특화된 것도 있고, "베어메탈" 환경에 더 초점을 맞춘 것도 있으며, 더 범용적인 것도 있죠.
다음 단계
Connecting Applications with Services 튜토리얼을 통해 실습 예제로 Services와 Kubernetes 네트워킹을 배울 수 있어요.
Cluster Networking 문서는 클러스터 네트워킹을 어떻게 구성하는지 설명하고, 관련 기술 전반을 개괄적으로 보여줘요.
구체적인 네트워킹 개념을 배우려면 다음을 참고하세요.
- Service - 애플리케이션을 단일 외부 지향 엔드포인트 뒤에 노출하기
- Ingress - URI, 호스트네임, 경로를 사용하는 프로토콜 인지형 HTTP/HTTPS 라우팅
- Gateway API - 동적 인프라 프로비저닝과 고급 트래픽 라우팅
- Network Policies - IP 주소나 포트 수준(OSI 3·4계층)에서 트래픽 흐름 제어
- DNS for Services and Pods - DNS로 클러스터 안의 서비스 디스커버리