Kube-Proxy
위의 그림을 보면 Worker Node 안쪽에 Kube-Proxy는 컴포넌트를 확인할 수 있습니다.
Kube-Proxy는 Kubernetes에서 네트워크 동작을 관리하는 컴포넌트입니다.
Kube-Proxy는 모든 Worker Node에 하나씩 위치하고 있는데, Kubernetes의 오브젝트 중 모든 오브젝트에 하나씩 위치하는 오브젝트인 DaemonSet의 형태로 배포되어 있습니다.
# DaemonSet 조회
$ kubectl get daemonset --all-namespaces
Kube-Proxy는 모든 Worker Node에 DaemonSet의 형태로 위치하여, 서로 다른 Worker Node의 Pod들 간의 통신이 가능하도록 해줍니다.
Kube-Proxy 동작 원리
Proxy의 사전적 의미는 대리인입니다.
네트워크에서도 Proxy는 서버와 클라이언트 사이에서 대리인으로써 동작합니다.
어떤 서버가 Proxy의 역할을 수행하기 위해서는 interface가 필요합니다.
말은 어려울수도 있지만, 생각해보면 정말 당연한 이야기입니다.
서버와 클라이언트 사이에서 대리인으로써 중계를 해주기 위해서는 서버 및 클라이언트와 통신할 수 있는 interface를 가지고 있어야 합니다.
Kube-Proxy가 설치된 위치는 Worker Node입니다.
클라우드 환경에서 해당 Worker Node를 구성했다고 가정할 경우 Worker Node는 두 가지 interface를 가지고 있습니다.
위 그림에서 보시다시피 하나는 Worker Node Host의 interfcae(그림에서 eth0)이고, 하나는 pod의 interface(그림에서 veth0, veth1)입니다.
Kubernetes에서 Pod들 사이의 통신에서 이 Host interface와 pod interface를 사용하면 정상적으로 통신이 될까요?
물론 통신은 됩니다. 하지만, 문제가 생겼을 때 Node나 Pod을 쉽게 교체하는 Kubernetes의 특징에서 유추해 볼 때 Host나 Pod의 interface를 사용할 경우 문제가 생겨 해당 자원이 교체되었을 때 문제가 생길것입니다.
그렇기 때문에 Kubernetes 환경에서 자원이 교체되어도 안정적으로 운영되는 네트워크 환경을 구성하기 위해서는 다른 방법이 필요합니다.
Kube-proxy는 netfilter와 iptables를 통해서 이를 해결했습니다.
만약 위 그림의 왼쪽 Host의 Client pod이 오른쪽 Host의 Server pod1으로 요청을 보낸다고 생각해보겠습니다.
Client pod이 Server pod1이 위치한 Host의 veth0의 IP인 10.0.2.2를 알고 있다면 바로 해당 IP로 요청을 전달하면 됩니다.
위에 router/gateway에 라우팅 테이블이 설정되어 있기 때문입니다.
하지만, Pod의 interface의 IP는 언제라도 바뀔 수 있기 때문에 어느 순간 서비스가 정상적으로 동작하지 않을지도 모릅니다.
Kube-proxy는 새로운 Cluster IP가 생성되거나 Pod이 추가될 때, 자신이 동작하고 있는 Node의 iptables에 룰을 추가하여 줍니다.
또한, Node Port와 같은 Service를 통해 외부에 port를 노출시켜야 할 때, 그 port를 Listen하는 역할을 담당합니다.
Kubernetes에서의 보다 상세한 네트워크 흐름은 같은 시리즈의 Kubernetes-Networking을 참고해주세요.
