Kubernetes
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 세 타입의 선택 기준까지 한 사이클 따라가겠습니다.
K8s 기초 #4 Deployment와 ReplicaSet — 선언형 배포와 롤링 업데이트
[#3](/ko/posts/k8s-basics-3)의 마지막에서 본 한 줄 — Pod는 mortal, 죽으면 그냥 사라진다 — 의 후속편. 이번 글에서는 처음으로 컨트롤러 매니페스트를 적어 본다. Deployment / ReplicaSet / Pod 세 단의 관계를 잡고, 같은 nginx Pod를 replicas: 3으로 띄우고 한 개를 지웠을 때 어떻게 자동 복구되는지, 이미지 태그를 한 글자 바꾸면 롤링 업데이트가 어떻게 굴러가는지, 그리고 잘못 올라간 버전을 한 줄로 어떻게 되돌리는지를 한 사이클 따라가겠습니다.
K8s 기초 #3 kubectl과 첫 Pod
[#2](/ko/posts/k8s-basics-2)에서 띄운 클러스터 위에 처음으로 워크로드 한 개를 올릴 차례. kubectl 명령 패턴을 한 표로 정리하고, kubectl run으로 명령형으로 첫 Pod를 띄워 본 다음 같은 모양을 YAML 매니페스트로 다시 적어 적용하겠습니다. describe,logs,exec로 Pod 안을 들여다보고, 마지막에는 Pod 한 개로는 왜 부족한지 — 그래서 다음 글의 Deployment가 왜 필요한지를 짚겠습니다.
K8s 기초 #2 로컬 환경 — minikube / kind / Docker Desktop k8s
[#1](/ko/posts/k8s-basics-1)에서 본 control plane / worker 그림을 실제로 마주할 차례. 노트북 한 대 위에 K8s 클러스터를 띄우는 세 가지 길(minikube / kind / Docker Desktop k8s)을 비교하고, kubectl을 설치한 뒤, kind로 첫 클러스터를 띄워 노드와 시스템 파드를 확인하는 흐름까지 한 번에 따라가겠습니다.
K8s 기초 #1 쿠버네티스란 — 왜 컨테이너 오케스트레이터가 필요한가
도커로 컨테이너 한 대를 띄우는 데 익숙해진 다음의 질문 — 그러면 컨테이너 100대는 어떻게 굴리지? 죽으면 누가 다시 살리고, 트래픽이 몰리면 어떻게 늘렸다 줄였다 하지? 이 시리즈의 첫 글에서는 단일 컨테이너의 한계, 컨테이너 오케스트레이터가 푸는 문제, 그리고 쿠버네티스 클러스터의 큰 그림을 정리하겠습니다.