위의 그림을 보면 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
들 간의 통신이 가능하도록 해줍니다.
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을 참고해주세요.