Cilium, L7 천재인 줄 알았는데... 진짜 핵심은 따로 있다? 🧐

쿠버네티스 네트워킹의 세계에서 Cilium(실리움)은 eBPF 기술을 기반으로 한 강력한 성능과 기능으로 큰 주목을 받고 있습니다. 특히 HTTP 요청 경로(GET /api/v1)나 gRPC 메소드 기반으로 정책을 설정하는 Layer 7(애플리케이션 계층) 기능은 Cilium을 '차세대 CNI'로 각인시키는 데 큰 역할을 했죠.

 

하지만 "Cilium은 L7 CNI다"라고만 알고 있다면, 가장 중요한 핵심을 놓치고 있는 것일지도 모릅니다. Cilium의 진짜 힘은 어디에서 나올까요? 그 심장부를 함께 파헤쳐 보겠습니다. 🚀

---

🏛️ Cilium의 핵심 데이터패스: L3와 L4가 진짜 주인공

결론부터 말하자면, Cilium의 핵심 데이터패스는 Linux 커널에서 직접 작동하며, 그 주 무대는 OSI 모델의 Layer 3(네트워크 계층)와 Layer 4(전송 계층)입니다.

1. Layer 3 (네트워크 계층) 🌐: 모든 통신의 기본기

• 역할: Pod 네트워킹의 가장 기본이 되는 IP 주소 기반의 라우팅을 담당합니다.
• Cilium의 역할: Cilium은 각 Pod에 IP 주소를 할당하고, eBPF를 이용해 노드 간의 Pod 통신 경로를 매우 효율적으로 처리합니다. 복잡한 iptables 규칙이나 오버레이 네트워크의 성능 저하 없이, 커널 수준에서 직접 패킷을 전달하죠. 이것이 Cilium이 빠른 속도를 자랑하는 첫 번째 비결입니다.

2. Layer 4 (전송 계층) 🔌: 서비스와 정책의 심장부

• 역할: TCP/UDP 포트(Port)를 기반으로 데이터를 정확한 서비스(프로세스)에 전달합니다.
• Cilium의 역할: 쿠버네티스의 핵심 기능인 서비스(Service) 로드 밸런싱과 네트워크 정책(Network Policy)이 바로 이 L4에서 이루어집니다.
  • kube-proxy 대체: Cilium은 eBPF를 사용하여 kube-proxy의 기능을 완전히 대체합니다. 서비스의 ClusterIP와 포트로 들어온 요청을 실제 Pod의 IP와 포트로 변환하고 분배하는 과정을 커널에서 직접 처리하여 엄청난 성능 향상을 가져옵니다.
  • 핵심 네트워크 정책: "A 파드는 B 파드의 80번 포트로만 통신할 수 있다"와 같은 기본적인 네트워크 정책은 모두 L4 수준에서 처리됩니다.

이처럼 Cilium은 eBPF를 통해 L3/L4에서 이미 빠르고 효율적인 네트워크 기반을 완성합니다. 대부분의 트래픽은 이 단계에서 신속하게 처리되죠.

---

✨ 그렇다면 강력한 L7 기능의 정체는?

"잠깐, 그럼 Cilium의 자랑인 L7 정책은 어떻게 동작하는 거죠?"

아주 좋은 질문입니다. Cilium의 L7 기능이 강력한 것은 사실이지만, 이는 L3/L4 데이터패스 위에 구축된 '지능적인 확장 기능'입니다. 모든 트래픽을 L7에서 검사하는 것은 비효율적이기 때문이죠.

Cilium의 작동 방식을 단계별로 살펴보면 명확해집니다.

1. 패킷 도착: 패킷이 노드에 도착하면 커널의 eBPF 프로그램이 가장 먼저 가로챕니다.
2. L3/L4 검사 (eBPF): eBPF는 이 패킷의 출발지/목적지 IP(L3)와 포트(L4)를 확인하여 네트워크 정책과 일치하는지 빠르게 판단합니다.
3. 분기점 (Decision Point):
   • L7 정책이 없는 경우 ✅: 만약 해당 트래픽에 적용될 L7 정책이 없다면, eBPF는 커널 수준에서 바로 ALLOW 또는 DENY 처리를 하고 끝냅니다. 매우 빠릅니다!
   • L7 정책이 있는 경우 ➡️: 만약 "80번 포트로 들어오는 트래픽 중 GET /public만 허용"과 같은 L7 정책이 있다면, eBPF는 해당 트래픽을 사용자 공간(User Space)에서 실행 중인 Envoy 프록시로 보냅니다.
4. L7 검사 (Envoy Proxy): Envoy 프록시는 전달받은 트래픽의 HTTP 헤더, 경로, 메소드 등을 상세히 분석하여 정책에 따라 허용/차단 여부를 결정합니다.

즉, Cilium은 필요할 때만 선별적으로 트래픽을 L7 프록시로 보내 처리하는 효율적인 하이브리드 모델을 사용합니다. L3/L4의 속도와 L7의 깊이를 모두 잡은 것이죠!

📜 코드로 보는 L4와 L7 정책의 관계

아래 CiliumNetworkPolicy 예시를 보면 이 구조를 명확히 이해할 수 있습니다.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: api-access-policy
spec:
  endpointSelector:
    matchLabels:
      app: my-api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    # ⬇️ L4 Policy: 먼저 80번 포트로 들어오는 TCP 트래픽을 허용합니다.
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      # ⬇️ L7 Policy: 위 L4 규칙에 해당하는 트래픽 중, HTTP 규칙을 추가로 적용합니다.
      rules:
        http:
        - method: "GET"
          path: "/public/.*"
        - method: "POST"
          path: "/data"

 

보시는 것처럼, L7 규칙(rules.http)은 L4 규칙(toPorts) 내부에 정의되어 있습니다. 이는 L7 정책이 L4라는 더 큰 틀 안에서 작동하는 확장 기능임을 보여주는 직관적인 증거입니다.

---

❌ "Cilium은 L7 CNI다" 라는 오해가 위험한 이유

만약 Cilium을 순수한 L7 솔루션으로만 이해하면, 다음과 같은 오해를 할 수 있습니다.

• 성능 오해: 모든 트래픽이 프록시를 통과한다고 착각하여 성능 저하를 우려할 수 있습니다. 하지만 실제로는 대부분의 트래픽이 커널에서 빠르게 처리됩니다.
• 정책 설계의 비효율성: L4에서 간단히 차단할 수 있는 트래픽을 불필요하게 복잡한 L7 정책으로 만들 수 있습니다. 기본은 L4에서 시작하는 것이 좋습니다.
• 문제 해결의 어려움: 통신 문제 발생 시, L7 프록시(Envoy)만 들여다볼 수 있습니다. 하지만 문제의 원인이 L3/L4의 기본 라우팅이나 포트 정책에 있을 수 있다는 사실을 간과하기 쉽습니다.

🎯 결론: 전체를 봐야 진짜가 보인다

Cilium의 진짜 강점은 단순히 L7 기능이 뛰어나다는 점에만 있는 것이 아닙니다.

eBPF를 활용한 초고속 L3/L4 데이터패스를 기반으로, 필요에 따라 L7 가시성과 제어 기능을 지능적으로 통합한 하이브리드 아키텍처

이것이 바로 Cilium을 이해하는 핵심입니다. 튼튼한 기초(L3/L4) 위에 정교한 기능(L7)을 쌓아 올린, 잘 설계된 건물과도 같죠. 이제 Cilium을 바라볼 때, 그 강력한 기반이 되는 L3와 L4의 역할을 꼭 기억해주세요! ✨

---