N° 01 — 목록
'identity' (2)
-
Cloud & Infrastructure/Kubernetes SecurityK8s Security - 02. authentication
"누구인가"를 증명하는 세 가지 방법 — Kubernetes 인증의 지형한 클러스터에 세 종류의 접속자가 있었다: 운영자(사람), CI/CD 파이프라인(자동화), 그리고 Pod 안의 앱. 셋 다 apiserver에 접근하지만 증명 방식이 달랐다 — 운영자는 회사 SSO(OIDC), CI는 서비스 계정 토큰, 앱은 마운트된 토큰. Kubernetes는 이 셋을 다른 방식으로 식별한다. "인증"이 하나가 아니라는 것을 모르면, 접속이 안 되는 이유를 엉뚱한 곳에서 찾는다.이 글이 푸는 것은: Kubernetes가 "누구인가"를 증명받는 여러 방식(X.509, OIDC, Service Account token)과 그 차이다. 특히 왜 세 방식이 다른가 — 접속자의 성격(사람/자동화/시스템)이 방식을 결정한다는..
-
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가 규모에서 무너지나 — 선형 탐색..