GCP GKE Autopilot Cluster

GKE is a managed Kubernetes service in GCP that implements the full Kubernetes API, 4-way autoscaling, release channels and multi-cluster support.

View Source Code


Made by







GCP GKE Autopilot Cluster is a fully managed service for deploying containers on Kubernetes, providing an automated experience for cluster management. Autopilot abstracts away most of the underlying infrastructure and focuses on the application workloads, making it easier for developers to deploy and manage their applications in a cost-efficient way.

Use Cases

Autopilot is ideal for small to medium-sized applications with predictable resource needs. It’s best suited for the following use cases:

Web Applications

Autopilot is an excellent choice for serving web applications that require scalability and high availability.


Autopilot is an efficient solution for building microservices that can increase overall resiliency by isolating failure domains.


Use services like Kubeflow and Argo Workflows for machine-learning capabilities.

Cloud Agnostic

If your application can run on Kubernetes, you can run it on any cluster, whether it is Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS), Microsoft Azure Kubernetes Service (AKS), or even your own on-premises cluster.


GCP GKE Autopilot clusters offer a more cost-efficient way to run your workloads. You only pay for the resources you use, and there are no upfront costs or minimum fees. With Autopilot, you can save up to 20% on the total cost of running a cluster.

Configuration Presets

Autopilot provides two presets for cluster configuration:


The development preset creates a GKE Autopilot cluster with a single node pool and optimized for cost-effectiveness.


The production preset creates a GKE Autopilot cluster with multiple node pools optimized for workload isolation and resource allocation.


GCP GKE Autopilot clusters come with several features that make them easier to manage:

Automated Management

Autopilot automates much of the cluster management process, reducing the need for manual configuration and optimization.


Autopilot automatically scales the cluster based on resource usage and workload demands. It also optimizes resource allocation for individual workloads.

Cluster-Level Management

Autopilot manages the entire cluster, including the control plane, node pool management, and other cluster-level operations.

Best Practices

Core Services

Enable nginx-ingress, cert-manager and external-dns at the click of a button, allowing you to run secure, web accessible workloads without a second thought.


Autopilot provides several security features to keep your workloads secure:

Node Hardening

Autopilot hardens the nodes in your cluster to prevent unauthorized access and reduce the risk of vulnerabilities.

Node Auto-upgrades

Autopilot automatically upgrades your nodes to the latest version of Kubernetes to protect your workloads from security vulnerabilities.

Cluster Auto-upgrades

Autopilot automatically upgrades the control plane and other cluster-level components to ensure the latest security patches and updates are applied.


After you have deployed a Kubernetes cluster through Massdriver, you may want to interact with the cluster using the powerful kubectl command line tool.

Install Kubectl

You will first need to install kubectl to interact with the kubernetes cluster. Installation instructions for Windows, Mac and Linux can be found here.

Note: While kubectl generally has forwards and backwards compatibility of core capabilities, it is best if your kubectl client version is matched with your kubernetes cluster version. This ensures the best stability and compability for your client.

The standard way to manage connection and authentication details for kubernetes clusters is through a configuration file called a kubeconfig file.

Download the Kubeconfig File

The standard way to manage connection and authentication details for kubernetes clusters is through a configuration file called a kubeconfig file. The kubernetes-cluster artifact that is created when you make a kubernetes cluster in Massdriver contains the basic information needed to create a kubeconfig file. Because of this, Massdriver makes it very easy for you to download a kubeconfig file that will allow you to use kubectl to query and administer your cluster.

To download a kubeconfig file for your cluster, navigate to the project and target where the kubernetes cluster is deployed and move the mouse so it hovers over the artifact connection port. This will pop a windows that allows you to download the artifact in raw JSON, or as a kubeconfig yaml. Select “Kube Config” from the drop down, and click the button. This will download the kubeconfig for the kubernetes cluster to your local system.

Download Kubeconfig

Use the Kubeconfig File

Once the kubeconfig file is downloaded, you can move it to your desired location. By default, kubectl will look for a file named config located in the $HOME/.kube directory. If you would like this to be your default configuration, you can rename and move the file to $HOME/.kube/config.

A single kubeconfig file can hold multiple cluster configurations, and you can select your desired cluster through the use of contexts. Alternatively, you can have multiple kubeconfig files and select your desired file through the KUBECONFIG environment variable or the --kubeconfig flag in kubectl.

Once you’ve configured your environment properly, you should be able to run kubectl commands. Here are some commands to try:

# get a list of all pods in the current namespace
kubectl get pods

# get a list of all pods in the kube-system namespace
kubectl get pods --namespace kube-system

# get a list of all the namespaces
kubectl get namespaces

# view the logs of a running pod in the default namespace
kubectl logs <pod name> --namespace default

# describe the status of a deployment in the foo namespace
kubectl describe deployment <deployment name> --namespace foo

# get a list of all the resources the kubernetes cluster can manage
kubectl api-resources
cluster_networking.cluster_ipv4_cidr_blockstringCIDR block to use for kubernetes pods. Set to /netmask (e.g. /16) to have a range chosen with a specific netmask. Set to a CIDR notation (e.g. from the RFC-1918 private networks (e.g.,, to pick a specific range to use.
cluster_networking.master_ipv4_cidr_blockstringCIDR block to use for kubernetes control plane. The mask for this must be exactly /28. Must be from the RFC-1918 private networks (e.g.,,, and should not conflict with other ranges in use. It is recommended to use consecutive /28 blocks from the range for all your GKE clusters ( for the first cluster, for the second, etc.).
cluster_networking.services_ipv4_cidr_blockstringCIDR block to use for kubernetes services. Set to /netmask (e.g. /20) to have a range chosen with a specific netmask. Set to a CIDR notation (e.g. from the RFC-1918 private networks (e.g.,, to pick a specific range to use.
core_services.cloud_dns_managed_zones[]array(string)No description
core_services.enable_ingressbooleanEnabling this will create an nginx ingress controller in the cluster, allowing internet traffic to flow into web accessible services within the cluster
k8s_versionstringThe version of Kubernetes to run