클라우드 네이티브 완전 가이드 — Kubernetes·Serverless·eBPF·Container Runtime·GitOps를 2025년 기준으로 한 번에 정리

문제: 컨테이너 1000개를 어디에 어떻게 띄우지?
     죽으면 누가 살리지? 트래픽은 어떻게 분산?
     업데이트는? 롤백은? 스케일링은?

해결: Kubernetes — "선언적으로 원하는 상태를 말하면 클러스터가 맞춘다"

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: nginx:1.27
          ports: [{ containerPort: 80 }]
          resources:
            requests: { cpu: 100m, memory: 128Mi }
            limits: { cpu: 500m, memory: 512Mi }
          livenessProbe:
            httpGet: { path: /health, port: 80 }
          readinessProbe:
            httpGet: { path: /ready, port: 80 }
---
apiVersion: v1
kind: Service
metadata: { name: web }
spec:
  selector: { app: web }
  ports: [{ port: 80, targetPort: 80 }]
  type: ClusterIP

spec:
  nodeSelector: { disktype: ssd }
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: topology.kubernetes.io/zone
                operator: In
                values: [us-east-1a, us-east-1b]
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            labelSelector: { matchLabels: { app: web } }
            topologyKey: kubernetes.io/hostname
  tolerations:
    - key: spot
      operator: Equal
      value: "true"
      effect: NoSchedule

Request: 스케줄러가 "이만큼 있어야 해" → 빈 노드 찾기
Limit: 컨테이너가 넘으면 → CPU는 throttle, 메모리는 OOM Kill

규칙:
- Request는 항상 설정 (없으면 0으로 간주 → 과밀집)
- Limit은 CPU는 보통 안 둠(throttle이 성능 저하), Memory는 반드시
- Request = Limit → Guaranteed QoS (최우선)

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: databases.example.com
spec:
  group: example.com
  names:
    kind: Database
    plural: databases
  scope: Namespaced
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                engine: { type: string, enum: [postgres, mysql] }
                storage: { type: string }

# 이제 이런 리소스 생성 가능
apiVersion: example.com/v1
kind: Database
metadata: { name: prod-db }
spec:
  engine: postgres
  storage: 100Gi

// controllers/database_controller.go
func (r *DatabaseReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    var db examplev1.Database
    if err := r.Get(ctx, req.NamespacedName, &db); err != nil {
        return ctrl.Result{}, client.IgnoreNotFound(err)
    }

    // 원하는 상태: StatefulSet 있어야 함
    sts := &appsv1.StatefulSet{ObjectMeta: metav1.ObjectMeta{Name: db.Name, Namespace: db.Namespace}}
    _, err := ctrl.CreateOrUpdate(ctx, r.Client, sts, func() error {
        sts.Spec = buildPostgresStatefulSet(&db)
        return ctrl.SetControllerReference(&db, sts, r.Scheme)
    })
    return ctrl.Result{RequeueAfter: 30 * time.Second}, err
}

선택 A: Serverless (Lambda, Workers, Cloud Run)
조건:
- 이벤트 기반 (HTTP, S3 upload, DB 변경)
- 트래픽 불규칙
- Stateless
- 운영 인력 최소화

선택 B: Container (Kubernetes, Nomad)
조건:
- 상시 실행
- 복잡한 워크로드 (GPU, large memory)
- 운영 팀 있음
- Stateful 가능

선택 C: VM
조건:
- 특수 하드웨어
- 레거시 앱
- 규정 (강한 격리 필요)

eBPF = Extended Berkeley Packet Filter
"커널 안에서 샌드박스 프로그램 실행" — 재컴파일 없이
원래 패킷 필터(tcpdump의 BPF) → 2014년 eBPF로 확장 → 2020년대 폭발

기능:
- CNI (Pod 네트워킹)
- NetworkPolicy (L3-7 규칙)
- Service Mesh (mTLS 지원, 사이드카 없음)
- Load Balancing (XDP 가속)
- Observability (Hubble)

# falco rule
- rule: Shell in Container
  desc: Shell 프로세스가 컨테이너에서 실행됨
  condition: container and (proc.name in (bash, sh))
  output: "Shell in container (user=%user.name container=%container.id)"
  priority: WARNING

에이전트 설치 → 모든 HTTP, gRPC, MySQL 트래픽 자동 관측
별도 코드 변경 X
eBPF로 TLS 이전에 HTTP 디코드 (암호화되기 전 가로챔)

kubelet
  ↓ CRI (Container Runtime Interface)
containerd / CRI-O
  ↓ OCI (Open Container Initiative)
runc / crun / Kata / gVisor / Firecracker

Amazon이 Lambda/Fargate용으로 제작
Rust로 작성, 초경량 VMM
Boot time: 125ms
Memory: 5MB 오버헤드
Use: AWS Lambda, Fly.io, Koyeb, Modal

wasmtime, wasmer, spin (Fermyon)
Container보다 작고 빠름 (KB 수준 바이너리)
크로스 아키텍처 (ARM/x86 공통)
Cold start ms 단위
한계: 시스템 콜 제한, 기존 앱 마이그레이션 어려움

1. 선언적 (Declarative): YAML이 원하는 상태
2. 버전 관리 (Versioned): Git이 Single Source of Truth
3. 자동 적용 (Automated): Agent가 Git → 클러스터 sync
4. 지속 조정 (Continuously Reconciled): drift 감지 시 복원

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: web
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/infra
    targetRevision: main
    path: apps/web/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: web-prod
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

infra/
├── base/
│   └── web/
│       ├── deployment.yaml
│       ├── service.yaml
│       └── kustomization.yaml
└── overlays/
    ├── dev/
    │   ├── kustomization.yaml
    │   └── replicas-patch.yaml
    ├── staging/
    └── prod/

# values.yaml
replicas: 3
image:
  repository: nginx
  tag: "1.27"

# templates/deployment.yaml
spec:
  replicas: {{ .Values.replicas }}
  template:
    spec:
      containers:
        - image: {{ .Values.image.repository }}:{{ .Values.image.tag }}

# base/deployment.yaml (순수 YAML)
spec:
  replicas: 3
  template:
    spec:
      containers:
        - image: nginx:1.27

# overlays/prod/kustomization.yaml
resources:
  - ../../base
patches:
  - path: replicas-patch.yaml

// CUE로 타입 검증 + 제약 가능
#WebApp: {
    replicas: int & >=1 & <=100
    image: string
    resources: {
        requests: cpu: string
        limits: memory: string
    }
}

클러스터 비용 = 노드(VM) + LB + 스토리지 + 네트워크 송출 + 관리형 제어 plane
         → 대부분 노드 비용

# VPA recommender 모드
kubectl apply -f vpa-recommender.yaml
# 실제 사용 대비 request 권장치 확인
kubectl describe vpa web

apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata: { name: default }
spec:
  template:
    spec:
      requirements:
        - key: node.kubernetes.io/instance-type
          operator: In
          values: [m5.large, m5.xlarge, m6i.large, c5.large]
        - key: karpenter.sh/capacity-type
          operator: In
          values: [spot, on-demand]
      nodeClassRef: { name: default }
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h  # 30일 후 교체

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: { name: web-pdb }
spec:
  minAvailable: 2
  selector: { matchLabels: { app: web } }

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: web }
spec:
  scaleTargetRef: { kind: Deployment, name: web }
  minReplicas: 2
  maxReplicas: 50
  metrics:
    - type: Resource
      resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
spec:
  scaleTargetRef: { name: worker }
  minReplicaCount: 0  # idle 시 0
  maxReplicaCount: 20
  triggers:
    - type: kafka
      metadata:
        bootstrapServers: kafka:9092
        consumerGroup: workers
        topic: jobs
        lagThreshold: "10"

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: deny-all }
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: allow-web-to-api }
spec:
  podSelector: { matchLabels: { app: api } }
  ingress:
    - from:
        - podSelector: { matchLabels: { app: web } }
      ports:
        - protocol: TCP
          port: 8080

apiVersion: v1
kind: Namespace
metadata:
  name: prod
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace