[Kubernetes] CNI와 Kube Proxy

CNI(Container Network Interface)

• CNI는 쿠버네티스 클러스터 환경에서 파드 간의 네트워킹 및 라우팅을 도와준다. 이게 없으면 ip link add 와 같은 명령어로 세팅해줘야한다. 그러므로 무조건 설치해야한다.
• CNI는 파드에 IP를 부여한다.
• 컨테이너를 어떤 네트워크에 붙일지 정의한다.
• 컨테이너가 지워졌을때 네트워크 플러그인(Bridge)를 실행시키는 책임을 갖는다.
• 설정 파일이 JSON 포맷으로 이루어져 있다.
• CNI 종류로는 WeaveNet, Calico, Flannel 등이 있다

IP 명령어

ip link

CNI도 네트워크 인터페이스이기 때문에 네트워크 인터페이스 정보를 조회할 수 있다.
위의 명령어로 어떤 브릿지를 사용하는지 등의 검색을 할 수 있다.

ip addr

 

네트워크 인터페이스의 IP 정보를 조회할 수 있다.

Network Range를 확인 할 수 있으며 네트워크 인터페이스 카드 첫번째인 eth0을 확인하면 된다.

ip route

 

워커 노드로 들어가서 위의 명령어를 입력해보면 CNI로 부터 연결된 라우팅 연결 주소를 확인할 수 있다.

CNI Weave 설치

kubectl apply -f https://github.com/weaveworks/weave/releases/download/v2.8.1/weave-daemonset-k8s.yaml

 

• 대표적인 CNI인 WeaveNet을 위의 명령어로 설치한다.
• Weave는 DeamonSets로 관리된다.
• Weave는 각 노드에 에이전트 배치해서 사용한다.
• Weave는 파드 간 통신 패킷을 캡슐화한다.
• 설치 후 k get po -n kube-system -o wide 을 해보면 각 node에 에이전트인 peer pod가 설치된 것을 확인할 수 있다.

 

Pod에 구성된 IP 주소 범위 조회

즉 weave가 어떤 IP 주소 범위로 Pod에 IP를 할당할 것인지 결정하는 것을 로깅으로 볼 수 있다.

k logs <weave-pod-name> -n kube-system

Service에 구성된 IP 주소 범위 조회

find / -name "*apiserver*"
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep "range"

 

설치된 CNI 확인

k get ds -A

위의 명령어로 현재 설치된 CNI를 확인할 수 있다.

ps -aux | grep kubelet

위 명령어로 현재 설치된 CNI Plugin에 대한 경로를 확인 할 수 있다.

물론 위 명령어로 조회되지 않아도 시스템의 PATH에 따라 바이너리를 찾는 방식을 사용하는 경우라고 볼 수 있다.

가장 확실한 건 /opt/cni 경로에 CNI 제공 파일이 있고 /etc/cni 경로에 CNI 플러그인에 대한 설정 파일이 있다.

그 외로 Container Runtime Endpoint도 위의 명령어로 확인해볼 수 있다.

 

설치되어있지 않은 상태로 Pod를 Describe 해보면 아래처럼 에러가 발생한다.

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "55a62649a70f9eb7fef79fb7992f1139f81c8916c777dfd67c55149b8ed2e936": plugin type="weave-net" name="weave" failed (add): unable to allocate IP address: Post "http://127.0.0.1:6784/ip/55a62649a70f9eb7fef79fb7992f1139f81c8916c777dfd67c55149b8ed2e936": dial tcp 127.0.0.1:6784: connect: connection refused

Kube Proxy

 

Kube Proxy도 CNI 처럼 Daemonset을 통해 Pod띄워서 사용한다.

CNI로 네트워크 구성을 했다면 Proxy는 적절한 백엔드 파드로 트래픽을 포워딩하여 서비스를 제공하는 기능을 담당한다.

kube-proxy가 어떤 네트워크 방식으로 구성됐는지 조회

k logs kube-proxy-2j7z6 -n kube-system

조회를 해보면 iptables, userspace, ipvs 중 하나다.

• iptable - 가장 일반적인 선택
• userspace - 성능 이슈로 안씀
• ipvs - 대규모 클러스터에 적합