Kubernetes 2026: From Container Orchestration to Platform Engineering Backbone

on Kubernetes, Cloud, Devops, Platform engineering, Infrastructure, K8s



Kubernetes Is Not a Container Scheduler Anymore

When Kubernetes graduated from CNCF in 2018, most teams treated it as a “better Docker Swarm” — a way to run containers at scale. In 2026, that framing is ancient history. Kubernetes has become the universal control plane: the runtime substrate on which platforms, developer tools, AI workloads, and even databases are built.

Kubernetes cluster architecture Photo by Taylor Vick on Unsplash

Understanding modern Kubernetes means understanding the ecosystem built around it — not just kubectl apply and helm install.

Key Evolutions Since Kubernetes 1.30

1. Sidecar Containers as First-Class Citizens (1.29+)

The sidecar pattern was always popular (Envoy, Vault agent, logging daemons) but historically fragile — init containers and lifecycle hooks were hacks. Kubernetes 1.29 introduced native sidecar support:

apiVersion: v1
kind: Pod
spec:
  initContainers:
    - name: log-collector
      image: fluentd:v1.17
      restartPolicy: Always  # This is the sidecar declaration
      volumeMounts:
        - name: app-logs
          mountPath: /var/log/app
  containers:
    - name: app
      image: my-service:latest
      volumeMounts:
        - name: app-logs
          mountPath: /var/log/app
  volumes:
    - name: app-logs
      emptyDir: {}

This eliminates the “sidecar zombie” problem where sidecars would outlive main containers during job completion.

2. Gateway API: Ingress Is Finally Replaced

The Ingress API was always a compromise. Gateway API reached GA status in Kubernetes 1.28 and has become the standard for traffic management:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
spec:
  parentRefs:
    - name: production-gateway
  hostnames:
    - "api.myservice.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v2
      filters:
        - type: RequestHeaderModifier
          requestHeaderModifier:
            add:
              - name: X-API-Version
                value: "2"
      backendRefs:
        - name: api-v2-service
          port: 8080
          weight: 90
        - name: api-v2-canary
          port: 8080
          weight: 10

Gateway API supports canary releases, header-based routing, and traffic mirroring natively — without vendor-specific annotations.

3. In-Place Resource Updates

One of the longest-requested features: updating Pod CPU/memory without restart. Now GA:

kubectl patch pod my-app-xxx --patch \
  '{"spec":{"containers":[{"name":"app","resources":{"requests":{"cpu":"500m"},"limits":{"cpu":"1000m"}}}]}}'

This is transformative for AI inference workloads where GPU allocation needs to scale dynamically.

Platform Engineering Patterns

The most significant shift in how teams use Kubernetes is the emergence of Internal Developer Platforms (IDPs). Kubernetes is now the backend for platforms that abstract away infrastructure complexity from developers.

Crossplane: Kubernetes as Cloud Control Plane

Crossplane lets you provision AWS, GCP, Azure resources using Kubernetes CRDs:

apiVersion: rds.aws.upbound.io/v1beta1
kind: Instance
metadata:
  name: production-db
spec:
  forProvider:
    region: ap-northeast-2
    instanceClass: db.r6g.large
    engine: postgres
    engineVersion: "16.2"
    allocatedStorage: 100
    storageEncrypted: true
  providerConfigRef:
    name: aws-provider

No Terraform. No separate state management. Your cloud resources live in Git alongside your Kubernetes manifests.

Argo CD + ApplicationSets: GitOps at Scale

Managing 50 microservices across 3 environments with plain Helm was a nightmare. ApplicationSet solves this:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: all-services
spec:
  generators:
    - matrix:
        generators:
          - git:
              repoURL: https://github.com/myorg/services
              revision: main
              directories:
                - path: services/*
          - list:
              elements:
                - env: staging
                - env: production
  template:
    spec:
      project: default
      source:
        repoURL: https://github.com/myorg/services
        targetRevision: main
        path: ""
        helm:
          valueFiles:
            - "values-.yaml"
      destination:
        server: "https://kubernetes.default.svc"
        namespace: "-"
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

One ApplicationSet generates all application/environment combinations. Add a new service → commit a folder → Argo handles the rest.

AI/ML Workloads on Kubernetes

GPU cluster infrastructure Photo by Alexandre Debiève on Unsplash

GPU Operator and Time-Slicing

NVIDIA’s GPU Operator transforms K8s GPU management. With MIG (Multi-Instance GPU) and time-slicing, you can share a single A100 across multiple Pods:

# ConfigMap for time-slicing config
apiVersion: v1
kind: ConfigMap
metadata:
  name: time-slicing-config
  namespace: gpu-operator
data:
  any: |-
    version: v1
    flags:
      migStrategy: none
    sharing:
      timeSlicing:
        replicas: 8  # 8 logical GPUs from 1 physical A100

This slashes infrastructure costs for inference workloads that don’t need a full GPU.

KubeRay: Ray Clusters on Kubernetes

For distributed ML training and serving, KubeRay is now the dominant solution:

apiVersion: ray.io/v1
kind: RayCluster
metadata:
  name: llm-training-cluster
spec:
  rayVersion: "2.40.0"
  headGroupSpec:
    replicas: 1
    template:
      spec:
        containers:
          - name: ray-head
            image: rayproject/ray-ml:2.40.0-gpu
            resources:
              limits:
                nvidia.com/gpu: "1"
  workerGroupSpecs:
    - replicas: 4
      template:
        spec:
          containers:
            - name: ray-worker
              image: rayproject/ray-ml:2.40.0-gpu
              resources:
                limits:
                  nvidia.com/gpu: "4"

Observability: OpenTelemetry + Kubernetes Metadata

The auto-instrumentation operator injects OTel agents into Pods without code changes:

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: auto-instrument
spec:
  exporter:
    endpoint: http://otel-collector:4317
  propagators:
    - tracecontext
    - baggage
  python:
    env:
      - name: OTEL_PYTHON_LOG_CORRELATION
        value: "true"
  java:
    image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:2.10.0

Kubernetes metadata (node, namespace, pod name) is automatically attached to every trace and metric.

What’s Coming in Kubernetes 1.33+

  • Structured authentication config: Replacing webhook-based token review
  • DRA (Dynamic Resource Allocation): Generalized hardware allocation (GPUs, FPGAs, SmartNICs)
  • Node memory swap: Beta support for swap on Linux nodes
  • Recursive read-only mounts: Security hardening for supply chain compliance

Conclusion

Kubernetes in 2026 is less about “running containers” and more about building reliable, scalable platforms. The teams winning aren’t the ones with the most YAML — they’re the ones who’ve abstracted Kubernetes behind developer-facing APIs, automated away day-2 operations, and built GitOps pipelines that make deployments boring.

Boring deployments are the goal. Kubernetes, at its best, makes infrastructure invisible.

이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :)