K8S Pod Networking과 Weave CNI 정리

 

< Pod Networking >

 

클러스터 내에서 Pod간의 네트워킹은 다음을 만족해야 한다. 

 

- 모든 포드는 ip 주소를 가져야 한다. 

- 같은 노드의 포드끼리 통신가능해야한다.

- 모든 포드는 NAT없이 다른 노드의 포드들과 통신 가능해야 한다. 

 

위 조건을 만족하기 위해서는 다음과 같은 네트워크 구성을 따라야 한다. 

 

 

 

1. 같은 노드의 포드간 통신  

 

 

1) 포드를 연결할 브릿지 만들어 준다.  

2) 각 포드에 ip 할당한다.  

3) 브릿지와 각 포드의 인터페이스를 연결한다. 

 

같은 노드의 포드간 통신은 브릿지를 통해 이루어진다. 

 

 

 

2. 다른 노드 간의 포드 통신 

 

 

각 노드의 라우팅 규칙에 게이트웨이 경로를 추가한다.

또는 노드를 연결하는 라우터를 두어서 라우팅 규칙을 추가한다. 

게이트 웨이 경로를 추가함으로써 다른 노드의 포드간의 통신까지 가능해진다. 

 

하지만 이 많은 과정을 수작업으로 하기는 힘들다.

그래서 이를 편하게 해주는 CNI 플러그인이다. 

CNI 플러그인을 이용하면 자동으로 위와 같은 네트워킹 구성을 만들어준다. 

 

 

 

 

< CNI 플러그인>

 

CNI 플러그인을 클러스터에 설치하면 클러스터 각 노드의 kubelet 서비스에 configure 된다.  

 

opt/cni/bin 경로에는 실행할 수 있는 cni 플러그인들이 들어 있다. 

 

 

etc/cni/net.d 경로에는  cni confguration 파일이 있다.

이 config파일을 통해 Kubelet이 어떤 플러그인을 사용하는지 확인할 수 있다. 

 

 

cni configuration 파일을 뜯어보자. 

 

 

- 브릿지 타입의 mynet을 생성 

- isGateway는 이 브릿지를 게이트웨이로 사용할 것인지

- ipMasq는 NAT 룰에 ip masquerading이 추가되어야 하는지 말아야하는지 

 - ipam: 파드에 할당될 Ip대역들과 서브넷을 명시한다. 

- host-local은 ip주소가  호스트 내부의 주소다. 

 

 

 

 

 < weave >

 

일반적으로 중간에 라우터를 두어 여러 노드로 라우팅하는 방식은 힘들다.

 

노드 수가 많아지면 라우팅 테이블에 많은 엔트리를 적어야 하고,

라우팅 테이블 엔트리는 그렇게 많은 수를 지원하지 않기 때문이다. 

 

이에 대한 대안으로 패킷 전달에 특화된 agent를 두어 패킷을 주고 받는 방식이 있다.

 

weave가 이 방식이다.  

 

 

각 노드에 weave agent를 파견한 후, weave cni는 각 노드마다 weave 브릿지를 만든다.

(weave는 데몬셋으로 배포된다)

 

브릿지에 IP 할당 후, 포드들을 붙인다.

 

포드 내부에서  Routing 테이블을 확인해 보면,  weave bridge를 통해서 밖으로 나간다.

  

 

 

다른 노드의 포드로 패킷을 전송할 때는 보내는 노드의 weave agent가 패킷을 encapsulate한 후 이를 다른 노드로 보낸다.

이후 패킷을 받은 노드는 agent를 통해 패킷을 decapsulate하여 포드에게 전달한다.