# How to Resolve the GCE Autoscaler Conflict with GKE Node Pools > Resolve GCE Autoscaler conflicts with GKE node pools. Learn how to stop node oscillation and thrashing by disabling the GCE Autoscaler on MIGs backing your GKE clusters. - Repository: [Google/skills](https://github.com/google/skills) - Tags: how-to-guide - Published: 2026-08-09 --- **The GCE Autoscaler conflicts with GKE node pools when both attempt to scale the same Managed Instance Group (MIG), causing aggressive node oscillation and thrashing that can only be resolved by disabling the GCE Autoscaler on MIGs backing GKE clusters.** The GCE Autoscaler conflict with GKE node pools emerges from a fundamental architectural overlap in Google Cloud's infrastructure. According to the `google/skills` repository, this issue arises when two distinct autoscaling mechanisms simultaneously target the same Compute Engine resources. Resolving this conflict requires understanding how each component manages scaling decisions and implementing the documented best practices to ensure stable cluster operations. ## Understanding the Architectural Conflict The **GCE (Google Compute Engine) Autoscaler** and the **GKE (Google Kubernetes Engine) Cluster Autoscaler** are two distinct components that can both attempt to scale the same underlying Compute Engine resources. This creates a direct conflict when both systems operate on identical Managed Instance Groups (MIGs). | Component | What It Manages | Typical Use | |-----------|----------------|-------------| | **GCE Autoscaler** | Managed Instance Groups (MIGs) in Compute Engine | Scales VMs up or down based on CPU, memory, or custom metrics. | | **GKE Cluster Autoscaler** | GKE node pools (which are themselves backed by MIGs) | Adjusts the number of GKE nodes so that pods have enough capacity. | When a MIG that backs a GKE node pool has the GCE Autoscaler **enabled**, both autoscalers act on the same VM instances independently. The GCE Autoscaler modifies VM counts based on infrastructure metrics, while the GKE Cluster Autoscaler simultaneously monitors pod scheduling requirements and adjusts node counts accordingly. ## Symptoms of Dual Autoscaling Because each autoscaler works independently, they can "fight" each other, producing four distinct operational problems: 1. **Aggressive Oscillation** – GCE adds instances while GKE sees excess capacity and tries to delete them, leading to rapid creation and deletion cycles. 2. **Thrashing of Minimum/Maximum Limits** – GKE respects the node-pool `min-nodes`/`max-nodes` settings, but GCE may ignore them, causing violations of the intended floor and ceiling constraints. 3. **Resource Contention** – Conflicting scaling actions generate extra API calls, increase quota consumption, and may stall both autoscalers. 4. **Debugging Noise** – Logs show both "Cluster Autoscaler" and "GCE Autoscaler" events, making it harder to pinpoint the root cause of scaling failures. ## Resolution: Disable GCE Autoscaler on GKE Node Pools The recommended solution is to **disable the GCE Autoscaler on any MIG that backs a GKE node pool**. This ensures that only the GKE Cluster Autoscaler (or Node Auto-Provisioning) controls the lifecycle of those nodes, eliminating the conflict and providing a single source of truth for scaling decisions. According to [`skills/cloud/gke-cluster-autoscaler/SKILL.md`](https://github.com/google/skills/blob/main/skills/cloud/gke-cluster-autoscaler/SKILL.md) at line 40, the guidance explicitly states: > "GCE Autoscaler Conflict: Disable GCE Autoscaler on Managed Instance Groups (MIGs) used by GKE node pools to prevent aggressive node oscillation and thrashing." To disable the GCE Autoscaler on the MIG backing your GKE node pool, execute the following command: ```bash # Replace and with your managed instance group name and zone gcloud compute instance-groups managed update \ --zone \ --no-autoscaling ``` ## Configuring GKE Cluster Autoscaler After disabling the GCE Autoscaler, enable the GKE Cluster Autoscaler on your node pool to handle scaling automatically based on pod demands: ```bash # Replace , , and size limits as needed gcloud container node-pools update \ --cluster \ --enable-autoscaling \ --min-nodes 1 \ --max-nodes 10 ``` This configuration ensures the GKE Cluster Autoscaler respects your defined `min-nodes` and `max-nodes` boundaries without interference from the GCE Autoscaler. ## Verification and Monitoring Verify that the MIG no longer has autoscaling enabled to confirm the conflict is resolved: ```bash gcloud compute instance-groups managed describe \ --zone \ --format="value(autoscaling)" ``` The output should be empty or display "None", indicating that GCE Autoscaler is disabled. To monitor scaling events and confirm that only the GKE Cluster Autoscaler is acting on your nodes, use the visibility logging script provided in the repository: ```bash # Tail visibility logs for your cluster ./assets/log-autoscaler-events.sh ``` For diagnosing scaling blockers after disabling the GCE Autoscaler, reference the [`find-scale-down-blockers.sh`](https://github.com/google/skills/blob/main/find-scale-down-blockers.sh) utility located at [`skills/cloud/gke-cluster-autoscaler/assets/find-scale-down-blockers.sh`](https://github.com/google/skills/blob/main/skills/cloud/gke-cluster-autoscaler/assets/find-scale-down-blockers.sh). ## Key Source Files The following files in the `google/skills` repository provide authoritative guidance on this conflict: - **[`skills/cloud/gke-cluster-autoscaler/SKILL.md`](https://github.com/google/skills/blob/main/skills/cloud/gke-cluster-autoscaler/SKILL.md)** – Contains the "GCE Autoscaler Conflict" rule and detailed best-practice guidance for preventing node pool instability. - **[`skills/cloud/gke-cluster-autoscaler/assets/find-scale-down-blockers.sh`](https://github.com/google/skills/blob/main/skills/cloud/gke-cluster-autoscaler/assets/find-scale-down-blockers.sh)** – Script referenced for diagnosing scaling blockers, useful after disabling the GCE Autoscaler to ensure proper GKE Autoscaler operation. - **[`skills/cloud/gke-cluster-autoscaler/assets/log-autoscaler-events.sh`](https://github.com/google/skills/blob/main/skills/cloud/gke-cluster-autoscaler/assets/log-autoscaler-events.sh)** – Utility to view Cluster Autoscaler visibility logs, helping confirm that only GKE Autoscaler is managing node lifecycle. ## Summary - **Never enable both autoscalers** on the same MIG, as the GCE Autoscaler and GKE Cluster Autoscaler operate independently and create conflicting scaling directives. - **Disable GCE Autoscaler** on all MIGs backing GKE node pools using the `--no-autoscaling` flag to eliminate aggressive node oscillation. - **Rely solely on GKE Cluster Autoscaler** (or Node Auto-Provisioning) for scaling decisions, ensuring it respects your node pool's `min-nodes` and `max-nodes` constraints. - **Monitor with repository scripts** like [`log-autoscaler-events.sh`](https://github.com/google/skills/blob/main/log-autoscaler-events.sh) to verify that only the intended autoscaler is active and diagnose any remaining blockers with [`find-scale-down-blockers.sh`](https://github.com/google/skills/blob/main/find-scale-down-blockers.sh). ## Frequently Asked Questions ### What happens if I accidentally enable both GCE Autoscaler and GKE Cluster Autoscaler on the same node pool? You will experience aggressive oscillation where VMs are rapidly created and deleted as each autoscaler responds to different metrics. The GCE Autoscaler scales based on CPU or memory utilization, while the GKE Cluster Autoscaler scales based on pod scheduling requirements, causing them to work against each other and potentially violate your intended node count limits. ### How do I identify which MIG backs my GKE node pool? Run `gcloud container node-pools describe --cluster --zone ` and look for the `instanceGroupUrls` field. This URL contains the MIG name that you must check with `gcloud compute instance-groups managed describe` to verify whether GCE Autoscaler is enabled. ### Can I use GCE Autoscaler for some instance groups and GKE Cluster Autoscaler for others in the same project? Yes, but only if the MIGs are strictly separated. You may use GCE Autoscaler for standalone Compute Engine MIGs that are not associated with GKE clusters, while using GKE Cluster Autoscaler exclusively for MIGs that serve as node pools. Never enable both on the same MIG. ### Why does GKE Cluster Autoscaler not respect the GCE Autoscaler settings? The two autoscalers are independent systems with different control planes. The GKE Cluster Autoscaler manages node pools through the Kubernetes API and respects `min-nodes`/`max-nodes` settings defined in GKE, while the GCE Autoscaler manages MIGs directly through the Compute Engine API and knows nothing about Kubernetes pod scheduling requirements or GKE constraints.