This page gives you a high-level comparison between Google Kubernetes Engine (GKE) Autopilot clusters and Standard clusters. The comparison includes important GKE features and the functional differences between these cluster modes.
This page is intended for the following people:
- Platform administrators who want to know the major differences between Autopilot and Standard clusters, so that you can make an informed choice when you create a cluster.
- New GKE users who are familiar with GKE and want to know which cluster mode offers the most suitable functionality for a specific requirement.
Feature comparison of Autopilot and Standard clusters
The following table provides a detailed comparison of the feature configuration in Autopilot and Standard clusters. Either you or GKE define these feature configurations for the entire cluster.
The table doesn't show every feature in GKE. If you want to know whether a feature that isn't in this table is supported in Autopilot or in Standard, check the documentation for that feature.
This table uses the following terminology:
- Pre-configured: always enabled. Google configures these settings. You can't change or disable pre-configured features.
- Default: GKE configures the feature for you if you don't explicitly configure the feature. You can change default feature configurations.
- Optional: available for you to configure and use. Not enabled by default.
Versions and releases
Default : Regular release channel
Optional :
Default : Regular release channel
Optional :
Node management
Optional :
- You create and manage nodes in node pools.
Node provisioning and scaling
Pre-configured : Autopilot automatically scales the quantity and size of nodes based on Pods in the cluster.
Optional :
- Horizontal Pod autoscaling .
- Vertical Pod autoscaling : enabled in the cluster, but GKE doesn't configure any Pod autoscaling parameters by default.
Default :
- Manually provision new nodes
- Manually specify node resources
Optional :
- Node auto-provisioning
- Cluster autoscaler
- Horizontal Pod autoscaling
- Vertical Pod autoscaling
Node operating system
Default : Container-Optimized OS with containerd
Optional :
Node compute configuration
Default : Container-optimized compute platform that's recommended for general-purpose workloads.
Optional :
- Built-in compute classes for Autopilot clusters . These built-in classes are recommended for workloads that have specific needs, such as Arm architecture .
- Custom compute classes for specific node configurations when autoscaling.
- Hardware accelerators ( GPUs and TPUs ).
- Local SSDs
Default : General-purpose Compute Engine machine types
Optional :
- Compute classes:
- Custom compute classes to set specific node configurations when autoscaling
- Choice of specific Compute Engine machines and hardware , such as Arm architecture , for node pools
- Hardware accelerators ( GPUs and TPUs )
- Local SSDs
Node upgrades and maintenance
Pre-configured :
Optional :
Security
Pre-configured :
Optional :
Networking
Pre-configured :
Default :
- Public IPv4 cluster endpoint
- Default CIDR ranges for Pods
- VPC network name and subnet name
- Google-managed IP Range for Services
- NIC type:
- Google Virtual NIC (gVNIC) : For nodes with version 1.30.2-gke.1023000 or later
- GKE Dataplane V2 enabled
- Kubernetes network policy using GKE Dataplane V2
Optional :
Pre-configured : Maximum 256 Pods in each node
Default :
- 110 Pods in each node
- VPC-native
- Public IPv4 cluster endpoint
- VPC network name and subnet name
- kube-dns
Optional :
Logging and monitoring
Pre-configured :
- System-level logs
- Workload-level logs
- System-level monitoring
- Google Cloud Managed Service for Prometheus
Optional :
Add-ons
Pre-configured :
- HTTP load balancing
- Compute Engine persistent disk CSI Driver
- Filestore CSI Driver
- Cloud Storage FUSE CSI Driver
- NodeLocal DNSCache
- Image streaming
Optional : Managed Cloud Service Mesh , which also provides Istio mesh capabilities.
Functional differences between Autopilot and Standard clusters
The following table shows you important functional differences between GKE Autopilot and Standard clusters. Use this comparison to make a more informed choice of mode.
| Functionality | Autopilot clusters | Standard clusters |
|---|---|---|
|
Third-party monitoring tools
|
Deploy a third-party monitoring tool provided by Google Cloud partners , or any third-party tool that doesn't require elevated access on the node. | Deploy any third-party monitoring tool regardless of the level of node access. |
|
Expose applications externally
|
Use a LoadBalancer
Service
. This provisions an ephemeral external IP address for you.
If you already have a static IP address that you want to use, specify it in the loadBalancerIP
field. Autopilot doesn't support the externalIps
field,
which doesn't use Google Cloud load balancing. |
Use a LoadBalancer
Service
. This provisions an ephemeral external IP address for you.
If you already have a static IP address that you want to use, specify it in the loadBalancerIP
field. You can also use the externalIps
field in the Service
manifest, although we don't recommend this approach. |
|
Pod bursting
|
Pods can burst into unused burstable capacity if your resource limits are greater than your resource requests, or if you don't set resource limits. The burstable capacity depends on whether the Pod requests specific hardware. For more information, see Configure Pod bursting in GKE . |
Pods can burst into unused node capacity if your resource limits are greater than your resource requests. |
|
Google Cloud Marketplace applications
|
You can't install apps from Cloud Marketplace . | You can install apps from Cloud Marketplace . |
|
Built-in security constraints
|
In Autopilot mode, GKE enforces the GKE Autopilot security measures . | GKE does automatically enforce security constraints for Standard clusters. |
|
Long-running fault-intolerant Pods
|
You can protect fault-intolerant Pods such as game servers from eviction caused by node auto-upgrades or scale-downs for up to 7 days. For details, see Extend the run time of Autopilot Pods . | You can't protect fault-intolerant Pods from eviction caused by node auto-upgrades. You can protect those Pods from scale-down eviction indefinitely, but you continue to pay for the underutilized nodes on which the Pods run. |
