# GKE Cluster Autoscaler Location Policy: BALANCED vs ANY Explained

> Understand GKE Cluster Autoscaler location policy BALANCED vs ANY. Learn how BALANCED spreads nodes for availability and ANY maximizes capacity acquisition for your workloads.

- Repository: [Google/skills](https://github.com/google/skills)
- Tags: deep-dive
- Published: 2026-08-09

---

**The GKE Cluster Autoscaler location policy controls how newly provisioned nodes are distributed across zones, with `BALANCED` evenly spreading nodes for high availability and `ANY` maximizing capacity acquisition from any available zone.**

The GKE Cluster Autoscaler supports two distinct location policies that determine node distribution behavior during scale-up events. According to the `google/skills` repository documentation, these policies are configured via the `--location-policy` flag in gcloud or the `locationPolicy` field in a ComputeClass specification.

## What Is the GKE Cluster Autoscaler Location Policy?

The **location policy** is a node-level configuration that instructs the Cluster Autoscaler how to select zones when provisioning new nodes. This decision happens at the infrastructure layer and affects only node placement, not pod scheduling.

As documented in [`ca-optimization.md`](https://github.com/google/skills/blob/main/ca-optimization.md), the autoscaler evaluates available capacity across zones and applies the selected policy to determine where new instances are created.

### BALANCED Policy (Default)

The **`BALANCED`** policy directs the autoscaler to **evenly distribute nodes across all available zones** during scale-up operations. When the cluster needs additional capacity, the autoscaler attempts to maintain equilibrium in node counts between zones.

Use this policy for **high-availability (HA) workloads** where zone redundancy is critical. However, note that this node-level balancing does not influence pod placement. Applications requiring zone-distributed pods must implement additional constraints separately.

### ANY Policy

The **`ANY`** policy allows the autoscaler to provision nodes from **any zone that has available resources**, without attempting to maintain balanced node counts across zones. The autoscaler simply selects the zone with the best available capacity at the moment of scaling.

This policy is optimal for **Spot VMs** or scarce machine SKUs where maximizing obtainability and minimizing provisioning latency takes priority over even distribution. As noted in [`ca-optimization.md`](https://github.com/google/skills/blob/main/ca-optimization.md), this prevents the autoscaler from waiting for capacity in under-provisioned zones.

## How to Configure the Location Policy

You can configure the location policy using either the gcloud CLI or declarative YAML configurations via ComputeClass resources.

### Using gcloud CLI

Update an existing cluster to use the balanced policy for even zone distribution:

```bash
gcloud container clusters update CLUSTER_NAME --location-policy=BALANCED

```

Switch to the any policy to optimize for Spot VM acquisition:

```bash
gcloud container clusters update CLUSTER_NAME --location-policy=ANY

```

These commands modify the cluster's autoscaling configuration immediately, as referenced in [`ca-provisioning.md`](https://github.com/google/skills/blob/main/ca-provisioning.md).

### Using ComputeClass YAML

For workload-specific configurations, define the location policy within a ComputeClass manifest. This approach allows different workloads to use different policies within the same cluster.

```yaml
apiVersion: networking.gke.io/v1
kind: ComputeClass
metadata:
  name: spot-any
spec:
  priorities:
  - machineFamily: n4
    spot: true
    location:
      locationPolicy: ANY

```

In this example from the `google/skills` source, the `ANY` policy combined with `spot: true` ensures the autoscaler aggressively acquires Spot capacity from any available zone.

## Location Policy vs Pod Topology Spread Constraints

A critical distinction exists between the autoscaler's location policy and pod-level spreading. The **location policy controls node distribution**, while **pod distribution requires `topologySpreadConstraints`**.

If your application requires pods to be balanced across zones, you must implement a Pod spec with topology spread constraints:

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: my-app

```

The `whenUnsatisfiable: DoNotSchedule` setting is required for autoscaler compatibility, as documented in [`SKILL.md`](https://github.com/google/skills/blob/main/SKILL.md). Without this configuration, the scheduler may place multiple pods in one zone even when nodes exist in others, rendering the balanced node distribution ineffective for workload resilience.

## Summary

- The **BALANCED** location policy evenly distributes nodes across zones for high-availability architectures, serving as the default behavior.
- The **ANY** location policy provisions nodes from any available zone to maximize capacity acquisition, ideal for Spot VMs and scarce resources.
- Configure policies via `gcloud container clusters update --location-policy` or the `locationPolicy` field in ComputeClass specifications.
- Node-level location policies do not affect pod placement; use `topologySpreadConstraints` with `whenUnsatisfiable: DoNotSchedule` for zone-balanced workloads.
- Reference implementation details in [`ca-optimization.md`](https://github.com/google/skills/blob/main/ca-optimization.md), [`ca-provisioning.md`](https://github.com/google/skills/blob/main/ca-provisioning.md), and [`SKILL.md`](https://github.com/google/skills/blob/main/SKILL.md) within the `google/skills` repository.

## Frequently Asked Questions

### Does the BALANCED location policy guarantee my pods are spread across zones?

No. The **BALANCED** policy only affects node distribution, not pod scheduling. The autoscaler attempts to create an equal number of nodes in each zone, but the Kubernetes scheduler may still place multiple pods on nodes in a single zone. To ensure pod distribution across zones, you must configure `topologySpreadConstraints` in your Pod spec with `topologyKey: topology.kubernetes.io/zone`.

### When should I use the ANY location policy instead of BALANCED?

Use the **ANY** policy when running **Spot VMs** or workloads using scarce machine types where capacity availability varies significantly between zones. This policy minimizes provisioning time by allowing the autoscaler to immediately acquire resources from any zone with available capacity, rather than waiting to maintain balanced node counts. Avoid this policy for strict HA requirements that depend on node distribution symmetry.

### How do I check which location policy my GKE cluster is currently using?

The location policy configuration is visible in your cluster's node pool autoscaling settings. Use the command `gcloud container clusters describe CLUSTER_NAME` and examine the `autoscaling` section. If no policy is explicitly set, the cluster uses **BALANCED** as the default. For ComputeClass-defined policies, inspect the specific ComputeClass resource using `kubectl get computeclass CLASS_NAME -o yaml` to verify the `locationPolicy` value.

### Can different node pools in the same cluster use different location policies?

Yes. Location policies can be configured at the node pool level when using ComputeClass resources. By creating multiple ComputeClass manifests with different `locationPolicy` values and assigning them to specific workloads, you can run a **BALANCED** policy for standard HA workloads in one node pool while using **ANY** for Spot-based preemptible workloads in another. The cluster-level `--location-policy` flag serves as the default for node pools without specific ComputeClass overrides.