16 min read 2026 Cloud Solutions Report views

2026 Cloud Solutions Report #5: Containers and Kubernetes

Kubernetes is the operating system for AI. Four vendors — EKS, AKS, GKE, OpenShift — diverge on how to run the workloads on top.

That Kubernetes (K8s) has become the standard for container orchestration is no longer news. What’s new is that the standard is moving into its next phase — and in January 2026, the Cloud Native Computing Foundation’s (CNCF) annual survey formalized that move. Kubernetes production usage at 82%, cloud-native technology adoption overall at 98%, and most meaningfully, 66% of generative-AI model hosting now running on Kubernetes [1]. The report’s subtitle — “Infrastructure of AI’s Future” — was the conclusion. The label “container orchestration standard” is already yesterday’s framing; Kubernetes is now being redefined as the control plane for AI infrastructure.

That this isn’t just accumulating adoption shows up in a single month of events in April. On the 22nd, Kubernetes 1.36 “Haru” reached general availability — and Dynamic Resource Allocation (DRA)’s Prioritized Alternatives KEP (Kubernetes Enhancement Proposal) graduated to stable, the standard API for GPU allocation [2]. The same day at Next ’26, Google Cloud unveiled GKE Hypercluster — a single control plane managing roughly one million chips [3]. In one month the standard tightened a notch further, and on top of it, vendor differentiation accelerated again.

So the question left for decision-makers is no longer should we use Kubernetes? — it’s what Kubernetes do we run AI workloads on, and with what operating model? The four vendors in this report are the three cloud service provider (CSP) managed offerings — Amazon’s EKS (Elastic Kubernetes Service), Microsoft Azure’s AKS (Azure Kubernetes Service), Google Cloud’s GKE (Google Kubernetes Engine) — and Red Hat OpenShift, which binds containers, VMs, and AI together on one plane. Before the head-to-head comparison, two macro forces frame the choice: the unification of the GPU standard, and a new variable in Korea’s K8s landscape.

Two Macro Currents Shaping K8s in the AI Era

GPU Standardization: DRA Goes GA, and NVIDIA Donates to CNCF

Until recently, GPU requests in Kubernetes looked like “one, two.” Write nvidia.com/gpu: 1 in a pod spec, and you’d claim an entire GPU card on the node. But unlike CPU, a single GPU card binds memory, compute slices, and interconnect topology together — and depending on workload, you need to use a slice, or chain several together. Dynamic Resource Allocation (DRA) is the new standard API that enables attribute-based request, sharing, and partitioning of specialized hardware like GPUs, FPGAs, and high-performance NICs (Network Interface Cards). Declaratively express conditions like_“40GB+ memory, a card that supports Multi-Instance GPU (MIG) partitioning, a group of GPUs on the same node connected by NVLink”_ — and the scheduler matches automatically. It does for GPU what PersistentVolumeClaim (PVC) did for storage.

Getting DRA here took three years. Introduced as alpha in Kubernetes 1.26 in 2023, the core API graduated to stable in 1.34 in September 2025. In 1.36 “Haru” on April 22, Prioritized Alternatives (KEP-4816) reached stable — moving operational-mode standardization one more step — while supporting KEPs like AdminAccess and the Kubelet PodResources API settled into beta [2]. A month before the 1.36 release, on March 24 at KubeCon Europe, NVIDIA donated its GPU DRA driver to CNCF [4] — an interface that had been vendor-controlled becoming community property, meaning the standard way to request GPUs is no longer tied to one company’s library. It’s now part of Kubernetes.

What this means for CIOs and CTOs is plain. GPUs shift from “expensive, all-or-nothing resources” to “a pool you can carve up and stitch back together flexibly” — and more decisively, the request method is standardized. Whichever Kubernetes distribution you run, follow DRA and you request GPUs the same way. That said, the details of operators, device drivers, and node-pool configuration still differ vendor by vendor — so the axis of comparison has shifted from do you support GPUs? to how well do you abstract and automate them?

Korea’s K8s Landscape — A New Variable in 260,000 GPUs

The Kubernetes decision in Korea, going into 2026, is being made under a new variable. At the APEC summit in October 2025, NVIDIA and Korea’s government and industrial groups agreed to a plan to deploy roughly 260,000 NVIDIA GPUs in Korea, and the first phase is now underway. Samsung Group, SK Group, and Hyundai Motor Group each receive 50,000+; Naver Cloud takes 60,000+; and the government’s Ministry of Science and ICT (MSIT) handles up to 50,000. Five axes of AI factories are being built simultaneously [5].

The first commercial signal came from NHN Cloud, which in January 2026 won KRAFTON’s GPU cluster business — building roughly 1,000 NVIDIA Blackwell Ultra GPUs at the NCC (NHN Cloud Center) in Pangyo, with operations starting July [6]. Together with the government’s target of 70% cloud-native adoption for new systems starting in 2026, and the End-of-Life of NGINX Ingress Controller in March 2026 prompting a Gateway API transition [7], GPU infrastructure scale and standard architecture are both moving at once. The era when global cloud providers were the only GPU infrastructure option is closing, and the question that decision-makers face converges into one: against this shift, what Kubernetes do we run, and with what operating model?

A Deep Look at the Vendors: AI-Era Positioning

Table 1: Four 2026 K8s Vendors — Core Capabilities for AI Infrastructure
Table 1: Four 2026 K8s Vendors — Core Capabilities for AI Infrastructure

Even on “GPU control,” the approach splits — EKS hides the standard, AKS exposes it directly, GKE layers another abstraction on top, and OpenShift sits on a different axis entirely, binding GPUs together with VMs and AI rather than chasing node-count scale. The differences determine the workloads each vendor fits best — and the gotchas you’ll meet six months in.

Amazon EKS — Automation That Hides DRA

EKS Auto Mode doesn’t expose DRA to the user. Send a GPU request and Bottlerocket’s accelerated AMI (Amazon Machine Image) gets selected automatically; GPU failures get recovered by Node Auto Repair within ten minutes; monitoring agents like DCGM-Exporter (NVIDIA GPU telemetry) and Neuron Monitor (for Inferentia and Trainium) come pre-installed, so telemetry flows by default. “Hide the standard, own operations one layer up” — that’s the line EKS Auto Mode picked. Container image pull time dropped by up to 60% after the fall 2025 introduction of SOCI (Seekable OCI) parallel pull [8]. On AWS’s own chips, Trainium3 adds 3x faster training performance over Trainium2 [9]. The automation effects show up in customer numbers: StormForge cut cluster upgrade time by 65% after adopting Auto Mode, and Liquid Analytics spun up 1,000 K8s pods in 1.2 seconds while cutting compute cost by 63% [10].

The best fit is environments that mix general microservices with GPU workloads, where you want fast automation results without growing the operations headcount. The two-edged nature of abstraction is the caveat to watch. Workloads needing specialized network topology or custom AMIs have to fall back to self-managed node groups — at which point the value of automation shrinks. The control plane cost of $0.10 per hour is also a load against AKS and GKE’s free options [11].

Figure 1. Creating an EKS cluster with “Quick configuration (with EKS Auto Mode).” Source: AWS News Blog
Figure 1. Creating an EKS cluster with “Quick configuration (with EKS Auto Mode).” Source: AWS News Blog

Microsoft AKS — Positioning Itself as DRA’s Reference Implementation

If EKS hid the standard, AKS took the opposite line. It picked the path of exposing DRA to the user as fast and as actively as possible. In March 2026 alone, AKS announced Multi-Instance GPU (MIG) with DRA on the 3rd and NVIDIA vGPU with DRA on the 6th [12]; on April 1, RDMA (Remote Direct Memory Access) performance optimization was added through DRANET. Three releases in a quarter — fast enough to call this a “reference implementation of the DRA standard.”

The best fit is enterprise AI development and fine-tuning environments where a single GPU has to be safely shared across multiple teams. Native integration with Microsoft Entra ID (formerly Azure AD), Azure Arc, and Azure DevOps becomes the deciding factor for large Korean organizations whose stack runs on Microsoft 365 and Entra ID. That said, the per-cluster cap of 1,000 nodes (per-node-pool ceiling) is unfit for large-scale LLM (Large Language Model) training [11], and the AKS Automatic control plane fee of $0.16 per hour is a cost increase against the previously-free Standard cluster.

Figure 2. AKS exposes DRA directly: a single GPU is partitioned (MIG / vGPU) and each slice is claimed by a different team through attribute-based ResourceClaims.
Figure 2. AKS exposes DRA directly: a single GPU is partitioned (MIG / vGPU) and each slice is claimed by a different team through attribute-based ResourceClaims.

Google GKE — One Layer Above DRA, the Leader in Inference and Scale

GKE’s differentiation isn’t DRA itself — it’s the workload layer one level above. GKE Inference Gateway, GA in 2026, reduces Time-to-First-Token (TTFT) by 96% through intelligent routing of AI inference traffic, and cuts token cost by up to 25% [13]. On April 8, GKE Managed DRANET reached stable, raising RDMA-class performance on NVIDIA A3 Ultra, A4, A4X, and A4X Max GPUs and on Cloud TPU (Tensor Processing Unit) v6e and v7x instances to a cluster-standard interface [14].

The scale is a different order of magnitude. GKE Hypercluster, announced at Next ’26 on April 22, 2026, has a single Kubernetes control plane managing roughly one million chips across 256,000 nodes spread across multiple regions [3] — orders of magnitude beyond the EKS single-cluster cap of ~3,000 nodes and AKS’s 1,000, and roughly doubling GKE’s own previous record of 130,000 nodes from five months earlier. Hypercluster is built on top of Google’s Titanium Intelligence Enclave with a “no-admin-access” model that isolates model weights and prompts from the platform operator itself — the first Kubernetes implementation to isolate AI assets at the infrastructure layer [3]. Also announced on April 22, GKE Agent Sandbox is a K8s primitive using gVisor-based kernel-level isolation to safely run LLM-generated code [3], expanded at KubeCon EU 2026 into a K8s community Agent Sandbox project [15]. For workloads where inference optimization, large-scale training, and agent execution all overlap, the most advanced platform as of May 2026 is GKE.

Two caveats. GCP’s own market share is lower than AWS or Azure, so organizations already on another cloud face multi-cloud burden. And some differentiating features outside Inference Gateway are very recent, with thin production references — meaning the timing of adoption requires care.

Figure 3. GKE Inference Gateway routes each request by model name and priority, sending high-priority traffic to a faster serving lane.
Figure 3. GKE Inference Gateway routes each request by model name and priority, sending high-priority traffic to a faster serving lane.

Red Hat OpenShift — The Integrated Platform for Containers, VMs, and AI

If the three managed CSPs compete on GPU automation, OpenShift sits on a different axis. Of the four vendors, it’s the only platform that handles containers, VMs, and AI all under one Kubernetes control plane. With Broadcom’s 2023 VMware acquisition rolling out — perpetual licenses dropped, annual subscriptions mandated, and license cost increases of 2x to 10x+ being reported [16] — IBM formalized in its Q4 2025 earnings that OpenShift Virtualization contracts had accumulated to “more than $500 million across the last two years” [17]. Market analysis estimates that roughly 25% of large-scale VMware migrations are heading to OpenShift [18].

OpenShift 4.21 (released March 23, 2026, based on Kubernetes 1.34) tightened the integration promise another notch. The DRA Operator auto-allocates high-priority GPUs to AI training and scales them down when idle, making it possible for training and inference to share the same GPU pool across time slots [19]. Migration Toolkit for Virtualization 2.11 raised VM migration speed up to 10x through storage-offload approaches (per Hitachi internal testing) [20]. At Red Hat Summit 2026 (May 11–14, Atlanta), more than 20 organizations presented OpenShift Virtualization production cases — from global investment banks like Goldman Sachs and Morgan Stanley, to government and defense like the U.S. Navy and NASA, to manufacturers like GM, Ford, and Siemens, to medical institutions like Cleveland Clinic. The breadth of adoption industries has widened significantly [21]. NASA’s Jet Propulsion Laboratory (JPL) announced on day one of the conference that its mission-critical IT infrastructure supporting deep space mission operations had moved to OpenShift Virtualization [22]. Red Hat AI Factory with NVIDIA, revealed at the same event, ties IBM Granite, NVIDIA Nemotron, and Cosmos models in NIM (NVIDIA Inference Microservices) form, while supporting both vLLM and NVIDIA TensorRT-LLM and Dynamo for inference — a structure that connects hardware to AI agent execution in a single stack [23].

In the Korean context, two signals move in parallel. First, the government’s Onnara system, and Lotte Card — the first financial institution to move its core banking system to OpenShift back in December 2020 [24] — are now, five years on, the reference points pulling follow-on review. Second, the sovereign-cloud and private-cloud packages unveiled at the same Summit — compliance profiles that auto-check NIS2 (Network and Information Security 2 Directive), GDPR, and DORA (Digital Operational Resilience Act); regional software supply chains (starting with EU); landing zones that enforce policy from Day 0 — fit the compliance and network-separation requirements of Korean public and financial sectors. Korea availability needs separate confirmation, but Red Hat’s policy direction is clear [25].

Where it hurts. The trap you’ll meet six months in comes from the double-edged nature of an integrated platform. OpenShift subscription costs more than managed K8s on its own, so without computing a break-even where VMware license savings exceed adoption and operating costs, the “escape” turns into another burden. Managed options like ARO (Azure Red Hat OpenShift) and ROSA (Red Hat OpenShift Service on AWS) exist but the cost gap against self-operated is large. And the speed of IBM/Red Hat portfolio integration brings with it deepening dependency on Ansible and watsonx — a long-term consideration.

Figure 4: OpenShift runs containers, virtual machines, and AI/GPU workloads on one Kubernetes control plane — one console, one policy model, one shared GPU pool
Figure 4: OpenShift runs containers, virtual machines, and AI/GPU workloads on one Kubernetes control plane — one console, one policy model, one shared GPU pool

A Closing Note: A Decision Framework for K8s in the AI Era

Kubernetes is already the operating system of AI. The decision question isn’t will we use it? — it’s for which AI workload scenario, on which Kubernetes, with what operating model? And the answer changes with organization size, workload characteristics, and regulatory requirements. Two recommendations as the closing.

Recommendation 1: Reverse-engineer Kubernetes from your AI workload scenarios.

The common ordering is to pick the Kubernetes vendor first, then load AI on top. The recommended ordering is the reverse. The first candidate splits by priority scenario. If inference optimization and agent execution are central: GKE (Inference Gateway, Agent Sandbox, Hypercluster). If GPU auto-provisioning and self-healing rank highest: EKS Auto Mode. If you need a single GPU shared safely across multiple teams: AKS’s DRA + vGPU/MIG combination. If containers, VMs, and AI need to live on one plane: OpenShift Virtualization is the natural starting point.

Get Chaesang Jung’s stories in your inbox

With DRA now standard, any vendor can handle GPUs. But which AI scenario it’s optimized for is plainly different from vendor to vendor. Drawing the scenario first and choosing the vendor second is the most reliable way to cut the six-months-in traps.

Recommendation 2: For Korean decision-makers — design the operating model on top of three local variables.

Deciding Kubernetes in Korea means three Korea-specific variables landing on top of the global ones. Pick the operating model first or those three variables will end up steering the decision separately — and the result tends to add to the cases that Korea’s CIO Magazine survey reported as “88% TCO increase” [26].

First, the new option in GPU infrastructure. As the 260,000-GPU Korea deployment plan’s first phase emerges through NHN and KRAFTON’s 1,000-card buildout, the era of global cloud providers as the only option is closing fast — AI training on global, inference on domestic, or the reverse, has become a realistic combination. Second, the acceleration of the government’s 70% cloud-native policy. The Onnara system and Lotte Card’s OpenShift core banking are hardening into a de-facto standard candidate for public and financial-sector followers — and the same flow is spreading into banking and securities. Third, the simultaneous transition of standard architecture. The March EOL of NGINX Ingress and the Gateway API transition [7][27], together with simultaneous swaps in UI (Lens → Headlamp), tracing (Jaeger → Tempo), and logging (Elasticsearch → OpenSearch) [28], means the move to a new operating model is also the moment to bundle the standard-architecture transition — bundling lets you collapse what would otherwise be multiple migrations into one.

On top of these three variables, the questions converge to three: how far do we embrace the global-domestic hybrid; do we join the public/financial standardization flow; do we bundle the standard-architecture transition with the operating-model change? Designing the operating model first and placing the vendor on top of it is, when three variables move together, the way to pay the least and gain the most.

Kubernetes becoming the OS of AI is the starting point, not the conclusion. Which scenario, which operating model, which vendor on top of that is the real decision in 2026 — and for Korean decision-makers, those three Korea-specific variables stack on top. The global standard has settled. What operating model gets designed on top of it is the next assignment.

References

[1] CNCF. “Kubernetes Established as the De Facto Operating System for AI as Production Use Hits 82% in 2025; CNCF Annual Cloud Native Survey.” January 20, 2026. https://www.cncf.io/announcements/2026/01/20/kubernetes-established-as-the-de-facto-operating-system-for-ai-as-production-use-hits-82-in-2025-cncf-annual-cloud-native-survey/

[2] Kubernetes Blog. “Kubernetes v1.36: Haru.” April 22, 2026. https://kubernetes.io/blog/2026/04/22/kubernetes-v1-36-release/

[3] Google Cloud Blog. “What’s new in GKE at Next ’26.” April 22, 2026. https://cloud.google.com/blog/products/containers-kubernetes/whats-new-in-gke-at-next26

[4] NVIDIA Blog. “NVIDIA at KubeCon 2026: Cloud Native AI Tools and the DRA Driver Donation.” https://blogs.nvidia.com/blog/nvidia-at-kubecon-2026/

[5] NVIDIA Newsroom. “NVIDIA, South Korea Government and Industrial Giants Build AI Infrastructure and Ecosystem to Fuel Korea Innovation, Industries and Jobs.” October 30, 2025. https://nvidianews.nvidia.com/news/south-korea-ai-infrastructure

[6] ZDNet Korea. “NHN Cloud Wins KRAFTON GPU Cluster Business — Deploys 1,000+ Blackwell Ultra Units.” January 19, 2026. https://zdnet.co.kr/view/?no=20260119100834

[7] Kubernetes Blog. “Ingress NGINX Retirement: What You Need to Know.” November 11, 2025. https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/

[8] AWS Blog. “New Amazon EKS Auto Mode features for enhanced security, network control, and performance.” https://aws.amazon.com/blogs/containers/new-amazon-eks-auto-mode-features-for-enhanced-security-network-control-and-performance/

[9] Virtualization Review. “NVIDIA, AWS and Google Cloud Spotlight AI Infrastructure Push at GTC 2026.” March 20, 2026. https://virtualizationreview.com/articles/2026/03/20/nvidia-aws-and-google-cloud-spotlight-ai-infrastructure-push-at-gtc-2026.aspx

[10] AWS. “Amazon EKS Customer Success Stories.” https://aws.amazon.com/eks/customers/

[11] Sedai. “Kubernetes Cost: EKS vs AKS vs GKE.” https://sedai.io/blog/kubernetes-cost-eks-vs-aks-vs-gke

[12] AKS Engineering Blog. “DRA with vGPUs on AKS.” March 6, 2026. https://blog.aks.azure.com/2026/03/06/dra-with-vGPUs-on-aks

[13] Cloud Native Now. “Google Extends Kubernetes Service to Safely Run Agentic AI Workloads.” https://cloudnativenow.com/features/google-extends-kubernetes-service-to-safely-run-agentic-ai-workloads/

[14] Google Cloud Documentation. “GKE release notes (new features) — DRANET GA.” https://docs.cloud.google.com/kubernetes-engine/docs/release-notes-new-features

[15] Solo.io. “Highlights from KubeCon + CloudNativeCon Europe 2026.”https://www.solo.io/blog/highlights-from-kubecon-cloudnativecon-europe-2026

[16] Web And IT News. “The Great VMware Exodus: How Broadcom’s Licensing Overhaul Is Reshaping Enterprise Virtualization Strategy.” February 15, 2026. https://www.webanditnews.com/2026/02/15/the-great-vmware-exodus-how-broadcoms-licensing-overhaul-is-reshaping-enterprise-virtualization-strategy/

[17] The Motley Fool. “IBM (IBM) Q4 2025 Earnings Call Transcript.” January 28, 2026. https://www.fool.com/earnings/call-transcripts/2026/01/28/ibm-ibm-q4-2025-earnings-call-transcript/

[18] TechTarget. “AWS, Red Hat hybrid cloud wares court VMware converts.” https://www.techtarget.com/searchitoperations/news/366617436/AWS-Red-Hat-hybrid-cloud-wares-court-VMware-converts

[19] Red Hat Developers. “Dynamic resource allocation goes GA in Red Hat OpenShift 4.21: Smarter GPU scheduling for AI workloads.” March 25, 2026. https://developers.redhat.com/articles/2026/03/25/dynamic-resource-allocation-goes-ga-red-hat-openshift-421-smarter-gpu

[20] Red Hat Blog. “Red Hat OpenShift 4.21: Smarter scaling, faster migration, and AI-powered efficiency.” https://www.redhat.com/en/blog/red-hat-openshift-421-smarter-scaling-faster-migration-and-ai-powered-efficiency

[21] Red Hat Blog. “Customer stories and continued momentum: OpenShift Virtualization sessions at Red Hat Summit 2026.” https://www.redhat.com/en/blog/openshift-virtualization-sessions-red-hat-summit-2026

[22] Red Hat Press Release. “NASA’s Jet Propulsion Laboratory Advances Deep Space Mission Operations with Red Hat OpenShift Virtualization.” May 11, 2026. https://www.redhat.com/en/about/press-releases/nasa-jet-propulsion-laboratory-advances-deep-space-mission-operations-red-hat-openshift-virtualization

[23] Red Hat Press Release. “Red Hat AI Factory with NVIDIA Expands Support for a New Class of Autonomous Agents in the Enterprise.” May 12, 2026. https://www.businesswire.com/news/home/20260512891747/en/Red-Hat-AI-Factory-with-NVIDIA-Expands-Support-for-a-New-Class-of-Autonomous-Agents-in-the-Enterprise

[24] Red Hat Korea Press Release. “Red Hat Supports Lotte Card’s Core Banking System Modernization and Cloud-Native Technology Adoption.” March 3, 2021. https://www.redhat.com/ko/about/press-releases/

[25] Red Hat Press Release. “Red Hat Introduces New Sovereign and Private Cloud Capabilities to Power Digital Autonomy.” May 12, 2026. https://www.redhat.com/en/about/press-releases/red-hat-introduces-new-sovereign-and-private-cloud-capabilities-power-digital-autonomy

[26] CIO Korea. “Kubernetes Cost Explosion — 88% Report TCO Increase” (citing Spectro Cloud survey). https://www.cio.com/article/4042775/

[27] Kubernetes Blog. “Announcing Ingress2Gateway 1.0: Your Path to Gateway API.” March 20, 2026. https://kubernetes.io/blog/2026/03/20/ingress2gateway-1-0-release/

[28] sysnet4admin. “Kubernetes Standard Architecture 2026 (Korea K8s Standard Architecture).” https://github.com/sysnet4admin/_Book_k8sInfra/tree/main/docs/k8s-stnd-arch/2026

Part of the 2026 Cloud Solutions Report — an ongoing series on the 2026 cloud tooling landscape. See the full series →

Originally published in Korean by NIA Digital Service Issue Report, May 2026. Written as Adjunct Professor at KAIST College of Business.

Korean version on Brunch: brunch.co.kr/@chaesang/181

Comments