주의) 이 글은 eBPF 자체의 동작 원리나 쿠버네티스 자체의 동작 원리를 설명하는 글이 아니다. Cilium은 쿠버네티스를 위한 eBPF 기반 네트워킹·보안·가시성(Observability) 플랫폼이다. 쿠버네티스에 배포된 파드는 저마다 IP를 가진 채로 죽고 다시 뜨기를 반복한다. 그때마다 IP가 바뀌고, 배포 한 번에 수십 개의 IP가 사라지고 새로 생기기 때문에 전통적인 제어 규칙인 IPTables는 그때마다 재작성이 필요하다. 이는 성능 저하로 […] ||
주의) 이 글은 eBPF 자체의 동작 원리나 쿠버네티스 자체의 동작 원리를 설명하는 글이 아니다.
Cilium은 쿠버네티스를 위한 eBPF 기반 네트워킹·보안·가시성(Observability) 플랫폼이다. 쿠버네티스에 배포된 파드는 저마다 IP를 가진 채로 죽고 다시 뜨기를 반복한다. 그때마다 IP가 바뀌고, 배포 한 번에 수십 개의 IP가 사라지고 새로 생기기 때문에 전통적인 제어 규칙인 IPTables는 그때마다 재작성이 필요하다. 이는 성능 저하로 이어질 수 있다. 더 큰 문제는 수시로 변하는 IP만으로는 “이 IP가 어떤 워크로드인가”를 정의하기 어렵다는 점이다.
Cilium은 이 문제를 IP 대신 Identity라는 개념으로 풀어낸다. Identity는 IP 주소가 아니라 파드(Pod)의 쿠버네티스 라벨(Label, 예: app=frontend)을 기반으로 부여되는 숫자 형식의 보안 식별자다. Cilium은 이 Identity 값을 기준으로 정책을 만들고 평가한다. 즉 파드가 100개로 늘어나도 정책 자체는 그대로 유지된다. 이를 정책으로 표현하면 다음과 같다. app=frontend Identity가 app=backend Identity와 통신 가능/불가능. 파드의 IP가 바뀌어도 라벨이 유지되면 같은 Identity를 사용하므로 정책을 수정할 필요가 없다. 이러한 Identity는 클러스터 내에서 전역으로 관리되는 값이다.
Identity 외에 추가로 알아야 할 개념이 Endpoint다. 컨테이너가 동일한 IP 주소를 공유하는 파드 단위를 Cilium에서는 Endpoint라고 부른다. Cilium은 클러스터 노드마다 개별 Endpoint ID를 할당하고 관리한다.
정리하면, 정책의 표현은 Identity 기준으로 만들고, 그 정책이 실제로 적용되는 대상은 Endpoint라고 설명할 수 있다. 예를 들어 아래와 같은 정책이 있다고 가정한다.
endpointSelector:
matchLabels:
app: netshoot
ingress:
- fromEndpoints:
- matchLabels:
app: backend
Cilium은 app: backend 라벨을 Identity로 변환한다. 즉 내부적으로는 Identity(12345, app=backend) -> Identity(6789, app=netshoot) 통신을 허용으로 처리하는 방식이다.
전통적인 쿠버네티스의 패킷 처리는 커널의 IPTables를 거친다. IPTables는 규칙 체인에 패킷이 도달하면 체인을 선형적으로 탐색해 판단하는데, 이는 대규모 서비스에서 병목이 될 수 있다. Cilium은 기존 IPTables 사용을 걷어내고 eBPF 프로그램을 커널의 특정 지점에 부착해 패킷을 처리한다. 이 부분은 뒤에서 다시 자세히 살펴본다. 내부 트래픽은 cgroup/connect를 후킹해서 처리하고, 외부 트래픽은 TC 혹은 TCX 계층을 후킹(eBPF 프로그램 부착)해서 처리한다. 그 결과 커널 네트워크 스택을 이른 시점에 종료시키고, IPTables처럼 선형적으로 탐색하는 구간도 사라져 속도 면에서 개선을 이뤘다. 즉 Cilium은 Pod to Pod 통신뿐 아니라 기존 kube-proxy가 제공하던 Service to Pod 기능까지 함께 수행한다.
앞으로 Cilium을 설명할 때 IP, Endpoint, Identity라는 세 가지 개념이 자주 등장하므로 헷갈리지 않도록 미리 정의하고 넘어간다.
Identity: 무엇인가(정