Overview
이번 글에서는 Kubernetes에서의 네트워크 트래픽 흐름과 각 컴포넌트 간 통신 구조에 대해 정리해보았다.
Kubernetes는 컨테이너 오케스트레이션 플랫폼인 만큼 Pod, Service, Ingress 등 다양한 컴포넌트가 네트워크를 통해 상호작용한다. 이 구조는 클러스터 내부뿐 아니라 외부 트래픽과의 연결에서도 중요한 역할을 하며, CSP(클라우드 환경)과 온프레미스 환경에서의 동작 방식에 따라 설정과 구성 방식이 달라진다.
이번 정리에서는 다음과 같은 내용을 다루었다.
- 클라우드 환경(CSP) vs 온프레미스 환경에서의 트래픽 흐름 차이
- Ingress Controller, LoadBalancer Controller 간의 관계
- MetalLB를 통한 온프레미스 LoadBalancer 구현
- Pod, Service, Node 간의 통신 구조 및 구성 요소 역할
- Container-to-Container / Pod-to-Pod / Pod-to-Service / 외부-내부 통신 흐름
Kubernetes Network
Kubernetes 클러스터의 트래픽 흐름은 CSP(클라우드 서비스 제공업체) 환경과 온프레미스(On-premise) 환경은 차이점이 있다. 각 환경에서의 트래픽 흐름을 설명하려고 한다.
CSP 환경에서의 트래픽 흐름
- 외부 Load Balancer: 클라우드 제공업체는 외부 트래픽을 클러스터 내로 라우팅하기 위한 Load Balancer를 제공한다. 이는 클러스터 밖에 위치하며, 외부에서 들어오는 요청을 서비스나 인그레스 컨트롤러에 전달한다.
- Ingress Controller/Service: Ingress Controller는 HTTP/HTTPS 트래픽을 처리하고, `type: LoadBalancer`인 서비스는 그 외의 프로토콜을 처리한다. 이들은 클라우드 Load Balancer로부터 트래픽을 받아 적절한 Pod으로 라우팅한다.
- Pods: Pod은 애플리케이션의 컨테이너를 실행하는 최소 단위이다. Service 또는 Ingress를 통해 트래픽이 이들에게 전달된다.
온프레미스 환경에서의 트래픽 흐름
- 외부 Load Balancer/Router: 온프레미스 환경에서는 자체적으로 구성된 Load Balancer 또는 라우터가 외부 트래픽을 클러스터 내로 라우팅한다. 이는 온프레미스 데이터 센터 내에 위치한다.
- Ingress Controller/Service: 이 단계는 CSP 환경과 유사하다. Ingress Controller는 HTTP/HTTPS 트래픽을 처리하고, `type: LoadBalancer`인 서비스는 그 외의 프로토콜을 처리한다. 이들은 외부 Load Balancer/Router로부터 트래픽을 받아 적절한 Pod으로 라우팅한다.
- Pods: 온프레미스 환경에서도 Pod은 애플리케이션의 컨테이너를 실행하는 최소 단위로 동일하다.
CSP 환경에서의 인그레스 컨트롤러
CSP 환경에서 인그레스 컨트롤러는 종종 클라우드 제공 업체의 로드 밸런서 서비스와 통합된다.
인그레스 컨트롤러 서비스 유형이 LoadBalancer로 설정되면, 클라우드 제공 업체는 자동으로 외부 IP 주소(일반적으로 공용 IP)를 할당하고, 이 IP는 클라우드 로드 밸런서의 IP 주소가 된다.
이렇게 할당된 IP 주소를 통해 외부 트래픽은 클라우드 로드 밸런서를 거쳐 인그레스 컨트롤러로 라우팅되고, 최종적으로 적절한 파드로 전달된다.
CSP (Cloud Service Provider) 환경에서의 인그레스 컨트롤러와 로드 밸런서 컨트롤러의 관계를 설명한다.
- 인그레스 컨트롤러 (Ingress Controller)
- 인그레스 컨트롤러는 쿠버네티스 클러스터 내에서 실행되는 소프트웨어이다. 인그레스 리소스를 관찰하고, 이 리소스에 정의된 라우팅 규칙을 구현한다.
- 인그레스 컨트롤러는 트래픽을 적절한 서비스와 파드로 전달하는 역할을 한다.
- 로드 밸런서 컨트롤러 (Load Balancer Controller)
- 클라우드 환경에서 로드 밸런서 컨트롤러는 보통 클라우드 제공 업체가 관리하는 별도의 서비스이다.
- 이 서비스는 외부 트래픽을 쿠버네티스 클러스터로 라우팅하는 역할을 한다.
- 통합 작업
- 쿠버네티스 서비스가 LoadBalancer 유형으로 생성될 때 (예: 인그레스 컨트롤러를 위해), 클라우드 제공 업체는 자동으로 외부 IP 주소를 할당하고 로드 밸런서를 구성한다.
- 이 로드 밸런서는 외부 트래픽을 받아 인그레스 컨트롤러로 전달한다. 인그레스 컨트롤러는 그 후 쿠버네티스 내의 적절한 서비스나 파드로 트래픽을 라우팅한다.
- CSP 환경의 특징
- CSP 환경에서는 일반적으로 인그레스 컨트롤러와 로드 밸런서가 긴밀하게 통합되어 있으며, 사용자는 로드 밸런서를 별도로 관리할 필요가 없다.
- 대신, 쿠버네티스 서비스를 구성하고 인그레스 리소스를 정의함으로써, 자동으로 클라우드 제공 업체의 로드 밸런싱 기능을 활용할 수 있다.
결론적으로, CSP에서의 인그레스 컨트롤러는 클라우드 제공 업체의 로드 밸런서와 긴밀하게 통합되어 있으며, 이를 통해 외부 트래픽을 클러스터 내의 적절한 서비스나 파드로 효율적으로 라우팅할 수 있다.
온프레미스 환경에서의 인그레스 컨트롤러
온프레미스 환경에서는 LoadBalancer 유형의 서비스가 자동으로 외부 IP를 할당받지 않는다.
대신, 일반적으로 온프레미스 네트워크에서 관리하는 외부 로드 밸런서 또는 라우터를 사용해야 한다.
이 경우, 외부 로드 밸런서 또는 라우터에 수동으로 IP 주소를 설정하고, 해당 IP를 인그레스 컨트롤러 또는 서비스로 트래픽을 라우팅하도록 구성한다.
온프레미스 환경에서는 NodePort 또는 ClusterIP 서비스 유형을 사용하여 인그레스 컨트롤러에 접근할 수 있으며, 외부 로드 밸런서가 이 서비스 유형에 맞게 트래픽을 라우팅한다.
따라서, 온프레미스 서버에서 인그레스 컨트롤러가 외부 IP(로드 밸런서 IP)를 가지고 있는 경우, 이는 보통 네트워크 구성 또는 수동 설정의 결과다. CSP 환경과 달리, 온프레미스 환경에서는 자동 IP 할당이 일반적이지 않다.
MetalLB(Onpremise LoadBalancer)
2023.05.03 - [Container Orchestration/Kubernetes] - MetalLB란?
MetalLB는 온프레미스 쿠버네티스 클러스터에서 LoadBalancer 서비스 유형을 지원하도록 설계된 솔루션이다. 일반적으로 클라우드 환경에서 제공되는 로드 밸런서 기능을 온프레미스 환경에서 사용할 수 있게 해준다.
MetalLB 설정에서 IP 주소 풀을 지정하면, MetalLB는 이 풀에서 IP 주소를 동적으로 할당하여 쿠버네티스의LoadBalancer 유형 서비스에 IP 주소를 제공한다. 이렇게 할당된 IP 주소는 외부에서 쿠버네티스 클러스터로의 접근 지점으로 사용한다.
예를 들어, MetalLB 설정에서 다음과 같이 IP 주소 범위를 지정할 수 있다.
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: example-pool
spec:
addresses:
- 192.168.1.100-192.168.1.150- MetalLB는 192.168.1.100에서 192.168.1.150 사이의 IP 주소를 LoadBalancer 서비스에 할당할 수 있다.
- 인그레스 컨트롤러를 LoadBalancer 서비스로 배포하면 MetalLB가 이 IP 풀에서 IP 주소를 자동으로 할당하여 인그레스 컨트롤러에 제공한다. 이 IP 주소는 외부에서 인그레스 컨트롤러로 트래픽을 라우팅하는 데 사용된다.
- 결론적으로, MetalLB를 사용하면 온프레미스 환경에서도 클라우드와 유사한 방식으로 LoadBalancer 서비스를 사용할 수 있게 되어, 인그레스 컨트롤러에 자동으로 IP 주소를 할당받을 수 있다.
그리고 Ingress-nginx-controller도 필요하다.
apiVersion: v1
kind: Service
metadata:
name: ingress-nginx-controller
spec:
type: LoadBalancer
selector:
app.kubernetes.io/name: ingress-nginx
ports:
- port: 80
targetPort: http
Component간 Kubernetes Network
Kubernetes 네트워킹은 Kubernetes 내의 다양한 엔터티 유형이 통신할 수 있도록 설계되었다.
- Container-to-container networking
- Pod-to-Pod networking
- Pod-to-Service networking
- Internet-to-Service networking
Container-to-container networking
단일 Pod 내에서 Kubernetes를 사용하면 여러 컨테이너가 동일한 네트워크 네임스페이스를 공유할 수 있다. 이는 동일한 Pod 내의 컨테이너가 동일한 IP 주소와 포트 공간을 공유하므로 localhost를 사용하여 서로 통신할 수 있음을 의미한다.
이러한 Pod 내 통신은 긴밀하게 함께 작동해야 하는 컨테이너(예: 기본 애플리케이션 컨테이너 및 기본 애플리케이션을 기록하거나 모니터링하는 사이드카 컨테이너)에 매우 중요하다.
Pod-to-Pod networking
Kubernetes를 사용하면 모든 노드에 파드용으로 지정된 CIDR IP 범위가 있다. 이렇게 하면 모든 파드가 클러스터의 다른 파드에서 볼 수 있는 고유한 IP 주소를 수신하게 된다.
Kubernetes는 NAT(Network Address Translation) 없이 파드가 노드 간에 서로 통신할 수 있도록 보장한다. 각 파드는 고유한 IP 주소를 가져오므로 모든 파드가 어떤 노드에 있는지에 관계없이 이 IP 주소를 사용하여 클러스터의 다른 파드와 통신할 수 있다.
이는 CNI(컨테이너 네트워크 인터페이스) 표준을 구현하는 기본 네트워크 플러그인을 통해 달성되며, 다양한 구현(예: Calico, Flannel 또는 Cilium)은 이 노드 간 파드 간 통신을 활성화하는 다양한 방법을 제공한다.
보안 관점의 통신 제어(Kubernetes Network Policy)
NetworkPolicy는 Kubernetes 클러스터에서 Pod 간의 통신을 세밀하게 제어할 수 있는 리소스이다. 기본적으로 Kubernetes에서는 모든 Pod 간 통신이 허용되어 있으나, NetworkPolicy를 적용하면 특정 Pod 간 트래픽을 허용하거나 차단할 수 있어 보안적으로 매우 중요하다.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-nginx
spec:
podSelector:
matchLabels:
app: nginx
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
Pod-to-Service networking
쿠버네티스에서 서비스(Service)는 파드(Pod)들에 대한 안정적인 인터페이스를 제공한다. 서비스는 특정 파드의 집합에 대한 요청을 중재하고, 트래픽을 적절한 파드로 라우팅하는 역할을 합니다. 각 서비스는 ClusterIP라고 불리는 고유한 IP 주소를 가지며, 이 주소는 서비스를 안정적으로 유지한다.
- 파드(Pod): 각 파드는 쿠버네티스 클러스터 내에서 실행되는 애플리케이션의 인스턴스이다. 파드는 자체 IP 주소를 가지고 있으며, 다른 파드와 통신할 수 있다.
- 가상 브릿지(Virtual Bridge): 파드 내의 eth0과 veth 페어를 통해 연결된다. 이 브릿지는 파드가 노드의 네트워크와 통신할 수 있도록 하는 중간 통신 역할을 한다.
- 노드(Node): 클러스터의 물리적 또는 가상의 머신이다. 각 노드는 여러 파드를 호스팅하며, kube-proxy를 통해 네트워크 트래픽을 관리한다.
- kube-proxy: 노드 내에서 실행되며, iptables 또는 IPVS를 사용하여 트래픽을 서비스의 ClusterIP로 라우팅하고, 서비스의 파드 선택 알고리즘(예: 라운드 로빈)에 따라 트래픽을 적절한 파드에게 전달한다.
- 서비스(Service): 파드의 논리적 집합을 대표하고, 클라이언트가 파드의 개별 IP를 알 필요 없이 일관된 방법으로 파드에 접근할 수 있게 한다. ClusterIP를 사용해 클러스터 내부에서 파드에 접근할 수 있으며, 필요에 따라 외부로 노출될 수도 있다 (예: NodePort, LoadBalancer).
- 클러스터 네트워크(Cluster Network): 클러스터 전체에서 통신을 가능하게 하는 네트워크이다. 노드 간 통신 및 파드 간 통신이 이 네트워크를 통해 이루어진다.
NodePort, ClusterIP, LoadBalancer 비교
쿠버네티스에서 서비스(Service)는 파드 접근을 위한 추상화 계층이다. 대표적인 3가지 유형이다.
| 유형 | 설명 | 접근 범위 |
| ClusterIP | 기본값, 클러스터 내부에서만 접근 가능 | 내부 전용 |
| NodePort | 각 노드의 특정 포트를 통해 외부에서 접근 가능 | 외부 접근 (노드IP + 포트) |
| LoadBalancer | 클라우드 환경에서 외부 로드 밸런서를 자동 생성하고 공인 IP 부여 | 퍼블릭 접근 |
외부 서비스 연동 - ExternalName 서비스
Kubernetes에서 ExternalName 서비스는 클러스터 외부의 DNS 이름을 내부 서비스처럼 매핑할 수 있도록 해준다.
apiVersion: v1
kind: Service
metadata:
name: my-db
spec:
type: ExternalName
externalName: database.example.com
- 이 서비스를 사용하면 Pod에서 1my-db` 라는 서비스 이름으로 외부 호스트에 접근할 수 있다.
Internet-to-Service networking
두 가지 방법으로 외부 네트워크에 애플리케이션을 노출할 수 있다.
- Egress: Kubernetes Service에서 인터넷으로 트래픽을 라우팅하려는 경우 이를 사용한다. 이 경우 iptables는 소스 NAT를 수행하므로 트래픽이 Pod가 아닌 노드에서 나오는 것처럼 보인다.
- Ingress: 외부 세계에서 서비스로 들어오는 트래픽이다. Ingress는 또한 연결 규칙을 사용하여 서비스와의 특정 통신을 허용하고 차단한다. 일반적으로 서로 다른 네트워크 스택 지역에서 작동하는 두 가지 ingress 솔루션, 즉 서비스 Load Balacner와 Ingress Controller가 있다.
CNI 플러그인 종류 및 차이점 (Calico vs Flannel vs Cilium)
쿠버네티스에서 CNI(Container Network Interface)는 Pod 간 통신을 위한 핵심 네트워크 구현체입니다. 주요 CNI 플러그인 비교는 아래와 같다.
| CNI | 특징 | 정책 지원 | 성능 | eBPF |
| Calico | 네트워크 정책 및 보안 기능 풍부, BGP 지원 | ✅ | 우수 | 일부 지원 |
| Flannel | 가장 단순한 오버레이 네트워크 구조, VXLAN 기반 | ❌ | 보통 | ❌ |
| Cilium | eBPF 기반 고성능, L3/L4/L7 정책까지 지원 가능 | ✅ | 매우 우수 | ✅ |
eBPF 기반 네트워크 (Cilium)
eBPF는 커널 수준에서 고성능 네트워크 처리를 가능하게 해주는 기술이다. Cilium은 eBPF 기반 CNI로 L3~L7까지 트래픽을 정책으로 제어하며, 특히 관찰성, 보안성, 성능 면에서 뛰어난 장점을 제공한다.
- L7까지의 정책 지원
- Envoy와 통합 가능
- 서비스 메시 대체 가능 (Sidecarless)
- Zero-trust 네트워킹 기반
참고 : 2024.02.02 - [Networking, Security, Protocols] - Cilium이란?
마무리: “쿠버네티스 네트워크 구조를 이해하는 첫걸음”
Kubernetes의 네트워크는 복잡해 보일 수 있지만, 핵심은 Pod 간 통신이 NAT 없이 가능해야 하며, 서비스가 클러스터 내에서 안정적인 접근 지점을 제공해야 한다는 원칙이다.
클라우드 환경에서는 CSP가 제공하는 LoadBalancer와 Ingress Controller가 자동으로 통합되며, 외부에서 클러스터로의 접근이 간편해진다.
반면, 온프레미스 환경에서는 MetalLB, 외부 라우터, 수동 IP 설정 등을 통해 네트워크 구성을 직접 해야 하는 경우가 많다.
또한, Kubernetes의 CNI(Container Network Interface) 구현체인 Calico, Flannel, Cilium 등을 선택하면 내부 네트워크 정책, 성능, 보안 등에서 다양한 최적화를 할 수 있다.
쿠버네티스를 사용하는 데 있어 네트워크 구조를 명확히 이해하고 있어야
- 애플리케이션 디버깅
- 서비스 노출 전략
- 보안 정책 설계
- 클러스터 확장 및 고가용성 구성
등에서 안정적이고 예측 가능한 운영이 가능해진다.
Reference
https://opensource.com/article/22/6/kubernetes-networking-fundamentals
https://learn.microsoft.com/ko-kr/azure/virtual-network/kubernetes-network-policies
https://www.researchgate.net/figure/Kubernetes-Network-routing-to-export-the-services_fig1_337362475
https://kubernetes.io/ko/docs/concepts/cluster-administration/networking/
'Container Orchestration > Kubernetes' 카테고리의 다른 글
| Kubernetes Volumes 및 StorageClass: CSI 드라이버 사용 가이드 (0) | 2024.04.28 |
|---|---|
| Kubernetes Affinity 및 Scheduling 설정 가이드 (0) | 2024.04.19 |
| Kubernetes 클러스터 구축하기(kubespray 2024v.) (0) | 2024.02.02 |
| k3d(k3s in docker)란? (2) | 2024.01.14 |
| kind(Kubernetes in Docker)란? (2) | 2024.01.13 |