Kubernetes
K8s 실전 #3 DB 연동 — RDS / Secrets Manager / External Secrets / 커넥션 풀
[#2](/ko/posts/k8s-practice-2)에서 외부 노출까지 만든 myshop-api는 데이터 저장소가 비어 있는 빈 껍데기입니다. 이번 글에서는 RDS PostgreSQL을 Terraform으로 띄우고, AWS Secrets Manager에 마스터 비밀을 두고, External Secrets Operator로 그 비밀을 K8s Secret으로 자동 동기화하고, IRSA로 정적 자격 증명 없이 접근하고, PgBouncer로 커넥션 풀까지 얹는 운영 흐름을 정리하겠습니다. 스키마 마이그레이션을 Job으로 자동화하는 패턴도 함께 짚겠습니다.
K8s 실전 #2 앱 배포의 기본 구조 — Deployment / Service / Ingress / Helm
[#1](/ko/posts/k8s-practice-1)에서 띄운 비어 있는 EKS 클러스터에 myshop-api를 올리는 단계입니다. Deployment / Service / Ingress / ConfigMap / Secret / ServiceAccount / HPA를 한 묶음으로 정리하고, AWS Load Balancer Controller로 ALB를 자동 프로비저닝하고, 그 묶음을 Helm 차트로 추상화해 dev / prod에 같은 차트가 다른 values로 배포되는 흐름까지 한 사이클로 정리하겠습니다.
K8s 실전 #1 EKS 클러스터 셋업 — Terraform / eksctl / IRSA / 애드온
K8s 실전 시리즈의 첫 글입니다. 추상이 아니라 실제 운영 클러스터를 구성하는 흐름을 따라가겠습니다. Terraform으로 VPC와 EKS 클러스터를 정의하고, 노드 그룹과 IRSA를 셋업하고, 필수 애드온(VPC CNI, CoreDNS, kube-proxy, EBS CSI)까지 얹는 흐름입니다. 빠른 셋업이 필요할 때의 eksctl 옵션도 함께 비교하겠습니다. 6편 전체에서 사용할 가상 서비스 myshop-api를 위한 클러스터의 출발점을 만드는 첫 글입니다.
K8s 고급 #6 GitOps — ArgoCD / Flux
K8s 고급 시리즈의 마지막 글입니다. 매니페스트의 source of truth를 git에 두고, 클러스터 안의 컨트롤러가 git을 watch해 동기화하는 운영 모델 — GitOps를 정리하겠습니다. push 모델과 pull 모델의 차이, ArgoCD의 Application CRD와 sync wave, Flux의 Source / Kustomization / HelmRelease, 디렉터리 구조 패턴, Sealed Secrets / External Secrets로 비밀을 git에 안전하게 두는 길까지가 이번 글의 범위입니다. 시리즈 마지막 글이므로 K8s 고급 6편 회고와 다음 트랙 K8s 실전의 예고도 같이 담겠습니다.
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까지 한 사이클로 정리하겠습니다.