calico에 대한 소개 (1)

안녕하세요.

이번 포스팅은 k8s cni중에서도 핫한 calico에 대한 글을 작성 할 예정입니다.

 

중간에 제가 잘못 이해하여 틀린 내용이 있다면 편하게 댓글 부탁드립니다.

 

 

시 ~ 작 !!

 

 

다들 아시다시피, calico는 k8s cluster에서 컨테이너 네트워킹을 제공하는 cni plugin 입니다. 

Linux-native tools을 사용하여 routing을 가능하게 하고 네트워크 정책을 시행합니다. 

또한 다른 node에 경로를 알리기 위해 BGP daemon을 사용합니다.

 

 

calico의 컴퍼넌트들은 아래와 같습니다.

- Calico API server
- Felix
- BIRD
- confd
- Dikastes
- CNI plugin
- Datastore plugin
- IPAM plugin
- kube-controllers
- Typha
- calicoctl

 

 

출처 : https://docs.projectcalico.org/reference/architecture/overview

출처 : https://tanzu.vmware.com/developer/guides/container-networking-calico-refarch/

 

 

 

 

 

그 중 몇가지를 정리 해 보겠습니다.

 

1) Calico API server
- 칼리코 리소스를 직접 관리하는데 필요한 api 서버

2) Felix

- 각 host에서 felix가 agent daemon으로 동작함

- pod의 route 및 network policy를 충족하도록 host를 프로그래밍하는 일을 담당

  - host의 FIB에 route 정보 프로그래밍 (bird로 학습한 route정보를 fib에 넣어주는 역할)

- 이를 위해 Linux 커널의 routing table 및 iptables와 상호작용
- 인터페이스 관리
  - 커널이 endpoint의 트래픽을 잘 처리할 수 있도록 인터페이스에 대한 정보를 커널에 프로그래밍 함
  - host의 mac으로 들어오는 arp request를 host가 처리하게 하고, 관리하는 인터페이스에 대해 ip forwarding을 enable 함

3) BIRD
- 새
- routing daemon

- felix와 마찬가지로 각 host에서 실행됨
- 예전에 쓰던 zebra, quagga를 생각하면 됨 (가벼움)
- 최근에 frr과 더불어 오픈소스 라우팅 대몬으로 잘나가는 것으로 보여짐
- felix에서 자기의 경로를 갖고와서 다른 host(bgp peer)에게 광고함
- default는 node간 bgp full mesh neighbor를 맺음
- 규모가 커지면 bgp rr을 사용할 수도 있음

 

출처 : https://tanzu.vmware.com/developer/guides/container-networking-calico-refarch/

 

4) confd
- 가벼운 오픈소스 configuration management tool
- calico datastore를 모니터링함 (bgp config, global default, logging level, ipam 정보)
- datastore의 data update를 기반으로 BIRD Configuration file을 생성함
- 변경사항이 발생하면 BIRD를 트리거해서 새 파일을 로드함

5) Dikastes
- Istio 서비스 메시에 대한 네트워크 정책을 실행
- 클러스터에서 Istio Envoy에 대한 사이드카 프록시로 실행됨

6) Datastore plugin
- Calico 구성, 라우팅, 정책 및 기타 정보를 저장하는 곳 
- 2가지의 datastore mode가 있음

  - Kubernetes API datastore (kdd)
     - 추가 datastore가 필요없어서 관리 간단
     - k8s RBAC 사용가능

     - calico에서 사용하는 모든 persisted data는 k8s api 서버를 통해 custom resource definitions(CRD)로 저장됨

출처 : https://tanzu.vmware.com/developer/guides/container-networking-calico-refarch/

  - etcd
     - k8s, calico간의 리소스 이슈가 분리됨

     - 조금 복잡..

출처 : https://tanzu.vmware.com/developer/guides/container-networking-calico-refarch/

 

7) IPAM plugin
- calico의 IP 풀을 사용하여 pod에 IP 할당을 제어
- 기본 플러그인

 

8) Kube-Controllers
- 라우팅에 영향을 미치는 k8s object의 변경 사항을 인식하는 역할을 함

- 컨트롤러에는 내부에 여러 컨트롤러가 포함되어 있으며 다음과 같은 변경 사항을 관찰함

   - Network Policies (used to program IPtables for network access enforcement)
   - Pods (e.g. labels)
   - Namespaces (used to determine if enforcement is needed for the new namespace)
   - Service Accounts (used for setting up Calico profiles)
   - Nodes (used to determine the associated subnet and inform the routing topology)

- 컨트롤러에서 확인된 변경 사항을 기반으로 calico는 datastore를 update할 수 있음 (결국 각 calico-node에서 확인 및 적용됨)

출처 : https://tanzu.vmware.com/developer/guides/container-networking-calico-refarch/

 

9) Typha
- 기본적으로 설치되지만 구성은 셀프로... (필요하다 판단되면 직접 해야됨)

- 각각의 felix를 datastore에 연결하면 kube api server의 성능에 영향을 미칠 수 있기 때문에

- typha는 datastore <-> 각 node의 felix 사이에 들어가면서, datastore와 단일 연결을 형성

출처 : https://medium.com/@bikramgupta/why-use-typha-in-your-kubernetes-calico-deployments-5c0ca4da30dd

- datastore 상태 cache, 이벤트 중복제거 역할 수행

   - felix에서 api 호출하는 대부분이 watch event임

   - 100개가 100번 물어보는 것 보다, 1개(typha)가 1번 물어보고 캐싱해서 처리함

   - api 서버 입장에서는 watch 빈도수가 감소되면서 부하가 감소

   - node가 계속 확장되어도 api 호출 빈도수는 큰 변함 없음
- felix 입장에서는 typha가 불필요한 이벤트를 filter 해주기 때문에 부하가 감소

- k8s API 서버를 datastore로 사용할 경우에는 node가 많아지면 typha를 필수적으로 사용하는 것을 권장

- etcd를 datastore로 사용할 경우는 etcd v3 자체가 이미 많은 client를 처리할 수 있도록 최적화 되어 있기때문에 사용하지 않는 것을 권장 (중복적인 기능을 사용 할 필요가 없으므로)