<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1667372393119-3d4c48d07fc9?w=1200&amp;q=80"><h2 id="kubernetes-is-not-a-container-scheduler-anymore">Kubernetes Is Not a Container Scheduler Anymore</h2>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.<img src="https://images.unsplash.com/photo-1558494949-ef010cbdcc31?w=900&amp;q=80" alt="Kubernetes cluster architecture"> Photo by <a href="https://unsplash.com/@tvick">Taylor Vick</a> on UnsplashUnderstanding modern Kubernetes means understanding the ecosystem built around it — not just <code>kubectl apply</code> and <code>helm install</code>.<hr><h2 id="key-evolutions-since-kubernetes-130">Key Evolutions Since Kubernetes 1.30</h2><h3 id="1-sidecar-containers-as-first-class-citizens-129">1. Sidecar Containers as First-Class Citizens (1.29+)</h3>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:<div><pre><code>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: {}
</code></pre></div>This eliminates the “sidecar zombie” problem where sidecars would outlive main containers during job completion.<h3 id="2-gateway-api-ingress-is-finally-replaced">2. Gateway API: Ingress Is Finally Replaced</h3>The Ingress API was always a compromise. <code>Gateway API</code> reached GA status in Kubernetes 1.28 and has become the standard for traffic management:<div><pre><code>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
</code></pre></div>Gateway API supports canary releases, header-based routing, and traffic mirroring natively — without vendor-specific annotations.<h3 id="3-in-place-resource-updates">3. In-Place Resource Updates</h3>One of the longest-requested features: updating Pod CPU/memory without restart. Now GA:<div><pre><code>kubectl patch pod my-app-xxx --patch \
 '{"spec":{"containers":[{"name":"app","resources":{"requests":{"cpu":"500m"},"limits":{"cpu":"1000m"}}}]}}'
</code></pre></div>This is transformative for AI inference workloads where GPU allocation needs to scale dynamically.<hr><h2 id="platform-engineering-patterns">Platform Engineering Patterns</h2>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.<h3 id="crossplane-kubernetes-as-cloud-control-plane">Crossplane: Kubernetes as Cloud Control Plane</h3><a href="https://crossplane.io/">Crossplane</a> lets you provision AWS, GCP, Azure resources using Kubernetes CRDs:<div><pre><code>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
</code></pre></div>No Terraform. No separate state management. Your cloud resources live in Git alongside your Kubernetes manifests.<h3 id="argo-cd--applicationsets-gitops-at-scale">Argo CD + ApplicationSets: GitOps at Scale</h3>Managing 50 microservices across 3 environments with plain Helm was a nightmare. <code>ApplicationSet</code> solves this:<div><pre><code>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
</code></pre></div>One <code>ApplicationSet</code> generates all application/environment combinations. Add a new service → commit a folder → Argo handles the rest.<hr><h2 id="aiml-workloads-on-kubernetes">AI/ML Workloads on Kubernetes</h2><img src="https://images.unsplash.com/photo-1518770660439-4636190af475?w=900&amp;q=80" alt="GPU cluster infrastructure"> Photo by <a href="https://unsplash.com/@alexkixa">Alexandre Debiève</a> on Unsplash<h3 id="gpu-operator-and-time-slicing">GPU Operator and Time-Slicing</h3>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:<div><pre><code># 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
</code></pre></div>This slashes infrastructure costs for inference workloads that don’t need a full GPU.<h3 id="kuberay-ray-clusters-on-kubernetes">KubeRay: Ray Clusters on Kubernetes</h3>For distributed ML training and serving, <a href="https://ray-project.github.io/kuberay/">KubeRay</a> is now the dominant solution:<div><pre><code>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"
</code></pre></div><hr>The auto-instrumentation operator injects OTel agents into Pods without code changes:<div><pre><code>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
</code></pre></div>Kubernetes metadata (node, namespace, pod name) is automatically attached to every trace and metric.<hr><h2 id="whats-coming-in-kubernetes-133">What’s Coming in Kubernetes 1.33+</h2><ul><li>Structured authentication config: Replacing webhook-based token review</li><li>DRA (Dynamic Resource Allocation): Generalized hardware allocation (GPUs, FPGAs, SmartNICs)</li><li>Node memory swap: Beta support for swap on Linux nodes</li><li>Recursive read-only mounts: Security hardening for supply chain compliance</li></ul><hr><h2 id="conclusion">Conclusion</h2>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. <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

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.
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
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.

Kubernetes 2026: From Container Orchestration to Platform Engineering Backbone

댓글