Calico가 무엇인지 알기 전에 먼저 Kubernetes에서는 왜 CNI(Container Network Interface)가 필요한가부터 알아봐야할 것 같습니다.
왜 CNI가 필요할까요?
공식문서상 쿠버네티스는 4가지의 풀어야할 네트워킹 문제가 있다고 합니다.
1. 고도로 결합된 컨테이너 간의 통신(이는 pause컨테이너를 통해 Localhost통신으로 해결 됩니다.)
2. pod 간 통신
3. pod와 Service 간 통신
4. 외부와 Service 간 통신
이러한 문제점들을 해결하기 위해 생겨난 것이 CNI이며 이를 통해 위 문제점 들을 극복하여 대규모 클러스터 환경에서도 높은 네트워킹 퍼포먼스로 운영할 수 있게 됩니다.
가장 보편적으로 많이 사용하는 CNI는 Calico이나, CNI의 종류는 굉장히 다양합니다. 따라서, 니즈에 맞게 적절히 사용하면 됩니다.
다양한 CNI별로 비교한 좋은글이 있어 참고하시면 좋을 것 같습니다.
그럼 이제 Calico에 대해서 알아보겠습니다
Calico란?
쿠버네티스 및 기타 컨테이터 오케스트레이션을 위한 고성능의 오픈소스 네트워킹 / 네트워크 보안 솔루션입니다.
그럼 Calico의 구성 요소를 살펴보겠습니다.
Clico CNI는 3개의 주요 컴포넌트가 있습니다.
Calico를 배포하게 되면 calico-node-* 라는이름의 Pod가 노드별로 스케쥴링 되는데 이때 아래 프로세스가 노드에 함께 띄워지게 됩니다.(calico-node-*는 daemonset형상으로 띄워집니다)
** Calio Component **
1. Felix: Calico의 Felix 컴포넌트는 네트워크 라우팅 정보를 관리하고, 호스트 시스템의 iptables 규칙을 설정하여 파드 간의 네트워크 정책과 트래픽 라우팅을 담당합니다. Routing 및 네트워크 설정정보는 etcd에서 정보를 가져오는데, 이는 Kubernetes etcd 또는 Calico의 자체 etcd일 수 있습니다. 현대의 Calico 설치에서는 주로 Kubernetes etcd를 사용하는 추세입니다.
Felix는 주로 Pod-to-Pod 통신에 관여하며, Service-to-Pod 통신은 kube-proxy가 관리합니다.
2. Bird: Bird또한 모든 Host마다 설치되며 Felix가 etcd에 라우팅 정보를 저장하면 Bird는 이를 가져와 서로 간 전파 및 공유합니다.
3. Confd: BGP Configuration에 대한 정보를 모니터링 합니다. 즉, 네트워크 구성 및 설정이 변경될 경우 Confd가 변화를 감지하여 Bird가 이를 반영하여 Peer Host에게 전파 및 전달을 받을 수 있도록 합니다.
[Calico Architecture]
Pod통신 방식(IP in IP방식)
#1 Pod와 Pod간 통신
Pod와 Pod간 통신은 2가지로 나눌 수 있습니다.
1. 같은 노드 내 Pod간 통신
동일한 노드 내의 Pod간 통신에는 cali* 인터페이스를 통해 통신하게 됩니다.
2. 다른 노드 내 Pod간 통신
다른 노드 내 Pod간 통신에는 cali*인터페이스를 지나, tunl0을 지나 물리네트워크를 통해 상대측 Node 및 Pod에 도달하게 됩니다.
출발지에서 도착지로 ping을 보내게 되면 출발지에서 시작된 패킷은 cali*인터페이스를 지나, tunl0을 거쳐 Encapsulation되어 해당 패킷은 Host의 물리 네트워크 주소로 감싸져 도착지로 도달하게 되고, 도착지에서는 다시 Decapsulation 되어 Pod에 도착할 수 있게 됩니다.
[인터페이스별 정보]
cali*: pod의 개수에 비례하여 생기는 가상인터페이스입니다. 해당 인터페이스를 통해 Node와 Pod, Pod와 Pod간의 통신이 가능한 것이며, 이로인해 Pod는 해당 가상 인터페이스로 고유IP를 가지게 됩니다.
tunl0: tunl0인터페이스는 Calico 설치시 서로 다른 노드간 터널링을 통해 통신이 가능하도록 해주는 가상 인터페이스입니다.
주로 IPinIP모드에서 사용되는 가상 인터페이스이며 패킷은 해당 인터페이스를 통과하면서 호스트의 네트워크정보로 패킷 헤더에 덧대지고
상대측 노드에 도달 후 새로 덧대졌던 헤더는 벗겨져 노드는 기존 Source, Destination정보를 바탕으로 Pod로 도달하게 됩니다.
리스폰스의 경우에도 마찬가지로 반대로 동작하게 됩니다.
소개드린 Calico의 네트워킹 방식은 IP in IP방식이었는데요.
또다른 방식으로 VXLAN방식이 있습니다.
둘은 모두 overlay방식의 네트워킹 모델이고, 패킷 캡슐화를 진행한다는 것은 동일 하나 대규모 클러스터에 누가 더 적합한지를 묻는다면 VXLAN방식이라고 할 수 있습니다.
IP in IP: 기존 IP패킷을 다른 IP패킷에 캡슐화 함. 소규모 클러스터 환경에서는 적합하나 대규모 클러스터 환경에서는 부적합
VXLAN: 기존 IP패킷을 UDP패킷에 캡슐화함. 대규모 클러스터 환경에서는 적합하나, 구성 및 설정이 다소 복잡
* 정리: IPinIP는 간단한 터널링 작업에 용이하고, VXLAN은 구성 및 설정은 복잡하나 대규모 클러스터 환경에서 사용하기 좋음.
[VXLAN Mode 테스트 진행_테스트 환경 아키텍처]
* 응답이 올때에도 응답 패킷에 대한 Decapsulation은 출발지 노드에서도 마찬가지로 이루어 집니다.
* 실제 패킷 트래픽과 TCPdump의 출력 결과는 다를 수 있습니다.
실제로는 10.100.19.9 Request 패킷 발생 이후 test-default~node-0을 통해 목적지 노드로 VXLAN을 통해 Encapsulation되어 나가는 것을 확인할 수 있고, 응답으로는 목적지 노드의 IP주소로 들어와서 출발지 Node에 도착 후, 목적지 Pod의 IP주소와 출발지 Pod의 IP주소로 Decapsulation되어 응답 패킷을 확인할 수 있습니다.
혹시라도 틀린부분, 수정이 필요한 부분이 있다면 댓글로 피드백주시면 반영 하도록 하겠습니다.
같이 공부합시다.
참고:
https://gasidaseo.notion.site/gasidaseo/CloudNet-Blog-c9dfa44a27ff431dafdd2edacc8a1863
https://docs.tigera.io/calico/latest/reference/architecture/overview#felix
'Kubernetes' 카테고리의 다른 글
| kubesec install 및 사용법 (1) | 2024.03.19 |
|---|---|
| Kubernetes Network Study #2(Service to Pod) (0) | 2023.11.23 |
| [NKS]Velero를 활용하여 특정 네임스페이스를 통으로 백업하고 복원하기 (2) | 2023.07.31 |
| Ingress에서 다른 Namespace에 있는 Service로 라우팅 하기 (0) | 2023.07.25 |
| Kubernetes 인증서 관리를 위한 가이드: cert-manager와 issuer 설치 (1) | 2023.07.25 |
