N° 01 — 목록
'Kubernetes' (40)
-
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 - 11. istio
Istiod가 수천 개의 Envoy를 어떻게 조율하는가 — 그리고 Ambient가 바꾸는 것한 팀이 Istio를 도입했다. 500개의 Pod에 사이드카(Envoy)가 하나씩 들어갔다. 그 500개의 Envoy에게 "서비스 간 mTLS, 카나리 규칙, 분산 추적"을 어떻게 일관되게 적용할까? 사람이 500대를 돌며 설정할 수는 없다. Istiod가 그 조율을 담당한다 — 컨트롤플레인이 500개의 사이드카를 watch 모델로 지휘한다. 그런데 최근 Istio에 Ambient mesh라는 사이드카 없는 모드가 들어왔다. 이것이 메시의 판도를 어떻게 바꾸나?이 글이 푸는 것은: Istio의 아키텍처(Istiod + Envoy 사이드카), 트래픽 관리 객체(VirtualService/DestinationRule)..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 10. service-mesh concepts
왜 모든 앱에 "트래픽 관리 코드"를 중복해서 짜야 할까 — 서비스 메시가 푸는 문제마이크로서비스가 30개로 늘었다. 각 서비스마다 같은 코드가 반복됐다: 재시도, 타임아웃, 서킷 브레이커, 메트릭, 분산 추적, mTLS 인증. 개발자는 비즈니스 로직보다 이 인프라 코드*를 더 짜고 있었다. 그리고 언어마다(Java/Go/Node) 각자 다시 구현했다. 한 팀이 물었다: "이걸 *앱 밖으로 뺄 수 없나?" 서비스 메시(service mesh)가 바로 그 답이다.이 글이 푸는 것은: 서비스 메시가 어떤 문제를 풀고, 사이드카 패턴으로 어떻게 앱 코드에서 인프라 로직을 빼내는가다. 이해하면 11장(Istio)/12장(Cilium 메시)의 설계가 보인다.서비스 간 통신에 필요한 것 — 그리고 그것이 앱마다 중..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 09. gateway-api
Ingress의 뒤를 잇다 — Gateway API가 역할 분리로 푸는 문제2024년 ingress-nginx에서 치명적 CVE(CVE-2025-1974)가 발견됐다 — 컨트롤 플레인 컴포넌트가 임의 코드 실행까지 허용할 수 있는 구멍이었다. 동시에 ingress-nginx의 유지보수 부담이 오랜 이슈로 떠올랐다. 커뮤니티는 한 방향으로 수렴했다: 단순히 패치를 넘어, L7 진입의 다음 세대 API인 Gateway API로의 전환. 한 팀은 이를 기회 삼아, 수백 줄의 nginx annotation을 표준 API로 재작성했다 — 더 이상 nginx 전용이 아닌, 어느 구현체든 해석하는 매니페스트로.이 글이 푸는 것은: Gateway API가 Ingress의 어떤 근본 한계를 어떻게 해결하는가, 그리고 왜..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 08. ingress
"경로마다 다른 앱으로"를 annotation으로 때우던 시절 — Ingress와 그 한계한 팀이 단일 도메인에서 경로별로 여러 앱을 서비스하려 했다: /api는 백엔드, /는 프론트, /admin은 관리자 앱. Ingress로 이걸 표현하려 하자 — HTTP 헤더 기반 라우팅, 호스트별 정책, TLS 종단이 필요했다. 그런데 Ingress API엔 이런 것들이 없었다. 결국 nginx.ingress.kubernetes.io/... 같은 구현체별 annotation으로 한 줄 한 줄 때웠다. 그 매니페스트는 nginx 전용이 돼 다른 Ingress Controller로 못 옮겼다.이 글이 푸는 것은: Ingress가 L7(외부→클러스터) 진입을 어떻게 다루고, 왜 그 표현력 한계가 Gateway API로..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 07. calico advanced-policy
"이 IP만 거부해라" — 기본 NetworkPolicy가 못 하는 것을 Calico CRD가 푸는 법보안 팀이 한 가지를 더 요구했다: "특정 의심 IP에서 오는 모든 트래픽을 거부해라." 팀은 06장의 기본 NetworkPolicy로 시도했다. 그런데 기본 NetworkPolicy엔 거부(deny) 규칙이 없다 — 모든 규칙이 "허용"이다. "화이트리스트로 우회하라"는 답을 들었지만, IP 대역이 수천 개면 화이트리스트는 현실이 아니다. 팀은 Calico CRD 정책(GlobalNetworkPolicy)으로 넘어갔다 — 거부 규칙이 있고, L7까지, namespace마다 따로 안 써도 된다.이 글이 푸는 것은: 06장에서 본 기본 NetworkPolicy의 네 가지 한계를 Calico CRD 정책이 ..