- HA 3-zone Deployments with PodSpreadTopology on AutopilotPodSpreadTopology is a way to get Kubernetes to spread out your pods across a failure domain, typically nodes or zones. Kubernetes platforms typically have some default spread built in, although it may not be as aggressive as you want (meaning, it might be more tolerant of imbalanced spread). Here’s an example Deployment with a PodSpreadToplogy… Continue reading HA 3-zone Deployments with PodSpreadTopology on Autopilot
- SSD Ephemeral Storage on AutopilotDo you need to provision a whole bunch of ephemeral storage to your Autopilot Pods? For example, as part of a data processing pipeline? In the past with Kubernetes, you might have used emptyDir as a way to allocate a bunch of storage (taken from the node’s boot disk) to your containers. This however requires… Continue reading SSD Ephemeral Storage on Autopilot
- TensorFlow on GKE Autopilot with GPU accelerationLast week, GKE announced GPU support for Autopilot. Here’s a fun way to try it out: a TensorFlow-enabled Jupyter Notebook with GPU-acceleration! We can even add state, so you can save your work between sessions. Autopilot makes all this really, really easy, as you can configure everything as a Kubernetes object. Setup First, create a… Continue reading TensorFlow on GKE Autopilot with GPU acceleration
- Migrating an IP-based service in GKELet’s say you want to migrate a service in GKE from one cluster to another (including between Standard and Autopilot clusters), and keep the same external IP while you do. DNS might be the ideal way to update your service address, for whatever reason you need to keep the IP the same. Fortunately, it is… Continue reading Migrating an IP-based service in GKE
- Running GKE Autopilot at ScaleIf you like what you see with Autopilot (now the recommended way to use GKE), and want to run it at scale, there are a few things to know when setting up the cluster, and scaling your workload. Cluster Creation To run a large Autopilot cluster, it’s advisable to do two things: 1) create the… Continue reading Running GKE Autopilot at Scale
- Provisioning Capacity in GKE AutopilotI previously documented how to add spare capacity to an Autopilot Kubernetes cluster, whereby you create a balloon Deployment to provision some scheduling headroom. This works to constantly give you a certain amount of headroom, so for example if you have a 2vCPU balloon Deployment, and use that capacity it will get rescheduled. A useful… Continue reading Provisioning Capacity in GKE Autopilot
- Kubernetes for Developers: Reader DiscountReaders of my blog can score a special 35% discount for my book Kubernetes for Developers! Simply enter this code at checkout: au35den
- High-Performance Compute on AutopilotThis week, Autopilot announced support for the Scale-Out Compute Class, for both x86 and Arm architectures. The point of this compute class is to give you cores for better single-threaded performance, and improved price/performance for “scale-out” workloads — basically for when you are saturating the CPU, and/or need faster single-threaded performance (e.g. remote compilation, etc).… Continue reading High-Performance Compute on Autopilot
- Building Arm Images with Cloud BuildThis week’s big news in Google Cloud was the addition to Arm across a wide range of products, including GCE VMs, and GKE (both Standard and Autopilot). In an earlier post, I covered how to get an Arm-ready Autopilot cluster on day 1. The recommended way to build images for Arm is with buildx. This… Continue reading Building Arm Images with Cloud Build
- Arm on AutopilotArm was made available in Preview on Google Cloud, and GKE Autopilot today! As this is an early stage Preview, there’s a few details to pay attention to if you want to try it out, like the version, regions and quota. I put together this quickstart for trying out Arm in Autopilot today. Arm nodes… Continue reading Arm on Autopilot
- Minimizing Pod Disruption on AutopilotThere are 3 common reasons why a Pod may be terminated on Autopilot: node upgrades, a cluster scale-down, and a node repair. PDBs and graceful termination periods modify the disruption to pods when these events happen, and maintenance windows and exclusions control when upgrade events can occur. Upgrade gracefulTerminationPeriod: limited to one hourPDB: is respected… Continue reading Minimizing Pod Disruption on Autopilot
- Building GKE AutopilotLast month gave a presentation at KubeCon Europe in Valencia on “Building a Nodeless Kubernetes Platform”. In it, I shared the details about the creation of GKE Autopilot including some key decisions that we made, how the product was implemented, and why I believe that the design leads to an ideal fully managed platform. Autopilot… Continue reading Building GKE Autopilot
- Transferring a Google Fi eSIM on iOSGoogle Fi, despite being originally designed for Android supports iOS, and works really well there. I’ve been using it for years. The only drawback is the lack of 5G, but for international travel I don’t think there is anything better. The Fi eSIM option is useful too, especially since Fi is the line I never… Continue reading Transferring a Google Fi eSIM on iOS
- Preferring Spot in GKE AutopilotSpot Pods are a great way to save money on Autopilot, currently 70% off the regular price. The catch is two-fold: Your workload can be disrupted There may not always be spot capacity available For workload disruption, this is simply a judgement call. You should only run workloads that can accept disruption (abrupt termination). If… Continue reading Preferring Spot in GKE Autopilot
- Separating Workloads in AutopilotAutopilot while being operationally nodeless, still creates nodes for your workloads behind the scenes. Sometimes it may be desirable as an operator to separate your workloads so that certain workloads are scheduled together. One example I heard recently was a cluster that primarily processes large batch jobs. In addition to these spikey workloads that cause… Continue reading Separating Workloads in Autopilot
- Developing in Rails via DockerOne of the neat things about Docker is that you don’t need to install any dev tools on your local machine. Sometimes though you’ll need to run commands in the dev environment without your app being built (say if there is an error building the app, or you want to run a command like rails… Continue reading Developing in Rails via Docker
- Kubernetes Nodes and AutopilotOne of the key design decisions of GKE Autopilot is the fact that we kept the same semantic meaning of the Kubernetes node object. It’s “nodeless” in the sense that you don’t need to care about, or plan for nodes—they are provisioned and managed automatically based on your PodSpec. However, the node object still exists… Continue reading Kubernetes Nodes and Autopilot
- Testing Knative on GKE AutopilotAhmet’s blog Did we market Knative wrong? got me interested to try out Knative again. I’ll confess that I found the original Istio requirement a bit of a heavy one just to run serverless, and it looked like the project has matured a lot since the early days. Version 1.0.0 was also just released, so… Continue reading Testing Knative on GKE Autopilot
- Install kn on Cloud ShellWant to run the Knative CLI tool kn in Google Cloud’s Cloud Shell? It’s easy: Download the latest release from github. linux-amd64 is the platform you want for CloudShell. Here I download version 1.0.0: Then, move it into place, and add it to your PATH:
- Understanding Kubernetes Node Resource AllocationThe question often comes up: where do my node resources go in Kubernetes? In this post, I share how to use kubectl describe node to look at resource usage by different categories (system, user, etc). The way I think about Kubernetes node resource usage is to assign resource allocations into 4 categories: OS and Kubernetes… Continue reading Understanding Kubernetes Node Resource Allocation
- Creating an Autopilot cluster at a specific versionSometimes you may wish to create or update a GKE Autopilot cluster with a specific version. For example, the big news this week is that mutating webhooks are supported in Autopilot (from version 1.21.3-gke.900). Rather than waiting for your desired version to be the default in your cluster’s release channel, you can update ahead of… Continue reading Creating an Autopilot cluster at a specific version
- Choosing the right network size for AutopilotOne of the most important decisions you can make for your Autopilot cluster is selecting the right network size. Too small and you’ll constraint your potential growth. Too large and you might run out of IPs if you have a lot of cluster. You can’t change the Pod address size after creation, so it’s important… Continue reading Choosing the right network size for Autopilot
- Using GKE Autopilot in specific zonesGKE Autopilot is deployed using the regional cluster architecture. This has a number of advantages such as giving you 3 master nodes for high availability of the control plane, and the ability to spread pods among zones for high availability of your workloads. But sometimes this may be more than what you need. If you’re… Continue reading Using GKE Autopilot in specific zones
- GKE Autopilot: how to know if Pending pods will be scheduledGKE Autopilot is pretty magical. You create a cluster just by picking a region and giving it a name, schedule Kubernetes workloads and the compute resources are provisioned automatically. While Kubernetes is provisioning resources, your Pods will be in the Pending state. This is all well and good, except… there are other reasons that your… Continue reading GKE Autopilot: how to know if Pending pods will be scheduled
- Configuring phpMyAdmin with CloudSQL, RDS, and DockerI still have a place in my heart for phpMyAdmin, that tool that I was introduced when developing PHP on my shared hosting provider many moons ago. It’s just a great way to inspect your MariaDB/MySQL databases. These days I don’t install any web applications (or databases) on my local machine, I use Docker for… Continue reading Configuring phpMyAdmin with CloudSQL, RDS, and Docker
- Adding spare capacity to GKE Autopilot with balloon podsAutopilot is a new mode of operation for Google Kubernetes Engine (GKE) where compute capacity is dynamically provisioned based on your pod’s requirements. Among other innovations, it essentially functions as a fully automatic cluster autoscaler. When you deploy a new pod in this environment, sometimes they’ll be existing spare capacity on the cluster and it… Continue reading Adding spare capacity to GKE Autopilot with balloon pods