Calico Components

이번엔 Calico를 구성하는 Component들에 대해 알아보자. 아래 그림은 Calico component와 관계를 설명하는 다이어그램이다. 

 

Calico Diagram

 

Felix

Calico Datastore로부터 가져온 설정 정보에 맞게 Host의 인터페이스, 라우팅 테이블, iptables(kube-proxy 모드에 따라 IPVS가 될 수 있음)를 관리하여 패킷이 지정된 Pod에 정확히 전달될 수 있게 한다. 클러스터의 Network Policy를 위반한 패킷이 전송되지 않게 차단하는 ACL 기능도 제공한다.

 

BIRD

BGP Client 역할을 담당하는 Component다. Felix가 Route 정보를 Linux Kernel FIB(Forwarding Information Base)에 추가할 때, 이를 다른 Node에 공유하는 'Route Distribution' 기능이 우선된다. 

기본적으로 모든 노드가 서로 연결되어 Route 정보를 전달하는 Mesh Topology로 구성되나, 이를 유지하기 힘든 규모의 클러스터(> 50 nodes)는 특정 Node를 BGP Route Reflector로 설정하여 부하를 줄일 수 있다. 

 

confd

Calico Datastore를 모니터링하여 업데이트된 내용(BGP 설정, IPAM 정보 등)이 있을 경우, BIRD 설정 파일을 생성하여 BIRD가 새로운 설정을 Load할 수 있게한다.

CNI Plugin

Cluster Networking을 위한 CNI 플러그인으로 Spec이 정해져 있으며 Node마다 실행파일 형식으로 제공된다. 자세한 내용은 링크를 참고할 것.

 

IPAM Plugin

Pod의 IP 주소를 할당, 관리하는 플러그인이며 자세한 내용은 링크를 참고할 것.

Datastore

Calico는 Cluster Networking에 필요한 정보와 현재 상태를 저장하기 위해 Datastore를 요구한다. 다음 2개의 모드 중 하나를 선택하여 사용한다.

• Kubernetes
  • k8s api server를 통해 데이터를 저장하는 방식
  • k8s에서 제공하는 RBAC 기능을 통해 Calico 리소스에 대한 접근을 제어할 수 있음
  • Calico 리소스 업데이트에 대한 로깅 가능
• etcd
  • k8s가 아닌 플랫폼(ex: 오픈스택)인 경우
  • k8s와 Calico 리소스를 분리할 수 있음
  • Multi-cluster에서 Calico 사용시

Typha

클러스터의 규모가 커질 수록, 수많은 node가 Datastore에 데이터를 직접 요청하게 되는 문제가 발생한다. Typha는 Datastore와 다른 component(ex: felix) 사이에서 Cache 역할을 수행하며, 하나의 Datastore로부터 수많은 listener에게 데이터를 전달하는 Fan-out 형태를 갖게 된다. 하나의 Typha가 100개 이상의 felix 인스턴스를 지원할 수 있는 것으로 알려져있으며, Scale in/out이 가능하다. Optional Component로 Calico를 Default 모드로 설치할 경우, 비활성화된 상태로 배포된다.

 

calicoctl

Calico 리소스의 CRUD Operation을 위한 전용 CLI. Datastore에 접근 가능한 Host에서 사용 가능하며, Binary 및 Container 형태로 배포된다. Calico와는 별개이며 따로 설치해야 함. 설치 방법은 링크 참고.

 

참고
Component architecture - Project Calico