김신건의 로그 - 위키 / kubernetes

[K8s] ConfigMap & Secret: 설정과 비밀의 분리

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

	ConfigMap	Secret
데이터	평문	base64 (암호화 아님)
크기	1MB	1MB
용도	설정	비밀
RBAC	일반	더 엄격 권장
저장 (etcd)	평문	암호화 가능 (EncryptionConfiguration)

[!IMPORTANT] Secret = base64 만으로는 암호화 아님. etcd encryption at rest + RBAC 으로 보호.

ConfigMap 예시

apiVersion: v1
kind: ConfigMap
metadata: { name: app-config }
data:
  log_level: "info"
  db_host: "db.production"
  feature_flags: |
    new_ui: true
    beta_search: false

Secret 예시

apiVersion: v1
kind: Secret
metadata: { name: db-creds }
type: Opaque
data:
  username: a29h           # base64(koa)
  password: cGFzc3dvcmQ=   # base64(password)

Pod 에서 사용

1. 환경 변수

spec:
  containers:
    - name: app
      image: app:v1
      env:
        - name: LOG_LEVEL
          valueFrom:
            configMapKeyRef: { name: app-config, key: log_level }
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef: { name: db-creds, key: password }
      envFrom:
        - configMapRef: { name: app-config }    # 전체 import
        - secretRef: { name: db-creds }

2. Volume mount

spec:
  containers:
    - name: app
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config
        - name: secret-vol
          mountPath: /etc/secrets
          readOnly: true
  volumes:
    - name: config-vol
      configMap: { name: app-config }
    - name: secret-vol
      secret: { secretName: db-creds }

[!TIP] Volume mount 의 장점: ConfigMap 갱신 → 자동 반영 (수십 초). env var 는 pod 재시작 필요.

Secret 관리 패턴 (절대 git 에 평문 금지!)

flowchart TD
    Q{Secret 관리}
    Q --> S1["Sealed Secrets (Bitnami)"]
    Q --> S2[External Secrets Operator]
    Q --> S3[SOPS + git]
    Q --> S4[Vault Agent / CSI driver]
    Q --> S5["클라우드 시크릿 (AWS Secrets Manager 등)"]

1. Sealed Secrets

# 일반 secret 작성
kubectl create secret generic db --from-literal=password=xxx --dry-run -o yaml > secret.yaml

# kubeseal 로 암호화 (cluster 의 public key 사용)
kubeseal -f secret.yaml -w sealed-secret.yaml
# sealed-secret.yaml 은 git 에 안전하게 commit 가능

2. External Secrets Operator

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata: { name: db-creds }
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target: { name: db-creds }
  data:
    - secretKey: password
      remoteRef: { key: prod/db, property: password }

AWS Secrets Manager / GCP Secret Manager / Vault 에서 동기화.

3. SOPS

git 에 암호화된 YAML commit. KMS / age 키로 복호화.

흔한 함정

[!WARNING]

echo secret | base64 가 암호화 라고 오해 = base64 는 인코딩일 뿐. 디코드 1줄.

Secret 을 git 에 평문 = 치명적. SOPS / Sealed Secrets / ExternalSecret 으로.

etcd encryption at rest 안 켬 = root 권한자가 etcd 직접 → 모든 secret 노출.

너무 큰 ConfigMap (1MB+) = 거절. 큰 데이터는 volume (PVC, S3 mount).

env var 갱신 안 됨 = ConfigMap 변경 후 pod 재시작 필요. volume mount 는 자동.

[K8s] DaemonSet: 모든 노드에 한 pod

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

DaemonSet = 각 노드에 정확히 1 pod 보장. 노드 추가 시 자동 배치, 노드 제거 시 자동 정리.

흔한 사용

사용	예시
로그 수집	fluent-bit, fluentd, vector
메트릭 수집	node-exporter, datadog-agent
네트워크	calico-node, cilium, kube-proxy
스토리지	csi-driver, longhorn-manager
보안	falco, sysdig

YAML

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit
  namespace: logging
spec:
  selector: { matchLabels: { app: fluent-bit } }
  template:
    metadata: { labels: { app: fluent-bit } }
    spec:
      tolerations:
        - operator: Exists       # 모든 taint 무시 (master 노드도)
      hostNetwork: true          # 노드 네트워크 직접 사용
      containers:
        - name: fluent-bit
          image: fluent/fluent-bit:3
          volumeMounts:
            - name: varlog
              mountPath: /var/log
              readOnly: true
            - name: containers
              mountPath: /var/lib/docker/containers
              readOnly: true
      volumes:
        - name: varlog
          hostPath: { path: /var/log }
        - name: containers
          hostPath: { path: /var/lib/docker/containers }

동작

flowchart TB
    DS[DaemonSet] --> Node1[Node 1]
    DS --> Node2[Node 2]
    DS --> Node3[Node 3]
    Node1 --> P1["Pod (fluent-bit)"]
    Node2 --> P2["Pod (fluent-bit)"]
    Node3 --> P3["Pod (fluent-bit)"]
    Note["새 노드 자동 배포, 제거 자동 회수"]

Node Selector / Tolerations

특정 노드에만 배포:

spec:
  template:
    spec:
      nodeSelector:
        kubernetes.io/os: linux
        accelerator: nvidia-tesla-v100
      tolerations:
        - key: nvidia.com/gpu
          operator: Exists
          effect: NoSchedule

GPU 노드, ARM 노드, edge 노드 등 특화.

흔한 함정

[!WARNING]

Tolerations 누락 = master node, taint 있는 node 에 배치 안 됨. 로그 / 메트릭 누락.

Resource limit 너무 작음 = 트래픽 큰 노드에서 OOM. 노드 크기 비례 큰 limit.

hostNetwork 부주의 = 노드 포트 충돌 가능. 명시적 namespace 분리.

updateStrategy 의 동시 update = 클러스터 전체 동시 재시작 → 일시 log/metric blind. RollingUpdate + maxUnavailable=1.

[K8s] Deployment: ReplicaSet, rolling update, rollback

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Deployment = stateless 워크로드를 위한 컨트롤러. 내부적으로 ReplicaSet 관리 + rolling update / rollback.

계층

flowchart TB
    Dep[Deployment] --> RS[ReplicaSet]
    RS --> P1[Pod 1]
    RS --> P2[Pod 2]
    RS --> P3[Pod 3]
    Note["사용자는 Deployment 만 관리.<br/>ReplicaSet 은 자동."]

객체	책임
Deployment	원하는 상태 + rollout 전략
ReplicaSet	replica 수 보장
Pod	실제 워크로드

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet: { path: /, port: 80 }

Rolling Update

sequenceDiagram
    autonumber
    participant D as Deployment
    participant Old as ReplicaSet v1 (3 pods)
    participant New as ReplicaSet v2 (0 pods)

    D->>New: scale up 1 (maxSurge)
    Note over Old,New: 4 pods 동안 운영
    New->>D: pod ready
    D->>Old: scale down 1 (maxUnavailable)
    Note over Old,New: 3 pods
    D->>New: scale up 1
    Note over Old,New: 4 pods
    Note over D: 반복...
    Note over Old: 모두 0
    Note over New: 모두 3

옵션	의미	기본
`maxUnavailable`	동시에 불가용 될 수 있는 pod 수 (또는 %)	25%
`maxSurge`	동시에 추가 될 수 있는 pod 수	25%

[!TIP] 짧은 maxUnavailable + 짧은 maxSurge = 안전 + 느림. zero-downtime + readiness probe 필수.

Recreate Strategy

strategy:
  type: Recreate

옛 pod 모두 종료 → 새 pod 시작.
다운타임 발생.
DB schema 마이그레이션 같이 두 버전 동시 운영 불가 한 경우.

Rollout 명령

kubectl rollout status deployment/web        # 진행 상황
kubectl rollout history deployment/web        # 이전 버전 목록
kubectl rollout undo deployment/web           # 이전 버전으로 롤백
kubectl rollout undo deployment/web --to-revision=3
kubectl rollout restart deployment/web        # 모든 pod 재시작 (rolling)
kubectl rollout pause deployment/web          # rollout 일시 정지 (canary 용)
kubectl rollout resume deployment/web

Canary / Blue-Green (Deployment 만으로는 부족)

Deployment 의 기본 rolling 은 부분 canary. 진짜 canary / blue-green 은:

Istio / Linkerd: traffic 분배 5%, 20%, 50%, 100%
Argo Rollouts: 정식 canary / blue-green
Flagger: progressive delivery 자동화

자세한 건 [[Zero Downtime Deployment]] 참고.

Revision History

spec:
  revisionHistoryLimit: 10   # 기본 10. 옛 ReplicaSet 보관 수

kubectl get rs   # 옛 ReplicaSet 들이 있음 (replica=0)

흔한 함정

[!WARNING]

readinessProbe 없음 = rolling update 가 준비 안 된 pod 도 ready 로 인식 → 503 폭증.

maxSurge=0 = 새 pod 만들기 전에 옛 pod 죽임 → 일시 capacity 부족.

이미지 tag latest = kubectl rollout restart 안 하면 새 이미지 안 받음. 항상 명시 tag (sha).

Resource limits 없이 = 한 pod 가 node 자원 독점 → 다른 pod throttle.

[K8s] Helm: 패키지 매니저, chart, release, hook

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Helm = K8s 의 패키지 매니저. Chart (YAML 템플릿 + 메타데이터) → Release (cluster 에 배포된 인스턴스).

구조

my-chart/
├── Chart.yaml        # 메타데이터 (이름, 버전)
├── values.yaml       # 기본 설정값
├── templates/        # Go template YAML
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   └── _helpers.tpl  # 공통 함수
└── charts/           # 의존 chart

Chart.yaml

apiVersion: v2
name: my-app
description: A web application
type: application
version: 0.1.0          # chart 버전
appVersion: "1.27.0"    # 앱 버전
dependencies:
  - name: postgresql
    version: "16.x.x"
    repository: https://charts.bitnami.com/bitnami

values.yaml

replicaCount: 3
image:
  repository: nginx
  tag: "1.27"
  pullPolicy: IfNotPresent
service:
  type: ClusterIP
  port: 80
ingress:
  enabled: true
  className: nginx
  hosts:
    - host: my-app.example.com
      paths: [{ path: /, pathType: Prefix }]
resources:
  limits: { cpu: 500m, memory: 512Mi }
  requests: { cpu: 100m, memory: 128Mi }

Template 예시

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "my-app.fullname" . }}
  labels: {{- include "my-app.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels: {{- include "my-app.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels: {{- include "my-app.selectorLabels" . | nindent 8 }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: {{ .Values.service.port }}
          resources: {{- toYaml .Values.resources | nindent 12 }}

흔한 명령

helm install my-release ./my-chart
helm install my-release oci://registry-1.docker.io/bitnamicharts/postgresql
helm upgrade my-release ./my-chart --set image.tag=1.28
helm rollback my-release 2          # 2번 revision 으로
helm uninstall my-release
helm list
helm template ./my-chart            # 렌더만 (apply X)
helm lint ./my-chart
helm package ./my-chart             # tgz 패키지
helm repo add bitnami https://charts.bitnami.com/bitnami
helm search repo postgresql
helm show values bitnami/postgresql

Release 의 lifecycle

stateDiagram-v2
    [*] --> Pending: install
    Pending --> Deployed: 성공
    Pending --> Failed: 실패
    Deployed --> Pending: upgrade
    Pending --> Superseded: 옛 revision
    Deployed --> Uninstalling: uninstall
    Uninstalling --> [*]

helm history my-release    # 모든 revision
helm rollback my-release 3

Hooks

Hook	시점
`pre-install`	install 직전
`post-install`	install 직후
`pre-upgrade` / `post-upgrade`	upgrade
`pre-delete` / `post-delete`	uninstall
`pre-rollback` / `post-rollback`	rollback
`test`	`helm test` 명령

metadata:
  annotations:
    "helm.sh/hook": pre-install
    "helm.sh/hook-weight": "0"
    "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded

DB migration, secret pre-creation 등에 활용.

Helm vs Kustomize

항목	Helm	Kustomize
메커니즘	Go template + values	overlay (patch)
패키지 관리	예 (repo, chart)	없음
변수 표현력	강	약
학습 곡선	높음	낮음
배포 도구	helm CLI	kubectl 내장 (`kubectl apply -k`)
적합	3rd-party 도구 설치	자기 앱 환경별

자주 Helm chart + Kustomize overlay 조합.

Helmfile (multi-release 관리)

# helmfile.yaml
releases:
  - name: postgres
    namespace: data
    chart: bitnami/postgresql
    version: 16.x.x
    values:
      - environments/prod/postgres.yaml
  - name: redis
    namespace: data
    chart: bitnami/redis
    values:
      - environments/prod/redis.yaml

helmfile sync

흔한 함정

[!WARNING]

values.yaml 의 secret 평문 = git 에 secret 노출. SOPS / Sealed Secrets.

template 안 디버깅 어려움 = helm template . --debug 로 렌더 결과 확인.

chart upgrade 시 의도 외 변경 = --reset-values vs --reuse-values 명시.

hook 의 cleanup 정책 = hook resource 가 cluster 에 영구 남음 가능. hook-delete-policy 명시.

[K8s] HPA / VPA / KEDA: 자동 확장

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

3가지 스케일링

flowchart TB
    Q[스케일링 종류]
    Q --> HPA[HPA<br/>Pod 수 ↑↓]
    Q --> VPA[VPA<br/>Pod resource ↑↓]
    Q --> CA[Cluster Autoscaler<br/>Karpenter<br/>Node 수 ↑↓]

HPA (Horizontal Pod Autoscaler)

CPU / Memory / custom metric 기반 pod 수 조정.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: web }
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 3
  maxReplicas: 50
  metrics:
    - type: Resource
      resource:
        name: cpu
        target: { type: Utilization, averageUtilization: 70 }
    - type: Pods
      pods:
        metric: { name: http_requests_per_second }
        target: { type: AverageValue, averageValue: "1000" }
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100
          periodSeconds: 15
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60

HPA 알고리즘

desired = ceil(currentReplicas × (currentMetric / targetMetric))

예: 현재 4 pod, CPU 80%, 목표 50%:

desired = ceil(4 × (80/50)) = 7 pod

VPA (Vertical Pod Autoscaler)

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata: { name: web }
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  updatePolicy:
    updateMode: "Auto"   # Off (recommendation only) / Initial / Recreate / Auto
  resourcePolicy:
    containerPolicies:
      - containerName: '*'
        minAllowed: { cpu: 50m, memory: 64Mi }
        maxAllowed: { cpu: 2, memory: 2Gi }

[!CAUTION] VPA + HPA on CPU 동시 사용 금지. 둘이 같은 메트릭으로 다툼. HPA 는 custom metric, VPA 는 resource → 분리 가능.

KEDA (Kubernetes Event-Driven Autoscaling)

flowchart LR
    Trigger[외부 트리거<br/>Kafka lag, SQS depth, ...] --> KEDA
    KEDA --> HPA[표준 HPA 생성]
    HPA --> Deploy[Deployment scale]

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata: { name: kafka-consumer }
spec:
  scaleTargetRef:
    name: consumer
  minReplicaCount: 0
  maxReplicaCount: 30
  triggers:
    - type: kafka
      metadata:
        bootstrapServers: kafka:9092
        topic: events
        consumerGroup: my-group
        lagThreshold: '1000'

[!IMPORTANT] KEDA 가 2026 시점 표준. 50+ scaler (Kafka, SQS, Prometheus, Redis, DB query, …) 지원. scale-to-zero 가능.

Cluster Autoscaler / Karpenter

flowchart LR
    HPA --> NeedMore[새 pod 들이 Pending]
    NeedMore --> CA[Cluster Autoscaler]
    CA -->|EC2 / GCE| AddNode[새 node 추가]
    AddNode --> Schedule[pending pod 스케줄]

	Cluster Autoscaler	Karpenter
종류	표준 K8s 도구	AWS 발 (이제 CNCF)
Node 선택	미리 정의된 node group	동적 instance type 선택
속도	분 단위	수십 초
비용 최적화	제한적	우수 (spot, right-sizing)
클라우드	다양	AWS, Azure

흔한 함정

[!WARNING]

stabilization window 너무 짧음 = 빈번한 scale up/down → 비용 + 안정성 문제.

HPA + VPA 동시 (같은 메트릭) = 충돌. 분리 또는 VPA off mode + 수동.

metrics-server 미설치 = HPA 작동 안 함. cluster 부팅 시 자동 설치 확인.

resource request 없음 = HPA CPU 기준 무의미. requests 필수.

[K8s] Ingress: L7 라우팅, TLS termination, Gateway API

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Ingress = 클러스터 외부 HTTP/HTTPS 트래픽 → 내부 Service 라우팅. L7 LB 역할. Service 의 LoadBalancer 다수 대안.

[!IMPORTANT] Ingress 오브젝트는 표준, 컨트롤러는 별도. nginx, Traefik, Envoy, AWS Load Balancer Controller 등 직접 설치 필요.

아키텍처

flowchart LR
    Internet --> ALB["ALB / nginx<br/>(IngressController)"]
    ALB -->|"Host: api.example.com<br/>Path: /v1/*"| Sv1[Service: api-v1]
    ALB -->|"Host: api.example.com<br/>Path: /v2/*"| Sv2[Service: api-v2]
    ALB -->|"Host: web.example.com"| Sv3[Service: web]
    Sv1 --> P1[Pods]
    Sv2 --> P2[Pods]
    Sv3 --> P3[Pods]

YAML 예시

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
    - hosts: [api.example.com]
      secretName: api-tls
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /v1
            pathType: Prefix
            backend:
              service:
                name: api-v1
                port: { number: 80 }
          - path: /v2
            pathType: Prefix
            backend:
              service:
                name: api-v2
                port: { number: 80 }

Path Type

pathType	동작
`Exact`	정확 일치
`Prefix`	prefix 일치 (`/api` matches `/api/...`)
`ImplementationSpecific`	컨트롤러 정의

Ingress Controller 비교

Controller	강점
ingress-nginx	표준, 모든 기능, 무거움
Traefik	자동 cert (Let’s Encrypt), 동적
Envoy / Contour	L7 advanced, gRPC, service mesh 친화
AWS Load Balancer Controller	ALB / NLB 직접
HAProxy Ingress	매우 빠름
Istio Ingress Gateway	service mesh 통합

TLS Termination

flowchart LR
    Client -->|HTTPS| Ingress
    Ingress -->|"HTTP (cluster-internal)"| Service
    Cert["cert-manager<br/>(Let's Encrypt ACME)"] -.자동 갱신.-> Ingress

cert-manager 가 Let’s Encrypt 인증서 자동 발급 / 갱신. 거의 모든 클러스터 표준.

Gateway API (Ingress 의 차세대)

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-gateway
spec:
  gatewayClassName: nginx
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      tls:
        certificateRefs:
          - name: prod-tls
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api
spec:
  parentRefs: [{ name: prod-gateway }]
  hostnames: [api.example.com]
  rules:
    - matches:
        - path: { type: PathPrefix, value: /v1 }
      backendRefs:
        - name: api-v1
          port: 80

Ingress vs Gateway API

항목	Ingress	Gateway API
출시	2015	2021+
표현력	제한적 (annotation 의존)	풍부 (HTTPRoute, TCPRoute, TLSRoute)
역할 분리	단일	GatewayClass / Gateway / Route 분리
트래픽 정책	annotation	정식 필드
상태	stable	beta → GA (2026 대다수)

[!IMPORTANT] 2026 시점 Gateway API 가 점점 표준. 신규 클러스터는 Gateway API 추천.

흔한 패턴: Canary

metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"   # 10% 만 새 버전

또는 헤더 기반:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary-by-header: "X-Canary"
    nginx.ingress.kubernetes.io/canary-by-header-value: "always"

흔한 함정

[!WARNING]

IngressClass 누락 = 다중 컨트롤러 환경에서 동작 안 함. spec.ingressClassName 명시.

TLS secret namespace 다름 = Ingress 와 같은 namespace 의 secret 만 사용.

cert-manager rate limit = Let’s Encrypt staging 으로 테스트 후 production.

Ingress + WebSocket = nginx.ingress.kubernetes.io/proxy-read-timeout, proxy-send-timeout 늘려야 idle close 회피.

[K8s] Job / CronJob: 일회성 + 스케줄 작업

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

컨트롤러	의미
Job	완료까지 실행하는 일회성 작업
CronJob	스케줄 (cron) 에 따라 Job 생성

Job

apiVersion: batch/v1
kind: Job
metadata: { name: migrate }
spec:
  backoffLimit: 3                # 실패 시 재시도 한도
  ttlSecondsAfterFinished: 3600  # 완료 후 1시간 뒤 정리
  template:
    spec:
      restartPolicy: OnFailure
      containers:
        - name: migrate
          image: app:v2
          command: ['python', 'manage.py', 'migrate']

흐름

stateDiagram-v2
    [*] --> Active: Job 생성
    Active --> Succeeded: completions 달성
    Active --> Failed: backoffLimit 초과
    Succeeded --> Cleaned: TTL 후 자동 삭제
    Failed --> Cleaned: TTL 후

병렬 실행 (parallelism / completions)

spec:
  completions: 10       # 총 10개 완료 필요
  parallelism: 3        # 동시 3개 실행

패턴	의미
`completions=1, parallelism=1`	단일 작업 (기본)
`completions=N, parallelism=N`	N개 병렬
`completions=N, parallelism=M < N`	동시 M, 총 N
`completions=null, parallelism=M`	무한 (작업 큐 패턴)

작업 큐 패턴

flowchart LR
    Queue[(Job Queue<br/>Redis / SQS)] --> P1[Pod 1]
    Queue --> P2[Pod 2]
    Queue --> P3[Pod 3]
    P1 --> Output[(처리 완료)]
    P2 --> Output
    P3 --> Output

각 pod 가 큐에서 work 가져와 처리 후 종료. completions 없이 queue 가 빌 때까지.

Indexed Job (1.24+)

spec:
  completions: 10
  parallelism: 3
  completionMode: Indexed
  template:
    spec:
      containers:
        - name: worker
          image: app:v1
          env:
            - name: JOB_COMPLETION_INDEX
              valueFrom:
                fieldRef:
                  fieldPath: metadata.annotations['batch.kubernetes.io/job-completion-index']

각 pod 가 고유 인덱스 (0..N-1). 파티션된 작업 분배.

CronJob

apiVersion: batch/v1
kind: CronJob
metadata: { name: nightly-backup }
spec:
  schedule: "0 2 * * *"           # 매일 2시
  timeZone: "Asia/Seoul"           # K8s 1.27+
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  concurrencyPolicy: Forbid       # 이전 job 끝나기 전 새 job 안 만듦
  startingDeadlineSeconds: 300    # 5분 안에 시작 못 하면 skip
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: backup
              image: db-backup:v1

concurrencyPolicy

정책	의미
`Allow` (기본)	동시 실행 허용
`Forbid`	이전 job 끝나기 전 새 job skip
`Replace`	이전 job 중단 + 새 job

Cron 식

┌──── 분 (0-59)
│ ┌── 시 (0-23)
│ │ ┌── 일 (1-31)
│ │ │ ┌── 월 (1-12)
│ │ │ │ ┌── 요일 (0-6, 0=Sun)
│ │ │ │ │
0 2 * * *    매일 2시
*/15 * * * * 15분마다
0 9 * * 1-5  평일 9시

흔한 함정

[!WARNING]

restartPolicy: Always = Job 의 의미 깨짐. OnFailure 또는 Never.

ttlSecondsAfterFinished 없음 = 완료된 Job 누적. cluster cluttered.

CronJob 의 시간대 = K8s 1.27+ 까지 UTC 만. timeZone 명시 권장.

concurrencyPolicy: Allow + 무거운 작업 = job 들이 겹쳐 시스템 부하. Forbid 안전.

JOB 실패 알림 부재 = silent fail. Prometheus + Alertmanager 로 failed Job 알림.

[K8s] NetworkPolicy: pod 간 네트워크 차단

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

NetworkPolicy = pod 간 허용된 트래픽만 통과. 없으면 모든 pod ↔ pod 가 허용 (기본 open).

[!IMPORTANT] NetworkPolicy 는 CNI 플러그인이 구현. Calico, Cilium, Weave 가 지원. Flannel 단독은 미지원.

Default Deny

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny }
spec:
  podSelector: {}        # 모든 pod
  policyTypes: [Ingress, Egress]
  # ingress / egress 비어있음 → 전부 차단

모든 namespace 에 default deny + 필요한 규칙만 명시 허용 이 Zero-Trust 정통.

Ingress 허용 예시

kind: NetworkPolicy
metadata: { name: allow-frontend-to-api }
spec:
  podSelector:
    matchLabels: { app: api }
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector:
            matchLabels: { app: frontend }
      ports:
        - protocol: TCP
          port: 8080

api pod 는 frontend pod 의 8080 트래픽만 허용.

Egress 허용 예시

kind: NetworkPolicy
metadata: { name: allow-egress-to-db }
spec:
  podSelector:
    matchLabels: { app: api }
  policyTypes: [Egress]
  egress:
    - to:
        - podSelector:
            matchLabels: { app: db }
      ports:
        - protocol: TCP
          port: 5432
    - to:                    # DNS 허용 (필수)
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: kube-system }
          podSelector:
            matchLabels: { k8s-app: kube-dns }
      ports:
        - protocol: UDP
          port: 53

[!CAUTION] Egress default-deny 시 DNS (kube-dns) 허용 잊지 말 것. 안 그러면 모든 외부 호출이 DNS resolution 실패.

Namespace 격리

metadata: { name: allow-from-same-namespace }
spec:
  podSelector: {}
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: same-namespace

IP Block (외부 IP 허용)

spec:
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 10.0.0.0/8        # 내부 IP 제외
              - 172.16.0.0/12
              - 192.168.0.0/16

Cilium 의 확장 (L7 NetworkPolicy)

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata: { name: api-l7 }
spec:
  endpointSelector: { matchLabels: { app: api } }
  ingress:
    - fromEndpoints: [{ matchLabels: { app: frontend } }]
      toPorts:
        - ports: [{ port: "80", protocol: TCP }]
          rules:
            http:
              - method: GET
                path: "/api/.*"
              - method: POST
                path: "/api/orders"

L7 (HTTP method / path) 까지. Service Mesh 가 아니어도 L7 보안.

흔한 함정

[!WARNING]

CNI 가 NetworkPolicy 미지원 = YAML 만 적용되고 실제 동작 안 함. Calico/Cilium 확인.

Egress default-deny + DNS 차단 = 모든 외부 호출 실패. DNS 항상 허용.

policyTypes 누락 = Egress 없으면 egress 규칙 무시.

namespaceSelector 의 label = 1.21+ 부터 자동 kubernetes.io/metadata.name. 옛 버전은 namespace 에 직접 label.

[K8s] Pod: 컨테이너의 최소 단위, sidecar, lifecycle

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Pod = K8s 의 가장 작은 배포 단위. 1개 이상의 컨테이너 + 공유 네트워크 + 공유 스토리지.

[!IMPORTANT] Pod 는 컨테이너의 wrapping 이 아니다. 서로 강하게 결합한 컨테이너들의 묶음 (메인 + sidecar). 단일 컨테이너 pod 가 가장 흔함.

구조

flowchart TB
    subgraph Pod
        Pause["pause container<br/>(네트워크 namespace)"]
        Main[Main container<br/>nginx]
        Side[Sidecar container<br/>logger]
        Init["Init container<br/>(완료 후 종료)"]
    end
    Pod --> Net[공유 IP + 포트]
    Pod --> Vol[공유 volume]

라이프사이클

stateDiagram-v2
    [*] --> Pending: scheduled
    Pending --> ContainerCreating: pull image
    ContainerCreating --> Running: init + main start
    Running --> Succeeded: 모든 컨테이너 0 exit
    Running --> Failed: 컨테이너 fail
    Running --> Terminating: delete
    Terminating --> [*]

Phase	의미
Pending	스케줄링 대기 / 이미지 pull
Running	모든 컨테이너 시작
Succeeded	모든 컨테이너 성공 종료
Failed	컨테이너 실패
Unknown	API server 통신 실패

YAML 예시

apiVersion: v1
kind: Pod
metadata:
  name: web
  labels:
    app: web
spec:
  initContainers:
    - name: setup
      image: busybox
      command: ['sh', '-c', 'echo init done > /shared/ready']
      volumeMounts:
        - name: shared
          mountPath: /shared
  containers:
    - name: nginx
      image: nginx:1.27
      ports:
        - containerPort: 80
      resources:
        requests: { cpu: 100m, memory: 128Mi }
        limits:   { cpu: 500m, memory: 512Mi }
      livenessProbe:
        httpGet: { path: /, port: 80 }
        initialDelaySeconds: 10
      readinessProbe:
        httpGet: { path: /ready, port: 80 }
      volumeMounts:
        - name: shared
          mountPath: /var/data
    - name: log-sidecar
      image: fluent-bit:3
      volumeMounts:
        - name: shared
          mountPath: /var/log/source
  volumes:
    - name: shared
      emptyDir: {}

Probes (3종)

Probe	목적	실패 시
Startup	느린 시작 보호	죽인 후 재시작
Liveness	살아있나	컨테이너 재시작
Readiness	트래픽 받을 준비	Service endpoint 에서 제외

flowchart LR
    Start[컨테이너 시작] --> Startup[Startup probe 통과까지<br/>liveness 무시]
    Startup --> Live[Liveness 시작]
    Startup --> Ready[Readiness 시작]
    Live --|실패|--> Restart[컨테이너 재시작]
    Ready --|실패|--> RemoveFromLB[Service 에서 제외]
    Ready --|성공|--> AddToLB[Service 에 추가]

[!IMPORTANT] Probe 가 없으면 K8s 가 언제 트래픽 보낼지 모름 → 첫 요청 실패. readiness 는 거의 필수.

Sidecar Pattern

flowchart LR
    Main[Main: app] -.공유 volume.-> Log
    Main -.공유 network.-> Proxy
    Log[Sidecar: log shipper<br/>fluent-bit]
    Proxy[Sidecar: envoy<br/>mTLS, retry]

흔한 sidecar:

Log shipper (fluent-bit, vector)
Service mesh proxy (envoy, linkerd)
Secret rotation (vault-agent)
TLS termination (nginx)
Metrics adapter (statsd → prometheus)

Init Container

sequenceDiagram
    Scheduler->>Pod: start
    Pod->>Init1: init-1 실행
    Init1-->>Pod: exit 0
    Pod->>Init2: init-2 실행
    Init2-->>Pod: exit 0
    Pod->>Main: main + sidecars 시작

용도:

DB schema migration
설정 파일 생성
TLS cert pre-fetch
데이터 download

Resource: Requests / Limits

flowchart LR
    Req[requests<br/>= 최소 보장] --> Schedule[스케줄링 결정 기준]
    Lim[limits<br/>= 최대 한도] --> Throttle["CPU: throttle<br/>Memory: OOM kill"]

[!CAUTION] Memory limit 초과 = OOM kill (즉시). CPU limit 초과 = throttle (느려짐). memory 는 보수적으로.

Pod 의 변경 불가성

Pod spec 의 대부분 필드 = immutable
변경하려면 → 새 Pod 생성, 옛 Pod 삭제

→ 직접 Pod 만들 일 거의 없음. Deployment / StatefulSet / DaemonSet 이 자동 관리.

흔한 함정

[!WARNING]

Probe 없음 = 트래픽 일부 실패. readiness 필수.

Memory limit 너무 작음 = OOM kill 반복. Resource 측정 후 결정.

Sidecar 가 main 보다 늦게 종료 = pre-stop hook + grace period 부족 → log 누락.

Init container 가 느림 = pod 시작 자체 지연.

[K8s] RBAC: Role, ClusterRole, ServiceAccount, RoleBinding

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

RBAC (Role-Based Access Control) = K8s 의 권한 부여 모델. 주체 + 권한 + 바인딩.

4 객체

flowchart LR
    User[User / Group<br/>또는 ServiceAccount] -->|RoleBinding| Role
    User -->|ClusterRoleBinding| CRole[ClusterRole]
    Role -->|namespace 안| API[API resources]
    CRole -->|cluster 전체| API

객체	범위
`Role`	단일 namespace
`ClusterRole`	전체 cluster
`RoleBinding`	같은 namespace 안 user → Role
`ClusterRoleBinding`	cluster 전체 user → ClusterRole

ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
  namespace: default

Pod 가 K8s API 호출 할 때의 identity.
기본은 default SA. 명시 권장.
모든 SA 는 토큰 자동 마운트 (/var/run/secrets/kubernetes.io/serviceaccount/token).

Role 예시

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: default
rules:
  - apiGroups: [""]
    resources: [pods, pods/log]
    verbs: [get, list, watch]
  - apiGroups: [apps]
    resources: [deployments]
    verbs: [get, list]

verb	의미
`get`	단일
`list`	목록
`watch`	변경 stream
`create`	생성
`update`	갱신
`patch`	부분 갱신
`delete`	삭제
`deletecollection`	일괄 삭제

RoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-pod-reader
  namespace: default
subjects:
  - kind: ServiceAccount
    name: app-sa
    namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRole + ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata: { name: namespace-admin }
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]
---
kind: ClusterRoleBinding
metadata: { name: alice-cluster-admin }
subjects:
  - kind: User
    name: alice
roleRef:
  kind: ClusterRole
  name: namespace-admin

검사 / 디버깅

# 내가 무엇을 할 수 있나?
kubectl auth can-i get pods
kubectl auth can-i list secrets --as alice

# 특정 SA 권한
kubectl auth can-i get pods --as=system:serviceaccount:default:app-sa

# 누가 어떤 권한?
kubectl get rolebinding,clusterrolebinding -A | grep alice

Aggregated ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring
  labels:
    rbac.authorization.k8s.io/aggregate-to-monitoring: "true"
rules: [...]

다른 ClusterRole 이 자동 결합. 운영 도구의 plugin 권한 추가 패턴.

흔한 함정

[!WARNING]

verbs: ["*"] 남발 = 권한 최소화 원칙 위배. 필요한 verb 만.

default SA 사용 = 모든 pod 가 같은 권한. 명시 SA + 최소 Role.

apiGroups: ["*"] 와 resources: ["*"] = 모든 자원 접근. cluster-admin과 다를 바 없음.

RoleBinding namespace 잘못 = Role 은 같은 namespace 만. 다른 namespace 면 무효.

token 직접 사용 = 만료 짧음 (1시간 기본, 1.24+). projected SA token 으로 자동 갱신.

[K8s] Service: ClusterIP / NodePort / LoadBalancer / ExternalName

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Service = Pod 집합에 안정 가상 IP + DNS 부여. Pod 가 죽고 다시 만들어져도 Service IP 는 그대로.

{}

4가지 타입

flowchart TB
    Q{Service 종류}
    Q --> CIP["ClusterIP<br/>(기본)<br/>클러스터 안에서만"]
    Q --> NP[NodePort<br/>각 노드의 포트 노출]
    Q --> LB[LoadBalancer<br/>클라우드 LB 자동 생성]
    Q --> EN[ExternalName<br/>외부 DNS 별칭]

1. ClusterIP (기본)

apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  type: ClusterIP
  selector: { app: api }
  ports:
    - port: 80
      targetPort: 8080

클러스터 안에서만 접근.
다른 pod 가 http://api:80 로 호출.
DNS: <service>.<namespace>.svc.cluster.local.

2. NodePort

spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080   # 옵션

모든 노드의 30000-32767 포트 에서 접근.
http://<any-node>:30080.
보통 개발용. 프로덕션은 LoadBalancer 또는 Ingress.

3. LoadBalancer

spec:
  type: LoadBalancer
  selector: { app: api }
  ports: [{ port: 80, targetPort: 8080 }]

클라우드 (AWS, GCP) 가 자동으로 LB 생성 + 외부 IP.
AWS = ALB / NLB.
Service 당 LB 하나 → 많으면 비싸다. Ingress 가 대안.

4. ExternalName

spec:
  type: ExternalName
  externalName: api.external.com

DNS CNAME 처럼 외부 호스트 별칭.
기존 외부 service 와 통합 용.

Headless Service

spec:
  clusterIP: None    # ← Headless

Service IP 없음.
DNS 가 모든 pod IP 직접 반환.
StatefulSet 의 peer discovery 에 필수.

DNS 와 Service Discovery

nslookup api
→ api.default.svc.cluster.local
→ 10.96.0.42 (ClusterIP)

nslookup api-headless
→ 10.244.0.5  (pod-1)
→ 10.244.0.6  (pod-2)
→ 10.244.0.7  (pod-3)

내부 동작: kube-proxy

flowchart LR
    Client[Client pod] -->|Service IP| KP["kube-proxy<br/>(node)"]
    KP -->|iptables / IPVS rule| P1[pod 1]
    KP -->|iptables / IPVS rule| P2[pod 2]
    KP -->|iptables / IPVS rule| P3[pod 3]

모드	특징
`iptables` (기본)	nat 규칙. 수천 Service 까지 OK
`IPVS`	더 빠름, 더 큰 규모
`nftables` (1.31+)	iptables 대체, 더 빠름

트래픽 분배

Service → endpoints (Pod IP 목록)
kube-proxy → random pick (iptables) 또는 알고리즘 (IPVS)

L4 round-robin. 세션 sticky 가 필요하면 service.spec.sessionAffinity: ClientIP.

Service 와 Endpoints

kubectl get endpoints api
NAME   ENDPOINTS                                AGE
api    10.244.0.5:8080,10.244.0.6:8080,...      5m

Service = 추상.
Endpoints = 실제 pod IP.
Pod 의 readiness 가 OK 인 것만 endpoint 에 포함.

EndpointSlice (1.21+)

큰 클러스터에서 Endpoints 의 확장. 1000+ pod 의 Service 에 효율적.

흔한 함정

[!WARNING]

LoadBalancer 남발 = AWS 1 LB = 시간당 비용 + LCU. Ingress 로 통합 권장.

Service IP 변경 시도 = ClusterIP 는 immutable. 변경하려면 삭제 + 재생성.

Headless 잘못 사용 = LB 동작 없음. StatefulSet 만.

selector label 오타 = endpoints 0개. Service 동작 안 함.

[K8s] StatefulSet: 순서 보장, 고유 ID, 영속 스토리지

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

StatefulSet = 상태 있는 워크로드를 위한 컨트롤러. Deployment 와의 차이:

항목	Deployment	StatefulSet
Pod 이름	random hash (`web-7d9c-xpqr`)	순서 (`db-0, db-1, db-2`)
Pod 식별	변경됨	고정 (sticky identity)
시작 순서	parallel	순차 (0 → 1 → 2)
종료 순서	parallel	역순 (N-1 → 0)
스토리지	공유 또는 ephemeral	pod 별 PVC
Headless Service	옵션	필수

사용처

flowchart TD
    Yes[StatefulSet 적합]
    Yes --> Y1["DB (PostgreSQL, MySQL replica)"]
    Yes --> Y2[Kafka, Zookeeper]
    Yes --> Y3[Elasticsearch]
    Yes --> Y4[etcd]
    Yes --> Y5[Cassandra]
    No[Deployment 가 충분]
    No --> N1[Stateless API]
    No --> N2[Web frontend]
    No --> N3[Worker]

YAML

apiVersion: v1
kind: Service
metadata: { name: db-headless }
spec:
  clusterIP: None        # ← Headless 필수
  selector: { app: db }
  ports: [{ port: 5432, targetPort: 5432 }]
---
apiVersion: apps/v1
kind: StatefulSet
metadata: { name: db }
spec:
  serviceName: db-headless
  replicas: 3
  selector: { matchLabels: { app: db } }
  template:
    metadata: { labels: { app: db } }
    spec:
      containers:
        - name: postgres
          image: postgres:17
          ports: [{ containerPort: 5432 }]
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
    - metadata: { name: data }
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources: { requests: { storage: 100Gi } }

Pod 이름과 DNS

pod 0: db-0   → db-0.db-headless.default.svc.cluster.local
pod 1: db-1   → db-1.db-headless.default.svc.cluster.local
pod 2: db-2   → db-2.db-headless.default.svc.cluster.local

각 pod 가 고유 DNS 이름. peer 끼리 서로 직접 통신 (replication 등).

시작 / 종료 순서

sequenceDiagram
    autonumber
    Note over STS: Create / Scale up
    STS->>Pod0: start (ready 대기)
    Pod0-->>STS: ready
    STS->>Pod1: start (ready 대기)
    Pod1-->>STS: ready
    STS->>Pod2: start (ready 대기)
    Note over STS: Delete / Scale down (역순)
    STS->>Pod2: terminate
    STS->>Pod1: terminate
    STS->>Pod0: terminate

[!IMPORTANT] Master-replica DB 처럼 순서가 중요 한 경우 핵심. podManagementPolicy: Parallel 로 순차 종속성 제거 가능 (Kafka 같이 peer 끼리 sync).

PVC per Pod (영속 스토리지)

flowchart LR
    STS[StatefulSet] --> P0[db-0]
    STS --> P1[db-1]
    STS --> P2[db-2]
    P0 --> PVC0[(PVC: data-db-0<br/>100GB)]
    P1 --> PVC1[(PVC: data-db-1<br/>100GB)]
    P2 --> PVC2[(PVC: data-db-2<br/>100GB)]

pod 재생성 후에도 같은 PVC 재연결.
pod 삭제 해도 PVC 보존 (직접 삭제 필요).

Update 전략

전략	의미
`RollingUpdate` (기본)	순차 업데이트 (N-1 → 0)
`OnDelete`	수동 삭제 시 만 새 spec
`partition: N`	인덱스 ≥ N 만 업데이트 (canary)

운영 패턴: Operator

flowchart LR
    Op["Operator (controller)"] -->|관리| STS[StatefulSet]
    Op -->|backup| Backup[(S3 backup)]
    Op -->|failover| Promote[Replica → Primary]
    Op -->|scale| Add[새 replica join]

DB 운영의 표준 (PostgreSQL Operator, Kafka Strimzi, ElasticSearch ECK).
StatefulSet 만으로 부족한 애플리케이션 특화 로직 자동화.

흔한 함정

[!WARNING]

Headless Service 없음 = pod DNS 안 잡힘 → peer discovery 실패.

partition 활용 안 함 = canary 불가. 모든 pod 한 번에 업데이트.

PVC delete 정책 = StatefulSet 삭제 시 PVC 보존 (기본). 의도적으로 삭제 안 하면 영구 storage cost.

DB 의 순서 의존성 + parallel 정책 잘못 = 데이터 손상.

김신건의 로그 - 위키 / kubernetes

[K8s] ConfigMap & Secret: 설정과 비밀의 분리

정의

ConfigMap 예시

Secret 예시

Pod 에서 사용

1. 환경 변수

2. Volume mount

Secret 관리 패턴 (절대 git 에 평문 금지!)

1. Sealed Secrets

2. External Secrets Operator

3. SOPS

흔한 함정

관련 위키

[K8s] DaemonSet: 모든 노드에 한 pod

정의

흔한 사용

YAML

동작

Node Selector / Tolerations

흔한 함정

관련 위키

[K8s] Deployment: ReplicaSet, rolling update, rollback

정의

계층

YAML

Rolling Update

Recreate Strategy

Rollout 명령

Canary / Blue-Green (Deployment 만으로는 부족)

Revision History

흔한 함정

관련 위키

[K8s] Helm: 패키지 매니저, chart, release, hook

정의

구조

Chart.yaml

values.yaml

Template 예시

흔한 명령

Release 의 lifecycle

Hooks

Helm vs Kustomize

Helmfile (multi-release 관리)

흔한 함정

관련 위키

[K8s] HPA / VPA / KEDA: 자동 확장

3가지 스케일링

HPA (Horizontal Pod Autoscaler)

HPA 알고리즘

VPA (Vertical Pod Autoscaler)

KEDA (Kubernetes Event-Driven Autoscaling)

Cluster Autoscaler / Karpenter

흔한 함정

관련 위키

[K8s] Ingress: L7 라우팅, TLS termination, Gateway API

정의

아키텍처

YAML 예시

Path Type

Ingress Controller 비교

TLS Termination

Gateway API (Ingress 의 차세대)

Ingress vs Gateway API

흔한 패턴: Canary

흔한 함정

관련 위키

[K8s] Job / CronJob: 일회성 + 스케줄 작업

정의

Job

흐름

병렬 실행 (parallelism / completions)

작업 큐 패턴

Indexed Job (1.24+)

CronJob

concurrencyPolicy

Cron 식

흔한 함정

관련 위키

[K8s] NetworkPolicy: pod 간 네트워크 차단