Kubernetes
K8s 고급 #5 옵저버빌리티 — Prometheus / Grafana / Loki / OpenTelemetry
운영 클러스터의 옵저버빌리티는 메트릭, 로그, 트레이스의 세 축으로 구성됩니다. 각 축의 K8s 표준 스택은 거의 굳어 있습니다. 메트릭은 Prometheus + kube-state-metrics + node-exporter, 로그는 Loki(또는 EFK), 트레이스는 OpenTelemetry, 시각화는 Grafana, 알람은 Alertmanager. 이번 글에서는 세 축의 모델과 각 축의 표준 컴포넌트, 그리고 카디널리티,보존 기간,알람 설계 같은 운영 원칙을 한 사이클로 정리하겠습니다.
K8s 고급 #4 CRD와 Operator 패턴 — controller-runtime
K8s가 강력한 이유 중 하나는 자기 API 자체를 확장할 수 있다는 점입니다. CustomResourceDefinition으로 새 객체 종류를 정의하고, controller-runtime으로 그 객체에 대한 reconcile 루프를 만들면 K8s 위에 우리 도메인의 객체가 표준 자원처럼 살게 됩니다. PostgresCluster, RedisFailover, KafkaBroker 같은 이름의 객체가 그 결과물입니다. 이번 글에서는 CRD의 모델, controller-runtime 기반의 Operator 골격, ownerReference / finalizer / status subresource까지 한 사이클로 정리하겠습니다.
K8s 고급 #3 Admission Controller — OPA Gatekeeper / Kyverno
K8s API 서버는 매니페스트를 etcd에 저장하기 직전에 검사하고 변형할 수 있는 단계를 갖고 있습니다. Admission Controller라는 이 단계가 운영 클러스터의 정책 엔진이 들어오는 길입니다. "limits 없는 컨테이너 거부", "특정 라벨 강제", "이미지 출처 제한" 같은 정책을 코드 한 줄도 안 바꾸고 매니페스트 차원에서 막아 냅니다. 이번 글에서는 admission 단계의 위치, 빌트인 컨트롤러, ValidatingWebhook과 MutatingWebhook, 그리고 두 정책 엔진 OPA Gatekeeper와 Kyverno의 모델을 한 사이클로 정리하겠습니다.
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`을 한 편에 정리하겠습니다.