Cilium은 eBPF를 이용해 쿠버네티스의 라우팅, 정책과 가시성 일부를 노드 커널에서 처리해 파드마다 붙는 프록시의 역할을 줄일 수 있습니다. 그렇다고 서비스 메시의 모든 L7 기능과 프록시가 없어지는 것은 아닙니다. 도입 여부는 “사이드카 제거”라는 목표보다 현재 기능을 어느 계층에서 대체하고 어떻게 검증, 롤백할지로 결정해야 합니다.
Cilium으로 사이드카를 줄여도 될까: L4, L7 경계와 마이그레이션
사이드카 없는 데이터 경로는 무엇이 달라지는가
사이드카 방식에서는 애플리케이션 트래픽이 파드 안의 프록시를 거치도록 리다이렉션됩니다. 이 과정은 정책과 텔레메트리를 한 위치에 모으지만 각 파드에 프록시 CPU, 메모리와 수명주기를 추가합니다. 프록시 재시작, 리소스 제한과 애플리케이션 준비 상태가 서로 영향을 주는 운영 문제도 생깁니다.
Cilium은 노드에 로드된 eBPF 프로그램과 Map을 사용해 서비스 조회, 라우팅과 L3/L4 정책을 처리합니다. 정책 정보를 파드마다 별도 프록시에 복제하기보다 노드 수준 제어기와 커널 데이터 경로가 공유하는 구조입니다. 동일 노드의 특정 소켓 통신에서는 socket-level acceleration을 사용할 수 있지만 모든 트래픽과 환경이 같은 우회 경로를 타는 것은 아닙니다.
비교할 때는 “커널 경로는 1단계, 프록시는 여러 단계” 같은 고정 도식보다 실제 노드에서 패킷 경로를 확인해야 합니다. 터널링, 암호화, 로드밸런싱, 호스트 방화벽과 클라우드 CNI 설정이 추가되면 훅과 경로가 달라집니다. 사이드카 개수를 줄였다는 사실만으로 전체 지연과 자원 사용을 추정하면 안 됩니다.
socket acceleration 예제는 무엇을 생략하는가
원문의 다음 코드는 TCP 연결이 만들어졌을 때 소켓 정보를 Map에 등록하는 개념을 단순화한 의사코드입니다. 실제 Cilium 구현과 배포 설정을 그대로 재현하는 코드로 사용해서는 안 됩니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
// 커널의 Socket Operations 훅(Hook)에 부착되는 eBPF 프로그램
SEC("sockops")
int bpf_sockmap(struct bpf_sock_ops *skops) {
// TCP 연결이 수립(ESTABLISHED)되었는지 확인
if (skops->op == BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB ||
skops->op == BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) {
// 출발지 IP/Port와 목적지 IP/Port를 기반으로 eBPF Map에 소켓 정보 저장
bpf_sock_hash_update(skops, &sock_map, &skops->local_ip4, BPF_ANY);
// 🚀 핵심 포인트: 이후 통신은 TCP/IP 스택을 우회하고 Map을 통해 다이렉트로 쏴버림!
}
return 0;
}
연결을 Map에 넣었다고 모든 후속 패킷이 자동으로 원하는 파드에 전달되는 것은 아닙니다. 주소, 포트 키, 네임스페이스, 연결 종료, 재시작과 Map 정리, 지원 프로토콜과 fallback 경로가 필요합니다. 실제 socket acceleration이 가능한 커널과 기능 플래그도 현재 Cilium 문서에서 확인해야 합니다.
시험에서는 같은 노드와 다른 노드의 파드 통신, 서비스 IP, 직접 파드 IP, 짧은 연결과 오래 유지되는 연결을 나눕니다. 기능을 끈 기준선과 켠 조건에서 연결 성공, 재전송, p50, p99 지연과 노드 CPU를 봅니다. 개선이 없는 경로까지 모두 eBPF 효과로 묶지 않는 것이 중요합니다.
L7 기능에서는 왜 프록시가 다시 필요한가
IP, 포트, 프로토콜에 따른 허용과 차단은 L3/L4 정보로 결정할 수 있습니다. 반면 HTTP 헤더 기반 라우팅, 세밀한 재시도, 일부 인증, 변환과 프로토콜 해석은 애플리케이션 계층을 이해해야 합니다. 이 기능을 커널의 짧은 eBPF 프로그램만으로 모두 구현하는 것은 목적과 제약이 맞지 않습니다.
Cilium 구성에서도 L7 정책과 서비스 메시 기능을 위해 프록시가 사용될 수 있습니다. 차이는 반드시 파드마다 sidecar가 붙는지, 노드 수준이나 다른 배치로 프록시 역할을 제공하는지에 있습니다. 따라서 “sidecarless”는 “proxyless”와 같은 말이 아니며 필요한 L7 기능이 많으면 예상한 자원 이득이 줄 수 있습니다.
현재 메시 기능을 목록으로 만들어 mTLS, 트래픽 분할, 재시도, 타임아웃, 헤더 규칙, 인증과 텔레메트리를 각각 매핑합니다. Cilium이 같은 의미와 실패 동작을 제공하는지, 노드 프록시 장애가 몇 개 파드에 영향을 주는지도 확인합니다. 기능 이름이 같아도 기본값과 관측 지표가 달라질 수 있습니다.
네트워크 정책은 어떻게 동등성을 검증할까
원문에 있던 정책 예시는 특정 백엔드 라벨에서 데이터베이스 라벨의 TCP 3306으로 나가는 트래픽과 MySQL L7 규칙을 표현합니다. 아래 YAML은 구조를 설명하는 예시이며 현재 설치 버전의 스키마와 지원 프로토콜을 공식 문서에서 다시 검증해야 합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# eBPF 기반의 L7 가시성 및 보안 정책 예시 (CiliumNetworkPolicy)
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: "rule-capture-mysql-queries"
spec:
endpointSelector:
matchLabels:
app: backend-api
egress:
- toEndpoints:
- matchLabels:
app: database
toPorts:
- ports:
- port: "3306"
protocol: TCP
rules:
l7proto: mysql
l7:
- queryAction: "select"
# Select 쿼리만 통과시키고 실시간으로 메트릭 화, 코드 수정 불필요!
정책 검증은 허용 요청만 성공시키는 것으로 끝나지 않습니다. 잘못된 라벨, DNS 변경, 새 파드 시작, 정책 갱신 중 연결과 이미 열린 연결이 어떻게 처리되는지 봅니다. 평문 프로토콜에서 볼 수 있는 정보와 암호화된 트래픽에서 볼 수 없는 정보를 구분해야 합니다. 패킷 내용을 관찰할 수 있다는 설명을 모든 TLS 연결에 일반화하면 안 됩니다.
기존 Kubernetes NetworkPolicy와 서비스 메시 정책을 동시에 적용하면 어느 계층에서 차단했는지 혼란스러울 수 있습니다. 마이그레이션 동안 각 정책의 소유자와 우선순위를 기록하고, 감사 모드나 제한된 네임스페이스에서 차이를 비교합니다. 정책 변환 도구의 성공보다 실제 allow, deny 행렬이 동일한지가 완료 조건입니다.
Hubble과 기존 네트워크 도구를 어떻게 함께 쓸까
eBPF 데이터 경로에서 패킷이 일반 캡처 지점보다 일찍 전달되거나 차단되면 기존 tcpdump만으로 전체 흐름을 보지 못할 수 있습니다. Cilium의 흐름 관측과 Hubble 같은 도구가 endpoint, identity, 정책과 drop reason을 보여 주는 이유입니다. 새 데이터 경로를 도입하면 새 관측 방법도 온콜 절차에 포함해야 합니다.
Hubble 화면이 있다고 디버깅이 자동으로 쉬워지는 것은 아닙니다. 관측 이벤트가 누락되거나 집계가 지연될 때, 제어 평면과 데이터 평면 상태가 다를 때, 노드 한 곳에서만 프로그램 로드가 실패할 때를 시험합니다. 흐름 ID를 애플리케이션 로그와 연결할 방법이 있어야 네트워크 오류와 상위 서비스 오류를 구분할 수 있습니다.
장애 훈련에서는 정책을 잘못 배포해 정상 요청이 차단되는 상황을 만듭니다. 담당자가 drop reason, 적용 정책과 노드를 찾고 안전하게 롤백하는 데 걸린 시간을 잽니다. 새 도구를 모르는 팀원이 기존 tcpdump만 반복하다가 복구를 늦추지 않도록 명령과 대시보드를 문서화합니다.
어떤 순서로 마이그레이션해야 하나
첫 단계는 현재 상태의 계측입니다. 네임스페이스별 사이드카 CPU, 메모리, 연결 수, p50, p99 지연, 오류율과 L7 기능 사용량을 기록합니다. 사이드카가 실제 병목인지 확인하지 않으면 복잡한 CNI 변경 뒤에도 사용자 지표가 달라지지 않을 수 있습니다.
다음으로 비중요 네임스페이스에서 네트워크 기능과 정책 동등성을 검증합니다. L3/L4 데이터 경로만 바꾸고 L7 프록시 기능은 유지하는 중간 단계도 비교합니다. 노드 교체, 파드 재스케줄, Cilium agent 재시작, 커널 프로그램 로드 실패와 정책 롤백을 포함합니다. 블랙프라이데이 같은 최대 부하 수치를 가정하지 말고 자체 부하 생성으로 한계를 찾습니다.
마지막에 L7 기능을 하나씩 옮깁니다. 기존 사이드카 주입을 끄기 전에 동시 운영과 트래픽 분할이 가능한지 확인하고, 서비스별로 즉시 복원할 배포 설정을 보관합니다. 성공 기준에는 성능뿐 아니라 정책 오류, 관측 가능성, 팀의 복구 시간과 커널 지원 노드 비율을 둡니다.
사이드카를 유지하는 편이 나은 경우는 언제인가
클러스터가 작고 사이드카 비용이 미미하며 L7 라우팅과 확장 필터를 많이 사용한다면 전체 교체의 이득이 작을 수 있습니다. 오래된 커널이나 관리형 플랫폼 제약으로 필요한 eBPF 기능을 쓸 수 없는 환경도 먼저 기반 업그레이드 비용을 계산해야 합니다. 네트워크 팀이 새 관측 도구와 커널 수준 문제를 지원할 여력이 없는 경우에는 운영 위험이 더 큽니다.
반대로 파드 수에 비례한 프록시 자원이 명확한 비용이고, 대부분의 요구가 L3/L4 정책과 가시성이며, 지원 커널을 표준화할 수 있다면 단계적 축소를 시험할 이유가 있습니다. 결론은 사이드카 패턴이 끝났는지가 아니라 각 기능을 가장 적은 실패 표면으로 제공하는 위치가 어디인지입니다.
현재 지원 범위는 Cilium 사이트, Cilium 저장소와 eBPF 자료에서 사용 버전에 맞춰 확인해야 합니다. 기능과 요구 커널은 바뀔 수 있으므로 특정 시점의 성능 수치나 표현을 배포 보장으로 사용하지 않습니다.
함께 읽으면 이해가 이어지는 글
- 사이드카를 없애도 될까: eBPF 서비스 메시의 경계와 선택 기준 — eBPF, Cilium이 파드별 프록시의 L3/L4 역할을 어디까지 줄일 수 있는지 살펴보고, mTLS, L7 라우팅, 관측 요구에 따라 사이드카 유지 여부를 판단합니다.
- eBPF는 사이드카를 어디까지 대체할까: XDP, Sockmap과 운영 비용의 경계 — 사이드카의 사용자 공간 경로를 eBPF의 XDP, Sockmap, BPF Map으로 옮길 때 줄어드는 비용과 그대로 남는 L7 기능, 커널, 검증기, 운영 역량의 교환을 설명합니다.
- Istio 사이드카를 없애도 될까: eBPF 서비스 메시와 L7 하이브리드 조건 — 파드별 Istio, Envoy 비용을 eBPF와 노드 단위 프록시로 줄일 수 있는 조건을 살펴보고, mTLS, 재시도, HTTP 라우팅 때문에 남는 L7 기능과 안전한 전환 기준을 정리합니다.
자주 묻는 질문
Cilium을 도입하면 Envoy 같은 프록시가 완전히 사라지나요?
아닙니다. L3/L4 네트워크와 일부 소켓 경로는 eBPF로 처리할 수 있지만 헤더 기반 라우팅처럼 복잡한 L7 기능에는 프록시가 여전히 필요할 수 있습니다.
사이드카를 제거하면 애플리케이션 지연이 반드시 줄어드나요?
보장되지 않습니다. 실제 이득은 노드 커널, 트래픽 패턴, 사용한 L7 기능과 기존 프록시 설정에 따라 달라지므로 같은 부하에서 p50, p99와 CPU, 메모리를 직접 비교해야 합니다.
Cilium 마이그레이션에서 가장 먼저 확인할 것은 무엇인가요?
현재 네트워크 정책과 서비스 메시 기능을 L3/L4, L7, mTLS, 재시도, 관측성으로 분류하고, Cilium에서 동등하게 제공되는지와 기존 경로로 즉시 롤백할 방법을 확인해야 합니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.