네트워크 스터디 2주차 - Pause Container 와 k8s CNI(Flannel)

네트워크 스터디 2주차

 

 

<0. 지식의 흐름 정리:>

지난 주 복습. 종호님이 한 번 흐름을 놓치면 따라 올 수가 없다고 하셔서, 지난주에 배운 주요 개념을 다시 랩업했고, 2주차에는 격리된 네트워크 네임스페이스 개념이 또 다시 활용되었다. 지난번에는 도커 단에서 리눅스, 도커 관점에서 살펴봤다면, 이번에는 쿠버네티스 까지 영역을 확장한다. 스터디의 초점이 우선 네트워크이기 때문에 직접적으로 쿠버네티스의 전반적인 내용을 다룰 수 없고, 네트워크 관점에서 중요한 부분을 살펴볼려고한다. 쿠버네티스에서는 kube-proxy라는 녀석이 컨테이너의 네트워킹을 담당하고, 우리가 쿠버네티스 운영과정에서 사용했던 kubelet 명령어로 어떤 일들이 일어나는지 자세하게 배워보자.

 

 

 

====================================================================================

 

<1. 쿠버네티스에 대해서 알아보자>

 

해당 내용의 출처는 

https://blog.naver.com/love_tolty/222167051615

 

기본적으로 쿠버네티스를 사용할때 kubectl이라는 명령어 도구를 활용하는 데 이는 기본적으로 Control plane에 존재하는 api 서버를 활용해서 명령어를 내리고, 저장해야하는 정보들을 etcd에 저장해서 이뤄지기 때문에, kubectl을 기반으로 쿠버네티스 내부의 리소소들을 쉽게 관리할 수 있는 것이다.

 

 

 

 

api 서버를 통해 동작한다는 기본 개념만 안다면 답답하지 않았을 듯해서, 제 사례에 기반해서 공유드립니다. 

 

다른 분들에게 도움이 될지 모르겠는데, 쿠버네티스를 공부할때 yaml 파일 내 속성이 정확하게 무엇을 가리키는지 공식문서에서 찾기가 너무 힘들어서 너무 답답했었다. 하지만 결국 쿠버네티스 동작 원리를 이해하고, 결국 해당 정보가 어딨는지 정확하게 알게되었는데

 

https://github.com/kubernetes/kubernetes/blob/release-1.31/api/openapi-spec/swagger.json

kubernetes/api/openapi-spec/swagger.json at release-1.31 · kubernetes/kubernetes

ㅁ

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#

Kubernetes API Reference Docs

yaml 파일을 작성할때 내가 적는 속성이 올바른지 알게되고, 정확하게 무엇을 뜻하는지 알게되었다. 

 

해당 json 파일 https://editor.swagger.io/ 여기에 업로드하면 더 보기 쉽게 구동가능하다. 하지만 크롬에서 하니까 뻑이 남

 

예시) 

 

이런형태로 정확하게 컨테이너 안에 volume이 mount 되어야 하는 위치를 가리키고, ':' 이 포함되면 안된다는 것을 정확하게 알 수 있다.

 

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#volumemount-v1-core

Kubernetes API Reference Docs

 

조금더 정확하게 kublet에 대해서 살펴보면 

 

CRI를 조금 살펴보다가....... 중국인 분 github 까지 들어왔는데, chatgpt 도움받아서 보게되니 더 이해가 잘되었습니다.

 

 

https://github.com/JaneLiuL/kubernetes-book/blob/master/%E5%BC%80%E6%94%BE%E6%8E%A5%E5%8F%A3/CRI.md

kubernetes-book/开放接口/CRI.md at master · JaneLiuL/kubernetes-book

 

(중국인 github 요약) - dockershim은 이제 사용되지 않아서 x표시를 함

 

 

kubelet이 뭐냐고 물어보면 Container Runtime interface고 

고수준의 Container Runtime은 containerd와 crio-o가 있고 -> 이게 결국 저수준(추상화가 덜되어 있는 단의 조작)까지 내려가서 runC를 통해 OCI Image 조작하는 것

 

 

이 과정에서 우리는 몰랐는데 -> Pause 컨테이너가 네트워크 관점에서 매우매우 중요한 역할을 함.

 

 

 

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/dockershim-deprecation.html

dockershim에서 containerd로 마이그레이션 - Amazon EKS

 

 

 

 

1년 전에 링크드인에서 좋아요를 눌러놧는데, 이제 다시보니 더 이해가 잘된다. 

https://www.linkedin.com/pulse/containerd%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%B4%EA%B3%A0-%EC%99%9C-%EC%A4%91%EC%9A%94%ED%95%A0%EA%B9%8C-sean-lee/?trackingId=F5jG0HiIJWS5y67sIxMufA%3D%3D

 

 

 

이제 자연 스럽게 그럼 Pause 컨테이너가 뭔데? 

<2.  Pause 컨테이너에 대해서 알아보자>

 

 

Pause 컨테이너는 리눅스의 네임스페이스 격리기술을 활용해서 네트워크 네임스페이스를 공유해서 컨테이너간의 네트워크 통신을 할 수 있게 해준다.

 

처음에는 docker ps 가 pause 컨테이너와 관련이 있나 싶었다. 하지만 

 

 

 

 

하지만 아래의 글에서 언급된 "pause"는 pause 컨테이너와 관련이 있다.

 

 

쿠버네티스는 각 파드에 대해 특별한 컨테이너를 생성하여, 이 컨테이너의 유일한 목적이 다른 컨테이너들에게 네트워크 인터페이스를 제공하는 방식으로 이 패턴을 구현합니다.

 

만약 쿠버네티스 클러스터 노드에 SSH로 접속하여 해당 노드에 스케줄링된 파드가 있을 때 docker ps 명령어를 실행하면,

적어도 하나의 컨테이너가 pause 명령어로 시작된 것을 볼 수 있습니다.

 

pause 명령어는 신호를 받을 때까지 현재 프로세스를 일시 중단시키는 역할을 하므로, 이 컨테이너들은 실제로 아무 일도 하지 않고(pause) 단지 쿠버네티스가 SIGTERM 신호를 보낼 때까지 대기합니다.

 

이런 비활성 상태에도 불구하고 "pause" 컨테이너는 파드의 핵심 역할을 하며, 모든 다른 컨테이너들이 서로 및 외부와 통신할 수 있도록 가상 네트워크 인터페이스를 제공합니다. 따라서 가상적으로 파드와 같은 것을 상상해본다면, 마지막 그림은 이런 구조를 나타내고 있다고 볼 수 있습니다.

 

 

해당 글은 구글에서 공식 발간한 글이고, 시리즈가 3개여서 앞으로 스터디 주제 정리할때 활용예정

 

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

 

 

<3.  k8s network cni(Flannel)>

doccker ps 했을때 핑크색으로 한 부분이 안보인다. 그게 핵심 차이 d in d vs dod

 

사용자 인증이 통과 했기 때문에 API 서버 호출 가능

 

 

Flannel is a simple and easy way to configure a layer 3 network fabric designed for Kubernetes. # 공식 github 설명

 

Layer 3: 네트워크 계층(Network Layer) – 네트워크 간의 데이터 전송을 담당하며, 주로 IP 주소 기반의 라우팅을 수행합니다. 패킷을 목적지로 전달하는 계층입니다.

 

Flannel 을 파악하기 위해 kind 클러스터 활용하여 실습 진행

 

쿠버네티스 네트워킹에는 다음과 같은 요구사항이 있고, 이를 해결해야 함. flannel cni가 이를 도와줌.

 

 

 

Kind 클러스터를 구성해서 Flannel 실습을 준비함

 

A. 네트워크 네임스페이스 격리 파드가 없을 떄 (단순 control-plane, worker, woker-2 구성)

 

for i in myk8s-control-plane myk8s-worker myk8s-worker2; do echo ">> node $i <<"; docker exec -it $i cat /run/flannel/subnet.env ; echo; done

 

명령어 수행

 

FLANNEL_SUBNET은 control-plane, 워커 노드에 각각 할당 가능한 pod 대역대를 가리킴

 

 

 

 

워커 노드 (k8s-worker 접속) 해서 flannel의 네임스페이스 정보를 살펴보면

 

네트워크 네임스페이스를 (루트)호스트와 공유하기 때문에

 

 

flannel 서버의 ip는 node의 ip와 동일함. 왜냐하면 네트워크 네임스페이스를 호스트와 공유함

proxy도 노드(서버)의 ip와 동일함

 

왜냐하면 네트워크 네임스페이스를 호스트와 공유함

flannel 기본정보를 조금 살펴보면 

 

ip -c link | grep -E 'flannel|cni|veth' -A1  명령어를 통해서 살펴보면

 

worker 서버의 ip라고 생각하면 됨(etho0과 pair)

이 값은 실제로는 host 도커에서 kind network의 bridge의 inspect 정보 

 

 

 

172.20.0.2/16 값 확인 함.

 

flannel interface 확인함

 

 

B. 네트워크 네임스페이스 격리 파드가 있을 때 (2개 생성)

 

 

작업을 카페에서 하다가 -> 집으로 와서 해서 그런건지? ….. [우선 개념 이해하는 데는 문제 없음] worker-2는 문제 없엇음

 

ip -c -d addr show cni0 # 네트워크 네임스페이스 격리 파드가 1개 이상 배치 시 확인됨  (물음표 된 영역이 나옴)

 

이것도 원래 보이면 안됨

 

 

 

cni, kube-proxy가 pod cidr 대역대랑 통신할 수 있도록 셋팅해놓음 (flannel 플러그인이 알아서 해줌)

 

# iptables NAT 테이블 정보 확인 : 10.244.0.0/16 대역 끼리 통신은 마스커레이딩 없이 통신을 하며, # 10.244.0.0/16 대역에서 동일 대역(10.244.0.0/16)과 멀티캐스트 대역(224.0.0.0/4) 를 제외한 나머지 (외부) 통신 시에는 마스커레이딩을 수행  - 맨 마지막 줄 해석

 

 

 

worker2는 없었음

노드 셀렉터 사용

 

 

 

 

동일 노드에 파드 통신: flannel.1 거치지 않음 - 기본 인터페이스가 cni0임

다른 노드에 있는 있는 파드간의 통신: flannel.1을 거침

파드에서 외부 통신: iptable 마스쿼레이딩 - wireshark를 통해서 확인함(당연히 eth0을 거침) - 캡슐화 되어서 안보이는 것임

pod-1 접속

 

 

# GW IP는 어떤 인터페이스인가? (1) flannel.1 (2) cni0  

 

GW IP -> 10.244.1.1

 

worker 에 접속해서 확인 해보면  cni0 라는 것을 확인 가능함

 

 

pod에서의 Gateway IP는 cni0 인터페이스가 잡힘

 

 

당연히 flannel.1 인터페이스랑(10.244.1.0)도 통신은 됨

 

 

다른 노드의 pod(10.244.2.2)랑도 통신 가능함

 

# 덤프 실습 1. ping 10.244.2.2 (pod 1 -> pod 2로 ping 수행) // cni0(tcpdump 수행 위치)

결과:  worker, wokrer-2 에서 둘다 확인 가능함

 

 

 

# 덤프 실습 2. ping 8.8.8.8 (외부통신) // cni0(tcpdump 수행 위치)

결과:  worker에서만 확인 가능함

 

 

 

# 덤프 실습 3. ping 8.8.8.8 (외부통신) // flannel.1(tcpdump 수행 위치)

결과: 확인 되는 곳 없음 -> 외부 통신 할때는 cni0에서 바로 가능

 

 

 

덤프 실습을 통해서 결과 도출 됨

 

 즉  flannel.1 인터페이스는 다른 노드의 pod와 오버레이 네트워킹이 필요할 때만 필요함 (뒤에서 와이어샤크 활용)

 

 

 

# 덤프 실습 4. ping 8.8.8.8 (외부통신) // etho0(tcpdump 수행 위치)

결과:  worker 에서 확인됨

 

 

 

 

# 덤프 실습 5. ping 10.244.2.2 (pod 1 -> pod 2로 ping 수행) // etho0(tcpdump 수행 위치)

결과:  worker에서 확인 되지 않음 -> 이유는 캡슐화 되어 있기 때문에(vxlan overlay)

 

 

 

 

 

패킷이 캡쳐하고 파일로 떨굼

 

 

 

wireshark를 통해서 분석함

 

 

flannle.1 에서 - 오버레이 패킷을 만듬

 

 

 

======================================================================================

99. < 종호님이 수업 도중에 궁금하면 추가적으로 찾아보라고 언급하신 부분들> -  Chatgpt의 도움을 받았습니다. 실제로도 그런지 다시 확인하겠습니다. 제 생각과도 다른 점이 없어서 우선 기재했습니다. 

 

 

1. pause 컨테이너의 cgroup은 host의 namespace를 같이 씀

 

 

 

 

 

2. kind 클러스터 내의 /etc/resolv.conf는 호스트 머신의 dns 설정을 따르는지 여부. 

 

 

 

3. 왜 MTU 사이즈가 65485야? -> 오버레이 네트워크에서 더 큰 패킷을 처리하기 위해서

 

 

 

 

=====================================================

100.  지난주에 제가 잘못이해했던 D in D, DoD 는 다시 정리해서 1주차에 반영하겠습니다. 혹시 제가 작성한 내용중에 잘못된 부분이 있으면 그냥 이거 틀렸다라고 정도로만 남겨주시면 제가 반영하겠습니다.