N° 01 — 목록
'Cloud & Infrastructure/Kubernetes Networking' (14)
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 14. multi-cluster
클러스터 경계를 넘는 서비스 — 멀티클러스터 네트워킹의 두 접근한 조직이 리전별로 클러스터 3개(서울/도쿄/버지니아)를 운영한다. 각 클러스터는 독립적이다 — 그런데 "서울 클러스터의 서비스가 도쿄 클러스터의 서비스를 불러야 한다"는 요구가 생겼다. 인터넷 경유 공개 API로만 부르자니 지연과 보안이 문제다. 멀티클러스터 네트워킹이 이 문제를 푼다 — 클러스터 경계를 넘어 Pod가 마치 같은 클러스터에 있는 것처럼 통신하게.이 글이 푸는 것은: 클러스터 간 Pod/Service 통신을 어떻게 만드는가, Submariner와 Cilium Cluster Mesh 두 접근이 어떻게 다른가다. 02-k8s-networking 영역의 마지막 주제로, 규모가 커질 때의 네트워크 진화를 다룬다.왜 클러스터를 여러 개..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 13. troubleshooting
"네트워크가 안 된다"에서 시작해 범인을 좁히는 법 — 트러블슈팅 결정 트리한 서비스가 "DB에 연결이 안 된다"고 보고됐다. 운영자가 1시간을 헤맸다 — Pod가 살아있는지, Service가 있는지, NetworkPolicy가 막는지, CNI가 꼬였는지, DNS가 풀리는지 전부 의심했다. 결국 원인은 conntrack 테이블 만료. 그런데 그 1시간의 대부분은 틀린 층을 뒤진 데 쓰였다. 이 글은 그 1시간을 5분으로 줄이는 결정 트리를 다룬다.이 글이 푸는 것은: "네트워크가 안 된다"는 모호한 증상에서 시작해, 어느 층(DNS/kube-proxy/CNI/정책/커널)인지를 체계적으로 좁히는 절차다. 핵심은 층별로 나눠 한 층씩 검증하는 것이다.먼저 층을 나눈다 — 어디를 의심할 것인가지금까지 01~1..
-
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의 어떤 근본 한계를 어떻게 해결하는가, 그리고 왜..