[Day18] Certified Kubernetes Administrator (CKA) with Practice Tests

210강. CNI in kubernetes

CNI란? 

:(Container Network Interface)는 컨테이너 간의 네트워킹을 제어할 수 있는 플러그인을 만들기 위한 표준.

컨테이너의 발전이 가속화 됨에 따라 다양한 형태로 컨테이너 런타임과 오케스트레이터 사이의 네트워크 계층을 구현하는 방식이 다양하게 분리됨 -> 각자만의 방식으로 발전하는 것을 막기 위해 공통된 인터페이스 제공

 

-쿠버네티스는 기본적으로 매우 제한적인 네트워크 기능만을 제공하는 kubenet이라는 자체 CNI 플러그인을 기본 제공함.

 

-Kubenet 사용 안하고, 서드파티 CNI 플러그인 사용하는 이유?

:Kubenet은 컨테이너 사이 노드 간 교차 네트워킹 조차 지원하지 않아 network policy, public 클라우드와의 통합, 대규모 트래픽에 대한 안정성 등 다양한 기능을 제공하는 서드파티 CNI를 사용

 

<View kubelet options>

-ps -aux | grep kubelet

:CNI 플러그인을 클러스터에 설치하면 클러스터 각 노드의 Kubelet 서비스에 config됨.

-ls /opt/cni/bin 

: 실행할 수 있는 CNI plugin 목록.

-ls /etc/cni/net.d

: CNI Configuration 파일 확인 -> kubelet이 어떤 플러그인을 사용하는지 확인 가능

-cat /etc/cni/net.d/10-bridge.conf

 

211강. CNI weave

일반적으로 중간에 라우터를 둬 여러 node로 라우팅하는 방식은 어려움

-> 노드 수 증가-> 라우팅 테이블에 많은 엔트리 존재 -> 라우팅 테이블 엔트리는 많은 수를 지원 x

=> 대안: agent 를 두어 패킷을 주고 받는 방식

각 node에 weave agent 파견, weave CNI는 각 노드마다 weave 브릿지 생성

브릿지에 IP 할당 후, POD 붙임

 

weave를 우체국이라고 생각

다른 Node의 pod로 패킷을 전송할 때 보내는 node의 weave agent가 패킷을 캡슐화한 후(택배 포장) 다른 node로 보냄 

-> 패킷을 받은 node는 agent 를 통해 패킷을 decapsulate하여(택배 포장 뜯고) pod한테 전달. 

 

클러스터 안에서 delpoy 됨 

 

216강. IP Address Management (IPAM)-Weave

Pod에 IP주소를 할당하는 주체 = CNI PLUGIN

수동으로 네트워크를 구축했을 때, 플러그인 내에서 namespace 에 ip주소를 할당하는 섹션 있음 (3번째 줄)

IP가 중복되지 않도록 Host-local plugin 

:각각의 호스트 local 에서 ip 주소를 관리하는 방식

문제점: 스크립트 내부에서 플러그인을 적용해야하는 문제 

/etc/cni/net.d/net-script.conf 경로에 있는 cni 설정 파일에는 ipam을 설정할 수 있는 section 존재

스크립트에 직접 하드코딩 하지 않고 적절한 plugin 사용 가능 

 

219강. Serivce networking

*Pod IP를 이용한 애플리케이션 통신 문제점

쿠버네티스로 서비스하는 애플리케이션은 POD를 수동으로 삭제하고 다시 실행하거나, ReplicaController를 이용하여 pod가 죽더라도 다시 실행됨 -> 재실행되면 CNI에 의해 POD IP 재할당 됨 -> 서비스 장애 발생 위험 높음

 

POD IP재할당으로 통신이 되지 않는 문제해결 

POD IP가 변경되어도 계속해서 통신할 수 있도록 POD 네트워크 레벨을 추상화하여 통신 문제 해결

POD 네트워크로 패킷을 전달하는 프록시 개념 도입-> 서비스 

프록시가 동작할 수 있도록 각 NODE 설정을 담당하는 쿠버네티스 COMPONENT -> KUBE-PROXY

로드밸런싱 기능은 Pod를 수동으로 여러개 띄우거나 pod를 2개이상 실행할 때 동작

 

-서비스 특징

Endpoints

:서비스가 패킷을 전달하고자 하는 pod 집합 

-> 쿠버네티스가 자동으로 endpoints 안의 pod을 제거/생성 관리

-서비스 타입

 ClusterIP: 쿠버네티스 클러스터에서만 서비스에 접근

 NodePort: 외부에서 노드를 통해 서비스에 접근

 LoadBalancer: 외부 로드밸런서를 (ex 클라우드 공급자) 통해 서비스에 접근 

 

모든 node에 서비스를 사용할 수 있는 이유

: kube-proxy는 demonset으로 실행되어 모든 node에 존재 -> 모든 node에서 서비스를 이용해 pod로 접근 가능

 

222강. DNS in kubernetes

DNS resolution within the cluster

cluster를 설정하면 dns를 배포함 

<cluster 일 경우>

namespace가 달라지면 (ex apps 생성)

curl http://web-service.apps 로 뒤에 계속 추가하면 됨 

<pod 일 경우>

hostname이 10-244-2-4로 할당됨

curl http://10-244-2-4.apps.pod.cluster.local로 로 접근 가능  

 

223강. CoreDNS in kubernetes

쿠버네티스가 어떻게 DNS를 실행할까?

 

cat /etc/hosts로 pod ip address 확인 가능 

cat /etc/resolv.conf 도 naeserver 도 포함하여 확인 가능

dns에 다 저장됨 

pod는 -로 hostname 구분

<cluster>

cat /etc/coredns/Corefile

kubectl get service -n kube-system

host web-service를 눌리면 전체 entry가 나옴

 

출처)

https://ykarma1996.tistory.com/179

Calico?Weave? CNI에 관하여

 

https://seungjuitmemo.tistory.com/232

K8S Pod Networking과 Weave CNI 정리

https://zerojsh00.github.io/posts/CNI-Weave/

(K8S) CNI Weave의 기초 개념

https://malwareanalysis.tistory.com/265