💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

> "쿠버네티스는 더 이상 '플랫폼'이 아니라 '플랫폼을 만들기 위한 커널'이다. 2026년의 진짜 경쟁은 Argo CD/Flux/Crossplane이 그리는 컨트롤 플레인의 모양에 있다." — KubeCon NA 2025 키노트

쿠버네티스가 1.0을 찍은 2015년 7월에서 11년이 지났습니다. 2026년 5월 기준 최신 안정 버전은 1.33(Octarine)이며, 매년 4개월 단위로 1.30~1.33이 출시되었고, 1.34는 곧 RC에 들어갑니다. 그 사이 클러스터를 "어떻게 만드냐"보다 "**어떻게 그 위에서 워크로드를 GitOps로 굴리고, 자동으로 스케일하고, 자동으로 노드를 새로 띄우고, 멀티 클러스터를 묶고, CRD로 자기 확장하는지**" 가 핵심 질문이 되었습니다.

2026년의 쿠버네티스 생태계를 단순화하면 다음과 같은 6개 레이어로 정리됩니다. (1) **매니페스트 도구** — Helm, Kustomize, Carvel, Jsonnet, cdk8s. (2) **GitOps 컨트롤러** — Argo CD, Flux v2. (3) **자동화/스케일링** — KEDA, Karpenter, Cluster Autoscaler. (4) **클러스터 라이프사이클** — Cluster API, kOps, Talos Linux, k3s/k0s/microk8s/kind/k3d, vCluster, KubeVirt. (5) **확장 모델** — Operator Framework, Kubebuilder, Operator SDK, KCC, Crossplane. (6) **운영 UX** — k9s, Lens, Headlamp, Komodor, Pixie.

이 글은 그 6개 레이어를 한 번에 훑으면서, 한국·일본 기업의 실전 도입 사례까지 함께 정리합니다.

1. 2026년 쿠버네티스 지도 — 6개 레이어와 4개 흐름

쿠버네티스 생태계는 6개 레이어로, 그리고 그 위를 가로지르는 4개의 큰 흐름으로 정리됩니다.

| 레이어 | 대표 도구 | 핵심 역할 |

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

| 매니페스트 | Helm, Kustomize, Carvel ytt, Jsonnet, cdk8s | YAML 생성·재사용 |

| GitOps | Argo CD, Flux v2 | Git → 클러스터 동기화 |

| 오토스케일 | KEDA, Karpenter, CAS | 워크로드/노드 스케일링 |

| 라이프사이클 | Cluster API, kOps, Talos | 클러스터 자체의 IaC |

| 확장(CRD) | Operator Framework, Kubebuilder, KCC, Crossplane | 컨트롤러 패턴 |

| 운영 UX | k9s, Lens, Headlamp, Pixie | 사람을 위한 인터페이스 |

이 위를 가로지르는 4개의 흐름은 다음과 같습니다. 첫째, **선언형의 완승** — kubectl apply 시대는 끝났고 Git → Argo/Flux가 표준. 둘째, **노드 스케줄링의 단순화** — Karpenter가 AWS에서 사실상 기본, NodePool 한 장으로 ASG/MIG/MSS를 대체. 셋째, **OS의 K8s 전용화** — Talos Linux, Bottlerocket, Flatcar 같은 "K8s만을 위한 OS"가 빠르게 점유율을 늘리는 중. 넷째, **CRD 만능주의의 후퇴** — 작은 컨트롤러는 좋지만, 모든 것을 CRD로 만들지 말자는 반성이 강해졌고 Crossplane도 v2에서 더 가볍게 재설계되었습니다.

2. Kubernetes 1.30 → 1.33 — 무엇이 바뀌었나

2024.04의 1.30(Uwubernetes)부터 2025년 말~2026년 초의 1.33(Octarine)까지를 한 줄로 요약하면 "**사이드카가 정식이 되고, ImageVolume이 GA가 되고, Dynamic Resource Allocation이 GA를 향해 달려가고, in-place pod resize가 베타가 된 시기**" 입니다.

핵심 변화를 정리하면 다음과 같습니다. 1.29~1.30에서 **사이드카 컨테이너**가 베타로 들어와 init 컨테이너에 `restartPolicy: Always`를 붙이는 방식이 표준이 되었고, Istio ambient mesh와 OpenTelemetry 사이드카가 이를 적극 채택했습니다. 1.31에서 **AppArmor**가 GA, **PersistentVolume Last Phase Transition Time**이 GA가 되었고, kube-proxy의 nftables 모드가 베타로 들어왔습니다. 1.32에서 **In-Place Pod Vertical Scaling**이 베타, **Dynamic Resource Allocation(DRA)** 가 v1beta1으로 진입했고, 1.33에서 **ImageVolume**(컨테이너 이미지를 볼륨처럼 마운트)가 베타, **Sidecar Containers**가 GA로 승격되었습니다.

3. Helm 3.18 — 차트, OCI 레지스트리, Helmfile

Helm은 2026년에도 매니페스트 도구의 사실상 표준입니다. 3.18+에서 OCI 레지스트리 푸시/풀이 완전히 안정화되었고, `helm push oci://registry.example.com/charts/myapp --version 1.2.3` 한 줄로 ECR/GHCR/Harbor에 차트를 올릴 수 있게 되었습니다. Helm 4는 2025년 말 알파가 나왔지만 2026년 5월 현재 프로덕션은 여전히 3.x입니다.

Chart.yaml — 차트 메타데이터

apiVersion: v2

description: A Helm chart for myapp

type: application

version: 1.2.3

appVersion: "2.5.0"

dependencies:

- name: postgresql

version: "15.3.1"

repository: oci://registry-1.docker.io/bitnamicharts

- name: redis

version: "20.0.0"

repository: oci://registry-1.docker.io/bitnamicharts

condition: redis.enabled

values.yaml과 템플릿은 다음처럼 분리합니다.

values.yaml — 환경별 기본값

replicaCount: 2

image:

repository: ghcr.io/myorg/myapp

tag: "" # appVersion 폴백

pullPolicy: IfNotPresent

resources:

requests:

cpu: 100m

memory: 128Mi

limits:

cpu: 500m

memory: 512Mi

autoscaling:

enabled: true

minReplicas: 2

maxReplicas: 20

targetCPUUtilizationPercentage: 70

redis:

enabled: true

auth:

enabled: false

운영 팁: (1) `values-prod.yaml`, `values-stg.yaml`처럼 환경별 values를 두고 Argo CD ApplicationSet으로 합칩니다. (2) **helm-secrets** + SOPS로 민감 값은 KMS 암호화. (3) **sealed-secrets**(Bitnami)는 클러스터 단위 키로 GitOps 친화적, **External Secrets Operator**는 Vault/AWS Secrets Manager/GCP Secret Manager 같은 외부 SoT 연동에 강합니다. 2026년의 베스트프랙티스는 "**민감 값은 ESO로 외부 SoT, 비민감 환경 값은 helm-secrets로 Git**" 의 조합입니다.

4. Kustomize — 오버레이, 컴포넌트, replacements

Kustomize는 kubectl에 내장된 만큼 부담 없이 도입할 수 있고, "베이스 + 오버레이"라는 모델이 직관적입니다. 2026년 기준 권장 패턴은 base/, overlays/dev|stg|prod/, components/(공통 변형)의 3단 구조입니다.

base/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1

kind: Kustomization

resources:

- deployment.yaml

- service.yaml

- configmap.yaml

commonLabels:

app.kubernetes.io/name: myapp

images:

- name: myapp

newName: ghcr.io/myorg/myapp

newTag: 2.5.0

overlays/prod/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1

kind: Kustomization

namespace: prod

resources:

- ../../base

components:

- ../../components/hpa

- ../../components/podsecurity-restricted

replicas:

- name: myapp

patches:

- target:

kind: Deployment

patch: |-

- op: replace

path: /spec/template/spec/containers/0/resources/limits/memory

value: 2Gi

Helm vs Kustomize 논쟁은 2026년에 거의 사그라들었습니다. 결론은 "**Helm은 외부 OSS 차트 가져오기·재배포에 강하고, Kustomize는 내부 자체 매니페스트의 환경 분기에 강하다**" 이며, Argo CD/Flux 모두 Helm 차트를 Kustomize 오버레이로 감싸는 하이브리드를 1급 시민으로 지원합니다.

5. Carvel · Jsonnet · cdk8s — Helm 너머의 선택지

매니페스트 도구의 세 번째 그룹은 "**프로그래머블 YAML**" 진영입니다. **Carvel**(VMware/Broadcom)는 ytt(YAML 템플릿)·kapp(어플라이어)·kbld(이미지 핀)·vendir(의존성 락) 4종 세트를 제공합니다. Helm처럼 텍스트 치환이 아니라 YAML 구조를 직접 변형하기 때문에 들여쓰기 오류가 사라집니다.

**Jsonnet + Tanka**는 Grafana Labs가 자사 인프라를 운영하는 방식이고, Jsonnet 언어로 코드처럼 매니페스트를 작성합니다. Loki, Mimir, Tempo가 모두 Tanka로 배포됩니다. 학습곡선이 가파르지만 대규모 동질 환경에서는 강력합니다.

**cdk8s**(AWS, CNCF Sandbox)는 TypeScript/Python/Go/Java로 K8s 매니페스트를 생성합니다. 표준 라이브러리 cdk8s+가 Deployment/Service/Ingress 같은 고수준 컴포넌트를 제공하며, "타입 안전한 YAML"을 원하는 팀에 적합합니다. 단, 2026년 기준 사용량은 Helm/Kustomize 대비 한 자릿수 %대입니다.

6. Argo CD vs Flux v2 — GitOps의 양대 진영

CNCF Graduated 프로젝트 양쪽인 Argo CD(Intuit, 현 Akuity)와 Flux v2(Weaveworks 해체 후 ControlPlane)는 GitOps의 사실상 양대 표준입니다. 2026년 시장 점유율은 Argo CD가 약 70%, Flux v2가 약 25%, 자체 컨트롤러가 5% 수준으로 추정됩니다.

Argo CD Application — 가장 기본

apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

namespace: argocd

spec:

project: default

source:

repoURL: https://github.com/myorg/manifests

targetRevision: main

path: overlays/prod

destination:

server: https://kubernetes.default.svc

namespace: prod

syncPolicy:

automated:

prune: true

selfHeal: true

syncOptions:

- CreateNamespace=true

- ServerSideApply=true

retry:

limit: 5

backoff:

duration: 5s

factor: 2

maxDuration: 3m

ApplicationSet — 여러 클러스터/환경을 한 번에

apiVersion: argoproj.io/v1alpha1

kind: ApplicationSet

metadata:

namespace: argocd

spec:

generators:

- matrix:

generators:

- list:

elements:

- cluster: prod-asia

region: ap-northeast-2

- cluster: prod-us

region: us-east-1

- list:

elements:

- env: prod

template:

metadata:

spec:

project: default

source:

repoURL: https://github.com/myorg/manifests

targetRevision: main

path: 'overlays/{{env}}'

destination:

server: 'https://{{cluster}}.example.com'

namespace: myapp

Flux v2는 controller 4종(Source/Kustomize/Helm/Notification)으로 분리된 마이크로커널 구조가 강점이고, Argo CD는 UI/멀티 테넌시/RBAC/ApplicationSet이 강점입니다. 일반적인 권장은 "팀이 작고 Helm 차트를 그대로 쓰면 Flux, 대규모 멀티 테넌트와 UI가 필요하면 Argo CD"입니다.

Argo CD 동반 프로젝트인 **Argo Rollouts**(Canary/Blue-Green), **Argo Workflows**(K8s-native 워크플로우 엔진), **Argo Events**(이벤트 소스 → 트리거)도 함께 도입되는 경우가 많습니다. Argo Rollouts의 AnalysisTemplate은 Prometheus 메트릭을 기반으로 canary 트래픽을 자동으로 늘리거나 롤백합니다.

7. KEDA — 이벤트 기반 오토스케일링

KEDA(Kubernetes Event-Driven Autoscaling, CNCF Graduated)는 HPA가 다루지 못하는 외부 이벤트(Kafka lag, RabbitMQ queue depth, AWS SQS, Pub/Sub, Cron 등)를 기준으로 Pod을 0 ~ N으로 스케일합니다. 2026년 5월 기준 70개 이상의 스케일러를 지원합니다.

KEDA ScaledObject — Kafka lag 기준 스케일

apiVersion: keda.sh/v1alpha1

kind: ScaledObject

metadata:

namespace: orders

spec:

scaleTargetRef:

apiVersion: apps/v1

kind: Deployment

minReplicaCount: 0

maxReplicaCount: 100

cooldownPeriod: 60

pollingInterval: 15

triggers:

- type: kafka

metadata:

bootstrapServers: kafka.kafka.svc:9092

consumerGroup: order-consumer

topic: orders

lagThreshold: "1000"

offsetResetPolicy: latest

- type: prometheus

metadata:

serverAddress: http://prometheus.monitoring.svc:9090

threshold: "100"

query: sum(rate(http_requests_total{service="order-api"}[1m]))

KEDA의 핵심은 "**0까지 스케일 인**"입니다. 야간 배치, 이벤트 폭주가 드문 워커는 평시 0 replicas로 둘 수 있어 비용 절감 효과가 큽니다. 단, cold start가 있으니 SLA가 빡빡한 API에는 minReplicaCount를 2 이상 두는 것이 일반적입니다.

8. Karpenter — AWS 기본이 된 노드 오토스케일러

Karpenter는 2025년 11월 CNCF Incubating을 거쳐 2026년 초 Graduated로 승격되었고, AWS에서는 사실상 Cluster Autoscaler(CA)를 대체하는 기본 도구가 되었습니다. 핵심 차이는 (1) ASG/MIG에 묶이지 않고 **Pod의 실제 요구사항을 보고 EC2 인스턴스 타입을 그때그때 선택**한다는 점, (2) **30초 단위**의 빠른 반응성, (3) Spot/On-Demand/Graviton/x86을 단일 NodePool로 혼합 운용 가능, (4) Bottlerocket/Amazon Linux 2023/Ubuntu AMI 자동 패치입니다.

Karpenter NodePool — Spot 우선, Graviton 우선

apiVersion: karpenter.sh/v1

kind: NodePool

metadata:

spec:

template:

metadata:

labels:

team: platform

spec:

requirements:

- key: karpenter.k8s.aws/instance-category

operator: In

values: ["c", "m", "r"]

- key: karpenter.k8s.aws/instance-generation

operator: Gt

values: ["5"]

- key: kubernetes.io/arch

operator: In

values: ["arm64", "amd64"]

- key: karpenter.sh/capacity-type

operator: In

values: ["spot", "on-demand"]

nodeClassRef:

group: karpenter.k8s.aws

kind: EC2NodeClass

expireAfter: 720h # 30일 강제 재생성으로 패치

limits:

cpu: "10000"

memory: 10000Gi

disruption:

consolidationPolicy: WhenEmptyOrUnderutilized

consolidateAfter: 30s

budgets:

- nodes: "10%"

GCP에서는 Karpenter Provider for GCP(2025년 베타), Azure는 AKS Karpenter(2025년 GA)가 등장했지만 2026년 5월 현재 AWS 외에서는 여전히 Cluster Autoscaler가 우세합니다.

9. Cluster API — 클러스터 자체를 K8s 오브젝트로

Cluster API(CAPI, SIG-Cluster-Lifecycle)는 "클러스터를 만드는 클러스터(management cluster)"라는 메타 모델입니다. Cluster, MachineDeployment, ClusterClass 같은 CRD로 워크로드 클러스터의 모양을 선언하고, 인프라 프로바이더(CAPA=AWS, CAPG=GCP, CAPZ=Azure, CAPV=vSphere, CAPI-bootstrap-k0sproject=k0s 등)가 실제 머신을 만듭니다.

2026년 5월 현재 CAPI는 1.10+이고, **ClusterClass**(클러스터 템플릿)이 안정화되어 동일한 모양의 클러스터 10~100개를 선언적으로 찍어내는 패턴이 일반화되었습니다. AWS EKS는 EKS Anywhere의 코어로 CAPI를 사용하고, VMware Tanzu Kubernetes Grid, Rancher RKE2 Provisioner, Giant Swarm, Mirantis 모두 CAPI 위에 자사 제품을 올리는 형태로 수렴했습니다.

ClusterClass — 클러스터 템플릿 한 장

apiVersion: cluster.x-k8s.io/v1beta1

kind: ClusterClass

metadata:

spec:

controlPlane:

ref:

apiVersion: controlplane.cluster.x-k8s.io/v1beta2

kind: AWSManagedControlPlaneTemplate

infrastructure:

ref:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta2

kind: AWSManagedClusterTemplate

workers:

machineDeployments:

- class: default-worker

template:

bootstrap:

ref:

apiVersion: bootstrap.cluster.x-k8s.io/v1beta1

kind: EKSConfigTemplate

infrastructure:

ref:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta2

kind: AWSMachineTemplate

CAPI는 학습 곡선이 가파르지만 "**클러스터 자체의 GitOps**"가 가능해진다는 점에서 50개 이상의 클러스터를 운영하는 조직에는 필수에 가까운 도구가 되었습니다.

10. 클러스터 디스트로 — vanilla · Talos · k3s · k0s · microk8s

쿠버네티스 디스트로는 크게 5개로 분류됩니다. (1) **vanilla(kubeadm)** — 가장 표준적, EKS/GKE/AKS의 코어. (2) **Talos Linux**(Sidero Labs) — K8s 전용 OS로 SSH/패키지 매니저가 없고 모든 것이 API. 2026년 가장 빠르게 점유율이 늘고 있는 디스트로. (3) **k3s**(SUSE/Rancher) — 단일 바이너리 ~60MB, edge/IoT/홈랩의 표준. (4) **k0s**(Mirantis) — k3s와 유사하지만 hostPath 의존이 없고 controlplane HA가 더 간단. (5) **microk8s**(Canonical) — Ubuntu 친화적, snap 기반.

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

| k3s | ~60MB | sqlite/etcd | Edge/홈랩 |

| k0s | ~70MB | etcd 내장 | 임베디드/Edge |

| minikube | VM | etcd 내장 | 학습 |

Talos는 2026년 들어 LINE/Mercari 같은 일본 빅테크가 도입을 시작했고, 한국에서도 Toss와 NAVER가 일부 워크로드에 적용 실험 중입니다.

11. vCluster · KubeVirt — 클러스터 안의 클러스터, VM 안의 K8s

**vCluster**(Loft Labs)는 한 호스트 클러스터 안에 가벼운 가상 컨트롤 플레인을 띄워 "테넌트별 가짜 클러스터"를 만들어 줍니다. 사용자는 자기 vCluster에서 cluster-admin이지만, 호스트 클러스터의 별도 네임스페이스 안에 격리됩니다. 멀티 테넌트 K8s를 "네임스페이스 격리"가 아니라 "가짜 클러스터 격리"로 푸는 방식으로 2025년 이후 빠르게 성장 중입니다.

**KubeVirt**는 거꾸로 K8s 안에 VM을 띄우는 프로젝트입니다. Red Hat OpenShift Virtualization의 코어이며, VM과 컨테이너를 같은 컨트롤 플레인 아래 둡니다. 레거시 Windows/RHEL VM과 클라우드 네이티브 워크로드가 공존해야 하는 금융권/공공/통신에서 도입이 많습니다.

12. Operator Framework · Kubebuilder · Operator SDK

CRD + 컨트롤러 패턴은 K8s의 가장 강력한 확장 메커니즘입니다. 2026년 기준 사실상 표준은 **controller-runtime**(sigs.k8s.io) 위에서 **Kubebuilder**(scaffold) 또는 **Operator SDK**(Red Hat)으로 프로젝트를 시작하는 것입니다. 컨트롤러 패턴의 4대 원칙은 다음과 같습니다.

1. **레벨 트리거(level-triggered)** — 이벤트가 아니라 desired state vs actual state의 차이로 동작. 이벤트를 놓쳐도 다음 reconcile에서 회복.

2. **OwnerReferences** — 부모 리소스가 삭제되면 자식이 자동 GC.

3. **Finalizers** — 외부 리소스 정리가 끝날 때까지 삭제 차단.

4. **Idempotent Reconcile** — 같은 입력에 같은 출력. 중간 상태 저장 금지.

// controller-runtime 기반 Reconcile 골격

func (r *MyAppReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {

log := log.FromContext(ctx)

var app v1alpha1.MyApp

if err := r.Get(ctx, req.NamespacedName, &app); err != nil {

if apierrors.IsNotFound(err) {

return ctrl.Result{}, nil

}

return ctrl.Result{}, err

}

// Finalizer 등록

if app.DeletionTimestamp.IsZero() {

if !controllerutil.ContainsFinalizer(&app, "myapp.example.com/finalizer") {

controllerutil.AddFinalizer(&app, "myapp.example.com/finalizer")

return ctrl.Result{}, r.Update(ctx, &app)

}

} else {

if err := r.cleanupExternal(ctx, &app); err != nil {

return ctrl.Result{RequeueAfter: 30 * time.Second}, err

}

controllerutil.RemoveFinalizer(&app, "myapp.example.com/finalizer")

return ctrl.Result{}, r.Update(ctx, &app)

}

// Desired Deployment 만들고 SSA로 적용

desired := r.buildDeployment(&app)

if err := controllerutil.SetControllerReference(&app, desired, r.Scheme); err != nil {

return ctrl.Result{}, err

}

if err := r.Patch(ctx, desired, client.Apply, client.FieldOwner("myapp-controller"), client.ForceOwnership); err != nil {

return ctrl.Result{}, err

}

// 상태 업데이트

app.Status.Ready = true

if err := r.Status().Update(ctx, &app); err != nil {

return ctrl.Result{}, err

}

log.Info("reconciled", "name", app.Name)

return ctrl.Result{RequeueAfter: 5 * time.Minute}, nil

}

운영 팁: (1) **SSA(Server-Side Apply)** 를 기본으로 쓰세요. fieldManager가 갈등을 자동 해결합니다. (2) `RequeueAfter`를 적극 활용해 watch에만 의존하지 마세요. (3) `Status.Conditions`는 표준 패턴(Ready/Progressing/Degraded)으로 통일.

13. KCC · Crossplane — 클라우드를 K8s 오브젝트로

K8s 컨트롤 플레인을 "**클라우드 리소스의 인터페이스**" 로 쓰는 흐름은 두 진영으로 갈렸습니다. **KCC(Config Connector, GCP)** 는 GCP 리소스를 K8s CRD로 노출하고, **Crossplane**(CNCF Incubating)은 멀티 클라우드(AWS/GCP/Azure/외부 SaaS)를 한 추상으로 묶습니다. Crossplane v2(2025년 말 발표)는 Composition을 더 가볍게 만들고, function 기반 패턴을 1급 시민으로 만들었습니다.

선택 가이드는 단순합니다. **GCP 단일**이면 KCC, **멀티 클라우드 또는 외부 SaaS도 함께**라면 Crossplane, **AWS 단일**이면 AWS Controllers for Kubernetes(ACK)가 일반적입니다. 다만 2026년 기준 Crossplane은 학습 곡선이 여전히 가파르고, Terraform/OpenTofu와의 경계를 명확히 설계하지 않으면 운영 부담이 큽니다.

14. K8s 보안 — PSS · OPA Gatekeeper · Kyverno · Falco · KubeArmor

PodSecurityPolicy(PSP)는 1.25에서 제거되었고 그 자리를 **Pod Security Standards(PSS)** 가 차지했습니다. PSS는 3개 프로파일(privileged/baseline/restricted)을 네임스페이스 라벨로 적용합니다. 다만 PSS는 표현력이 부족해서 대부분의 조직은 정책 엔진을 별도로 둡니다.

| 도구 | 언어 | 강점 | 약점 |

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

2026년 추세는 "**정책 강제는 Kyverno, 런타임 탐지는 Falco**" 의 조합이 가장 많습니다. OPA Gatekeeper는 여전히 강력하지만 Kyverno의 YAML 친화성이 빠르게 점유율을 늘리고 있습니다.

Kyverno ClusterPolicy — latest 태그 금지, 리소스 limits 강제

apiVersion: kyverno.io/v1

kind: ClusterPolicy

metadata:

spec:

validationFailureAction: Enforce

background: true

rules:

- name: validate-image-tag

match:

any:

- resources:

kinds:

- Pod

validate:

message: "이미지 태그는 latest 또는 누락 금지"

pattern:

spec:

containers:

- image: "!*:latest"

- name: require-resources

match:

any:

- resources:

kinds:

- Pod

validate:

message: "모든 컨테이너에 resources.limits 필요"

pattern:

spec:

containers:

- resources:

limits:

memory: "?*"

cpu: "?*"

15. K8s 네트워킹 — NetworkPolicy · Gateway API · Cilium

NetworkPolicy는 1.7부터 있었지만 표현력이 약했고, 2026년 표준은 **Gateway API(GA)** 와 **CiliumNetworkPolicy** 의 조합입니다. Gateway API는 Ingress의 후계로 L4/L7 모두 다루며 GatewayClass/Gateway/HTTPRoute/GRPCRoute/TCPRoute로 분리됩니다. 2024년 GA 이후 대부분의 클라우드 LB 컨트롤러가 Gateway API 모드를 지원합니다.

Cilium은 CNI 시장에서 사실상 표준이 되었고, eBPF 기반으로 kube-proxy를 대체할 수 있으며, Cilium Service Mesh(L7 사이드카리스), Hubble(관측), Tetragon(보안)까지 한 스택으로 묶입니다. 2026년 기준 Cilium은 EKS/GKE/AKS 모두에서 1급 시민이며, 점유율은 약 40%로 1위입니다.

16. K8s 스토리지 — CSI, OpenEBS, Longhorn, Rook

스토리지 인터페이스는 **CSI(Container Storage Interface)** 로 통일되었습니다. 2026년의 옵션은 (1) 클라우드 네이티브(EBS/EFS/PD/Azure Disk/Files CSI 드라이버), (2) **OpenEBS**(Mayastor) — eBPF/NVMe-oF 기반 로컬 스토리지, (3) **Longhorn**(SUSE/Rancher) — 분산 블록 스토리지, (4) **Rook**(Ceph) — 대용량 블록/오브젝트/파일, (5) **Portworx**(Pure Storage) — 엔터프라이즈 상용입니다.

선택 기준은 단순합니다. **클라우드면 그 클라우드의 CSI**가 기본, **베어메탈/온프렘 + 작은 규모**면 Longhorn, **베어메탈/온프렘 + 대용량**이면 Rook이 일반적입니다.

17. 멀티 클러스터 — Karmada · Liqo · Submariner · Skupper

조직이 성장하면 단일 클러스터로는 부족해집니다. 2026년 멀티 클러스터의 4대 옵션은 다음과 같습니다.

**Karmada**(화웨이 → CNCF Incubating)는 "정책 기반 다중 클러스터 스케줄러"입니다. PropagationPolicy/OverridePolicy로 워크로드를 여러 클러스터에 분산 배치합니다. 중국 빅테크와 한국 일부 기업이 활발히 사용합니다.

**Liqo**(이탈리아 Polito → CNCF Sandbox)는 "**Virtual Kubelet으로 다른 클러스터를 하나의 노드처럼 보여주는**" 접근입니다. 동적 페어링이 강점입니다.

**Submariner**(Red Hat)와 **Skupper**(Red Hat)는 클러스터 간 네트워크 연결에 특화되어 있고, Submariner는 Pod CIDR을 직접 묶고 Skupper는 L7 프록시 기반입니다.

**Admiralty**는 멀티 클러스터 스케줄링에 특화된 또 다른 옵션입니다. 2024년에 KubeFed가 archived 되면서 그 자리를 Karmada/Liqo가 대체했습니다.

18. 서비스 메시 — Istio Ambient · Linkerd · Cilium

서비스 메시는 2024~2025년에 큰 전환을 겪었습니다. Istio가 **ambient mesh**(사이드카 없는 모드)를 GA로 출시하면서 Pod당 200MB 메모리 부담이 사라졌고, ztunnel(L4)과 waypoint(L7) 두 레이어로 분리되었습니다. Linkerd는 여전히 가장 가볍지만 Buoyant의 라이선스 정책 변경 이후 OSS 사용자가 일부 이탈했습니다. **Cilium Service Mesh**는 L7 처리를 사이드카 없이 eBPF로 푸는 접근으로 빠르게 성장 중입니다.

2026년 권장은 (1) **단순함 + 무료**면 Linkerd OSS 또는 Cilium Service Mesh, (2) **기능 풍부 + 대규모**면 Istio ambient, (3) **이미 Cilium CNI 도입**이면 그대로 Cilium Service Mesh입니다.

19. 운영 UX — k9s · Lens · Headlamp · Komodor · Pixie

CLI/UI 도구는 2026년에도 풍성합니다. **k9s**(Fernand Galiana)는 터미널 UI의 사실상 표준이며 거의 모든 SRE의 dotfiles에 들어 있습니다.

~/.config/k9s/skins/default.yaml — 간단한 다크 테마

k9s:

body:

fgColor: dodgerblue

bgColor: black

logoColor: orange

prompt:

fgColor: cadetblue

bgColor: black

suggestColor: dodgerblue

info:

fgColor: orange

sectionColor: white

views:

table:

fgColor: aqua

bgColor: black

cursorFgColor: black

cursorBgColor: aqua

header:

fgColor: white

bgColor: black

sorterColor: aqua

**Lens**(Mirantis)는 GUI의 강자였으나 2023년 라이선스 변경 이후 OSS 포크인 **OpenLens**가 갈라져 나왔고, **Headlamp**(Kinvolk → CNCF Sandbox)가 풀 OSS 대안으로 자리잡았습니다. **Octant**(VMware)는 2022년에 sunset 되었고, **Komodor**·**Devtron**은 워크플로우 중심의 상용/OSS 대안입니다. **Pixie**(New Relic → CNCF)는 eBPF 기반 자동 관측으로 사이드카 없이 트레이스를 수집합니다.

2026년 추천 스택은 일반적으로 "**터미널은 k9s, GUI는 Headlamp, 깊은 디버깅은 Pixie**" 의 조합입니다.

20. K8s CI/CD — Tekton vs Argo Workflows vs GitHub Actions

K8s 위에서의 CI/CD는 (1) **Tekton**(CD Foundation) — Pipeline/Task CRD 기반, (2) **Argo Workflows** — DAG 기반 K8s-native, (3) **GitHub Actions Runner Controller(ARC)** — GitHub Actions runner를 K8s Pod로, (4) **Jenkins X**(점차 쇠퇴), (5) **Drone**(Harness 인수 후 변화)로 정리됩니다.

2026년의 추세는 명확합니다. **빌드는 GitHub Actions/GitLab CI(ARC 패턴), 배포는 Argo CD/Flux**로 분리하는 것이 표준이 되었고, K8s-native 워크플로우(Tekton/Argo Workflows)는 ML 학습 파이프라인이나 데이터 처리 같은 "긴 잡" 영역으로 좁혀졌습니다.

21. 관측가능성 스택 — Prometheus · Grafana · OpenTelemetry · Loki · Tempo

K8s 관측가능성의 표준 스택은 (1) **메트릭** — Prometheus + Thanos/Mimir/Cortex, (2) **로그** — Loki/OpenSearch/Elastic, (3) **트레이스** — Tempo/Jaeger, (4) **수집** — OpenTelemetry Collector, (5) **시각화** — Grafana입니다. 2026년 들어 Prometheus 3.0(2024.11)이 OTel 호환을 강화했고, OTLP가 사실상 표준 수집 프로토콜이 되었습니다.

eBPF 기반 자동 관측의 **Pixie**, **Coroot**, **Parca**(continuous profiling)가 사이드카 없는 관측의 새 흐름을 만들고 있고, Grafana Labs의 **Beyla**(eBPF auto-instrumentation)도 빠르게 성장 중입니다.

22. 한국 기업 사례 — NAVER · Coupang · Toss · Kakao

**NAVER**는 NCP(NAVER Cloud Platform)에서 NKS(NAVER Kubernetes Service)를 제공하면서, 내부적으로도 사내 PaaS인 **NBP(NAVER Build Platform)** 위에 Argo CD와 자체 멀티 클러스터 컨트롤러를 운영합니다. 검색·쇼핑·웹툰 같은 대형 서비스가 K8s 위에 올라가 있고, 일부 ML 학습은 vCluster로 격리합니다.

**Coupang**은 AWS EKS를 대규모로 사용합니다. 2024년 발표에서 Karpenter 도입으로 EC2 비용을 약 30% 절감했다는 사례가 공개되었고, 새벽배송의 피크 트래픽을 KEDA + Karpenter 조합으로 흡수합니다. GitOps는 Argo CD 중심입니다.

**Toss**(비바리퍼블리카)는 자체 PaaS인 **Toss Cloud** 위에 EKS 멀티 리전을 운영합니다. KubeCon EU 2024에서 발표한 "수백 개 마이크로서비스를 Argo CD ApplicationSet으로 관리하는 패턴"이 잘 알려져 있습니다. 일부 워크로드는 Talos Linux 실험 중입니다.

**Kakao**는 자체 사내 K8s 플랫폼인 **DKOS(D2 Kubernetes Service)** 를 운영하며 카카오톡·다음·카카오페이가 그 위에서 돕니다. 사내 사용자에게는 멀티 테넌시를 vCluster + ArgoCD로 제공하는 패턴이 일부 적용되었다고 발표된 바 있습니다.

23. 일본 기업 사례 — LINE Verda · Mercari · ZOZO · CyberAgent · SoftBank

**LINE Verda**는 LINE/Yahoo Japan(현 LY Corporation)의 사내 클라우드입니다. OpenStack 위에 자체 K8s(LINE Kubernetes Engine)를 올려 운영하며, KubeCon에서 정기적으로 발표합니다. 2024~2025년에는 Talos 실험과 멀티 테넌트 vCluster 패턴이 화제였습니다.

**Mercari**는 GCP GKE를 중심으로 운영합니다. KubeCon 2023~2024 발표에서 "마이크로서비스 1,000개를 Argo CD로 GitOps하는 사례"가 공유되었고, 2025년부터 ml-platform을 KubeFlow에서 자체 Argo Workflows 기반으로 이관 중입니다.

**ZOZO**(ZOZOTOWN)는 AWS EKS 위에서 Argo CD + Karpenter 조합으로 운영합니다. ZOZO TECH BLOG에 Argo Rollouts canary 패턴 사례가 다수 공개되어 있습니다.

**CyberAgent(CA Group)** 는 자회사가 많아 각자 다른 클라우드를 쓰지만 사내 공통 플랫폼인 **AKE(AbemaTV Kubernetes Engine)** 와 **CIU(CyberAgent Internal Unit)** 가 K8s 표준을 정의합니다. ABEMA TV는 GKE + Argo CD가 메인입니다.

**SoftBank**는 자체 OpenStack 위에 K8s를 운영하면서 Operator 패턴을 적극 활용하고, B2B 5G 패킷 코어에 K8s를 적용하는 시도를 KubeCon에서 발표한 바 있습니다.

24. K8s 안티패턴 — 자주 보는 실수 10가지

운영 현장에서 반복되는 실수를 정리하면 다음과 같습니다.

1. **`latest` 태그 사용** — 이미지 캐시로 인한 비결정성. 항상 digest 또는 SemVer 핀.

2. **liveness probe를 readiness probe처럼 씀** — liveness 실패는 컨테이너 재시작. DB 커넥션 실패에 liveness를 걸면 무한 재시작.

3. **resources requests/limits 미설정** — 클러스터 전체가 노이지 이웃에 휘둘림.

4. **`hostNetwork: true` 남용** — 보안·이동성 모두 손해.

5. **Job 대신 Deployment로 일회성 작업** — 완료된 Pod이 영원히 남음.

6. **kubectl apply -f로 직접 배포** — GitOps 도입 후에도 손으로 만지면 selfHeal로 되돌아감.

7. **하나의 Helm 차트에 모든 서비스** — 한 줄 수정으로 전체 재배포.

8. **PDB 없이 노드 드레인** — 다운타임 발생.

9. **Operator 만능주의** — kubectl apply로 충분한 걸 CRD로 만들어 복잡도 증가.

10. **secret을 ConfigMap에 평문** — 또는 Git에 평문 commit. ESO/SOPS/sealed-secrets로 해결.

25. 2026년 권장 스택 — 규모별 가이드

조직 규모에 따라 권장 스택이 다릅니다.

**소규모(1~3명, 1~3클러스터)**: k3s 또는 매니지드 EKS/GKE/AKS, Helm + Argo CD, Cilium CNI, Karpenter(AWS) 또는 Cluster Autoscaler, k9s + Headlamp.

**중규모(10~50명, 5~20클러스터)**: 매니지드 K8s + Cluster API 일부 도입, Helm + Kustomize 혼합, Argo CD ApplicationSet, KEDA + Karpenter, Kyverno 정책, OpenTelemetry + Grafana 스택, ESO + sealed-secrets.

**대규모(100명+, 50클러스터+)**: Cluster API 본격 도입 또는 Talos Linux, Argo CD 멀티 인스턴스 또는 Flux + Argo CD 혼용, Karmada 또는 Liqo 멀티 클러스터, 자체 Operator 다수, Crossplane으로 클라우드 추상화, Pixie + Beyla로 자동 관측, Karpor로 워크로드 인벤토리.

26. 마이그레이션 가이드 — 무엇부터 손대야 하나

이미 K8s를 운영 중인 팀이 2026년 표준에 맞춰 점진적으로 옮길 때 권장 순서는 다음과 같습니다.

1. **PSP → PSS + Kyverno** (즉시, 1.25 이후 PSP 제거됨)

2. **Cluster Autoscaler → Karpenter**(AWS 사용 시, 비용 절감 효과 큼)

3. **Ingress → Gateway API**(점진적, 새 서비스부터)

4. **HPA만 → HPA + KEDA**(이벤트 기반 워크로드 식별 → 0 스케일 인)

5. **Argo CD/Flux 미도입 → 도입**(가장 큰 운영 개선)

6. **사이드카 Istio → Ambient Mesh**(메모리 대폭 절감)

7. **자체 Bash 스크립트 운영 → Operator로 캡슐화**(작은 것부터)

8. **단일 클러스터 → CAPI로 표준화**(클러스터 5개 넘어가면)

27. 결론 — 2026년 K8s는 "플랫폼을 만드는 플랫폼"

2026년의 쿠버네티스는 더 이상 "워크로드 오케스트레이터"가 아니라 "**플랫폼을 만들기 위한 컨트롤 플레인**" 입니다. Argo CD/Flux로 선언형 운영, Karpenter/KEDA로 자동 스케일, Cluster API/Talos로 클러스터 자체의 IaC, Operator/Crossplane으로 추상화, k9s/Headlamp/Pixie로 사람을 위한 UX — 이 다섯 축이 2026년의 표준이 되었습니다.

핵심은 "**모든 도구를 다 도입하지 말고, 조직 규모에 맞는 최소 스택을 골라 점진적으로 확장**" 하는 것입니다. Helm + Argo CD + Karpenter + Cilium + k9s만 잘 다뤄도 대부분의 조직에는 충분합니다.

References

- [kubernetes.io](https://kubernetes.io/) — 공식 문서, 1.33 릴리스 노트

- [helm.sh](https://helm.sh/) — Helm 공식, 3.18 문서

- [kustomize.io](https://kustomize.io/) — Kustomize 공식

- [argo-cd.readthedocs.io](https://argo-cd.readthedocs.io/) — Argo CD 문서

- [fluxcd.io](https://fluxcd.io/) — Flux v2 공식

- [keda.sh](https://keda.sh/) — KEDA 공식, 70+ 스케일러

- [karpenter.sh](https://karpenter.sh/) — Karpenter 공식

- [cluster-api.sigs.k8s.io](https://cluster-api.sigs.k8s.io/) — Cluster API 문서

- [talos.dev](https://www.talos.dev/) — Talos Linux 공식

- [k3s.io](https://k3s.io/) — k3s 공식

- [k0sproject.io](https://k0sproject.io/) — k0s 공식

- [k9scli.io](https://k9scli.io/) — k9s 공식

- [github.com/lensapp/lens](https://github.com/lensapp/lens) — Lens GitHub

- [headlamp.dev](https://headlamp.dev/) — Headlamp 공식

- [github.com/cncf/sandbox](https://github.com/cncf/sandbox) — CNCF Sandbox 목록

- [sigs.k8s.io/controller-runtime](https://github.com/kubernetes-sigs/controller-runtime) — controller-runtime

- [book.kubebuilder.io](https://book.kubebuilder.io/) — Kubebuilder Book

쿠버네티스는 2014년의 첫 commit부터 11년 동안 "느슨하게 묶인 컨트롤러의 집합"이라는 본질을 잃지 않았습니다. 2026년의 생태계도 그 본질 위에 새로운 레이어를 쌓는 방향으로 발전하고 있고, 이 글에 정리한 6개 레이어는 앞으로 몇 년간 변하지 않을 핵심 골격입니다.