N° 01 — 목록
'분류 전체보기' (197)
-
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 정책이 ..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 06. network-policy
NetworkPolicy 하나 넣었더니 모든 트래픽이 막혔다 — "기본 허용" 함정한 팀이 보안 점검을 앞두고 NetworkPolicy를 도입했다. "웹 Pod는 DB Pod로만 가게 하자"며 정책을 하나 넣었다. 그랬더니 갑자기 다른 트래픽 — 웹 Pod가 외부 API를 부르던 것, 모니터링이 메트릭을 수집하던 것 — 이 전부 멈췄다. "정책을 하나만 넣었는데 왜 다 막혔지?" 이 팀이 부딪힌 것이 NetworkPolicy의 "기본 허용, 정책 시 화이트리스트" 모델이다.이 글이 푸는 것은: NetworkPolicy가 기본으로 모든 트래픽을 허용하는 이유, 하나의 정책이 왜 전체를 막는가, 그리고 L3/L4 격리의 한계다.왜 Kubernetes 네트워크 기본이 "전부 허용"인가대부분의 방화벽은 기본이 ..
-
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가 규모에서 무너지나 — 선형 탐색..