Editing article

Title

Summary

<div class="block-paragraph_advanced"><p><span><span style="vertical-align: baseline;">Autopilot mode for Google Kubernetes Engine (GKE) is our fully managed, Pod-based Kubernetes platform. It provides category-defining features with a fully functional Kubernetes API that supports StatefulSet with block storage, GPUs, and other critical functionality that you don’t often find in nodeless/serverless-style Kubernetes offerings, while still offering a Pod-level SLA and a developer-friendly workload-based API.</span></span></p>
<p><span style="vertical-align: baseline;">But until now, Autopilot, like other products in this category, did not offer the ability to temporarily burst CPU and memory resources beyond what was requested by the workload. I’m happy to announce that now, powered by the unique design of GKE Autopilot on Google Cloud, we are able to </span><strong style="vertical-align: baseline;">bring burstable workload support to GKE Autopilot</strong><span style="vertical-align: baseline;">.</span></p>
<p><span style="vertical-align: baseline;">Bursting allows your Pod to temporarily utilize resources outside of those resources that it requests and is billed for. How does this work, and how can Autopilot offer burstable support, given the Pod-based model? The key is that in Autopilot mode we still group Pods together on Nodes. This is what powers several unique features of Autopilot such as our flexible Pod sizes. With this change, the capacity of your Pods is pooled, and Pods that set a limit higher than their requests can temporarily burst into this capacity (if it’s available).</span></p>
<p><span style="vertical-align: baseline;">With the introduction of burstable support, we’re also introducing another groundbreaking change: 50m CPU Pods — that is, Pods as small as 1/20th of a vCPU. Until now, the smallest Pod we offered was ¼ of a vCPU (250m CPU) — five times bigger. Combined with burst, the door is now open to run high-density-yet-small workloads on Autopilot, without constraining each Pod to its resource requests.</span></p>
<p><span style="vertical-align: baseline;">We’re also dropping the 250m CPU resource increment, so you can create any size of Pod you like between the minimum to the maximum size, for example, 59m CPU, 302m, 808m, 7682m etc (the memory to CPU ratio is automatically kept within a supported range, sizing up if needed). With these finer-grained increments, </span><a href="https://cloud.google.com/kubernetes-engine/docs/how-to/vertical-pod-autoscaling#update-requests-automatically"><span style="text-decoration: underline; vertical-align: baseline;">Vertical Pod Autoscaling</span></a><span style="vertical-align: baseline;"> now works even better, helping you tune your workload sizes automatically. If you want to add a little more automation to figuring out the right resource requirements, give Vertical Pod Autoscaling a try!</span></p>
<p><span style="vertical-align: baseline;">Here’s what our customer Ubie had to say:</span></p></div>
<div class="block-paragraph_with_image"><div class="article-module h-c-page">
  <div class="h-c-grid uni-paragraph-wrap">
    <div class="uni-paragraph
      h-c-grid__col h-c-grid__col--8 h-c-grid__col-m--6 h-c-grid__col-l--6
      h-c-grid__col--offset-2 h-c-grid__col-m--offset-3 h-c-grid__col-l--offset-3">

<p data-block-key="r7pag"><i>“GKE Autopilot frees us from managing infrastructure so we can focus on developing and deploying our applications. It eliminates the challenges of node optimization, a critical benefit in our fast-paced startup environment. Autopilot's new bursting feature and lowered CPU minimums offer cost optimization and support multi-container architectures such as sidecars. We were already running many workloads in Autopilot mode, and with these new features, we're excited to migrate our remaining clusters to Autopilot mode.”</i> - Jun Sakata, Head of Platform Engineering, Ubie</p><h3 data-block-key="61u6q"><b>A new home for high-density workloads</b></h3><p data-block-key="fejfj">Autopilot is now a great place to run high-density workloads. Let’s say for example you have a multi-tenant architecture with many smaller replicas of a Pod, each running a website that receives relatively little traffic, but has the occasional spike. Combining the new burstable feature and the lower 50m CPU minimum, you can now deploy thousands of these Pods in a cost-effective manner (up to 20 per vCPU), while enabling burst so that when that traffic spike comes in, that Pod can temporarily burst into the pooled capacity of these replicas.</p><p data-block-key="7c899">What’s even better is that you don’t need to concern yourself with bin-packing these workloads, or the problem where you may have a large node that’s underutilized (for example, a 32 core node running a single 50m CPU Pod). Autopilot takes care of all of that for you, so you can focus on what’s key to your business: building great services.</p><h3 data-block-key="f527a"><b>Calling all startups, students, and solopreneurs</b></h3><p data-block-key="9i45k">Everyone needs to start somewhere, and if Autopilot wasn’t the perfect home for your workload before, we think it is now. With the 50m CPU minimum size, you can run individual containers in us-central1 for under $2/month each (50m CPU, 50MiB). And thanks to burst, these containers can use a little extra CPU when traffic spikes, so they’re not completely constrained to that low size. And if this workload isn’t mission-critical, you can even run it in Spot mode, where the price is even lower.</p><p data-block-key="9s5rl">In fact, thanks to GKE’s free tier, your costs in us-central1 can be as low as $30/month for small workloads (including production-grade load balancing) while tapping into the same world-class infrastructure that powers some of the biggest sites on the internet today. Importantly, if your startup grows, you can scale in-place without needing to migrate — since you’re already running on a production-grade Kubernetes cluster. So you can start small, while being confident that there is nothing limiting about your operating environment. We’re counting on your success as well, so good luck!</p><p data-block-key="3fdkq">And if you’re learning GKE or Kubernetes, this is a great platform to learn on. Nothing beats learning on real production systems — after all, that’s what you’ll be using on the job. With one free cluster per account, and all these new features, Autopilot is a fantastic learning environment. Plus, if you delete your Kubernetes workload and networking resources when you’re done for the day, any associated costs cease as well. When you’re ready to resume, just create those resources again, and you’re back at it. You can even persist state between learning sessions by deleting just the compute resources (and keeping the persistent disks). Don’t forget there’s a <a href="https://cloud.google.com/free">$300 free trial</a> to cover your initial usage as well!</p><p data-block-key="2jnjr">Next steps:</p><ul><li data-block-key="56tbe">Learn about <a href="https://cloud.google.com/kubernetes-engine/docs/how-to/pod-bursting-gke">Pod bursting</a> in GKE.</li><li data-block-key="ccsjj">Read more about the <a href="https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-resource-requests#min-max-requests">minimum and maximum resource requests</a> in Autopilot mode.</li><li data-block-key="8snsm">Learn how to set <a href="https://cloud.google.com/kubernetes-engine/docs/how-to/vertical-pod-autoscaling#update-requests-automatically">resource requirements automatically</a> with VPA.</li><li data-block-key="bkqbn">Try GKE’s <a href="https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview">Autopilot mode</a> for a workload-based API and simpler Day 2 ops with lower TCO.</li><li data-block-key="e7upl">Going to Next ‘24? Check out session <a href="https://cloud.withgoogle.com/next/session-library?session=DEV224">DEV224</a> to hear Ubie talk about how it uses burstable workloads in GKE.</li></ul>
    </div>
  </div>
</div>

</div>

Content

Author

Link

Published date

Image url

Feed url

Guid

Hidden blurb

--- !ruby/object:Feedjira::Parser::RSSEntry
entry_id: !ruby/object:Feedjira::Parser::GloballyUniqueIdentifier
  guid: https://cloud.google.com/blog/products/containers-kubernetes/introducing-gke-autopilot-burstable-workloads/
categories:
- GKE
- Containers & Kubernetes
title: GKE Autopilot mode gets burstable workloads and smaller Pod sizes
summary: "<div class=\"block-paragraph_advanced\"><p><span><span style=\"vertical-align:
  baseline;\">Autopilot mode for Google Kubernetes Engine (GKE) is our fully managed,
  Pod-based Kubernetes platform. It provides category-defining features with a fully
  functional Kubernetes API that supports StatefulSet with block storage, GPUs, and
  other critical functionality that you don’t often find in nodeless/serverless-style
  Kubernetes offerings, while still offering a Pod-level SLA and a developer-friendly
  workload-based API.</span></span></p>\n<p><span style=\"vertical-align: baseline;\">But
  until now, Autopilot, like other products in this category, did not offer the ability
  to temporarily burst CPU and memory resources beyond what was requested by the workload.
  I’m happy to announce that now, powered by the unique design of GKE Autopilot on
  Google Cloud, we are able to </span><strong style=\"vertical-align: baseline;\">bring
  burstable workload support to GKE Autopilot</strong><span style=\"vertical-align:
  baseline;\">.</span></p>\n<p><span style=\"vertical-align: baseline;\">Bursting
  allows your Pod to temporarily utilize resources outside of those resources that
  it requests and is billed for. How does this work, and how can Autopilot offer burstable
  support, given the Pod-based model? The key is that in Autopilot mode we still group
  Pods together on Nodes. This is what powers several unique features of Autopilot
  such as our flexible Pod sizes. With this change, the capacity of your Pods is pooled,
  and Pods that set a limit higher than their requests can temporarily burst into
  this capacity (if it’s available).</span></p>\n<p><span style=\"vertical-align:
  baseline;\">With the introduction of burstable support, we’re also introducing another
  groundbreaking change: 50m CPU Pods — that is, Pods as small as 1/20th of a vCPU.
  Until now, the smallest Pod we offered was ¼ of a vCPU (250m CPU) — five times bigger.
  Combined with burst, the door is now open to run high-density-yet-small workloads
  on Autopilot, without constraining each Pod to its resource requests.</span></p>\n<p><span
  style=\"vertical-align: baseline;\">We’re also dropping the 250m CPU resource increment,
  so you can create any size of Pod you like between the minimum to the maximum size,
  for example, 59m CPU, 302m, 808m, 7682m etc (the memory to CPU ratio is automatically
  kept within a supported range, sizing up if needed). With these finer-grained increments,
  </span><a href=\"https://cloud.google.com/kubernetes-engine/docs/how-to/vertical-pod-autoscaling#update-requests-automatically\"><span
  style=\"text-decoration: underline; vertical-align: baseline;\">Vertical Pod Autoscaling</span></a><span
  style=\"vertical-align: baseline;\"> now works even better, helping you tune your
  workload sizes automatically. If you want to add a little more automation to figuring
  out the right resource requirements, give Vertical Pod Autoscaling a try!</span></p>\n<p><span
  style=\"vertical-align: baseline;\">Here’s what our customer Ubie had to say:</span></p></div>\n<div
  class=\"block-paragraph_with_image\"><div class=\"article-module h-c-page\">\n  <div
  class=\"h-c-grid uni-paragraph-wrap\">\n    <div class=\"uni-paragraph\n      h-c-grid__col
  h-c-grid__col--8 h-c-grid__col-m--6 h-c-grid__col-l--6\n      h-c-grid__col--offset-2
  h-c-grid__col-m--offset-3 h-c-grid__col-l--offset-3\">\n\n      \n\n\n\n\n\n\n  \n\n
  \   <figure class=\"article-image--wrap-small\n      \n      \"\n      >\n\n      \n
  \     \n        \n        <img\n            src=\"https://storage.googleapis.com/gweb-cloudblog-publish/images/ubie.max-1000x1000.jpg\"\n
  \       \n          alt=\"ubie\">\n        \n        </a>\n      \n    </figure>\n\n
  \ \n\n\n\n\n\n      <p data-block-key=\"r7pag\"><i>“GKE Autopilot frees us from
  managing infrastructure so we can focus on developing and deploying our applications.
  It eliminates the challenges of node optimization, a critical benefit in our fast-paced
  startup environment. Autopilot's new bursting feature and lowered CPU minimums offer
  cost optimization and support multi-container architectures such as sidecars. We
  were already running many workloads in Autopilot mode, and with these new features,
  we're excited to migrate our remaining clusters to Autopilot mode.”</i> - Jun Sakata,
  Head of Platform Engineering, Ubie</p><h3 data-block-key=\"61u6q\"><b>A new home
  for high-density workloads</b></h3><p data-block-key=\"fejfj\">Autopilot is now
  a great place to run high-density workloads. Let’s say for example you have a multi-tenant
  architecture with many smaller replicas of a Pod, each running a website that receives
  relatively little traffic, but has the occasional spike. Combining the new burstable
  feature and the lower 50m CPU minimum, you can now deploy thousands of these Pods
  in a cost-effective manner (up to 20 per vCPU), while enabling burst so that when
  that traffic spike comes in, that Pod can temporarily burst into the pooled capacity
  of these replicas.</p><p data-block-key=\"7c899\">What’s even better is that you
  don’t need to concern yourself with bin-packing these workloads, or the problem
  where you may have a large node that’s underutilized (for example, a 32 core node
  running a single 50m CPU Pod). Autopilot takes care of all of that for you, so you
  can focus on what’s key to your business: building great services.</p><h3 data-block-key=\"f527a\"><b>Calling
  all startups, students, and solopreneurs</b></h3><p data-block-key=\"9i45k\">Everyone
  needs to start somewhere, and if Autopilot wasn’t the perfect home for your workload
  before, we think it is now. With the 50m CPU minimum size, you can run individual
  containers in us-central1 for under $2/month each (50m CPU, 50MiB). And thanks to
  burst, these containers can use a little extra CPU when traffic spikes, so they’re
  not completely constrained to that low size. And if this workload isn’t mission-critical,
  you can even run it in Spot mode, where the price is even lower.</p><p data-block-key=\"9s5rl\">In
  fact, thanks to GKE’s free tier, your costs in us-central1 can be as low as $30/month
  for small workloads (including production-grade load balancing) while tapping into
  the same world-class infrastructure that powers some of the biggest sites on the
  internet today. Importantly, if your startup grows, you can scale in-place without
  needing to migrate — since you’re already running on a production-grade Kubernetes
  cluster. So you can start small, while being confident that there is nothing limiting
  about your operating environment. We’re counting on your success as well, so good
  luck!</p><p data-block-key=\"3fdkq\">And if you’re learning GKE or Kubernetes, this
  is a great platform to learn on. Nothing beats learning on real production systems
  — after all, that’s what you’ll be using on the job. With one free cluster per account,
  and all these new features, Autopilot is a fantastic learning environment. Plus,
  if you delete your Kubernetes workload and networking resources when you’re done
  for the day, any associated costs cease as well. When you’re ready to resume, just
  create those resources again, and you’re back at it. You can even persist state
  between learning sessions by deleting just the compute resources (and keeping the
  persistent disks). Don’t forget there’s a <a href=\"https://cloud.google.com/free\">$300
  free trial</a> to cover your initial usage as well!</p><p data-block-key=\"2jnjr\">Next
  steps:</p><ul><li data-block-key=\"56tbe\">Learn about <a href=\"https://cloud.google.com/kubernetes-engine/docs/how-to/pod-bursting-gke\">Pod
  bursting</a> in GKE.</li><li data-block-key=\"ccsjj\">Read more about the <a href=\"https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-resource-requests#min-max-requests\">minimum
  and maximum resource requests</a> in Autopilot mode.</li><li data-block-key=\"8snsm\">Learn
  how to set <a href=\"https://cloud.google.com/kubernetes-engine/docs/how-to/vertical-pod-autoscaling#update-requests-automatically\">resource
  requirements automatically</a> with VPA.</li><li data-block-key=\"bkqbn\">Try GKE’s
  <a href=\"https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview\">Autopilot
  mode</a> for a workload-based API and simpler Day 2 ops with lower TCO.</li><li
  data-block-key=\"e7upl\">Going to Next ‘24? Check out session <a href=\"https://cloud.withgoogle.com/next/session-library?session=DEV224\">DEV224</a>
  to hear Ubie talk about how it uses burstable workloads in GKE.</li></ul>\n    </div>\n
  \ </div>\n</div>\n\n</div>"
rss_fields:
- title
- summary
- categories
- published
- entry_id
- url
- author
carlessian_info:
  news_filer_version: 2
  newspaper: Google Cloud Blog
  macro_region: Technology
url: https://cloud.google.com/blog/products/containers-kubernetes/introducing-gke-autopilot-burstable-workloads/
author: William Denniss
published: 2024-04-03 16:00:00.000000000 Z

Language

Active

Ricc internal notes

Ricc source

Show this article Back to articles