Deployments
41
Made by
Massdriver
Official
Yes
No
Compliance
Clouds
Tags
gcp-gke-autopilot
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.
Microservices
Autopilot is an efficient solution for building microservices that can increase overall resiliency by isolating failure domains.
Workflows
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.
Pricing
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:
Development
The development preset creates a GKE Autopilot cluster with a single node pool and optimized for cost-effectiveness.
Production
The production preset creates a GKE Autopilot cluster with multiple node pools optimized for workload isolation and resource allocation.
Features
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.
Auto-scaling
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.
Security
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.
Connecting
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.
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
Variable | Type | Description |
---|---|---|
cluster_networking.cluster_ipv4_cidr_block | string | CIDR 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. 10.96.0.0/14) from the RFC-1918 private networks (e.g. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to pick a specific range to use. |
cluster_networking.master_ipv4_cidr_block | string | CIDR 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. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and should not conflict with other ranges in use. It is recommended to use consecutive /28 blocks from the 172.16.0.0/16 range for all your GKE clusters (172.16.0.0/28 for the first cluster, 172.16.0.16/28 for the second, etc.). |
cluster_networking.services_ipv4_cidr_block | string | CIDR 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. 10.96.0.0/14) from the RFC-1918 private networks (e.g. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to pick a specific range to use. |
core_services.cloud_dns_managed_zones[] | array(string) | No description |
core_services.enable_ingress | boolean | Enabling this will create an nginx ingress controller in the cluster, allowing internet traffic to flow into web accessible services within the cluster |
k8s_version | string | The version of Kubernetes to run |