개요
온프렘 운영이란 클라우드가 대신 해 주던 빈칸을 하나씩 채우는 일이다 — 이 덱의 목차가 그 빈칸 목록이다
클러스터는 이미 떴다고 치자. 그 위에서 서비스를 굴리려면 외부 IP · 인증서 · DNS · 로그인 · 오브젝트 스토리지 · 데이터베이스 · 관측 · 백업이 전부 필요한데, 클라우드에서는 이걸 관리형 서비스가 해 줬다. 온프렘에는 그게 없다.
이 덱은 그 빈칸을 채우는 도구들 — MetalLB · Gateway API · cert-manager · external-dns · Keycloak · oauth2-proxy · MinIO · CloudNativePG · Argo CD · Sealed Secrets · Velero — 을 하나씩이 아니라 한 판으로 다룬다. 각 도구의 매뉴얼이 아니라 어느 자리에 왜 들어가고, 서로 무엇을 주고받고, 무엇이 먼저 죽는가가 축이다.
쿠버네티스 기초는 CKA 덱, 리눅스 서버 운영은 서버 관리 덱, Keycloak 내부는 Keycloak 덱 수준을 전제하고 여기서 다시 설명하지 않는다. 관측 도구 넷(Prometheus · Loki · Tempo · Grafana)은 관측 덱이 맡는다 — 이 덱 8장은 그 스택의 자리와 배치 판단까지다.
2026년 8월 기준으로 쓰였다 — Kubernetes v1.35 · Gateway API v1.5 · CloudNativePG 1.30. 이 시점에 ingress-nginx와 MinIO 커뮤니티판이 둘 다 끝났다(0장).
첫 장부터 읽기- 3~5장바깥으로 여는 길
MetalLB와 Gateway API · cert-manager와 external-dns · Keycloak과 oauth2-proxy
외부에서 이름으로, HTTPS로, 로그인해서 닿게 하려면 무엇이 필요한가
- 13~14장마무리
용어 사전 · 마무리
전체를 관통하는 두 문장
섹션 제목: “전체를 관통하는 두 문장”온프렘의 일은 빈칸 채우기다. type: LoadBalancer가 영원히 <pending>인 것도,
인증서가 자동으로 안 붙는 것도, DB 페일오버가 안 되는 것도 전부 같은 이유다 —
클라우드에서 그 일을 하던 컨트롤러가 여기엔 없다. 그래서 온프렘 운영의 설계는
“무슨 도구를 쓸까”가 아니라 “어떤 자리가 비어 있나” 를 먼저 세는 것에서 출발한다
(1장).
빈칸을 채운 도구들은 바닥 두 개를 공유한다. Loki의 로그도, Tempo의 트레이스도, Velero의 백업도, CloudNativePG의 WAL도 전부 S3(오브젝트 스토리지) 로 떨어지고, Keycloak과 Grafana의 상태는 Postgres에 들어간다. 이 둘이 흔들리면 위층이 통째로 흔들리고, 클러스터가 죽었을 때 로그를 못 보는 사고도 여기서 나온다 — 그래서 바닥을 어디에 두느냐가 이 덱에서 제일 중요한 결정이다 (6장 · 7장).