컴포넌트 아키텍처

Calico를 구성하는 컴포넌트들이 어떤 역할을 하고 어디에서 실행되는지 한눈에 정리한 레퍼런스예요. Felix, BIRD, confd, Typha, kube-controllers 같은 핵심 컴포넌트부터 CNI·IPAM 플러그인과 클라우드 오케스트레이터 플러그인까지 다뤄요. 각 컴포넌트의 "주요 역할(Main task)"을 먼저 확인하면 전체 그림이 빠르게 잡혀요.

출처: 문서

본문

Calico 컴포넌트

다음 다이어그램은 네트워킹과 네트워크 정책을 함께 쓰는 Kubernetes 온프레미스 배포에 필요한 컴포넌트와 선택적 컴포넌트를 보여줘요.

Calico 컴포넌트

• Calico API 서버
• Felix
• BIRD
• confd
• Dikastes
• CNI 플러그인
• Datastore 플러그인
• IPAM 플러그인
• kube-controllers
• Typha
• calicoctl

클라우드 오케스트레이터 플러그인

• 클라우드 오케스트레이터 플러그인

Calico API 서버

주요 역할: kubectl로 Calico 리소스를 직접 관리할 수 있게 해줘요.

기본 설치에서는 projectcalico.org/v3와 내부 CRD 표현 사이를 변환하는 aggregation API 서버예요. 네이티브 v3 CRD를 사용하면 이 컴포넌트는 쓰이지 않아요. 이때는 kubectl이 projectcalico.org/v3 CRD와 직접 통신하고, 검증과 기본값 채우기는 admission 정책이 대신 처리해요.

Felix

주요 역할: 라우트와 ACL, 그리고 그 호스트의 엔드포인트가 원하는 연결성을 갖도록 호스트에 필요한 모든 것을 프로그래밍해요. 엔드포인트를 호스팅하는 각 머신에서 에이전트 데몬으로 실행돼요. Felix 리소스.

오케스트레이터 환경에 따라 Felix가 담당하는 작업은 다음과 같아요.

• 인터페이스 관리

  엔드포인트의 트래픽을 커널이 올바르게 처리할 수 있도록 인터페이스 정보를 커널에 프로그래밍해요. 특히 호스트가 각 워크로드의 ARP 요청에 호스트 자신의 MAC으로 응답하게 하고, 관리하는 인터페이스에서 IP 포워딩을 활성화해요. 또한 프로그래밍이 적절한 시점에 적용되도록 인터페이스를 감시해요.

• 라우트 프로그래밍

  자기 호스트의 엔드포인트로 가는 라우트를 Linux 커널 FIB(Forwarding Information Base)에 프로그래밍해요. 덕분에 그 엔드포인트로 향하는 패킷이 호스트에 도착했을 때 올바르게 포워딩돼요.

• ACL 프로그래밍

  Linux 커널에 ACL을 프로그래밍해서 엔드포인트 사이에는 유효한 트래픽만 오가고, 엔드포인트가 Calico 보안 조치를 우회할 수 없도록 해요.

• 상태 보고

  네트워크 상태 데이터를 제공해요. 특히 호스트를 구성할 때 발생한 오류와 문제를 보고해요. 이 데이터는 데이터스토어에 기록되기 때문에 다른 컴포넌트와 네트워크 운영자가 볼 수 있어요.

SECONDARY: calico/node는 Felix가 BIRD와 confd 없이 실행되는 policy only mode로 구동할 수 있어요. 이 모드는 호스트 간 라우트 배포 없이 정책 관리만 제공하며, 매니지드 클라우드 프로바이더 같은 배포에서 쓰여요. 노드를 시작하기 전에 환경 변수 CALICO_NETWORKING_BACKEND=none을 설정하면 이 모드가 켜져요.

BIRD

주요 역할: Felix에서 라우트를 받아 네트워크의 BGP 피어에 배포해서 호스트 간 라우팅을 가능하게 해요. Felix 에이전트를 호스팅하는 각 노드에서 실행돼요. 오픈소스 인터넷 라우팅 데몬이에요. BIRD.

BGP 클라이언트의 역할은 다음과 같아요.

• 라우트 배포

  Felix가 Linux 커널 FIB에 라우트를 넣으면 BGP 클라이언트가 그 라우트를 배포의 다른 노드들에 배포해요. 이를 통해 배포 전체의 트래픽 라우팅이 효율적으로 유지돼요.

• BGP 라우트 리플렉터 구성

  대규모 배포에서는 표준 BGP 클라이언트 대신 BGP 라우트 리플렉터를 구성하는 경우가 많아요. BGP 라우트 리플렉터는 BGP 클라이언트들을 연결하는 중심점 역할을 해요. (표준 BGP에서는 모든 BGP 클라이언트가 메시 토폴로지로 서로 연결되어야 하는데, 유지하기가 어렵거든요.)

  이중화를 위해 BGP 라우트 리플렉터는 여러 개를 매끄럽게 배포할 수 있어요. BGP 라우트 리플렉터는 네트워크 제어에만 관여하고 엔드포인트 데이터는 통과하지 않아요. Calico BGP 클라이언트가 FIB의 라우트를 라우트 리플렉터에 광고하면, 라우트 리플렉터가 그 라우트를 배포의 다른 노드들에 다시 광고해요.

confd

주요 역할: Calico 데이터스토어를 감시하면서 BGP 구성과 AS 번호, 로그 레벨, IPAM 정보 같은 글로벌 기본값의 변경을 추적해요.

오픈소스 경량 구성 관리 도구예요.

Confd는 데이터스토어 데이터의 업데이트를 바탕으로 BIRD 구성 파일을 동적으로 생성해요. 구성 파일이 바뀌면 confd가 BIRD에게 새 파일을 로드하라고 트리거해요. confd 구성, confd 프로젝트.

Dikastes

주요 역할: Istio 서비스 메시를 위한 네트워크 정책을 강제해요. 클러스터에서 Istio Envoy의 사이드카 프록시로 실행돼요.

(선택 사항) Calico는 Linux 커널(iptables, L3-L4)과 Dikastes라는 Envoy 사이드카 프록시를 통한 L3-L7 두 지점에서 요청의 암호화 인증과 함께 워크로드에 대한 네트워크 정책을 강제해요. 여러 지점에서 강제하면 여러 기준을 바탕으로 원격 엔드포인트의 신원을 확립할 수 있어요. 호스트 Linux 커널의 강제 덕분에 워크로드 파드가 침해당하고 Envoy 프록시가 우회되더라도 워크로드는 보호돼요.

SECONDARY: Dikastes는 환경 변수 DIKASTES_HTTP_BIND_ADDR과 DIKASTES_HTTP_BIND_PORT로 지정한 소켓 주소의 /terminate로 HTTP POST 요청을 보내 종료할 수 있어요. 이는 Kubernetes Job이 성공적으로 끝날 수 있도록 우아하게 종료하기 위한 것이고, Envoy의 /quitquitquit과 유사해요. 예: curl -XPOST http://127.0.0.1:7777/terminate

CNI 플러그인

주요 역할: Kubernetes 클러스터에 Calico 네트워킹을 제공해요.

이 API를 Kubernetes에 제공하는 Calico 바이너리를 CNI 플러그인이라고 부르며, Kubernetes 클러스터의 모든 노드에 설치해야 해요. Calico CNI 플러그인 덕분에 CNI 네트워킹 명세를 사용하는 어떤 오케스트레이터에서도 Calico 네트워킹을 쓸 수 있어요. 표준 CNI 구성 메커니즘과 Calico CNI 플러그인으로 구성해요.

Datastore 플러그인

주요 역할: 각 노드가 데이터스토어에 주는 부하를 줄여서 확장성을 높여줘요. Calico CNI 플러그인 중 하나예요.

• Kubernetes API 데이터스토어 (kdd)

  Calico와 함께 Kubernetes API 데이터스토어(kdd)를 사용할 때의 장점은 다음과 같아요.

  • 별도의 데이터스토어가 필요 없어서 관리가 간단해요
  • Kubernetes RBAC로 Calico 리소스 접근을 제어할 수 있어요
  • Kubernetes 감사 로깅으로 Calico 리소스 변경에 대한 감사 로그를 남길 수 있어요

• etcd

  etcd는 일관성 있는 고가용성 분산 키-값 저장소로, Calico 네트워크의 데이터 저장과 컴포넌트 간 통신을 담당해요. etcd는 비클러스터 호스트 보호 목적으로만 지원돼요(Calico v3.1 기준). 참고로 etcd의 장점은 다음과 같아요.

  • Kubernetes가 아닌 플랫폼에서 Calico를 실행할 수 있어요
  • Kubernetes와 Calico 리소스의 관심사를 분리할 수 있어요. 예를 들어 데이터스토어를 독립적으로 스케일할 수 있어요
  • 단일 Kubernetes 클러스터 이상으로 이루어진 Calico 클러스터를 운영할 수 있어요. 예를 들어 Calico 호스트 보호가 적용된 베어메탈 서버와 Kubernetes 클러스터의 연동, 또는 여러 Kubernetes 클러스터가 가능해요

  etcd 관리 가이드

IPAM 플러그인

주요 역할: Calico의 IP 풀 리소스를 사용해 클러스터 안의 파드에 IP 주소가 할당되는 방식을 제어해요. 대부분의 Calico 설치에서 기본 플러그인으로 쓰여요. Calico CNI 플러그인 중 하나예요.

kube-controllers

주요 역할: Kubernetes API를 감시하고 클러스터 상태에 따라 동작을 수행해요. kube-controllers.

tigera/kube-controllers 컨테이너에는 다음 컨트롤러가 들어 있어요.

• Policy 컨트롤러
• Namespace 컨트롤러
• Serviceaccount 컨트롤러
• Workloadendpoint 컨트롤러
• Node 컨트롤러

Typha

주요 역할: 각 노드가 데이터스토어에 주는 부하를 줄여서 확장성을 높여줘요. 데이터스토어와 Felix 인스턴스 사이에서 데몬으로 실행돼요. 기본으로 설치되지만 별도 구성은 필요 없어요. Typha 설명, Typha 컴포넌트.

Typha는 Felix와 confd 같은 모든 클라이언트를 대표해 데이터스토어 연결을 하나만 유지해요. 데이터스토어 상태를 캐시하고 이벤트를 중복 제거해서 많은 리스너에게 fan-out할 수 있어요. 하나의 Typha 인스턴스가 수백 개의 Felix 인스턴스를 지원할 수 있기 때문에 데이터스토어 부하를 큰 폭으로 줄여줘요. 그리고 Felix와 무관한 업데이트를 걸러낼 수 있어서 Felix의 CPU 사용량도 줄여줘요. 대규모 Kubernetes 클러스터에서는 API 서버가 만드는 업데이트 수가 노드 수에 비례해 늘어나기 때문에 이런 기능이 필수적이에요.

calicoctl

주요 역할: Calico 객체를 생성, 조회, 수정, 삭제하는 커맨드라인 인터페이스예요. calicoctl 커맨드라인은 Calico 데이터스토어에 네트워크 접근이 가능한 어떤 호스트에서든 바이너리 또는 컨테이너로 쓸 수 있어요. 별도 설치가 필요해요. calicoctl.

클라우드 오케스트레이터 플러그인

주요 역할: 네트워크를 관리하는 오케스트레이터 API를 Calico 데이터 모델과 데이터스토어로 변환해요.

클라우드 프로바이더를 위해 Calico는 주요 클라우드 오케스트레이션 플랫폼마다 별도의 플러그인을 제공해요. 덕분에 Calico가 오케스트레이터와 긴밀하게 결합되어, 사용자가 자신의 오케스트레이터 도구로 Calico 네트워크를 관리할 수 있어요. 필요할 때 오케스트레이터 플러그인은 Calico 네트워크에서 오케스트레이터로 피드백을 전달해요. 예를 들어 Felix의 생존 상태 정보를 제공하거나, 네트워크 설정에 실패한 특정 엔드포인트를 실패로 표시하는 일이 있어요.

더 알아보기 (Learn more)

컴포넌트별 "주요 역할"만 훑어도 Calico의 동작 방식이 큰 그림으로 그려져요. 데이터플레인 구성을 고민하고 있다면 Felix와 BIRD, Typha의 관계부터 살펴보세요. 각 컴포넌트의 세부 설정은 링크된 리소스 레퍼런스 문서에서 확인할 수 있어요.