> **TL;DR** — Kubernetes는 2014년 Google의 Borg 경험에서 탄생해, 2024년 기준 **Fortune 100의 96%**가 사용하는 사실상의 클라우드 OS다. 하지만 그 복잡도는 악명 높고 — 기본 리소스 40여 종, Istio만 추가해도 CRD 60+ 종, 운영자 1명이 이해해야 하는 개념 수백 개. 이 글은 "**K8s는 왜 이렇게 복잡한가**"라는 원질문에서 출발해, **Control Plane 아키텍처**, **CNI/eBPF/Cilium**, **Service Mesh 논쟁**(Istio Ambient vs sidecar), **GitOps 혁명**(ArgoCD, Flux), **Platform Engineering**(Backstage, IDP), **Operator 패턴**, **Karpenter 자동 스케일**, **WASM 런타임**까지 — 2025년 Kubernetes의 전 지형도와 실전 트레이드오프를 추적한다.

Kubernetes의 탄생과 확산

2003년 Google은 **Borg**라는 자사 클러스터 관리 시스템으로 수십만 머신을 운영하고 있었다. 2014년, Borg 설계자 Joe Beda, Brendan Burns, Craig McLuckie가 오픈소스 버전을 공개 — 이것이 **Kubernetes**(그리스어 "조타수"). 2015년 CNCF(Cloud Native Computing Foundation)가 설립되며 리누스 토르발즈 이후 가장 큰 오픈소스 프로젝트 중 하나가 된다.

**확산 속도**:

- 2015: CNCF 창립, 1.0 릴리스

- 2017: AWS EKS 발표 — Docker Swarm/Mesos 패배 확정

- 2019: 대부분 클라우드 업체 관리형 K8s 제공

- 2022: **Fortune 500의 85%** 도입

- 2024: **Fortune 100의 96%** 사용, 5.6M 개발자

- 2025: AI/ML 워크로드 집약 (Ray, Kubeflow, Dify)

K8s가 해결한 문제

1. **배포 자동화** — 선언형 YAML로 원하는 상태 기술

2. **자가 치유** — Pod 죽으면 자동 재시작

3. **수평 확장** — HPA/VPA/Karpenter

4. **서비스 디스커버리** — 내장 DNS + Service

5. **롤링 배포** — 다운타임 없는 업데이트

6. **리소스 관리** — CPU/메모리 제한 + 스케줄링

7. **스토리지 추상화** — CSI (Container Storage Interface)

8. **멀티 클라우드** — 동일 YAML이 AWS/GCP/Azure에서 동작

K8s가 새로 만든 문제

1. **인지 부담 폭발** — 40+ 기본 리소스, 수백 개 개념

2. **네트워킹 복잡** — CNI + kube-proxy + Ingress + Service Mesh

3. **보안 복잡** — RBAC, NetworkPolicy, PodSecurity, Secret 관리

4. **디버깅 어려움** — 왜 Pod가 Pending? 왜 502? 원인 추적 지옥

5. **업그레이드 지옥** — 3개월 릴리스 주기, API 변경

6. **비용 통제 어려움** — 리소스 과할당, idle node

7. **한 사람이 다 아는 건 불가능** — 팀 규모 최소 3명 이상 필요

"K8s는 정말 필요한가"라는 질문이 반복되는 이유다. **중소 서비스는 Heroku, Fly.io, Render, Vercel로 충분**하다. K8s는 **조직 규모, 워크로드 다양성, 멀티 클라우드 요구**가 있을 때 가치가 드러난다.

Control Plane 아키텍처

K8s는 **Control Plane** + **Data Plane**(Worker Nodes)으로 나뉜다.

Control Plane (제어 평면)

┌─────────────────────────────────────────┐

│ kube-apiserver │

│ (모든 변경의 유일한 진입점, REST API) │

│ ↕ │

│ etcd (분산 KV 스토어, 클러스터 상태) │

│ ↕ │

│ kube-scheduler (Pod → Node 배정) │

│ kube-controller-manager │

│ (ReplicaSet, Deployment, Job ... 루프) │

│ cloud-controller-manager │

│ (LoadBalancer, Volume ... 클라우드 통합)│

└─────────────────────────────────────────┘

Data Plane (Worker Nodes)

┌────────────┬────────────┬────────────┐

│ Node 1 │ Node 2 │ Node 3 │

│ kubelet │ kubelet │ kubelet │

│ kube-proxy │ kube-proxy │ kube-proxy │

│ container │ container │ container │

│ runtime │ runtime │ runtime │

│ (containerd│(containerd │(containerd │

│ /CRI-O) │ /CRI-O) │ /CRI-O) │

│ Pods... │ Pods... │ Pods... │

└────────────┴────────────┴────────────┘

etcd — 모든 상태의 유일한 진실

etcd는 Raft 컨센서스 기반 분산 KV 스토어. 보통 3-5대. 모든 K8s 객체가 여기 저장.

- **버전**: 홀수(3, 5, 7, ...) 유지 — 장애 허용 = (n-1)/2

- **크기 제한**: 기본 2GB, 최대 8GB

- **성능**: ~10000 writes/sec, 디스크 I/O 민감

- **백업 필수** — etcdctl snapshot save

**주의**: etcd 장애 = 클러스터 다운. 그래서 관리형 K8s(EKS, GKE)는 Control Plane을 클라우드 사업자가 운영.

API Server — 모든 변경의 문지기

모든 `kubectl` 명령, 컨트롤러, kubelet 호출이 여기로 향함. 인증 → 인가 → admission control → etcd 저장의 파이프라인.

Scheduler — Pod가 어느 Node에 가는가

2단계:

1. **Filter** — nodeSelector, affinity, taint/toleration, 리소스 맞는 노드만

2. **Score** — 남은 노드 중 최적 선택 (LeastRequested, 이미지 locality, ...)

**Pod Topology Spread Constraints**, **PriorityClass** 등으로 세밀 제어 가능.

Controller Manager — 무한 Reconciliation Loop

for {

desired := getDesiredState() // YAML에서

current := getCurrentState() // 실제 상태

if desired != current {

reconcile(desired, current)

}

sleep(resyncPeriod)

}

이 **level-triggered** 패턴이 K8s의 핵심 철학 — "명령형 if-then 대신 상태 선언".

Pod — 최소 배포 단위

**Pod**는 1개 이상의 컨테이너 묶음. 같은 네트워크 namespace와 볼륨 공유.

apiVersion: v1

kind: Pod

metadata:

name: my-app

spec:

containers:

- name: app

image: my-app:1.0

resources:

requests: { cpu: 100m, memory: 128Mi }

limits: { cpu: 500m, memory: 512Mi }

readinessProbe:

httpGet: { path: /healthz, port: 8080 }

initialDelaySeconds: 5

livenessProbe:

httpGet: { path: /healthz, port: 8080 }

periodSeconds: 10

- name: sidecar # 같은 Pod의 부 컨테이너

image: log-shipper:2.0

**requests vs limits 차이**:

- `requests` — 스케줄러가 보장하는 최소 리소스

- `limits` — 컨테이너가 넘을 수 없는 상한

**OOMKilled**(메모리 초과 시 강제 종료), **CPU throttling**(CPU 초과 시 느려짐) — 이 둘이 가장 흔한 장애 원인.

Probe 3종

- **startupProbe** — 느린 앱 초기화 (JVM) 보호. 성공하면 이후 다른 probe 활성화

- **livenessProbe** — "죽었나?" 실패 시 재시작

- **readinessProbe** — "트래픽 받을 준비?" 실패 시 Service endpoint에서 제외

**흔한 실수**: liveness를 DB 연결까지 확인하게 만들면, DB 지연으로 전체 Pod 재시작 → 폭주.

Deployment, StatefulSet, DaemonSet, Job

Deployment — Stateless 앱

apiVersion: apps/v1

kind: Deployment

metadata: { name: web }

spec:

replicas: 3

selector: { matchLabels: { app: web } }

template:

metadata: { labels: { app: web } }

spec:

containers:

- name: web

image: web:v2

strategy:

type: RollingUpdate

rollingUpdate:

maxSurge: 1 # 업데이트 중 최대 +1 Pod

maxUnavailable: 0 # 다운 허용 0

StatefulSet — 정체성 있는 Pod

- 이름이 고정 (web-0, web-1, web-2)

- 순차 배포 / 역순 삭제

- 각 Pod별 영구 볼륨

- 사용처: DB, Kafka, Redis cluster

DaemonSet — 노드마다 1 Pod

- 모든 노드(또는 nodeSelector에 맞는 노드)에 1개씩

- 사용처: 로그 수집(Fluent Bit), 모니터링 에이전트, CNI plugin

Job / CronJob — 배치/스케줄 작업

- `Job` — 완료될 때까지 실행

- `CronJob` — cron 표현식 스케줄

Service — 내부 로드 밸런서

Pod는 IP가 변하지만 Service는 안정적인 DNS/IP 제공.

apiVersion: v1

kind: Service

metadata: { name: web-svc }

spec:

selector: { app: web }

ports: [{ port: 80, targetPort: 8080 }]

type: ClusterIP # 기본 — 클러스터 내부만

type: NodePort — 각 노드의 특정 포트로 노출

type: LoadBalancer — 클라우드 LB 생성

Service는 kube-proxy가 iptables 또는 IPVS 규칙으로 구현. Cilium은 eBPF로 대체.

Ingress — HTTP L7 라우팅

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: my-ingress

spec:

rules:

- host: api.example.com

http:

paths:

- path: /users

pathType: Prefix

backend: { service: { name: user-svc, port: { number: 80 } } }

Ingress 컨트롤러 선택지: NGINX Ingress, Traefik, HAProxy, AWS ALB Controller, GKE Ingress.

Gateway API — Ingress의 후계자

2023년 GA. Ingress의 한계(L7 제한, 다중 테넌시 어려움)를 해결.

apiVersion: gateway.networking.k8s.io/v1

kind: HTTPRoute

metadata: { name: api-route }

spec:

parentRefs:

- name: my-gateway

hostnames: ["api.example.com"]

rules:

- matches: [{ path: { type: PathPrefix, value: /users } }]

backendRefs:

- name: user-svc

port: 80

**장점**: 역할 분리(Gateway는 인프라 팀, HTTPRoute는 앱 팀), 표준 L7, TCP/UDP 지원, traffic splitting.

CNI — Container Network Interface

모든 Pod에 고유 IP를 주고 서로 통신 가능하게. CNI plugin이 구현.

주요 CNI

| CNI | 방식 | 특징 |

|---|---|---|

| **Flannel** | VXLAN overlay | 가장 단순, 시작용 |

| **Calico** | BGP routing | NetworkPolicy 강점, 대규모 |

| **Cilium** | **eBPF** | 성능 최강, observability |

| **Weave Net** | VXLAN | 가장 오래됨 |

| **AWS VPC CNI** | AWS ENI 직접 | EKS 기본 |

| **Azure CNI** | Azure VNet | AKS 기본 |

| **GKE Dataplane V2** | Cilium 기반 | GKE 기본 |

eBPF — 커널 안의 작은 VM

**eBPF**(extended Berkeley Packet Filter)는 리눅스 커널에서 검증된 바이트코드를 실행하는 샌드박스. 2014년 도입, 2020년대 폭발.

- **Cilium** — L7까지 eBPF로 처리, kube-proxy 대체

- **Falco** — eBPF 기반 보안 감사

- **Pixie** — eBPF 기반 K8s observability

- **Tetragon** — eBPF 실시간 런타임 보안

eBPF는 컨테이너 런타임, 네트워킹, observability를 재정의 중. 2024년 CNCF Graduated project.

Service Mesh — sidecar vs Ambient 논쟁

Service Mesh는 마이크로서비스 간 **통신 관리 계층**: mTLS, retry, circuit breaker, traffic splitting, observability.

Sidecar 패턴 (Istio, Linkerd 전통)

각 Pod에 Envoy/proxy 컨테이너 추가.

Pod {

App Container

Envoy Sidecar ← 모든 in/out 트래픽 intercept

}

**장점**: 앱 변경 없음, 언어 무관.

**단점**: 리소스 2배, Pod당 수백MB 메모리, 업그레이드 어려움.

Ambient Mesh (Istio 2022-2024)

Sidecar 없애고 **노드 단위 ztunnel** + **Waypoint Proxy**로 대체.

Node {

ztunnel (L4: mTLS, observability)

Pod A, Pod B, Pod C ← sidecar 없음

}

+ Waypoint (L7 기능 필요 시 namespace당 배포)

**장점**: 리소스 절약, 점진적 도입 가능, 업그레이드 Pod 재시작 불필요.

**단점**: 2024년 GA, 아직 성숙도 낮음.

주요 Service Mesh

| Mesh | 제공자 | 특징 |

|---|---|---|

| **Istio** | Google/IBM | 기능 최다, 복잡도 최고, Ambient 신규 |

| **Linkerd** | Buoyant | 단순, 성능 좋음, Rust로 쓰인 데이터 플레인 |

| **Consul Connect** | HashiCorp | 멀티 플랫폼(VM+K8s) |

| **Cilium Service Mesh** | Isovalent | eBPF 기반, sidecar 없음 |

| **Kuma** | Kong | 엔터프라이즈 |

Service Mesh는 정말 필요한가

2024-2025 현장에서 답은 "**대부분은 필요 없다**"로 수렴. 이유:

- Ingress Controller + NetworkPolicy로 80% 해결

- Observability는 OpenTelemetry로 가능

- mTLS는 cert-manager + SPIFFE로 가능

- Service Mesh 학습/운영 비용이 이득 초과

**도입 기준**: 마이크로서비스 50+ 이상, 멀티 팀 독립 배포, 엄격한 zero-trust 요구.

GitOps — 배포의 선언형 혁명

2017년 Weaveworks가 제안. "**Git은 프로덕션의 유일한 진실**". 파이프라인이 아니라 **풀(pull) 기반 동기화**.

[Developer] → [Git PR] → [Merge]

↓

[ArgoCD/Flux Controller] ← git poll

↓

(diff 감지)

↓

[K8s Apply]

ArgoCD

apiVersion: argoproj.io/v1alpha1

kind: Application

metadata: { name: my-app }

spec:

project: default

source:

repoURL: https://github.com/org/repo

path: k8s/overlays/prod

targetRevision: HEAD

destination:

server: https://kubernetes.default.svc

namespace: prod

syncPolicy:

automated:

prune: true

selfHeal: true

- 웹 UI 제공, 여러 앱 한눈에

- App of Apps 패턴

- Rollback = git revert

Flux

- CNCF Graduated

- Helm, Kustomize, OCI artifacts 지원

- 경량화 (UI 없음, `fluxcd` CLI)

- 2024년 Flagger 통합으로 progressive delivery

GitOps가 해결한 문제

- "프로덕션에 뭐가 배포됐는지 몰라" → git이 진실

- "kubectl 누가 뭘 바꿨지?" → 직접 변경 자동 되돌림 (drift detection)

- "rollback 어떻게?" → git revert

Helm vs Kustomize vs Jsonnet

매니페스트 관리 도구 3대장.

Helm

- 템플릿 엔진 (Go template)

- Chart 패키징, Helm Hub 생태계

- `values.yaml`로 환경별 오버라이드

templates/deployment.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

name: "{"{"}}{"{"} .Release.Name {"}"}{"}"}"

spec:

replicas: "{"{"}}{"{"} .Values.replicas {"}"}{"}"}"

**장점**: 광대한 생태계 (nginx, redis, postgres 공식 chart).

**단점**: 템플릿 지옥, 디버깅 어려움.

Kustomize

- 오버레이 패턴, 템플릿 없이 patch

- `kubectl` 내장

base/deployment.yaml — 공통

overlays/prod/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1

kind: Kustomization

resources:

- ../../base

patches:

- patch: |-

- op: replace

path: /spec/replicas

value: 10

target: { kind: Deployment }

**장점**: 템플릿 없이 순수 YAML, 디버깅 쉬움.

**단점**: Helm 생태계 부재.

Jsonnet / CUE / KCL

- JSON/YAML을 프로그래밍 언어로 생성

- Grafana, Databricks 사용

- CUE는 Google 내부 구성 언어에서 유래

- **KCL**(Kusion)은 2024년 CNCF Sandbox 진입, Kubernetes 특화

Operator 패턴 — CRD로 K8s 확장

DB, Kafka, Cert-Manager 같은 **stateful 앱을 K8s에 통합**하는 표준 방식.

apiVersion: apiextensions.k8s.io/v1

kind: CustomResourceDefinition

metadata: { name: postgresqls.db.acme.io }

spec:

group: db.acme.io

versions: [{ name: v1, served: true, storage: true, schema: {...} }]

scope: Namespaced

names: { plural: postgresqls, singular: postgresql, kind: PostgreSQL }

이제 사용자는:

apiVersion: db.acme.io/v1

kind: PostgreSQL

metadata: { name: my-db }

spec:

version: "16"

replicas: 3

storage: 100Gi

**Operator**(컨트롤러)가 이를 실제 StatefulSet, Service, PVC, ConfigMap으로 변환 + 백업/장애 대응.

유명한 Operator

- **Prometheus Operator** — 모니터링

- **cert-manager** — TLS 자동화

- **CloudNativePG, Zalando PG Operator** — PostgreSQL

- **Strimzi** — Kafka

- **Elastic Operator** — Elasticsearch

- **Istio Operator** — Istio 설치

- **ArgoCD Operator** — ArgoCD 관리

- **Crossplane** — 클라우드 리소스를 K8s 리소스로

OperatorHub.io

600+ 공식 operator. "K8s Native"의 대부분 뜻하는 것.

Platform Engineering — 플랫폼 팀의 부상

**Platform Engineering**은 2022-2023년 급부상. "**개발자 생산성**을 제품으로 다루는 팀".

왜 Platform Engineering인가

- DevOps "you build it, you run it"이 너무 큰 부담

- 모든 팀이 K8s, Terraform, Argo, 모니터링을 전문가 수준으로 다 할 수 없음

- **Internal Developer Platform (IDP)** — 사내 Heroku 같은 추상화 제공

Backstage (Spotify, 2020 CNCF 기증)

Platform Engineering의 UI 표준.

apiVersion: backstage.io/v1alpha1

kind: Component

metadata:

name: user-service

annotations:

github.com/project-slug: org/user-service

sentry.io/project-slug: user-service

spec:

type: service

lifecycle: production

owner: team-platform

system: user-management

- **Software Catalog** — 사내 서비스/API/라이브러리 목록

- **Scaffolder** — 템플릿 기반 서비스 생성

- **TechDocs** — Markdown 기반 문서 자동 배포

- **Integrations** — GitHub, PagerDuty, Prometheus, ArgoCD, ...

Humanitec, Port, Cortex, Mia-Platform

Backstage의 SaaS 대안들. 2024-2025년 IDP 시장 폭발.

Platform as Product 철학

- 내부 사용자를 '고객'으로

- OKR, NPS 측정

- 기능은 adoption으로 검증

- 문서화와 DX가 성공의 80%

Autoscaling — HPA, VPA, Karpenter

HPA (Horizontal Pod Autoscaler)

Pod 수를 늘이고 줄임. CPU/메모리/커스텀 메트릭 기반.

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata: { name: web-hpa }

spec:

scaleTargetRef: { kind: Deployment, name: web }

minReplicas: 2

maxReplicas: 20

metrics:

- type: Resource

resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }

**KEDA** (Kubernetes Event-Driven Autoscaling) — Kafka 랙, SQS depth, Prometheus 쿼리 등 60+ 스케일러.

VPA (Vertical Pod Autoscaler)

Pod의 requests/limits 자동 조정. 재시작 필요해서 **권장 모드만**(recommend) 쓰는 경우 많음.

Cluster Autoscaler vs Karpenter

**Cluster Autoscaler** — 전통적, node group 기반, 느림.

**Karpenter** (AWS, 2021) — just-in-time 노드 프로비저닝, 수초 내, 비용 최적화 자동.

apiVersion: karpenter.sh/v1

kind: NodePool

metadata: { name: default }

spec:

template:

spec:

requirements:

- key: "karpenter.sh/capacity-type"

operator: In

values: ["spot", "on-demand"] # Spot 우선

- key: "kubernetes.io/arch"

operator: In

values: ["amd64", "arm64"]

limits: { cpu: "1000" }

disruption:

consolidationPolicy: WhenUnderutilized

expireAfter: 720h

Karpenter로 **비용 30-50% 감소** 사례 흔함.

비용 최적화 — 2024 핵심 이슈

K8s의 보이지 않는 비용 문제:

- 과도한 requests → 유휴 리소스 다량

- idle node → 시간당 돈

- PVC 미사용 → 스토리지 비용

- 로그/메트릭 보관 → 관찰 도구 비용

도구

- **OpenCost** — CNCF 프로젝트, 네임스페이스/워크로드별 비용

- **Kubecost** — OpenCost의 상업 버전, UI 강력

- **Cast.ai** — 자동 최적화 SaaS

- **Spot.io (NetApp)** — Spot 인스턴스 자동 관리

- **Datadog Cost Management** — APM + 비용 통합

체크리스트

1. Karpenter + Spot 70% 이상

2. Right-sizing (VPA recommend + 수동 조정)

3. HPA + PodDisruptionBudget

4. 미사용 PVC, namespace 정리

5. 개발/스테이징 nightly shutdown

6. Prometheus 메트릭 cardinality 감소

Observability — 3 pillars + eBPF

Metrics (Prometheus + Grafana)

- 표준 조합. 서비스별 exporter, PromQL

- Thanos, Cortex, Mimir로 장기 저장

- VictoriaMetrics (대안, 성능 강점)

Logs (Loki, Elastic, Datadog)

- Loki: Grafana Labs, 라벨 기반 저장 (저비용)

- Elastic: 전문 검색 강점

- Vector (Datadog), Fluent Bit: 로그 수집

Traces (OpenTelemetry + Jaeger/Tempo)

- OpenTelemetry가 2024년 de facto 표준

- 언어별 SDK + Collector

- Tempo, Jaeger, Zipkin, Datadog, Honeycomb 백엔드

Continuous Profiling (2024 주류화)

- **Parca, Pyroscope, Grafana Cloud Profiling** — eBPF로 CPU/메모리 프로파일링

- "왜 이 Pod가 CPU를 많이 쓰는지" 런타임 확인

2025년 Kubernetes 트렌드

WASM 런타임

- **SpinKube** (Fermyon, CNCF Sandbox) — WASM을 K8s 1차 시민으로

- **wasmCloud** — 분산 WASM 액터 모델

- **Kwasm** — kubelet에 WASM 런타임 주입

- 장점: 콜드 스타트 수 ms, 샌드박싱 강력, 언어 무관

AI/ML 워크로드

- **KubeRay** — Ray(분산 AI 프레임워크) K8s Operator

- **Kubeflow** — ML 파이프라인

- **Volcano** — 배치 + gang scheduling (GPU 공유)

- **NVIDIA GPU Operator** — GPU driver + 런타임 자동화

CRD as API

- **Crossplane** — AWS/GCP 리소스도 K8s manifest로

- **Terraform Controller**, **Atlas** — 선언형 클라우드 리소스

Confidential Containers

- TEE(Intel SGX, AMD SEV)로 암호화된 컨테이너

- 헬스케어, 금융 규제 대응

대안 — K8s가 과한 경우

| 도구 | 적합한 경우 |

|---|---|

| **Heroku** | 초기 스타트업, < 20 서비스 |

| **Fly.io** | Edge + 지역 배포, WebSocket 워크로드 |

| **Render** | Heroku 유사, Postgres 내장 |

| **Railway** | PaaS, 심플 |

| **Vercel/Netlify** | 프론트엔드 + Serverless |

| **AWS ECS/Fargate** | AWS 중심 + K8s 복잡도 피함 |

| **Cloud Run (GCP)** | 요청 기반 과금, HTTP만 |

| **Nomad** (HashiCorp) | 비컨테이너 + VM 워크로드 |

"**K8s가 과했다**"는 후기는 2023-2024년 여럿 — [37signals](https://37signals.com)의 HEY 탈 K8s 회자됨.

실전 운영 체크리스트 (2025)

1. **관리형 사용** — EKS, GKE, AKS 우선. 자체 운영은 팀 10명+일 때만

2. **버전 전략** — 최신 -1, -2 유지, 6개월마다 업그레이드

3. **RBAC 최소 권한** — `view`/`edit`/`admin` 기본 롤 활용

4. **NetworkPolicy 기본 deny** — 기본 egress 차단

5. **PodSecurityStandard** — `restricted` 프로필 기본

6. **Secret 관리** — External Secrets + Vault/AWS Secrets Manager

7. **Backup** — Velero + etcd snapshot

8. **GitOps** — ArgoCD 또는 Flux, `kubectl apply` 금지

9. **Monitoring** — Prometheus + Grafana + Loki

10. **Cost** — Kubecost/OpenCost + Karpenter + Spot

11. **Platform Eng.** — Backstage IDP 구축 (팀 50명+일 때)

12. **Disaster Recovery** — multi-region 또는 multi-cluster 훈련 분기별

10가지 흔한 안티패턴

1. **latest 태그** — 롤백 불가, 재현 불가

2. **리소스 requests 없음** — 스케줄러 오판, QoS BestEffort

3. **liveness에 DB 포함** — 폭주 재시작

4. **Node SSH 직접 변경** — drift, GitOps 원칙 파괴

5. **Namespace 없이 default에 모두** — 권한/격리 파괴

6. **ClusterRoleBinding 남발** — 권한 과도

7. **LoadBalancer Service 서비스마다** — 클라우드 LB 수십 개 = 비용 폭탄

8. **모든 것을 Operator로** — 오버엔지니어링, 유지보수 부담

9. **Service Mesh 먼저, 필요 확인 나중** — 복잡도 2-3배 증가

10. **CRD 난립** — CRD 50+ 되면 누구도 전체 이해 불가

다음 글 예고 — "관측 가능성(Observability)의 현재" — Prometheus, OpenTelemetry, eBPF, Continuous Profiling 심화

K8s를 다뤘으니 그 다음은 **"그래서 시스템이 지금 뭐 하고 있는지 어떻게 아는가"**다. 2024-2025년 관측 가능성(Observability)은 혁명의 한복판에 있다. **OpenTelemetry** 1.0 GA, **eBPF** 기반 agentless 프로파일링, **Continuous Profiling**의 주류화, **Datadog vs Grafana vs Honeycomb vs New Relic**의 경쟁 구도가 완전히 재편됐다.

다음 글에서는:

- **3 pillars + profiling** — Metrics, Logs, Traces, Continuous Profiling

- **Prometheus 깊이** — PromQL, cardinality 지옥, Thanos/Cortex/Mimir

- **OpenTelemetry 1.0** — 왜 de facto 표준이 됐나

- **분산 트레이싱** — span propagation, W3C trace-context

- **eBPF Observability** — Pixie, Parca, Pyroscope, Beyla

- **Structured Logging** — Loki, Elastic, Vector, Fluent Bit

- **SLO/SLI/Error Budget** — Google SRE의 대중화

- **Alerting 철학** — page-worthy vs dashboard

- **Chaos Engineering** — Litmus, Chaos Mesh, Gremlin

- **상업 SaaS 비교** — Datadog, Honeycomb, Grafana Cloud, New Relic 2025 시점

을 다룬다. '**모르는 것을 알게 되는 기술**', 현대 시스템 운영의 가장 중요한 역량을 원리부터 실전까지 추적한다.