KNAS 2주차_1 Flannel

도커로는 다수의 컨테이너를 관리하기가 역부족 -> k8s 등장 

쿠버네티스는 마스터와 워커 노드 2가지로 구분됨 

쿠버네티스의 기본 단위를 파드라고 하며 파드는 1개 이상의 컨테이너로 구성되어 있는 컨테이너 집합 

 

---

 

실습 구성도 

 

flannel에서 노드의 enps08 인터페이스를 사용하도록 설정이 필요

설정없을 시 enp0s3로 설정되어버림 

 

* Add-on? 

- 특정 프로그램의 기능을 보강하기 위한 플러그인 혹은 확장 프로그램 개념 

 

* 컴포넌트

- 재사용이 가능한 독립된 단위 모듈 

 

---

 

CNI Container Network Interface

- 쿠버네티스의 4가지 네트워크 문제를 해결하기 위해 만들어진 Add-on개념

- 오버레이 네트워크 환경을 만들어 통신하게 만들어주는 기능 제공 등등

- 서울 - 부산까지 물리적으로 신호등 다 끼고 국도로 가는 것보다 비행기 타고 스윽 가는것이 편함-> 오버레이

- 네트워크 네임스페이스도 만듦

- ip나 서브넷 등 컨테이너 네트워크 연결과 해제에 대해서 관여 

 

https://ikcoo.tistory.com/117

Network Overlay와 VXLAN

 

---

etcd

- k8s에 관련된 모든 데이터가 들어있는 스토리지

- key-value 형태로 데이터를 저장

 

 

https://tech.kakao.com/2021/12/20/kubernetes-etcd/

Kubernetes 운영을 위한 etcd 기본 동작 원리의 이해

 

---

 

기본 정보 확인 

 

 

k8s의 네임스페이스 의미 

핵심만 콕 쿠버네티스

- 클러스터를 논리적으로 분리하는 개념 

- 네임 스페이스 마다 다른 권한&정책 설정 가능 

- 네임스페이스 안에 존재하는 리소스 : pod , service 

 

 

파드정보 확인

- 보통 kubectl get pod 하면 뒤에 네임스페이스 default가 생략되어 있음

- -A옵션으로 전체 파드 확인 

 

파드 ip가 노드 ip랑 같음 

- 도커네트워크의 host모드를 사용 

 

워커노드 확인 

- kubelet이라는 데몬을 통해 마스터 노드의 api와 통신하면서 동작

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

 

 

---

 

Flannel CNI 

- 가장 단순하고 심플한 CNI

- 여러개 워커노드에 NAT없이 POD가 배포가 된 상황에서 다른 노드에서 IP중복이 생기면 안 되니까 IP를 컨트롤 해줌 

- VXLAN (udp:8472) 지원

- 노드마다 vxlan 통신을 위해 flannel.1 생성 : 가상 이더넷 생성 vtep 

- 노드마다 cni0 생성 : 브릿지역할 ( l2스위치 ) 

 

https://ikcoo.tistory.com/101

 

https://ikcoo.tistory.com/101

- 파드의 veth0 -> cni0 (브릿지) -> flannel.1 -> nat -> 외부 

- 쿠버네티스에서 두 노드간 nat 없이 통신할 수 있도록 해주어야 하니 cni가 필요

- 네트워크 확장된 것 처럼 overlay 느낌으로 flannel 인터페이스가 터널처럼 가상 네트워크를 만들어야함 

 

 

flannel 대역 확인 

#cat /run/flannel/subnet.env

- 클러스터의 모든 파드가 사용할 네트워크 대역 172.16.0.0/16

 

- 각 워커 노드마다 서브넷을 통해 네트워크 대역을 나눠서 파드들의 ip 중복을 피함 

- 각 노드마다 중복되지 않는 네트워크 대역을 사용하게끔 설정되어 있음 

- 

(⎈ |admin-k8s:default) root@k8s-m:/# ip -c link | grep -E 'flannel|cni|veth' -A1

#vxlan 역할

5: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/ether c2:aa:b9:3d:0b:62 brd ff:ff:ff:ff:ff:ff

#브릿지 역할

6: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 92:ac:0f:aa:19:00 brd ff:ff:ff:ff:ff:ff

#veth 인터페이스가 파드와 연결되어 통신
7: vethdc3f0bcc@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default
    link/ether da:13:ca:87:eb:fb brd ff:ff:ff:ff:ff:ff link-netnsid 0
8: veth84d31736@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default
    link/ether 7e:70:35:37:0d:19 brd ff:ff:ff:ff:ff:ff link-netnsid 1

 

- flannel이 vxlan 역할 해줌을 확인  flannel이 패킷을 감싸서 노드들의 파드 대역의 통신에 도움을 줌 

- 라우팅 정보를 보면 0:마스터 1:워커1 2:워커2 , 4:워커3 의 flannel 인터페이스  마스터에서 2.0대역 보내려면 워커노드 2쪽으로 보내라 

- 0으로 끝나는 경우라도 서브넷을 /32로 주면 사용 가능 

- 파드들이 filter 체인을 통한 통신이 허용되니 모든 파드와 통신이 가능해짐 ... 파드대역 설정 -> kubeproxy -> iptable rule 조작 

 

root@k8s-m:/# iptables -t nat -S | grep 'A POSTROUTING'
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 172.16.0.0/16 -d 172.16.0.0/16 -j RETURN
-A POSTROUTING -s 172.16.0.0/16 ! -d 224.0.0.0/4 -j MASQUERADE --random-fully

# 172.16.0.0/16대역이 244.0.0.0/4 대역을 향하는 게 아니라면 허용 

** flannel cni가 iptable 조작을 해서 네트워크를 컨트롤한다

 

 

파드 생성 후 통신 확인하기

- pod-1 : w1  172.16.1.4

- pod-2 : w3  172.16.4.4 

- pod1에서 pod2로 통신 

1) 1에서 출반한 패킷을 flannel인터페이스가 받음

2) flannel에서 vxlan overlay로 감싸서 워커노드 3번으로 보냄 

3) pod2로 전달 

 

 

파드 shell 접속 후 확인 

- 디폴트게이트웨이 주소 172.16.1.1  = cni0의 ip 주소 

 

- flannel이 0으로 끝나고 cni는 1로 끝남 파드들은 cni를 바라봄 (gw)

- 파드는 패킷을 cni로 보내고 cni는 flannel로 보내고 flannel은 vxlan으로 감싸서 통신 

 

패킷 캡처 

ip헤더가 2개 보임 파드 대역 통신 트래픽을 vxlan으로 감싸서 파드끼리 통신이 되도록 해줌 

 

와이어샤크로 패킷 확인 

- 처음 보이는 건 노드의 주소

- 그 안에 vxlan으로 감싸고 vxlan은 udp8472를 사용함

- vxlan이 감싼 정보는 파드들의 정보 ip 172.16 대역임을 확인 

역시 패킷으로 봐야 확실하게 눈에 보임 

 

** 같은 노드끼리의 다른 파드 통신은 그냥 가능 

** 다른 노드라면 flannel에서 vxlan으로 감싸서 보내서 다른 노드의 파드로 보냄 

** nat없는 통신을 위해서 cni flannel이 사용됨