[Kubernetes] 쿠버네티스 트래픽 전달방식 아키텍처

Kuberntes 트래픽 전달 아키텍처

---

이번 포스팅에서 외부에서 쿠버네티스에 요청이 왔을 때 어떤식으로 동작하는지 내부 아키텍처에 대해 알아보겠습니다.

 

1. 현재 아키텍처 구성요소 설명

Load Balancer: 외부에서 들어오는 트래픽을 클러스터 내부로 라우팅하는 진입점 트래픽을 여러 노드에 균등하게 부하를 분산시킵니다.

kubelet: 각 노드에서 실행되는 핵심 에이전트이며 마스터노드(API 서버)와 통신을 담당합니다. 컨테이너가 pod에서 실행되도록 관리하며 pod의 사양에 따라 컨테이너가 정상적으로 실행되는지 모니터링합니다.

kube-proxy: 각 노드에서 실행되는 네트워크 프록시다. pod 네트워크 서비스를 관리하고 pod 간 통신을 처리한다. 쿠버네티스의 service 추상화를 구현한다.

iptables: 리눅스 커널의 네트워크 규칙을 설정한다. 클러스터 내부의 네트워크 트래픽을 제어하고 라우팅하는데 pod간의 네트워크 정책을 실행한다.

Docker: 컨테이너 런타임 환경을 구성하고, 이미지를 실행하고 관리한다. 쿠버네티스 최신버전 가상화 컨테이너 엔진은 containerd로 변경됐다.

Pod: 쿠버네티스의 가장 작은 배포 단위이며, 하나 이상의 컨테이너를 포함할 수 있다.

 

 

2. 트래픽 흐름

Internet -> Service Load Balancer -> iptables(kube-proxy가 설정한 규칙) -> pod의 컨테이너로 라우팅 -> pod에 컨테이너 Port로 트래픽 라우팅 -> 서비스 응답

 

Pod와 Pod가 통신해야 할 경우

트래픽은 먼저 노드의 iptables로 전달 -> iptables 규칙에 따라 목적지 pod가 있는 노드로 전달 -> 대상 노드의 iptables를 통해 최종 목적지 pod에 도달

 

 

3. 결론

트래픽 흐름은 쿠버네티스의 Service를 통해 Pod 내의 컨테이너로 접속할 수 있게 됩니다. Service는 kube-proxy가 관리하는 서비스 디스커버리를 사용하며 ClusterIP, NodePort, LoadBalancer, ExternalName 와 같은 타입이 있습니다.

이러한 서비스의 추상화 덕분에 Pod가 재생성 되어 IP가 변경 되더라도 클라이언트는 항상 동일한 Service 주소로 접근 가능합니다.

https://weight-devlog.tistory.com/48

[Kubernetes] 쿠버네티스 서비스 디스커버리란?

 

 

 

또한 Ingress 라는 고급 기능을 통해서도 L7 레벨에서 트래픽을 라우팅할 수 있습니다. Ingress 따로 포스팅을 하도록 하겠습니다. 오늘은 서비스 디스커버리중 Load Balancer를 통해 Pod로 트래픽이 라우팅이 되는 내부 아키텍처를 살펴봤습니다.

 

 

 

⚠️참고자료

https://kubernetes.io/docs/concepts/services-networking/service-traffic-policy/

https://isovalent.com/blog/post/cilium-gateway-api/

https://www.f5.com/company/blog/nginx/kubernetes-networking-101