#쿠버네티스
136 편의 글
Certified Kubernetes Administrator (CKA) #2 클러스터 아키텍처 1: Control plane (apiserver/etcd/scheduler/controller-manager)
Certified Kubernetes Administrator (CKA) 시리즈의 두 번째 글입니다. 클러스터가 어떻게 도는지 control plane부터 들여다봅니다. kube-apiserver(모든 통신의 관문), etcd(클러스터 상태 저장소), kube-scheduler(Pod 배치 결정), kube-controller-manager(reconciliation loop)가 각각 무슨 일을 하는지, control plane이 static Pod로 어떻게 떠 있는지, 그리고 컴포넌트가 죽으면 클러스터에 무슨 일이 생기는지 운영자 관점으로 정리하겠습니다.
Certified Kubernetes Administrator (CKA) #1 시험 환경: alias와 dry-run, vim/yq 셋업, 시간 관리
Certified Kubernetes Administrator (CKA) 시리즈의 첫 글입니다. 2시간 실기 시험의 구조와 5개 도메인 비중(Troubleshooting 30%가 핵심), 합격선과 응시 환경을 정리하고, 시험 시간을 가르는 셋업(alias, dry-run, vim/yq, etcdctl, systemctl)을 손에 익히겠습니다. 이 시리즈는 CKA 합격을 목표로 하는 27편이며, 마지막 #27에서 실기 모의고사를 풉니다.
K8s 실전 #6 운영 체크리스트 — 업그레이드 / 백업,복구 / 비용 / 보안
K8s 실전 시리즈의 마지막 글입니다. 클러스터를 안정적으로 띄우는 일과 한 해 동안 안전하게 운영하는 일은 다른 결의 작업입니다. EKS 클러스터 업그레이드 사이클, 노드 그룹 교체 패턴, RDS 자동 백업과 PITR, Karpenter와 Spot으로 비용을 잡는 길, kube-bench와 Trivy로 보안 점검을 정기화하는 흐름까지 정리하겠습니다. 마지막 글이므로 K8s 실전 6편 회고와 26편짜리 K8s 트랙 전체의 회고도 함께 담겠습니다.
K8s 실전 #5 모니터링,알람 — Prometheus / CloudWatch / Alertmanager
[#4](/ko/posts/k8s-practice-4)까지 만든 myshop-api는 코드부터 배포까지 자동화됐지만, 그 동작을 보지 못하면 운영이 굴러가지 않습니다. 이번 글에서는 EKS 클러스터의 옵저버빌리티 스택을 정리하겠습니다. kube-prometheus-stack으로 Prometheus + Grafana + Alertmanager를 한 번에 설치하고, Container Insights와 Fluent Bit으로 CloudWatch에 메트릭,로그를 보내는 두 축을 결합하고, ServiceMonitor / PrometheusRule로 myshop-api 메트릭과 알람을 표준화하고, 4 golden signals 룰셋과 Slack / PagerDuty 라우팅으로 on-call 흐름까지 정리하겠습니다.
K8s 실전 #4 CI/CD 파이프라인 — GitHub Actions / ECR / ArgoCD
[#3](/ko/posts/k8s-practice-3)까지 만든 myshop-api는 새 버전이 들어오는 과정이 사람의 손에 묶여 있습니다. 이번 글에서는 그 과정을 자동화하겠습니다. GitHub Actions에서 OIDC로 정적 키 없이 AWS ECR에 컨테이너 이미지를 푸시하고, 매니페스트 repo의 Helm values를 자동 commit해 [고급 #6](/ko/posts/k8s-advanced-6)에서 다룬 ArgoCD가 그 변경을 감지해 클러스터로 동기화하는 흐름을 정리하겠습니다. PR 승인 게이트, dev/prod 분기, 카나리 배포까지 함께 짚겠습니다.
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의 모델을 한 사이클로 정리하겠습니다.