[Cilium]내 쿠버네티스 클러스터를 지키는 숨은 경호원, 정체는? 🕵️‍♂️

안녕하세요! 오늘은 쿠버네티스 네트워킹의 끝판왕, Cilium에 대해 깊이 파고들어 보려고 합니다.

쿠버네티스를 사용하다 보면 "A 파드에서는 B 파드로만 통신해야 해!" 와 같은 복잡한 네트워크 정책을 설정해야 할 때가 많죠. 이때 Cilium을 사용하면 eBPF라는 강력한 기술을 이용해 아주 효율적으로 정책을 적용할 수 있습니다.

그런데 여기서 궁금증이 생깁니다. 🤔 우리가 YAML 파일로 CiliumNetworkPolicy를 딱 하고 적용하면, 과연 어떤 구성 요소가 이 정책을 실제로 실행에 옮기는 걸까요? 클러스터의 수많은 노드 위에서 돌아가는 파드들의 트래픽을 일일이 검사하고 통제하는 진짜 일꾼은 누구일까요?

오늘은 그 숨은 경호원의 정체를 밝혀보겠습니다!

---

🎯 진짜 행동대장: Cilium Agent

정답부터 이야기하자면, 이 모든 마법을 현실로 만드는 주인공은 바로 Cilium Agent 입니다.

Cilium Agent는 클러스터의 모든 노드(Node)에 하나씩 배포되어 실행되는 핵심 컴포넌트입니다. 각 노드의 '개인 경호원'이라고 생각하면 이해하기 쉬워요. 💂‍♂️

이 경호원이 하는 일은 다음과 같습니다.

1. 정책 감시 👀: 사용자가 생성하거나 업데이트하는 CiliumNetworkPolicy와 같은 네트워크 정책 리소스를 계속 지켜봅니다.
2. eBPF로 번역 📜➡️💻: YAML로 작성된 사람이 이해하기 쉬운 정책을, 커널이 직접 실행할 수 있는 매우 빠른 eBPF 프로그램으로 컴파일(번역)합니다.
3. 커널에 주입 🧠: 컴파일된 eBPF 프로그램을 리눅스 커널 내의 네트워크 경로(예: 파드의 가상 이더넷 장치)에 직접 연결합니다.

이 과정이 중요한 이유는, 일단 eBPF 프로그램이 커널에 로드되면 그 이후의 모든 네트워크 패킷 필터링은 커널 레벨에서 직접 일어나기 때문입니다. 애플리케이션이나 별도의 프록시를 거치지 않으니 속도가 엄청나게 빠르고 효율적이죠.

예시로 이해하기

예를 들어, backend 파드는 frontend 파드로부터의 TCP 8080 포트 트래픽만 허용하는 정책을 적용해 보겠습니다.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-frontend-to-backend"
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP

backend 파드가 실행 중인 노드의 Cilium Agent는 이 YAML을 보고 다음과 같은 eBPF 규칙을 생성하여 커널에 적용합니다.

"이 노드에 있는 app=backend 파드로 들어오는 모든 패킷을 검사해라. 출발지 파드가 app=frontend 라벨을 가지고 있고, 목적지 포트가 TCP 8080이면 통과(ALLOW)시키고, 나머지는 차단(DROP)해라!"

이처럼 Cilium Agent는 각 노드에서 정책 시행의 최전선에 서 있는 핵심적인 역할을 담당합니다.

---

🤔 그럼 다른 애들은 뭘 할까? (feat. 오답노트)

Cilium Agent가 주인공인 것은 알겠는데, 그럼 다른 컴포넌트들은 왜 필요할까요? 각각의 역할을 알면 전체 그림을 이해하는 데 큰 도움이 됩니다.

Cilium Operator: 클러스터의 총괄 매니저 🧑‍💼

Cilium Operator는 Agent처럼 모든 노드에 있는 것이 아니라, 클러스터 전체에서 단 몇 개만 실행됩니다. 이 친구의 역할은 클러스터 전반에 걸쳐 한 번만 수행하면 되는 관리 작업을 처리하는 것입니다.

• IP 주소 할당 (IPAM): 클러스터 내의 파드들이 사용할 IP 주소 풀을 관리하고 노드에 할당해 줍니다.
• CRD 관리: CiliumNetworkPolicy와 같은 Cilium 고유의 리소스(CRD)가 쿠버네티스 API에 잘 등록되도록 관리합니다.
• 전역 서비스 관리: 여러 노드에 분산된 서비스의 정보를 취합하고 동기화합니다.

왜 정답이 아닌가? Operator는 정책을 직접 시행하는 '행동대장'이 아닙니다. 클러스터 전체의 조율과 관리를 담당하는 '매니저'나 '사령관'에 가깝죠. 실제 전투(트래픽 필터링)는 각 노드의 Agent가 수행합니다.

Cilium Hub (Hubble): 똑똑한 관제탑 🔭

Cilium Hub라는 이름의 공식 컴포넌트는 사실 없습니다. 아마도 Cilium의 강력한 관측성(Observability) 도구인 Hubble을 지칭하는 것으로 보입니다.

Hubble은 클러스터 내에서 발생하는 모든 네트워크 흐름을 시각적으로 보여주고, 어떤 정책에 의해 트래픽이 허용되거나 차단되었는지 등을 모니터링할 수 있게 해주는 도구입니다.

왜 정답이 아닌가? Hubble은 '관찰자'이지 '집행자'가 아닙니다. 마치 CCTV 관제탑처럼 네트워크 상황을 지켜보고 분석하는 역할은 하지만, 직접 문을 열고 닫는(정책을 시행하는) 역할은 하지 않습니다.

Cilium DaemonSet: 경호원을 배치하는 방법 🚚

DaemonSet은 Cilium의 기능적 구성 요소가 아니라, 쿠버네티스가 특정 파드를 모든 노드에 배포하기 위해 사용하는 배포 방식(Deployment Strategy)입니다.

Cilium은 바로 이 DaemonSet을 이용해서 Cilium Agent 파드를 클러스터의 모든 노드에 하나씩 착실하게 배포합니다.

왜 정답이 아닌가? DaemonSet은 '어떻게(HOW)'에 대한 답입니다. 즉, 'Cilium Agent를 어떻게 모든 노드에 배포할까?'에 대한 답이죠. 정책을 시행하는 '무엇(WHAT)'에 대한 답이 아닙니다. 경호원을 각자의 위치로 실어다 주는 '수송 트럭'이지, 경호원 자체는 아닌 셈입니다.

---

✨ 결론: 완벽한 팀플레이!

Cilium의 네트워킹 정책은 어느 한 컴포넌트가 단독으로 처리하는 것이 아니라, 여러 컴포넌트가 각자의 역할을 수행하며 만들어내는 완벽한 팀플레이의 결과입니다.

• DaemonSet이 모든 노드에 Cilium Agent를 배송하고,
• Cilium Operator가 중앙에서 IP 주소 할당 등 큰 그림을 관리하며,
• 각 노드의 Cilium Agent가 네트워크 정책을 eBPF로 변환해 커널에서 직접 시행하고,
• Hubble은 이 모든 과정을 투명하게 관찰할 수 있도록 도와줍니다.

이제 Cilium 네트워크 정책이 어떤 과정을 거쳐 우리 클러스터를 안전하게 지켜주는지 명확하게 이해되셨나요? 다음에 kubectl apply -f my-policy.yaml을 실행할 때, 보이지 않는 곳에서 묵묵히 일하는 Cilium Agent를 떠올려 보세요! 😉