본문 바로가기
IT/Kubernetes

[Kubernetes] Networking - Pods

by 물통꿀꿀이 2019. 4. 27.

이번 포스팅에서는 Pod에서 발생하는 Networking에 대해 알아보려고 한다.

그런데 k8s는 다양한 모델의 Network 방식을 지원한다. 각 모델 마다 특징이 존재하기 때문에 자세한 부분은 아래 URL을 참조하고 일반적인 Network 방식에 대해 알아 본다.

(https://kubernetes.io/docs/concepts/cluster-administration/networking/)


Inter Pod Networking



그림 1. Flat Network (No NAT)


일반적으로 Inter-Pod Network의 구성은 그림 1과 같다. NAT 없이 Pod와 Pod, Pod와 Node(Host)의 통신은 그림 1과 같이 구성되어 있다. 

(설명을 위해 Pod와 Pod 간의 통신으로 제한한다.)

NAT가 존재하지 않고 단일 Network Switch로 구성되는 Flat Network 상에서는 자체적으로 IP를 등록할 수 있다. 그래서 A -> B로 Packet을 전달하는 Networking 과정에서 Source와 Target IP을 항상 고정이 된다. (물론 NAT는 외부로 연결할 때 사용한다.)

그렇다면 어떻게 내부 Network가 구성되고 흘러가는지 아래에서 좀 더 자세히 알아보도록 하자.

그림 2. Network Container & Node


그림 1의 Node를 좀 더 들어간 것이 그림 2로 조금 더 다양한 Network 구성 요소를 확인 할 수 있다.

Pod의 Container가 만들어질 때, 내부적으로 Network Interface의 Pair(Ethernet, Virtual Ethernet)이 생성된다. 여기서 eth0은 Container에서 사용하는 Ethernet이며 veth0은 eth0과 1:1로 연결하는 Virtual Ethernet이다. (그림 2에서는 Container의 Ethernet인 eth0이 표시되지 않았다.)

그리고 eth0의 IP 주소는 Bridge (그림 2는 Docker를 기준으로 하기 때문에 Docker Bridge인 docker0으로 표시한다.)의 주소 범위 내에서 할당 받는다.

그림 3. Network Containers & Node


그림 2에서 알아본 것을 조금 확장하면 그림 3과 같다. Bridge의 주소 범위 내에서 각 Container의 주소가 할당되기 때문에 같은 주소 범위 내에서 Container 간의 통신은 아래와 같이 이루어진다.

eth0(Container 1) -> veth0 -> docker0 -> veth1 -> eth0(Container 2)

그런데 그림 2, 3에서 볼 수 있듯이 Ethernet과 Virtual Ethernet은 1:1 관계를 가지고 있다. 즉, Container가 추가 될 때마다 Virtual Ethernet 또한 계속 추가되는 구조이다. 그래서 단순하게 아래와 같이 사용 한다.

그림 4. Common veth0


그림 4는 Virtual Ethernet을 공통으로 사용하는 방식이다. 인터페이스가 단순해지고 외부에서는 veth0 주소로 접근하면 된다. 반대로 내부는 Localhost로 존재하기 때문에 Container 간에 Port만 다르면 Localhost + Port로 서로 통신 할 수 있다. (그렇기 때문에 Container는 Port의 중복이 있어서는 안된다.)

결과적으로 k8s는 그림 4의 방식이 구조적인 단순화로 다른 Pod와 통신 할 때(내/외부 Pod) 효율적이기 때문에 Node 안에 있는 Pod는 공통 Virtual Ethernet을 사용한다. 


그림 5. Across Nodes


이제까지는 Node 안에서 Container 간의 통신을 알아봤다면 조금 더 확장해서 Node 간 통신에 대해 알아보자. 그림 5에서 확인 할 수 있듯이 Bridge를 타고 Node의 Ethernet을 거쳐 간다. (Bridge, vethx 등의 구성은 무시한다. 적절한 그림을 찾을 수 없어서..) 그리고 각 Node의 Routing Table에 의해 Target Node로 Routing 된다. (중앙에 Router와 함께)

그런데 문제는 Node가 더 늘어날 수록 Router가 추가 될 수록 관리가 점점 어려워진다. 그래서 k8s의 새로운 Network 구성이 도입되었다.

그림 6. Overlay Network


기존이 Layer 3의 Routing을 사용했다면 새로운 Network를 SDN로 구성한다. SDN을 적용하면 수 많은 Node, Network Topology 등등의 복잡한 문제들을 쉽게 다룰수 있다. 그래서 그림 6에서 볼 수 있듯이 Node와 Node 간에 Overlay Network를 적용한다. 

(간단히 살펴보면 가상의 Network 환경을 새롭게 구성하여 통신하는 방식으로 자세한 것은 해당 내용을 넘어서는 부분이기 때문에 자세한 것은 넘어간다. )


현재 해당 방식이 k8s에서 CNI(Container Network Interface) 프로젝트로 진행하고 있는데 그 중 Flannel Plugin 예시는 아래와 같다.

(https://github.com/coreos/flannel#flannel)

그림 7. Flannel Network

Reference

https://medium.com/google-cloud/understanding-kubernetes-networking-pods-7117dd28727

https://medium.com/devopslinks/kubernetes-flat-nat-less-networking-4c12dc4ca78a

https://cloudnativelabs.github.io/post/2017-04-18-kubernetes-networking/

https://kubernetes.io/docs/concepts/cluster-administration/networking/

https://www.slideshare.net/MuratMukhtarov/kubernetes-networking-introduction-to-overlay-networks-communication-models-and-implementation

'IT > Kubernetes' 카테고리의 다른 글

[Kubernetes] Internals - Init Pod  (0) 2019.05.16
[Kubernetes] Namespace  (0) 2019.05.14
[Kubernetes] Networking - Kube Proxy  (0) 2019.04.26
[Kubernetes] Liveness & Readiness Probe  (0) 2019.04.26
[Kubernetes] Storage - StorageClass  (0) 2019.04.21

댓글