#쿠버네티스
136 편의 글
K8s 고급 #2 RBAC / ServiceAccount 깊이 — Aggregated ClusterRole / Impersonation / IRSA / Workload Identity
[중급 #7](/ko/posts/k8s-intermediate-7)에서 RBAC의 네 객체와 ServiceAccount의 모델을 짚었습니다. 그 위에 운영 클러스터에서 마주치는 깊이가 더 있습니다. ClusterRole을 라벨로 합쳐 확장 가능하게 만드는 Aggregated ClusterRole, 다른 사용자의 권한으로 일시적으로 행세하는 Impersonation, ServiceAccount의 토큰이 legacy secret에서 projected token으로 바뀐 흐름, 그리고 K8s의 ServiceAccount를 클라우드의 IAM과 묶어 주는 EKS의 IRSA와 GKE의 Workload Identity까지 — 권한 모델의 한 층 더 깊은 부분을 정리하겠습니다.
K8s 고급 #1 CNI 깊이 — Calico / Cilium / eBPF
K8s 고급 시리즈의 첫 글입니다. [중급 #7](/ko/posts/k8s-intermediate-7)에서 NetworkPolicy를 다루며 한 줄을 남겨 두었습니다. "매니페스트는 K8s 표준이지만, 실제 트래픽을 막는 일은 CNI 플러그인이 한다." 그 한 줄을 풀어내는 것이 이 글의 주제입니다. CNI가 무엇이고, 같은 K8s 매니페스트가 Calico 위와 Cilium 위에서 어떻게 다르게 굴러가는지, eBPF가 데이터 플레인을 어떻게 다시 그리는지를 한 사이클로 정리하겠습니다.
K8s 중급 #7 RBAC / NetworkPolicy / ResourceQuota — 보안과 자원 정책
K8s 중급 시리즈의 마지막 글입니다. [#6](/ko/posts/k8s-intermediate-6)까지 워크로드 운영 모델 — 컨트롤러, 영속 데이터, 외부 진입점, 자원 모델, 헬스 체크, 오토스케일링 — 까지 정리했습니다. 이번 글에서는 한 클러스터 위에 여러 팀,환경이 같이 사는 멀티테넌트 운영의 마지막 빈 부분을 메우는 세 객체 `RBAC`, `NetworkPolicy`, `ResourceQuota`를 정리하겠습니다. 누가 객체를 만들 수 있는가, 어떤 트래픽이 통하는가, 얼마나 많이 만들 수 있는가의 세 차원이 모두 네임스페이스 단위 정책으로 묶이며 [기초 #7](/ko/posts/k8s-basics-7)에서 짧게 짚었던 Namespace의 진짜 가치가 이 세 객체로 풀립니다. 시리즈 마지막 글이므로 7편 회고와 다음 트랙(K8s 고급) 예고도 함께 담겠습니다.
K8s 중급 #6 오토스케일링 — HPA / VPA / Cluster Autoscaler
[#5](/ko/posts/k8s-intermediate-5)까지 다룬 모델은 단일 Pod의 자원과 건강 신호 차원이었습니다. 그러나 운영의 부하는 시간대,사용자 패턴,이벤트에 따라 출렁이고, 사람이 매번 `replicas` 값을 손으로 맞추는 일은 곧 한계에 부딪힙니다. 이번 글은 그 빈 부분을 메우는 세 차원의 오토스케일링 — Pod 개수를 자동으로 늘리고 줄이는 `HPA`, Pod의 자원 요청,상한을 자동으로 권장,조정하는 `VPA`, 그리고 노드 자체를 자동으로 추가,제거하는 `Cluster Autoscaler`를 한 사이클로 정리하겠습니다. metrics-server라는 전제, HPA의 `autoscaling/v2` 매니페스트와 알고리즘, scale up,down 비대칭의 `behavior`, custom metric과 KEDA, VPA의 세 컴포넌트, HPA,VPA의 충돌, Karpenter까지 다룹니다.
K8s 중급 #5 Health check — liveness / readiness / startup probe
[#4](/ko/posts/k8s-intermediate-4)까지 Pod의 자원 모델을 정리했다면, 이번 글은 K8s가 컨테이너의 "살아 있음"과 "트래픽을 받을 준비됨"을 어떻게 판단하는가의 모델입니다. 세 종류의 probe — liveness, readiness, startup — 이 각자 다른 역할을 맡고, 잘못 설정하면 무한 재시작 루프,트래픽 미스,기동 실패 같은 운영 사고로 직결됩니다. `httpGet` / `tcpSocket` / `exec` 세 검사 방식, `initialDelaySeconds` / `periodSeconds` / `failureThreshold` 같은 공통 매개변수, liveness에 외부 의존성을 넣었을 때의 cascading failure, `terminationGracePeriodSeconds`와 PreStop 훅이 그리는 graceful shutdown까지 한 사이클로 정리하겠습니다.
K8s 중급 #4 resources.requests / limits — Pod의 자원 요청과 상한
[#3](/ko/posts/k8s-intermediate-3)까지 외부 트래픽이 클러스터 안으로 들어오는 길을 정리했습니다. 이번 글의 시점은 다시 Pod 안으로 들어옵니다 — 컨테이너가 CPU와 메모리를 어떻게 요청하고 어떻게 제한받는가의 모델입니다. `resources.requests`는 스케줄러가 노드를 고를 때 보는 값이고, `resources.limits`는 kubelet이 런타임에 강제하는 상한입니다. 이 둘의 분리, QoS 클래스(Guaranteed / Burstable / BestEffort), CPU throttling과 OOMKilled의 차이, JVM,Go 런타임의 cgroup 인식, `LimitRange`로 네임스페이스 기본값을 거는 패턴까지 한 사이클로 정리하겠습니다.
K8s 중급 #3 Ingress와 Ingress Controller — 외부 진입점
[K8s 기초 #5](/ko/posts/k8s-basics-5)의 LoadBalancer는 외부 진입의 표준이지만, 외부 노출이 필요한 Service가 수십 개라면 Service마다 클라우드 LoadBalancer를 한 개씩 띄우는 비용,관리 부담이 빠르게 커집니다. 도메인이나 경로별로 트래픽을 갈라야 하는 요구도 LoadBalancer 한 단으로는 풀리지 않습니다. 이번 글은 그 부담을 한곳에 모으는 객체 `Ingress`와, 그 매니페스트를 실제 트래픽으로 풀어 주는 **Ingress Controller**(nginx / Traefik / GKE Ingress / AWS ALB Controller 등)의 두 층 모델, 호스트,경로 기반 라우팅, `pathType`, TLS 종단, `IngressClass`까지 한 사이클로 정리하겠습니다.
K8s 중급 #2 PV / PVC / StorageClass — 영속 데이터 모델
[K8s 기초 #6](/ko/posts/k8s-basics-6)까지 매니페스트에 박힌 설정과 비밀을 외부 객체로 분리했지만, 한 차원이 더 남아 있습니다 — 데이터 자체입니다. 컨테이너 안 파일시스템은 컨테이너가 죽으면 같이 사라지지만, DB 데이터,사용자 업로드,메트릭 시계열은 Pod의 생애주기 너머까지 살아남아야 합니다. 이번 글은 세 객체 `PersistentVolume`, `PersistentVolumeClaim`, `StorageClass`의 삼각관계, 정적,동적 프로비저닝, `accessModes`, `reclaimPolicy`, `volumeBindingMode`, 그리고 [#1](/ko/posts/k8s-intermediate-1)에서 짧게 짚은 `volumeClaimTemplates`가 그 위에서 진짜로 무엇을 만들어 내는지를 한 사이클로 정리하겠습니다.
K8s 중급 #1 StatefulSet / DaemonSet / Job / CronJob — Deployment가 아닌 다른 컨트롤러들
[K8s 기초 #4](/ko/posts/k8s-basics-4)의 Deployment는 stateless 워크로드 위에 서 있는 컨트롤러입니다. 같은 Pod 여러 개가 서로 같다고 가정하고, 사라져도 다시 띄우면 그만이라는 단순한 모델입니다. 그러나 정체성과 디스크가 필요한 DB, 노드마다 정확히 하나씩 떠야 하는 에이전트, 한 번 실행하고 끝나야 하는 마이그레이션, 매일 도는 백업 — 이 네 가지는 Deployment로는 표현되지 않습니다. 이번 글은 그 역할을 담당하는 네 컨트롤러 `StatefulSet`, `DaemonSet`, `Job`, `CronJob`을 한 편에 정리하겠습니다.
K8s 기초 #7 Namespace와 라벨 — 클러스터 정리법
시리즈를 따라오면서 한 가지 사실이 조용히 지나갔습니다 — 지금까지 만든 Pod, Deployment, Service, ConfigMap, Secret이 전부 default 네임스페이스 한 곳에 들어갔다는 점. 그리고 [#4](/ko/posts/k8s-basics-4) selector부터 라벨도 쭉 보고 있었지만 정리는 안 했습니다. 이번 글은 그 두 도구 — Namespace와 라벨 — 로 클러스터를 사람이 읽을 수 있는 모양으로 정리하는 법, 그리고 시리즈 7편의 도착점에서 다음 트랙(K8s 중급)을 짧게 예고합니다.
K8s 기초 #6 ConfigMap과 Secret — 설정 분리
[#5](/ko/posts/k8s-basics-5)까지 만든 매니페스트에는 한 가지가 어색하게 남아 있습니다 — 이미지 태그,포트,도메인 같은 값이 매니페스트에 직접 적힌 채라는 점. 이번 글은 두 객체 ConfigMap과 Secret을 정리하겠습니다. 12-factor의 "설정은 환경에 둔다"를 K8s에서 푸는 모양, env / envFrom / volume 세 가지 주입 방식, Secret이 진짜로 암호화는 아니라는 한 줄, 설정이 바뀌었을 때 Pod 재시작이 필요한 이유까지 한 사이클 따라가겠습니다.
K8s 기초 #5 Service — ClusterIP / NodePort / LoadBalancer
[#4](/ko/posts/k8s-basics-4)에서 Pod 3개를 띄우는 데까지는 왔지만, 그 3개에 트래픽을 어떻게 흘릴지가 비어 있습니다. Pod IP는 매번 바뀌고, 같은 Deployment의 3개 Pod 사이에 부하 분산도 안 되고, 외부 브라우저에서는 접근이 아예 안 됩니다. 이번 글은 그 문제를 해결하는 추상화 — Service의 안정 IP,DNS, selector,Endpoints의 동작, ClusterIP / NodePort / LoadBalancer 세 타입의 선택 기준까지 한 사이클 따라가겠습니다.