본문 바로가기

데브옵스/K8S

[k8s network] kube-proxy 란? kube-proxy 역할

반응형
반응형

Intro

K8S cluster 내부에서는 컨테이너를 포함한 여러 객체들 간 여러 네트워킹이 이루어집니다. 그 중 주된 케이스는 pod 와 Service 객체 간의 통신이 아닐까 생각됩니다. 수많은 마이크로 서비스가 서로를 호출하고, 호출할 때 K8S 의 Service 객체를 사용하게 되는데요.
 
해당 포스트에는 이러한 흐름과 관련된 K8S Network component, kube proxy에 대해 설명합니다. 
 

K8S Service

kube-proxy 이야기를 하기 전에 Service 객체에 대한 이야기를 하지 않을 수 없습니다.
 
앞서 K8S 클러스터 내의 주된 호출 케이스가 pod - Service 간의 통신이라고 말씀드렸는데요. 그 이유는 쿠버네티스의 pod는 IP가 가변하는 특성을 가지고 있기 때문입니다. Service 객체를 사용해, 가변하는 여러 Pod의 트래픽을 앞단에서 받아낼 수 있습니다.
 
다만, Service 리소스는 CPU 및 메모리와 같은 리소스를 직접 소유하지 않습니다. Service는 단순히 네트워크 레벨에서 서비스의 일관된 인터페이스를 제공하는 가상 IP 주소를 할당하는 역할을 수행합니다. 실제로 클러스터를 구성해 어느정도 맛보기를 해보신 분들은 Service라는 객체가 pod 형태로 뜨지 않는다는 것을 알 수 있는데요.
 
이상하죠? 하지만 무언가 움직이기 위해선 반드시 일해야 하는 것이 있습니다.

무한동력이 아닌 이상 어디선가는 일하고 있습니다.

 

Kube-proxy

결국 실제 Service로 오는 요청을 로드 밸런싱하는 작업은 kube-proxy 컴포넌트가 수행합니다.
따라서 Kube-proxy는 Service를 통해 동작하는 네트워크에 대한 처리를 담당하는, 단어 그대로 proxy 역할을 관장하는 애플리케이션입니다.

1) 쿠버네티스 컨트롤 플레인의 서비스 및 엔드포인트 오브젝트의 추가와 제거를 감시하며, 2) 요청이 Service로 인입됬을 때의 네트워크 처리를 담당합니다.
 
그리고 이러한 특성 때문에, kube-proxy는 데몬셋으로 배포됩니다. 클러스터의 모든 노드에서 서비스 기반으로 통신해야 되기 때문에, 클러스터의 각 node마다 배포되어야 하는 성격을 가지기 때문입니다.
 

Kube-proxy 3가지 Mode

외워둘 필요는 없지만, 이러한 것이 있다는 정도로 알고가면 좋습니다.
 
1) user space 모드
요청 시, iptables를 거쳐 kube-proxy가 직접 프록시 서버를 프로세스로 실행하여 로드 밸런싱을 수행하는 방식. 현재는 권장되지 않는 방식입니다.
 

 
2) iptables 모드 (default)
요청 시, 리눅스 iptables를 이용하여 서비스로 오는 패킷과 나가는 패킷을 제어하는 방식. kube-proxy는 api server를 통해 Service와 pod 정보를 업데이트하고, iptables 규칙만을 업데이트합니다. 실제 트래픽 처리를 커널 단위에서 처리하기 때문에 user space모드 보다 안정적입니다. 현재 kube-proxy 설치 시 default 모드로 동작합니다.
 

 
3) IPVS 모드
요청 시, 리눅스 IPVS를 이용하여 서비스로 오는 패킷과 나가는 패킷을 제어하는 방식. iptables와 유사하지만, IPVS라는 리눅스 커널 기능을 사용합니다. 간단히만 설명 드리면, 클라이언트 요청을 가상 서버 IP 주소로 전달하고, IPVS가 로드 밸런싱 알고리즘에 따라 요청을 올바른 Pod로 전달한다고 하는데요.
 
이 IPVS라는 기능이 해시 테이블을 기본 데이터 구조로 사용하고 커널 스페이스에서 동작하기 때문에, iptables 대비하여 성능 및 확장성에서 강점을 가집니다. 다만 해당 모드를 사용하기 위해서는 노드의 커널 모듈 설정에서 IPVS 모듈이 활성화 되어 있어야 합니다.
 

 
 

마치며

kube-proxy는 K8S 클러스터 내의 주요한 네트워킹을 위한 기본 component입니다. 업데이트 됨에 따라 개선되는 모습을 보여주고 있지만, 최근에는 한계로 인해 e-BPF 기반의 cilium 등의 오픈소스로 대체되는 모습도 보이고 있는데요.
 
하지만 대규모 클러스터 등의 요건이 있지 않다면, 충분히 사용할 만한 기본 서비스라고 생각이 됩니다.
 
지금까지 kube-proxy 에 대한 개념 및 동작방식, 역할에 대해 알아보았습니다.
배워가며 작성하는 블로그입니다.
피드백 및 의견 환영입니다 🙂
 
 
 

반응형