Raul B.

Search "best managed Kubernetes hosting" and you get fifty listicles that read like they were written by the same intern with the same affiliate spreadsheet. They rank platforms on cluster provisioning speed and the color of the dashboard, then bury the only question that matters: should you be on Kubernetes at all.

I'm going to answer that question first. Then I'll rank the platforms, because if you've read this far you probably still want the ranking. But I want you to leave this post knowing that the cheapest managed Kubernetes cluster in the world is still more expensive than not running Kubernetes.

House rule: every claim in this post is sourced. If I can't back something up I cut it rather than handwave.

Before Railway I was at Citrix, working on customer environments at Verizon and Lockheed. Those are the kinds of shops where Kubernetes makes sense: enormous service fleets, hard compliance boundaries, platform teams measured in dozens. If your shop does not look like that, keep reading; the honest answer might surprise you.

There are four shapes of team for whom Kubernetes is the correct answer in 2026. If you don't fit one of these, the rest of this post is mostly entertainment.

You run a large fleet of services. I mean dozens of long-running services with independent release cadences, not a monolith and three workers. Kubernetes earns its complexity tax once you're orchestrating enough services that the cost of managing them by hand exceeds the cost of managing the orchestrator. The break-even point is higher than most teams think. Three services and a cron job is not a fleet.

You have a platform engineering team. Plural. Kubernetes is a platform you build platforms on, not a platform you ship products on. Somebody has to own the cluster, the upgrade path, the ingress controller, the secrets backend, the observability stack, the cost-allocation tagging, and the on-call rotation when CoreDNS decides to have a bad Tuesday. If that somebody is also your senior backend engineer, you don't have a platform team, you have a person who is about to burn out.

You have multi-tenancy or compliance requirements that force your own VPC. Customers in regulated industries (HIPAA-covered health data, PCI cardholder environments, FedRAMP workloads, ITAR-restricted defense) often need workloads inside their own cloud account, with their own network controls, their own audit trail. Bring-your-own-cloud (BYOC) Kubernetes is the right tool when an enterprise customer says "we will not let your runtime touch our data, but we'll let it run in our account." That contract is worth a lot of money and worth a lot of operational complexity.

You have exotic workload requirements. GPU pools for training jobs, specific kernel modules, custom CNI plugins, stateful workloads with operators that only ship as Helm charts, multi-region failover that has to be coordinated at the orchestrator layer. Kubernetes has the longest tail of "yes you can do that" of any platform around. That tail is the product.

If you fit one of these, congratulations, Kubernetes is for you and you should read the rankings below carefully.

If you don't fit any of these, here is the part the other listicles will not tell you: most teams searching for managed Kubernetes are paying an operational tax they did not need to pay. The tax shows up as dashboards nobody reads, runbooks nobody updates, and Slack threads at 2am that start with "our certs expired." A managed control plane removes maybe a third of that tax. You still own the rest.

Let's be precise about what "managed" means, because the marketing pages elide this on purpose.

When you buy managed Kubernetes, the provider runs the control plane: the API server, etcd, the scheduler, the controller-manager. They handle HA, they handle etcd backups, they handle Kubernetes version upgrades on the control plane (usually behind a button, sometimes automatically). This is real and valuable. Running your own etcd cluster in 2026 should be considered a hostile act against your future self.

What you still own is the data plane and everything that touches it:

• Nodes: their OS, their kernel patches, their right-sizing, their autoscaling configuration
• Cluster autoscaler / Karpenter: tuning, eviction policies, spot interruption handling
• Ingress: picking, deploying, and operating ingress-nginx, Traefik, Envoy Gateway, or your cloud's load balancer integration
• cert-manager: installing it, configuring issuers, debugging why a Let's Encrypt rate limit ate your renewal
• Secrets: External Secrets Operator, sealed-secrets, or a Vault integration, and the lifecycle of all of it
• Observability: Prometheus, Grafana, Loki, OpenTelemetry collectors, and the storage bill behind them
• Networking: NetworkPolicies, service mesh (or aggressive avoidance of one), egress controls, pod-to-pod encryption if your threat model requires it
• RBAC and policy: who can deploy what to which namespace, enforced by something like Kyverno or OPA Gatekeeper

If reading that list made you tired, that is the correct response. Managed K8s is "managed" the way a managed apartment building is managed. They fix the boiler. You still have to live there.

At a glance:

Best for production workloads that already live in AWS.

Most production Kubernetes in 2026 runs on EKS. That isn't because EKS has the nicest ergonomics (it does not). It's because the rest of the workload is already in AWS, the IAM model is already understood, and the org chart has already grown a team that knows how to wrangle VPCs. EKS wins by gravity.

The control plane is solid, upgrades are well-trodden, and the ecosystem is unmatched: ALB ingress controller, AWS Load Balancer Controller, IRSA for pod-level IAM, EKS Pod Identity for the slightly-less-painful successor, Karpenter for autoscaling that holds up under load.

Features: managed control plane, IRSA / Pod Identity for AWS IAM integration, Karpenter for node autoscaling, EKS Anywhere for on-prem, EKS Auto Mode for fully managed compute, integration with every AWS service you already pay for.

Pricing: $0.10/hour per cluster ($73/month) plus EC2 node costs, plus NAT gateway, plus data transfer, plus the inevitable bill from whatever ALB you forgot about.

Best for: AWS-native shops with a platform team that already speaks IAM fluently.

Honest trade-offs: the AWS networking setup is the cost. Standing up EKS the right way (VPC CNI, subnets, NAT, IRSA, ALB controller, Karpenter, cluster autoscaler, ExternalDNS) is a two-week project for somebody who has done it before, and a quarter-long project for somebody who hasn't. The console is also still slow.

Best for teams who want the cleanest Kubernetes experience available.

Google invented Kubernetes (it was Borg, then it was Omega, then it was Kubernetes, the lineage is well documented). GKE shows it. The control plane is the most polished of any cloud provider, upgrades are the least anxiety-inducing, and Autopilot mode is the closest any hyperscaler has come to "Kubernetes but you don't think about nodes."

Autopilot deserves its own paragraph. You pay per-pod for CPU, memory, and ephemeral storage, and Google handles node provisioning, scaling, OS patching, and the rest. For teams who want K8s semantics but don't want to operate the data plane, it is the best deal in the category, with the caveat that you give up some flexibility (DaemonSets are constrained, certain privileged workloads don't run).

Features: Autopilot mode (per-pod pricing, no node management), Standard mode for full control, GKE Enterprise (formerly Anthos) for multi-cluster, native Workload Identity, Gateway API support, image streaming for faster pod starts.

Pricing: Standard mode is $0.10/hour per cluster plus node costs. Autopilot is per-pod (CPU, memory, ephemeral storage) with no separate cluster fee on the first zonal cluster in a billing account. One zonal cluster per billing account is free on the management fee.

Best for: teams without strong AWS gravity who want the cleanest K8s experience available.

Honest trade-offs: GCP's ecosystem outside of GKE is smaller than AWS's, so if your data lives in BigQuery and your compute lives in GKE you're fine, but if you need a hundred adjacent managed services you'll feel the gap. Pricing math for Autopilot can be surprising at scale; benchmark it before committing.

Best for Microsoft-aligned shops, especially enterprise with Entra ID.

AKS is Microsoft's managed Kubernetes, and it lives or dies by your relationship with the rest of the Azure ecosystem. If your identity provider is Entra ID (the artist formerly known as Azure AD), if your compliance answers involve "we use Azure Government," if your developers already have Visual Studio licenses, AKS is a natural fit.

The free tier (no Uptime SLA) is free on the control plane, which is the most aggressive pricing of any hyperscaler. The Standard tier adds an SLA for $0.10/hour per cluster.

Features: free control plane on the no-SLA tier, Entra ID integration, Azure Policy for governance, AKS Automatic for opinionated managed mode, virtual nodes via Azure Container Instances for burst capacity.

Pricing: Free tier control plane is $0. Standard tier with Uptime SLA is $0.10/hour per cluster. Premium tier with long-term support is $0.60/hour. Nodes billed at standard VM rates.

Best for: enterprise shops with Microsoft licensing agreements already in place.

Honest trade-offs: AKS upgrades have historically been the most painful of the big three, though they've gotten better. The defaults for the no-SLA tier are not what you want in production. And the Azure portal remains a UI choice that Microsoft made on purpose.

Best for teams who want Kubernetes underneath without the Kubernetes ergonomics on top.

Northflank is the most interesting platform in this category because it's honest about what it is: a PaaS-shaped product surface that runs on real Kubernetes underneath, with BYOC into your AWS, GCP, or Azure account at no markup. You get the operational properties of K8s (multi-tenancy, network isolation, custom resource definitions if you need them) without writing YAML for everything.

The pitch lands well for teams who've outgrown a pure PaaS but don't want to staff a platform team. You bring your cloud account, Northflank brings the platform layer.

Features: BYOC into AWS / GCP / Azure with no markup on the underlying compute, build pipelines, preview environments, jobs and workflows, GPU support, addons (Postgres, Redis, etc.).

Pricing: BYOC starts around $300/month for the platform plus your cloud's compute bill at list price. There's also a Northflank-hosted option on their own infrastructure with usage-based pricing.

Best for: teams who want K8s semantics for compliance or multi-tenancy reasons but don't want to operate Kubernetes themselves.

Honest trade-offs: you're trusting another vendor's control plane abstraction over your cloud account, which means you've added a layer that can break, and a layer you can't fix yourself. The pricing only makes sense once you're at a certain scale; below that, you're better off on a pure PaaS.

Best for accessible mid-tier workloads that don't need hyperscaler depth.

DigitalOcean's managed Kubernetes (DOKS) is the platform that introduced a generation of indie devs and small teams to "managed K8s." The control plane is free, the droplets are reasonably priced, and the dashboard does not require a PhD.

Features: free control plane, integrated load balancers, block storage via DO Volumes, container registry, 1-click app marketplace for Helm charts.

Pricing: control plane is $0. Standard droplet nodes start around $12/month for the smallest viable size. HA control plane is an extra $40/month per cluster if you want it (you do, for anything resembling production).

Best for: small to mid-size teams who want K8s without an AWS bill.

Honest trade-offs: the ecosystem is shallow compared to the hyperscalers. If you need GPU pools, advanced networking, or anything exotic, you'll outgrow it. The HA control plane being an upsell is mildly annoying.

Best for teams who want DigitalOcean's shape with Akamai's network footprint.

LKE is structurally similar to DOKS: free control plane, reasonable node pricing, accessible dashboard. The differentiator since the Akamai acquisition is the network. Linode nodes now sit closer to Akamai's edge, which matters if you're doing anything latency-sensitive.

Features: free standard control plane, HA control plane upgrade available, integrated NodeBalancers, block storage, object storage.

Pricing: Standard control plane is $0. HA control plane is $60/month per cluster. Nodes start around $12/month for a 1GB shared CPU plan; production-shaped nodes are in the $30-100/month range.

Best for: teams with a latency-sensitive workload who want managed K8s without hyperscaler complexity.

Honest trade-offs: smaller ecosystem than the hyperscalers, smaller community than DigitalOcean, and the Akamai integration story is still maturing. Documentation quality is uneven.

Best for fastest cluster provisioning, K8s-first cloud.

Civo built their cloud around Kubernetes from the start, on k3s. The marketing claim is cluster creation in under 90 seconds, and in my testing that's roughly accurate. If you're the kind of team that spins up and tears down clusters for CI or for ephemeral environments, that speed is a real product advantage.

Features: k3s-based clusters, cluster creation in roughly 90 seconds, simple flat-rate pricing, GPU instances, marketplace apps.

Pricing: nodes start around $10/month for the smallest size, with a free control plane on standard clusters.

Best for: teams whose workflow involves frequent cluster creation, or who want a K8s-first cloud rather than a general cloud with K8s bolted on.

Honest trade-offs: smaller scale than the hyperscalers, fewer regions, and k3s has some semantic differences from upstream Kubernetes that can bite you in edge cases (etcd is replaced with SQLite or embedded etcd, certain controllers are absent by default).

Best for budget-conscious teams who want VPS-flavored Kubernetes.

VKE is Vultr's managed Kubernetes, and it competes on price. The control plane is free, the nodes are some of the cheapest in the market, and the regional footprint is wide.

Features: free control plane, integrated load balancers, block storage, wide regional coverage including secondary markets.

Pricing: control plane is $0. Nodes start around $6/month for the smallest size, with production-shaped nodes in the $20-50/month range.

Best for: budget-sensitive workloads, especially in regions where the hyperscalers don't have a nearby presence.

Honest trade-offs: the support experience is what you'd expect for the price. The dashboard is functional but not delightful. Ecosystem depth is the shallowest on this list.

Best for European data residency and sovereignty requirements.

OVHcloud is the answer when your compliance posture demands that your data stays in the EU, under EU jurisdiction, on infrastructure owned by an EU company. Post-Schrems-II, that question gets asked a lot more than American teams realize.

Features: managed control plane, EU data residency, integrated with OVHcloud's broader infrastructure (bare metal, public cloud, private cloud), GDPR-aligned operating model.

Pricing: control plane is free. Nodes billed at OVHcloud's public cloud rates, generally competitive with the hyperscalers in EU regions.

Best for: European teams, or teams selling to European customers who require EU-sovereign hosting.

Honest trade-offs: the ecosystem outside of OVHcloud's own services is thinner than the hyperscalers, and the operational tooling is more European in style, which is a polite way of saying the docs assume you know what you're doing. The 2021 Strasbourg datacenter fire is a memory that informs current architecture decisions, and OVHcloud has been transparent about their changes since, but it's worth reading up on if you haven't.

Best for teams who want to run their own.

Self-hosted Kubernetes is free in licensing and expensive in operations. The tooling has gotten dramatically better in the last few years. k3s gives you a single-binary lightweight distribution that's appropriate for edge and small clusters. kubeadm is the canonical "I want vanilla K8s and I'll bring my own automation" path. Talos Linux is the most interesting modern entry: an immutable, API-driven Linux distribution built specifically to run Kubernetes, with no SSH and no shell, configured entirely through declarative manifests.

Features: total control, no per-cluster fee, your hardware (or your VMs) your rules.

Pricing: free in software. Your time, your servers, your on-call.

Best for: teams with a real reason to self-host (sovereignty, air-gapped, specific hardware) and the operational maturity to back it up.

Honest trade-offs: you are now the managed control plane provider. Upgrades are yours. etcd backups are yours. The 3am page when the control plane goes down is yours. Talos Linux makes this much more reasonable than it used to be, but "reasonable" is doing a lot of work in that sentence.

Before you pick a platform from the list above, answer these honestly:

1. Do you have at least two engineers whose job will be the cluster? If no, you don't have a platform team, and you're going to feel it.
2. Do you have more than a dozen long-running services? If no, the orchestrator complexity is greater than the orchestration value.
3. Do you have a compliance or contractual requirement that forces your own VPC? If yes, K8s might be the cleanest path. If no, that's not a reason.
4. Do you have workloads that need K8s primitives (operators, CRDs, DaemonSets, custom schedulers)? If you can't name the specific primitive, you don't.
5. Are you willing to own ingress, cert-manager, secrets, observability, and networking forever? The control plane is managed. Everything else is you.
6. Is your team's time worth more than the operational tax? If yes, that's the answer.

If you answered no to most of these, the question isn't "which managed Kubernetes." The question is "why am I considering Kubernetes."

The vanilla-cloud anchor for this category remains AWS EKS. If you must run Kubernetes in production and you don't have a strong reason to pick something else, EKS is the default, and the listicles that rank it lower are usually selling you something.

Railway is intentionally not on this list. We are not a Kubernetes platform. That's a feature, not a bug, for the vast majority of teams who land on a post like this. If you don't fit one of the four shapes at the top of this article, the honest move is to save yourself the operational quarter and ship on a platform that handles the boring parts (build, deploy, networking, observability, scaling) without making you hire a platform team to do it.

If you fit one of those four shapes, K8s is the right answer, and you should pick from the list above based on where your gravity already is.

Happy shipping.

Angelo

Angelo Saraceno is a Solutions Engineer at Railway. Before Railway he was at Citrix, working inside Verizon and Lockheed environments, so he has seen what "enterprise IaaS" looks like after the slides come down. He writes about infrastructure, deployment, and the gap between how cloud is sold and how it runs in practice.

Try Railway →

Application owners and platform engineers have long faced a difficult choice: spend excessively by over-provisioning to guarantee quick startups, or minimize costs but endure slow cold starts.

We are excited to announce a solution to this compromise: Google Kubernetes Engine standby buffers. This builds on the launch of GKE active buffers earlier this year, a native version of the Kubernetes CapacityBuffers API that makes it easy to provision readily available capacity to handle traffic spikes, delivering near-zero startup latency for new pods. However, active buffers still impose a trade-off between performance and cost. New GKE standby buffers help by maintaining a low-cost, suspended capacity buffer for your GKE clusters. With a cost overhead in the low single-digit percent, GKE standby buffers help you achieve near-immediate scheduling for your workloads with negligible cost overhead. This is useful for all kinds of workloads — general-purpose, agentic, and everything in between.

The problem: High costs and latency

Traditionally, autoscaling with standard Kubernetes has been effective but slow. Traffic surges or batch jobs require cluster autoscalers to provision fresh nodes, leaving Pods in a pending state. To circumvent delays, you have to resort to clunky workarounds like lowering your Horizontal Pod Autoscaler (HPA) thresholds or managing so-called balloon pods. These workarounds are expensive: 

• Managing balloon pods is operationally complex, requiring manual configuration and ongoing maintenance of priority classes and resource requests to ensure they function correctly.

• Lowering the HPA threshold adds empty (wasted) space that linearly scales with the size of the node pool.

Both GKE active and standby buffers allow capacity to be defined declaratively, removing the need for clunky and operationally heavy workarounds.

In addition, GKE standby buffers lower infrastructure costs by storing the node’s state to disk, releasing compute and memory costs and keeping only persistent disk and IP address costs. Then, combined with an active buffer, you can achieve near-instant pod scheduling that has similar performance to over-provisioning, but at a very affordable price.

Active and standby buffers working together

All GKE capacity buffers operate on a principle similar to video streaming on platforms like YouTube. By proactively attempting to provision and manage available capacity ahead of impending demand (much like pre-downloading video content) GKE helps to ensure that resources are readily available when they’re needed.

With today’s launch, the two types of capacity buffers can work in harmony:

• Active buffer: Cluster Autoscaler works to reserve enough capacity for a predefined amount of pods on existing cluster nodes, and, if needed, provisions extra nodes. Select this ready-to-use buffer to provide capacity to your most latency-sensitive workloads. 

• Standby buffers: Nodes are pre-provisioned and fully initialized with necessary components like Kubernetes DaemonSets, and given time to preload images, but are then suspended, while the underlying compute capacity is released to save costs. When demand spikes, these nodes resume 2-3x faster than creating a fresh node, bridging the gap between cold starts and always-on capacity.

The active buffer covers the initial spike until standby buffers resume. The system prioritizes refilling the active buffer from the standby buffer. The standby buffer handles an extended load and protects against slower node cold starts. As standby buffers refill, they initially kick into an active state for a configurable amount of time before they are suspended, providing a boost of active capacity during sustained traffic loads.

Early benchmarks

In our tests, using standby buffers enabled us to deliver sub-second Agent Sandbox scheduling latency for up to 90% lower cost compared to complete overprovisioning.

Optimized for business needs

Businesses are under constant pressure to optimize resource consumption while streamlining operations. Recognizing that organizations need smarter tools to manage sporadic and spikey workloads, we worked hard to deliver standby buffers quickly. Now, whether you’re running agents, batch jobs, CI/CD pipelines, game servers, or spiky workloads, GKE capacity buffers allow you to dynamically balance performance and cost. You can finally define your "insurance policy" against traffic spikes without paying a high premium for it. With GKE standby buffers you can:

1. Circumvent cold starts: Nodes suspended by standby buffers resume 2-3x faster than provisioning fresh nodes, reducing pod scheduling latency during traffic spikes and sustained traffic load.

2. Enjoy lower costs: A standby buffer incurs a fraction of the cost of active capacity because the underlying VM is suspended. You pay for storage and an IP address, rather than for full compute-hours.

3. Gain declarative control: Replace complex balloon pod workarounds with the simple, native declarative CapacityBuffers API, explicitly stating how much headroom you need, and letting GKE handle the rest.

Get started

Ready to improve your performance and save on costs?

• Start by defining a CapacityBuffer resource in your cluster to specify your target buffer size.

• Try balancing between standby buffers to reduce pod scheduling latency for sustained loads, and active buffers to address immediate unpredictable capacity needs.

Let’s look at an example of how to configure buffers for a Deployment while also using custom ComputeClasses.

Basic setup

Beginning with some basic setup, create a namespace:

code_block

<ListValue: [StructValue([('code', 'apiVersion: v1\r\nkind: Namespace\r\nmetadata:\r\n name: my-namespace'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f41f817d670>)])]>

Then, create a custom ComputeClass (optional):

code_block

<ListValue: [StructValue([('code', 'apiVersion: cloud.google.com/v1\r\nkind: ComputeClass\r\nmetadata:\r\n name: my-ccc\r\n namespace: my-namespace\r\nspec:\r\n # Buffers will also be created according to these priorities \r\n priorities:\r\n - machineFamily: n4\r\n - machineFamily: n4d\r\n - machineFamily: c4\r\n - machineFamily: c4d\r\n nodePoolAutoCreation:\r\n enabled: true'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f41f845f370>)])]>

Define the buffer unit size

You can use a PodTemplate as a reference for the buffer unit size. You can also create a buffer for a  specific deployment or any object that defines scale subResource.

code_block

<ListValue: [StructValue([('code', '# Defines the resource requirements for one unit of buffer.\r\napiVersion: v1\r\nkind: PodTemplate\r\nmetadata:\r\n name: my-buffer-unit-template\r\n namespace: my-namespace\r\ntemplate:\r\n spec:\r\n terminationGracePeriodSeconds: 0\r\n tolerations:\r\n # Optional: Ensures buffer pods can land on any node.\r\n - key: "node-role.kubernetes.io/master"\r\n operator: "Exists"\r\n effect: "NoSchedule"\r\n containers:\r\n - name: buffer-container\r\n image: registry.k8s.io/pause:3.9\r\n resources:\r\n requests:\r\n cpu: "1"\r\n memory: "1Gi"\r\n limits:\r\n cpu: "1"\r\n memory: "1Gi"\r\n # Optional: Using buffers with a custom ComputeClass / \r\n # controls the properties of the nodes GKE provisions. \r\n nodeSelector:\r\n cloud.google.com/compute-class: my-ccc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f41f845f400>)])]>

Create buffers

Lastly, create a CapacityBuffer object by referring to our PodTemplate. Here, you create a standby buffer of 50 CPUs and 50 GB of RAM:

code_block

<ListValue: [StructValue([('code', 'apiVersion: autoscaling.x-k8s.io/v1beta1\r\nkind: CapacityBuffer\r\nmetadata:\r\n name: my-standby-buffer-resource-limits\r\n namespace: my-namespace\r\n annotations:\r\n # Optional: Time after which buffer nodes are suspended.\r\n # Default is 5 minutes. \r\n buffer.gke.io/standby-capacity-init-time: "5m"\r\n # Optional: Time after which standby buffers are recreated.\r\n # Default is 1 day, "never" avoids refreshing. \r\n buffer.gke.io/standby-capacity-refresh-frequency: "1d"\r\nspec:\r\n podTemplateRef:\r\n name: my-buffer-unit-template\r\n # The desired state is 20 standby buffer units.\r\n # When a standby buffer gets used, a new one gets created.\r\n limits:\r\n cpu: "50"\r\n memory: "50Gi"\r\n provisioningStrategy: "buffer.gke.io/standby-capacity"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f41f845f880>)])]>

And an active buffer of seven 5 CPUs and 5 GB of RAM (optional):

code_block

<ListValue: [StructValue([('code', 'apiVersion: autoscaling.x-k8s.io/v1beta1\r\nkind: CapacityBuffer\r\nmetadata:\r\n name: my-active-buffer-resource-limits\r\n namespace: my-namespace\r\nspec:\r\n podTemplateRef:\r\n name: my-buffer-unit-template\r\n # The desired state is 2 active buffer units.\r\n # When an active buffer gets used, a new one gets created. \r\n limits:\r\n cpu: "5"\r\n memory: "5Gi"\r\n provisioningStrategy: "buffer.x-k8s.io/active-capacity"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f41f845f670>)])]>

Finally, apply the above objects to your cluster. That’s it!

Now, any existing and future deployments that can schedule on the space reserved by the buffers will benefit from faster pod scheduling latencies.

Test the buffers

You can check on the status of your buffers. In Kubernetes, suspended nodes can be identified by condition Suspended.

code_block

<ListValue: [StructValue([('code', 'kubectl get nodes -o custom-columns=\'NAME:.metadata.name,SUSPENDED:.status.conditions[?(@.type=="Suspended")].status\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f41f8177b50>)])]>

Expect the following kind of output, and wait for the standby buffers to get suspended.

code_block

<ListValue: [StructValue([('code', 'NAME SUSPENDED\r\ngke-my-cluster-nap-n4-standard-8-k960-...-ffbx False # Node has been resumed.\r\ngke-my-cluster-nap-n4-standard-4-k960-...-h2x4 <none> # Node was never suspended.\r\ngke-my-cluster-nap-n4d-standard-8-1cip-...-74jf True # Node is suspended.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f41f9cbcd60>)])]>

To test the buffers, create a deployment and scale it.

code_block

<ListValue: [StructValue([('code', 'apiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: my-deployment\r\n namespace: my-namespace\r\nspec:\r\n replicas: 1\r\n selector:\r\n matchLabels:\r\n app: my-deployment\r\n template:\r\n metadata:\r\n labels:\r\n app: my-deployment\r\n spec:\r\n containers:\r\n - name: busybox\r\n image: busybox\r\n command: ["sleep", "inf"]\r\n resources:\r\n requests:\r\n cpu: "500m"\r\n memory: "500Mi"\r\n # Optional: Using buffers with a custom ComputeClass /\r\n # controls the properties of the nodes GKE provisions. \r\n nodeSelector:\r\n cloud.google.com/compute-class: my-ccc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f41f902e160>)])]>

Scaling this deployment to two replicas allows them to be assigned to the active buffer for immediate scheduling. The active buffer is then immediately refilled from the standby buffer. Simultaneously, the standby buffer initiates the provisioning of new nodes.

If you further scale the deployment to 50 replicas, scheduling all of them on the standby buffer occurs once the nodes resume. New nodes provisioned to refill the standby buffer briefly function as active buffers providing a temporary active standby boost. Therefore, when further scaling the deployment to 100 replicas during this time, you may notice that new replicas benefit from immediate scheduling.

GKE standby buffer best practices

When working with GKE standby buffers, here are a few things to consider:

1. Define standby buffers that are sufficient to cover the extended load you expect to encounter, so that buffers can refill in the background from a cold start. A sufficiently sized standby buffer can drop your max pod scheduling latency to the time it takes to resume a node — around 30 seconds.

2. When the buffer starts to get used and is refilled, new buffer nodes initially swing into an active state prior to suspending. This helps to boost active capacity during a prolonged load.

3. If your application requires the lowest possible pod scheduling latency, define an active buffer size that is sufficient to cover any initial spikes you expect to encounter until standby buffer nodes are able to resume. The system prioritizes refilling the active buffer by consuming the standby buffer. A sufficiently sized active buffer and a sufficiently sized standby buffer can help you achieve one-second pod scheduling latency for a fraction of the cost of overprovisioning.

4. Experiment with different buffer sizes to get the best result for your workload.

To help, we created a simulator to help with sizing the buffers to achieve your performance targets, available at https://github.com/gke-labs/buffers-simulator. 

Try it yourself!

Active and standby buffers in GKE provide a native solution for low-latency and cost-effective workload scaling by maintaining warm and standby capacity buffers. By circumventing slow node cold starts, buffers help performance-critical applications handle sudden traffic spikes. This feature replaces complex manual workarounds like balloon pods with a simple, declarative API, and allows for fixed, percentage-based, or resource-limited buffering strategies to help maintain strict service-level objectives cost-effectively and without over-provisioning for peak.

Standby buffers are available for GKE clusters running version 1.36.0-gke.2253000 or later. To get started with buffers, check out the documentation.

As oilprice.com asked earlier this week, why hasn’t oil hit $150 (yet)?

Tonight at 7 PM ET, ZeroHedge will host two former Goldman heavyweights to answer the question: is the recent oil price surge merely a temporary geopolitical shock, or are we entering a period of structurally higher energy prices?

Joining the discussion are former colleagues Jeff Currie, now chief strategy officer for energy pathways at the Carlyle Group, and Arjun Murti, Partner at Veriten. The conversation will be hosted by Real Vision's Ash Bennington.

After five potential deals to re-open the Strait of Hormuz and none resulting in a full resumption of traffic, Currie’s betting that it won’t be different this time:

On @cnbcAsiaTV this morning, @CommodMkt said, "Sell The Tweet, Buy The Molcule." Currie detailed that Trump tweeted five times that the war was effectively over, but it has not happened.

The chart shows my guess of the five times. Currie is correct. If you bought the crude oil… https://t.co/XosPN03Nm4 pic.twitter.com/ipdgaNXYqE

— Jim Bianco (@biancoresearch) May 25, 2026

Interesting highlight by Jim Bianco: “If you bought the crude oil collapse every time Trump said the war is over, you made $58, even though the price is only up $27 since the war started.“

Even if it is different this time, Currie has argued that global oil markets were already facing structural supply shortages before tensions with Iran escalated, with years of underinvestment leaving the system increasingly vulnerable to disruptions. In his view, the current conflict has simply accelerated a trend that was already underway, bringing forward a period of sustained higher oil prices that many investors have yet to fully appreciate.

Strait closure + baked in supply constraints, he says, could mean American storage tanks run dry as soon as July 4… just in time for the big 250 celebration.

"I've never seen anything like it before."

Oil storage tanks in the United States will run empty "somewhere in the July 4 period," Carlyle's Jeff Currie tells @flacqua https://t.co/vHoZcNL6ur pic.twitter.com/06RRdr6LqP

— Bloomberg (@business) May 6, 2026

Murti likewise remains bullish oil. Last October, he joined ZeroHedge for a debate on the price outlook and argued that crude prices were headed higher… a peaceful time when WTI crude sat at $60/barrell. The months that followed validated Murti so let’s see if that happens again.

Together, Currie and Murti will examine whether current oil prices fully reflect the underlying supply picture, how much of today's rally is attributable to Iran, what role U.S. foreign policy may play going forward, and whether investors should prepare for a prolonged period of elevated energy prices.

See you tonight at 7pm ET, here on the ZH homepage, X feed, or YouTube channel.
 

JPMorgan Chase CEO Jamie Dimon has drawn a battle line in Washington: the Clarity Act, as written, is dead on arrival - and Coinbase CEO Brian Armstrong is the enemy driving it.

In a Fox Business interview late last week, Dimon unloaded on the pending crypto market structure legislation, calling it a threat to the financial system and a gift to an industry that wants the privileges of banking without the responsibilities.

“It allows cryptocurrency firms to effectively pay interest on deposits - stablecoins or something like that - without the protection that they should have,” Dimon said.

“It has almost no legal protections.”

Jamie Dimon went on Fox and called Brian Armstrong "full of sh!t" over stablecoins. 😳

Jamie is the GOAT. Love him or loathe him, you absolutely know where he stands.

What stood out to me in the clip was to hear the CEO of America's biggest bank promise to fight, and admit he… pic.twitter.com/Jjbfj7zim9

— Simon Taylor (@sytaylor) May 31, 2026

As Micah Zimmerman reports for BitcoinMagazine.com, Dimon's core argument: if a crypto platform walks like a bank and talks like a bank, it needs to be regulated like one. That means Anti-Money Laundering compliance, Bank Secrecy Act obligations, FDIC insurance, capital requirements, liquidity rules, and the full weight of financial oversight that traditional banks carry. The Clarity Act, in his view, lets crypto firms skip all of it.

The fight over stablecoin rewards sits at the center of the dispute. Banks say allowing crypto exchanges to pay customers for holding stablecoins would accelerate deposit flight from traditional institutions — a ticking clock on the business model that has defined American banking for a century. 

Crypto advocates counter that such incentives are a natural evolution of payments infrastructure. The bill’s markup is approaching, and neither side is backing down.

Dimon also flagged the AML problem with cross-border stablecoin payments.

“The first one may be legitimate,” he said, “the second one may be a sex trafficker.”

Once money lands in a digital wallet overseas, it can move to a third wallet, a fourth — with no visibility and no accountability. That, he said, is the unresolved risk hiding beneath the optimism around stablecoin utility.

Dimon: Coinbase CEO Armstrong is full of sh*t

But Dimon reserved his sharpest words for Armstrong. The Coinbase CEO, he claimed, is spending hundreds of millions of dollars in Washington to push the legislation through.

“No one is going to bow down to this guy,” Dimon said, calling Armstrong “full of sh*t.” 

It was not the first time — Dimon made similar remarks at the World Economic Forum in Davos earlier this year.

JPMorgan is not alone. The American Bankers Association, community banks, and credit unions are aligned in opposition to the bill’s current form.

Dimon made clear this is a fight — not a negotiation.

“We’ll fight it,” he said. “If we lose, we lose. But it will be fought.”