K8s L7 네트워크 정책 실패 원인? eBPF 기반 디버깅 워크플로우 완벽 가이드

K8s L7 네트워크 정책 실패? eBPF 기반 근본 원인 분석 및 디버깅 가이드

클라우드 네이티브 환경이 성숙해지면서, 단순히 포트(L4)를 열어주는 수준을 넘어 '어떤 헤더를 가진 요청만 허용할지'와 같은 애플리케이션 레벨(L7)의 트래픽 제어가 필수화되었습니다. 서비스 메시(Service Mesh)의 도입과 함께 Kubernetes 네트워킹 정책의 복잡도는 기하급수적으로 증가했습니다.

하지만 막상 NetworkPolicy를 적용하고 "특정 API 키가 포함된 요청만 통과해야 한다"와 같은 정교한 규칙을 설정했을 때, 트래픽이 예상과 다르게 통과되거나 아예 차단되는 상황을 경험하는 것은 숙련된 인프라 엔지니어에게도 흔한 난관입니다. 단순히 kubectl apply를 다시 실행하는 것만으로는 이 문제를 해결할 수 없습니다.

이 글은 단순한 정책 적용 실패 메시지 너머, eBPF 레벨에서 발생하는 L7 트래픽 필터링의 근본적인 원인을 진단하고, 실질적인 디버깅 워크플로우를 제공하여 여러분의 네트워킹 문제 해결 능력을 한 단계 끌어올리는 것을 목표로 합니다.

iptables와 eBPF: 네트워크 정책 처리 방식의 근본적 차이 이해하기

네트워크 정책을 이해하려면, 커널이 패킷을 처리하는 방식을 알아야 합니다. 전통적인 방식과 최신 eBPF 기반 방식은 처리 메커니즘 자체가 다릅니다.

1. iptables 기반 처리 (커널 체인 기반)

iptables는 리눅스 커널의 Netfilter 프레임워크를 사용하여 패킷을 체인(Chain)별로 순차적으로 검사합니다. 각 정책 규칙은 하나의 '규칙(Rule)'으로 존재하며, 패킷이 들어올 때마다 이 규칙들을 순차적으로 매칭(Match)하고 액션(Accept/Drop)을 결정합니다.

한계점: 규칙이 많아질수록 매칭 과정에서 오버헤드가 누적되며, L7과 같은 복잡한 애플리케이션 레이어 정보(HTTP 헤더 등)를 검사하려면 커널 모듈이나 복잡한 트래픽 분리를 거쳐야 하므로 성능 병목이 발생하기 쉽습니다.

2. eBPF 기반 처리 (프로그램 로딩 기반)

eBPF(extended Berkeley Packet Filter)는 커널 공간에 사용자 정의 프로그램을 로드하여 네트워크 패킷이 커널 내부의 특정 지점(Hook Point)을 통과할 때 실행되도록 합니다. Cilium과 같은 최신 CNI는 이 eBPF를 활용하여 네트워킹 로직을 구현합니다.

장점:

1. 성능: 패킷이 들어올 때마다 모든 규칙을 순차적으로 검사하는 것이 아니라, 필요한 로직만 커널 내부에 효율적으로 '붙여넣기(Attach)' 하므로 오버헤드가 극적으로 낮습니다.
2. 기능성: L7 프로토콜 레벨의 정보를 커널 수준에서 직접 검사하고 필터링하는 것이 구조적으로 용이합니다.

💡 실무자의 관점: 저는 과거에 L7 정책 실패로 인해 수많은 시간을 허비했던 경험이 있습니다. 그때는 단순히 "정책이 적용되지 않았다"고만 보고했지만, 알고 보니 eBPF가 특정 트래픽 흐름(예: Keep-Alive 패킷)을 '정책 검사 대상'으로 인식하지 못하고 우회시키고 있었던 것이 근본 원인이었습니다. 이처럼 추상적인 '실패' 메시지 뒤에 숨겨진 패킷의 생애 주기(Lifecycle)를 이해하는 것이 핵심입니다.

L7 필터링 실패를 유발하는 3가지 함정

L7 정책이 실패하는 경우는 보통 다음 세 가지 중 하나에 해당합니다.

1. 정책 적용 순서의 함정 (Order Dependency)

네트워크 정책은 순서가 중요합니다. 만약 가장 포괄적인 Allow All 규칙이 너무 상위에 위치하거나, 특정 예외 처리가 필요한 규칙보다 먼저 일반적인 Drop 규칙이 실행되면, 의도한 로직이 실행되기 전에 트래픽이 차단되거나 통과될 수 있습니다.

2. 오버헤드와 성능 제한의 함정 (Overhead & State)

L7 필터링은 본질적으로 상태(Stateful) 검사를 요구합니다. 예를 들어, "X-API-Key가 유효한 세션 쿠키를 가진 요청만 허용"하려면, 해당 키의 유효성 검사(DB 조회 등)가 필요합니다. 이 검증 과정 자체가 커널 레벨에서 수행되려 할 때, 성능 오버헤드가 발생하거나, 정책 엔진이 이를 '과도한 부하'로 간주하고 검사를 건너뛸 수 있습니다.

3. 패킷 흐름의 불일치 (Flow Mismatch)

가장 흔한 실수입니다. 정책은 보통 '요청(Ingress)'에만 초점을 맞춥니다. 하지만 L7 통신은 요청과 응답(Response)의 왕복(Round Trip)으로 이루어집니다. 만약 Ingress 정책은 완벽하지만, Egress(나가는 트래픽)에 대한 정책이 누락되거나, 서비스 메시가 Sidecar를 통해 트래픽을 변조하는 과정에서 정책 엔진이 해당 변조된 패킷을 '새로운 흐름'으로 오인하여 정책 검사를 건너뛰는 경우가 발생합니다.

실전 디버깅 워크플로우: tcpdump와 cilium status의 조합

이러한 함정들을 극복하기 위해, 우리는 '정책 엔진의 의도'와 '실제 패킷의 흐름'을 교차 검증해야 합니다.

1단계: 정책 엔진의 상태 확인 (What Should Happen?)

먼저, 정책이 실제로 커널에 로드되었는지, 그리고 어떤 규칙이 활성화되었는지 확인합니다. Cilium을 사용한다면 cilium status가 가장 강력한 도구입니다.

# 활성화된 네트워크 정책 목록 및 상태 확인
cilium status
# 특정 네임스페이스의 정책 상세 확인 (버전 및 환경에 따라 명령어 상이)
kubectl get netpol -n <namespace>

만약 cilium status에서 정책이 정상적으로 보고되지만 트래픽이 막힌다면, 문제는 정책 정의가 아닌 패킷의 흐름에 있을 확률이 높습니다.

2단계: 실제 패킷 캡처 및 분석 (What Is Happening?)

이 단계에서는 tcpdump를 사용하여, 문제가 발생하는 Pod의 네트워크 인터페이스에서 실제 패킷이 어떻게 오가고 있는지 '눈으로' 확인해야 합니다.

예를 들어, api-server Pod가 frontend Pod로부터 특정 헤더를 가진 요청을 받아야 하는데 실패한다고 가정해 봅시다.

# 문제가 발생하는 Pod의 노드에서 실행 (가장 정확함)
# eth0는 실제 네트워크 인터페이스 이름으로 변경 필요
sudo tcpdump -i eth0 -nn host <target_pod_ip> and port 8080 -w capture_fail.pcap

캡처된 .pcap 파일을 Wireshark로 열어보면, 다음과 같은 패턴을 찾을 수 있습니다.

• 패킷이 아예 도달하지 않음: 이는 L3/L4 레벨의 방화벽이나 CNI의 기본 라우팅 문제일 가능성이 높습니다.
• 패킷이 도달했으나, 예상치 못한 포트로 드롭됨: L7 필터링 로직이 작동했으나, 정책 엔진이 해당 패킷을 '허용된 흐름'으로 인식하지 못하고 드롭한 경우입니다.
• 헤더가 누락되거나 변형됨: 서비스 메시나 프록시 레이어에서 트래픽을 변조하는 과정에서, 정책 엔진이 검사하는 시점의 헤더 정보가 손실된 경우입니다.

3단계: 정책 YAML 예시 및 검토 (Best Practice)

L7 정책을 정의할 때는 http 매칭을 명시적으로 사용하고, 필요한 경우 metadata를 활용하여 검증 로직을 명확히 분리하는 것이 좋습니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-secure-api
  namespace: api-ns
spec:
  podSelector:
    matchLabels:
      app: api-server
  policyTypes:
    - HTTP
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: HTTP
          port: 8080
      # L7 매칭을 명시적으로 정의
      rules:
        - operation: GET
          headers:
            # 반드시 이 헤더와 값이 포함되어야 함
            X-API-Key:
              str: "secure-key-123"

결론: 안정적인 L7 네트워크 제어를 위한 최종 체크리스트

L7 네트워크 정책은 단순한 설정 파일이 아니라, 복잡한 커널 레벨의 동작 로직입니다. 정책이 실패했을 때 다음 순서로 점검하는 습관을 들이는 것이 가장 중요합니다.

1. [정책 정의] 정책 YAML에 policyTypes: [HTTP]와 같은 L7 타입을 명시했는가?
2. [정책 로드] cilium status 등을 통해 정책이 정상적으로 커널에 로드되었음을 확인했는가?
3. [흐름 검증] tcpdump를 통해 문제가 되는 트래픽이 실제로 Pod에 도달하는지, 그리고 헤더 정보가 변조되지 않았는지 확인했는가?
4. [예외 처리] 정책이 너무 광범위한 Allow 규칙에 의해 무효화되지는 않았는지, 또는 필수적인 Keep-Alive 트래픽이 예외 처리되었는지 점검했는가?

이 워크플로우를 체화한다면, "정책 적용 실패"라는 모호한 메시지 대신, "패킷이 3단계에서 X 이유로 드롭됨"이라는 명확한 진단에 도달할 수 있을 것입니다.

참고: 공식 문서

이 글에서 다루는 동작·설정·에러의 1차 출처는 다음 공식 문서입니다. 버전별 옵션과 정확한 동작은 여기서 확인하세요.

• Kubernetes 공식 문서

자주 묻는 질문 (FAQ)

Q1: L7 정책을 적용했는데, Health Check 트래픽이 차단되는 경우가 있습니다. 어떻게 해야 하나요? A1: Health Check 트래픽은 종종 주기적이고 예측 가능한 패턴을 가지므로, 해당 트래픽의 소스 IP/Pod와 포트를 별도로 정의하여 Allow 규칙을 최상단에 배치하거나, 정책 엔진이 이를 무시하도록 예외 처리를 하는 것이 가장 안전합니다.

Q2: Cilium을 사용하지 않고, 순수 Kubernetes NetworkPolicy만으로 L7 필터링이 가능한가요? A2: 기본 Kubernetes NetworkPolicy 리소스 스펙만으로는 L7 필터링(HTTP 헤더 기반)을 직접 지원하지 않습니다. L7 필터링을 위해서는 Cilium과 같이 eBPF를 활용하여 L7 기능을 확장한 CNI 플러그인이 필수적입니다.

Q3: tcpdump로 패킷을 캡처했는데, 헤더 정보가 보이지 않습니다. 원인은 무엇인가요? A3: 이는 패킷이 이미 커널의 특정 계층(예: Service Mesh Sidecar 프록시)을 통과하면서 L7 정보가 추상화되거나 제거되었을 가능성이 높습니다. 이 경우, tcpdump보다 해당 프록시의 로그나 사이드카 컨테이너의 트래픽을 모니터링하는 것이 더 정확할 수 있습니다.