N° 01 — 목록
'ebpf' (4)
-
Infra Architecture/Compute PlatformsCompute Platforms - 10. 서버 성능 분석
"느리다"는 말에 데이터로 답한다 — 서버 성능 분석2019년, Brendan Gregg(Netflix 수석 성능 엔지니어)가 발표한 "eBPF for Performance Analysis" 데모는 충격적이었다. 그는 단 한 줄의 명령(bpftrace)으로 — 서버의 모든 시스템 콜을 나노초 단위로 추적하고, 어느 함수가 느린지 실시간으로 보여줬다. 기존의 성능 분석 도구(perf·strace·gdb)가 "무겁고 불편하다"고 느끼던 엔지니어들에게 — eBPF는 "커널 안에서 안전하게 돌아가는 가벼운 추적 도구"라는 새 세계를 열었다. 이 글은 서버가 "왜 느린가?"라는 질문에 데이터로 답하는 도구와 방법론을 다룬다.서버 성능 문제는 인프라 엔지니어가 가장 자주 만나는 도전이다. "서비스가 느려졌다"는 보..
-
Cloud & Infrastructure/Kubernetes SecurityK8s Security - 10. audit runtime-security
정적 방어를 넘어 "지금 무슨 일이 일어나는가"를 잡는 법 — 감사와 런타임 보안한 클러스터에서 침해가 일어났다. 공격자는 권한을 올리고 비밀을 빼갔지만, 발견은 며칠 뒤였다. 아무도 실시간으로 "이상한 일이 돌아가고 있다"를 못 봤기 때문이다. 지금까지의 정적 방어 — RBAC·NetworkPolicy·Pod Security — 는 "들어오는 것"을 막는 데는 강하지만, 이미 들어와서 행동하는 것은 잡지 못한다. 이 빈을 메우는 두 축이 감사 로그(audit log)와 런타임 보안(Falco)이다. 전자는 "누가 무엇을 했나"를 사후에 기록하고, 후자는 "지금 커널에서 무슨 일이 일어나나"를 실시간으로 잡는다. 이 글은 03-k8s-security 영역의 마지막 주제로, 이 두 관측 축이 침해를 어떻게..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 12. cilium-service-mesh
사이드카 없는 메시가 가능한 이유 — Cilium이 eBPF로 지운 계층한 클러스터에 Pod가 3000개였다. Istio 사이드카를 넣으려 하니 — Envoy 인스턴스 3000개, 자원 오버헤드가 어마어마했다. 메모리만 수십 기가. 팀은 물었다: "Pod마다 프록시를 넣지 않고 메시를 할 수 없나?" Cilium Service Mesh가 그 질문에 답한다 — eBPF가 커널 단에서 메시 기능을 처리해 사이드카를 없앤다.이 글이 푸는 것은: 왜 사이드카 없는 메시가 가능한가, Cilium이 eBPF로 사이드카의 어떤 역할을 흡수하는가, 그리고 Istio/Linkerd와 어떻게 다른가다.사이드카 메시의 비용 — 왜 "없애고" 싶은가10장에서 사이드카 메시(Istio 등)의 비용을 봤다:Pod마다 Envoy ..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 05. cilium ebpf
Cilium이 eBPF로 kube-proxy를 통째로 바꾸는 법한 클러스터의 노드가 2000개였다. Service가 만 개 넘게 있었고, kube-proxy가 각 노드에 만든 iptables 규칙이 수십만 줄이었다. 패킷 하나를 라우팅할 때마다 커널이 그 규칙을 선형으로 훑었다 — 지연이 눈에 띄게 커졌다. 팀은 Cilium으로 전환했다. kube-proxy를 끄고, eBPF가 라우팅을 직접 처리하게 했다. 규칙이 해시 테이블로 바뀌어 거의 일정한 속도로 떨어졌다.이 글이 푸는 것은: Cilium이 eBPF로 왜 iptables/kube-proxy를 대체할 수 있는가, 그리고 그것이 단순히 "빠른 CNI"가 아니라 근본적으로 다른 데이터플레인인 이유다.왜 iptables가 규모에서 무너지나 — 선형 탐색..