https://morioh.com/p/ecb38c8342ba

간단 요약

part 1

Kubernetes Networking Model

• 모든 Pod은 고유의 IP를 가진다.
• Pod IP는 Pod 내부의 모든 컨테이너와 공유한다. 그리고 모든 다른 Pod들과 routable 하다.
• k8s노드에서 구동되는 어떤 정지 컨테이너들은("pause" containers) sandbox 컨테이너라 부르고, 유일한 job은 network namespace (netns, pod내부의 모든 컨테이너들에게 공유됨)를 보존하고 유지하는 역할이다. ( https://www.ianlewis.org/en/almighty-pause-container )
• pod IP는 컨테이너가 죽거나 새로운 컨테이너로 대체된다고 해도 변하지 않는다.
• IP-per-pod 모델의 큰 장점은 호스트 내에서 ip/port 충돌이 절대 발생하지 않으며, 어플리케이션이 어떤 포트를 사용하는지 염려할 일이 없다는 것이다.
• k8s의 유일한 요구사항은 Pod IP들이 다른 모든 pod들에게 어떤 노드들이든 routable/accessible 한지 여부이다.

Intra-node communication

• k8s node root network namespace

root netns에 eth0 네트워크 인터페이스가 존재

• pods

비슷하게, 각 pod는 netns가 있고, vitual 이더넷 pair 연결이 root netns에 연결되어 있다. 기본 pipe-pair. root netns - pod netns

pod는 eth0 네트워크 인터페이스를 가지며, pod는 호스트에 대해서 알지 못하고, 자신의 root network setup만 있는 것으로 인지한다. 다른 end 인터페이스는 vethxxx 이다.

ifconfig 또는 ip a 로 당신의 노드에 있는 모든 네트워크 인터페이스 목록을 확인할 수 있다.

노드의 모든 pod가 서로 통신하기 위해서 리눅스 이더넷 브릿지인 cbr0이 사용된다. docker도 유사하게 docker0으로 이름을 지었다. 브릿지 리스트를 확인하려면 brctl show 명령어를 이용하면 된다.

패킷이 pod1에서 pod2로 간다고 해보자.

1. 패킷이 pod1 netns eth0을 떠나 root netns의 vethxxx로 들어간다.
2. ARP 리퀘스트를 사용해서 목적지를 발견하는 cbr0에게 던진다 "who has this IP?"
3. vethyyy 가 응답한다. 브릿지는 패킷을 어디로 보내야할지 이제 알게 되었다.
4. 패킷이 vethyyy로 도달하면, pipe-pair를 거쳐서 pod2의 netns에 도착한다.

docker도 동일한 방식으로 동작한다.

Inter-node communication

pods는 노드 사이를 거쳐서 도착해야 한다. k8s는 그 방식에 대해서 신경써주지 않는다. L2(노드간을 교차하는 ARP), L3(IP 라우팅 - 클라우드가 라우트 테이블을 제공하듯이), overlay 네트워크, 또는 carrier pigeons (전서구??) ( https://en.wikipedia.org/wiki/IP_over_Avian_Carriers ) ( IP(Internet Protocol)을 전서구에 실어서 보내자! April fool 인듯) 모든 노드는 유일한 pod IP들의 CIDR 블록으로 할당되어 있어서, 다른 노드의 pod들 ip와 충돌하지 않는다.

대부분의 경우, 클라우드 환경에서 클라우드 프로바이더 라우트 테이블은 패킷이 정확한 목적지에 도착하도록 해준다. 많은 종류의 네트워크 플러그인들이 존재한다.

이제 두 노드가 있고, 각 노드는 다양한 네트워크 네임스페이스, 네트워크 인터페이스, 브릿지를 가지고 있다고 하자.

패킷이 pod1에서 pod4(다른 노드)로 간다고 가정해보자.

1. 패킷이 pod1 netns eth0에서 root netns vethxxx 로 향한다.
2. cbr0을 통과하는데, cbr0은 목적지를 찾는 ARP 리퀘스트를 생성한다.
3. 패킷이 cbr0을 떠나 메인 네트워크 인터페이스 eth0으로 간다. 누구도 pod4 IP를 가진 노드가 없기 때문이다.
4. node1 머신을 떠난다. src=pod1 에서 dst=pod4 정보를 엮어서
5. 라우트 테이블은 각 노드의 CIDR블록을 셋업하고 있고, 패킷을 어떤 노드의 CIDR 블록이 pod4 IP를 포함하고 있는지 찾는다.
6. 패킷이 메인 네트워크 인터페이스 eth0의 node2에 도착한다.
7. pod4가 eth0의 IP가 아니더라도, 노드가 IP와 엮여 설정되어 있으므로 패킷은 cbr0에게 포워딩된다.
8. 노드의 라우팅 테이블 pod4 IP와 매칭되는지 확인한다. 곧 노드의 CIDR블록의 목적지로서 cbr0를 찾아낸다.
9. route -n 명령어를 이용하여 노드 라우트 테이블 리스트를 볼 수 있다. cbr0의 라우트를 보여줄 것이다.

10. 브릿지가 패킷을 가져가고 APR 리퀘스트를 하여 vethyyy IP를 찾는다.
11. 패킷이 pipe-pair 를 거쳐 pod4에 도착한다.

part 2

overlay networks 가 동작하는 원리를 살펴보자. 또한 pod의 변화가 k8s위에 실행하는 앱으로부터 추상화되는 방법을 이해하게 될 것이다.

Overlay networks

오버레이 네트워크는 필수옵션은 아니다. 그러지만 특정한 상황에서 도움이 된다. IP 공간이 충분하지 않을 경우, 네트워크가 외부의 routes를 다루지 못할때와 같은 상황이다. 또는 오버레이가 제공하는 어떤 부가적인 운영 피처들을 필요로 할수도 있다. 공통적으로 보는 케이스는 클라우드 프로바이더가 라우트 테이블을 제공할 수 있는 라우트 제한(limit)수치가 얼마인가이다. 예를 들어 AWS 라우트 테이블은 50 routes 까지는 네트워크 성능에 영향을 주지 않는다. 그러므로 k8s 노드가 50개를 넘어설 경우에 AWS 라우트 테이블은 충분치 않을 것이다. 이러한 경우에 오버레이 네트워크가 도움이 된다.

노드 사이에 네이티브 네트워크를 횡단하는 경우 패킷-내-패킷 encapsulating 이 필수적이다. 모든 패킷을 캡슐-디캡슐화 해야하는 latency와 복잡성의 오버헤드 때문에 오버레이 네트워크 사용을 원하지 않을 수도 있다. 오버레이 네트워크는 자주 필요하진 않다. 때문에 필요성이 확실히 있을 경우에만 사용해야 한다.

오버레이 네트워크 위에서 트래픽 흐름이 어떻게 진행되는지를 이해하기 위해서, flannel의 예를 살펴보도록 하자. CoreOS의 오픈소스이다.

root netns에 flannel0 가상 이더넷 디바이스가 추가된다. flannel은 가상확장 LAN (VXLAN)의 구현인데, 리눅스에게 있어서는 그저 다른 네트워크 인터페이스일 뿐이다.

다른 노드의 pod1에서 pod4로 전달하는 패킷의 플로우는 아래와 같다.

1. 패킷이 eth0에 pod1의 netns를 떠나 vethxxx의 root netns 로 진입한다.

2. 패킷이 cbr0 에 들어와 APR 리퀘스트를 통해 목적지를 찾는다.

3. 1. 노드의 누구도 pod4에 대한 IP 주소를 가지고 있지 않기 때문에 브릿지가 flannel0으로 패킷을 보낸다. 노드의 라우트 테이블이 flannel0의 pod 네트워크 range에 대해서 타겟으로 설정 구성되어 있기 때문이다.
   2. flanneld 데몬은 모든 pod IP를 알고 있는 k8s apiserver 또는 etcd를 호출하여, 어떤 노드에 속하는지를 알아낸다. flannel은 pod IP -> 노드 IP의 맵핑을 만들어낸다. (in userspace)

   flannel0 이 이 패킷을 잡아서 UDP 패킷 + extra 헤더를 만들고, source 와 destination IP를 관련 노드로 변경하여 특별한 vxlan port 로 보낸다. (일반적으로 8472 포트)

   

   맵핑이 유저스페이스(userspace)에 있다 해도, 실제적인 캡슐화와 데이터 플로우는 커널 스페이스에서 이루어진다. 따라서 상당히 빠르다.

   3. 캡슐화된 패킷은 노드 트래픽의 라우팅에 속해 있기 때문에 eth0 으로 보내진다.

4. 패킷은 노드 IP를 source, destination 으로 하고 노드를 떠난다.

5. 클라우드 프로바이더 라우트 테이블은 노드간의 라우트 트래픽이 어떤 방식인지를 이미 알고 있어서 목적지 node2에 패킷을 보낸다.

6. 1. 패킷이 node2의 eth0에 도착한다. 포트가 특별한 vxlan 포트이기 때문에 커널은 패킷을 flannel0 으로 보낸다.
   2. flannel0 은 패킷의 캡슐화를 풀고, root netns (network namespace)으로 되돌려 보낸다(emit it back)
   3. IP 포워딩이 가능하므로 커널은 cbr0으로 보내 라우트 테이블을 참조하게 한다.

7. 브릿지가 패킷을 잡아 APR 리퀘스트를 만들어 vethyyy 에 속한 IP임을 찾는다.

8. 패킷이 pipe-pair를 가로질러 pod4에 도달한다.

다른 구현에 따라서 조금씩 다를 수 있다. 그러나 k8s의 오버레이 네트워크의 기본적인 동작방식이다. k8s를 사용하면서l 오버레이 네트워크를 반드시 사용해야할 것 같은 보편적인 오해가 있다. 그러나 사실은 특별한 시나리오 상황에서 사용할지가 결정되는 것이다. 따라서 절대적으로 사용이 필요할 때만 사용해야 한다.

part 3

An illustrated guide to Kubernetes Networking [Part 3] Cluster dynamics Due to the every-changing dynamic nature of Kubernetes, and distributed systems in general, the pods (and consequently their IPs) change all the time. Reasons could range from desired rolling updates and scaling events to unpredictable pod or node crashes. This makes the Pod IPs unreliable for using directly for communications.

Enter Kubernetes Services — a virtual IP with a group of Pod IPs as endpoints (identified via label selectors). These act as a virtual load balancer, whose IP stays the same while the backend Pod IPs may keep changing.

The whole virtual IP implementation is actually iptables (the recent versions have an option of using IPVS, but that’s another discussion) rules, that are managed by the Kubernetes component — kube-proxy. This name is actually misleading now. It used to work as a proxy pre-v1.0 days, which turned out to be pretty resource intensive and slower due to constant copying between kernel space and user space. Now, it’s just a controller, like many other controllers in Kubernetes, that watches the api server for endpoints changes and updates the iptables rules accordingly.

Due to these iptables rules, whenever a packet is destined for a service IP, it’s DNATed (DNAT=Destination Network Address Translation), meaning the destination IP is changed from service IP to one of the endpoints — pod IP — chosen at random by iptables. This makes sure the load is evenly distributed among the backend pods.

When this DNAT happens, this info is stored in conntrack — the Linux connection tracking table (stores 5-tuple translations iptables has done: protocol, srcIP, srcPort, dstIP, dstPort). This is so that when a reply comes back, it can un-DNAT, meaning change the source IP from the Pod IP to the Service IP. This way, the client is unaware of how the packet flow is handled behind the scenes.

So by using Kubernetes services, we can use same ports without any conflicts (since we can remap ports to endpoints). This makes service discovery super easy. We can just use the internal DNS and hard-code the service hostnames. We can even use the service host and port environment variables preset by Kubernetes.

Protip: Take this second approach and save a lot of unnecessary DNS calls!

Outbound traffic The Kubernetes services we’ve talked about so far work within a cluster. However, in most of the practical cases, applications need to access some external api/website.

Generally, nodes can have both private and public IPs. For internet access, there is some sort of 1:1 NAT of these public and private IPs, especially in cloud environments.

For normal communication from node to some external IP, source IP is changed from node’s private IP to it’s public IP for outbound packets and reversed for reply inbound packets. However, when connection to an external IP is initiated by a Pod, the source IP is the Pod IP, which the cloud provider’s NAT mechanism doesn’t know about. It will just drop packets with source IPs other than the node IPs.

So we use, you guessed it, some more iptables! These rules, also added by kube-proxy, do the SNAT (Source Network Address Translation) aka IP MASQUERADE. This tells the kernel to use IP of the interface this packet is going out from, in place of the source Pod IP. A conntrack entry is also kept to un-SNAT the reply.

Inbound traffic Everything’s good so far. Pods can talk to each other, and to the internet. But we’re still missing a key piece — serving the user request traffic. As of now, there are two main ways to do this:

NodePort/Cloud Loadbalancer (L4 — IP and Port) Setting the service type to NodePort assigns the service a nodePort in range 30000-33000. This nodePort is open on every node, even if there’s no pod running on a particular node. Inbound traffic on this NodePort would be sent to one of the pods (it may even be on some other node!) using, again, iptables.

A service type of LoadBalancer in cloud environments would create a cloud load balancer (ELB, for example) in front of all the nodes, hitting the same nodePort.

Ingress (L7 — HTTP/TCP)

A bunch of different implements, like nginx, traefik, haproxy, etc., keep a mapping of http hostnames/paths and the respective backends. This is entry point of the traffic over a load balancer and nodeport as usual, but the advantage is that we can have one ingress handling inbound traffic for all the services instead of requiring multiple nodePorts and load balancers.

Network Policy Think of this like security groups/ACLs for pods. The NetworkPolicy rules allow/deny traffic across pods. The exact implementation depends on the network layer/CNI, but most of them just use iptables.

That’s all for now. In the previous parts we studied the foundation of Kubernetes Networking and how overlays work. Now we know how the Service abstraction helping in a dynamic cluster and makes discovery super easy. We also covered how the outbound and inbound traffic flow works and how network policy is useful for security within a cluster.

...