This page gives you a high-level comparison between Google Kubernetes Engine (GKE) Autopilot mode and Standard mode. The comparison includes important GKE features and the functional differences between the modes.
This page is intended for the following people:
- Platform administrators who are familiar with GKE and Standard mode, and want to find out the feature and functional differences in Autopilot to make an informed migration decision.
- New GKE users who are familiar with GKE and want to know which mode offers the most suitable functionality for a specific requirement.
Autopilot and Standard feature comparison
The following table provides a detailed comparison of options that are available, pre-configured, and default in each Google Kubernetes Engine (GKE) mode of operation.
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 settings. You can't change settings or disable.
- Default: Configured for you if you don't specify differently. You can change the default settings.
- Optional: Available for you to configure and use. Not enabled by default.
Versions and releases
Node management
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
Pre-configured: Container-Optimized OS with containerd
Default: Container-Optimized OS with containerd
Optional:
Node compute configuration
Default: General-purpose platform that is optimized for most workloads.
Optional:
- Predefined compute classes for workloads that have specific needs, such as Arm architecture .
- Custom compute classes for specific node configurations when autoscaling
- Hardware accelerators (GPUs)
Default: General-purpose Compute Engine machine types
Optional:
- Choose specific Compute Engine machines and hardware , such as Arm architecture , for node pools
- Hardware accelerators (GPUs)
- Local SSDs
- Custom compute classes for specific node configurations when autoscaling
Node upgrades and maintenance
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
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:
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.
Autopilot and Standard functional comparison
The following table shows you important functional differences between GKE Autopilot and Standard. Use this comparison to make a more informed choice of mode when you create a GKE cluster.
Functionality | Autopilot | Standard |
---|---|---|
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 have an available 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 is the sum of Pod resource requests on the node. To learn more, see Configure Pod bursting in GKE . |
Pods can burst into unused node capacity if your resource limits are greater than your resource requests. |
GKE-managed namespaces
|
As a security measure, Autopilot doesn't allow deploying
workloads in GKE-managed namespaces, such as To learn more, see Autopilot security capabilities . |
Workloads can run in any namespace, including kube-system
|
Google Cloud Marketplace applications
|
You can't install apps from Cloud Marketplace . | You can install apps from Cloud Marketplace . |
Certificate signing requests
|
You can create certificate signing requests. To prevent interference with system components, Autopilot rejects CertificateSigningRequests for known privileged identities such as system agents, system groups, or Google-managed IAM service agents. | You can create certificate signing requests. |
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. |