A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips below:

Create a VPC-native cluster | GKE networking

Skip to main content Create a VPC-native cluster

Stay organized with collections Save and categorize content based on your preferences.

This page explains how to configure VPC-native clusters in Google Kubernetes Engine (GKE).

To learn more about the benefits and requirements of VPC-native clusters, see the overview for VPC-native clusters.

For GKE Autopilot clusters, VPC-native networks are enabled by default and can't be overridden.

Before you begin

Before you start, make sure that you have performed the following tasks:

Limitations Create a cluster

This section shows you how to complete the following tasks at cluster creation time:

You can also create a cluster and enable auto IP address management in your cluster (Preview), which means that GKE automatically creates subnets and manages IP addresses for you. For more information, see Use auto IP address management.

After you create the cluster, you can modify access to the cluster's control plane. To learn more, see Customize your network isolation in GKE.

Create a cluster and subnet simultaneously

The following directions demonstrate how to create a VPC-native GKE cluster and subnet at the same time. The secondary range assignment method is managed by GKE when you perform these two steps with one command.

If using Shared VPC, you can't simultaneously create the cluster and subnet. Instead, a Network administrators in the Shared VPC host project must create the subnet first. Then you can create the cluster in an existing subnet with a secondary range assignment method of user-managed.

gcloud

To create a VPC-native cluster and subnet simultaneously, run the following command:

gcloud container clusters create CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --enable-ip-alias \
    --create-subnetwork name=SUBNET_NAME,range=NODE_IP_RANGE \
    --cluster-ipv4-cidr=POD_IP_RANGE \
    --services-ipv4-cidr=SERVICES_IP_RANGE

Replace the following:

Console

You can't create a cluster and subnet simultaneously using the Google Cloud console. Instead, first create a subnet then create the cluster in an existing subnet.

API

To create a VPC-native cluster, define an IPAllocationPolicy object in your cluster resource:

{
  "name": CLUSTER_NAME,
  "description": DESCRIPTION,
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "createSubnetwork": true,
    "subnetworkName": SUBNET_NAME
  },
  ...
}

The createSubnetwork field automatically creates and provisions a subnetwork for the cluster. The subnetworkName field is optional; if left empty, a name is automatically chosen for the subnetwork.

After you create the cluster, you can modify access to the cluster's control plane. To learn more, see Customize your network isolation in GKE.

Create a cluster in an existing subnet

The following instructions demonstrate how to create a VPC-native GKE cluster in an existing subnet with your choice of secondary range assignment method.

gcloud

Replace the following:

Console
  1. In the Google Cloud console, go to the Create an Autopilot cluster page.

    Go to Create an Autopilot cluster

    You can also complete this task by creating a Standard cluster.

  2. From the navigation pane, under Cluster, click Networking.
  3. Under Control Plane Access, configure access to the control plane endpoints.
  4. In the Cluster networking section, in the Network drop-down list, select a VPC.
  5. In the Node subnet drop-down list, select a subnet for the cluster.
  6. Ensure the Enable VPC-native traffic routing (uses alias IP) checkbox is selected.
  7. Select the Automatically create secondary ranges checkbox if you want the secondary range assignment method to be managed by GKE. Clear this checkbox if you have already created secondary ranges for the chosen subnet and would like the secondary range assignment method to be user-managed.
  8. In the Pod address range field, enter a Pod range, such as 10.0.0.0/14.
  9. In the Service address range field, enter a service range, such as 10.4.0.0/19.
  10. Configure your cluster.
  11. Click Create.
Terraform

You can create a VPC-native cluster with Terraform using a Terraform module.

For example, you can add the following block to your Terraform configuration:

module "gke" {
  source  = "terraform-google-modules/kubernetes-engine/google"
  version = "~> 12.0"

  project_id        = "PROJECT_ID"
  name              = "CLUSTER_NAME"
  region            = "COMPUTE_LOCATION"
  network           = "NETWORK_NAME"
  subnetwork        = "SUBNET_NAME"
  ip_range_pods     = "SECONDARY_RANGE_PODS"
  ip_range_services = "SECONDARY_RANGE_SERVICES"
}

Replace the following:

API

When you create a VPC-native cluster, you define an IPAllocationPolicy object. You can reference existing subnet secondary IP address ranges or you can specify CIDR blocks. Reference existing subnet secondary IP address ranges to create a cluster whose secondary range assignment method is user-managed. Provide CIDR blocks if you want the range assignment method to be managed by GKE.

{
  "name": CLUSTER_NAME,
  "description": DESCRIPTION,
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "clusterIpv4CidrBlock"      : string,
    "servicesIpv4CidrBlock"     : string,
    "clusterSecondaryRangeName" : string,
    "servicesSecondaryRangeName": string,

  },
  ...
}

This command includes the following values:

After you create the cluster, you can modify access to the cluster's control plane. To learn more, see Customize your network isolation in GKE.

Create a cluster and select the control plane IP address range

By default, clusters in version 1.29 or later use the primary subnet range to provision the internal IP address assigned to the control plane endpoint. You can override this default setting by selecting a different subnet range during the cluster creation time only.

The following sections show you how to create a cluster and override the subnet range.

gcloud 
gcloud container clusters create CLUSTER_NAME \
    --enable-private-nodes \
    --private-endpoint-subnetwork=SUBNET_NAME \
    --location=COMPUTE_LOCATION

Where:

Replace the following:

GKE creates a cluster with Private Service Connect. After you create the cluster, you can modify access to the cluster's control plane. To learn more, see Customize your network isolation in GKE.

Console

To assign a subnet to the control plane of a new cluster, you must add a subnet first. Complete the following steps:

  1. In the Google Cloud console, go to the Create an Autopilot cluster page.

    Go to Create an Autopilot cluster

    You can also complete this task by creating a Standard cluster.

  2. In the Standard or Autopilot section, click Configure.
  3. For the Name, enter your cluster name.
  4. From the navigation pane, under Cluster, click Networking.
  5. Under Control Plane Access, configure access to the control plane endpoints.
  6. In the Cluster networking section, select the Override control plane's default private endpoint subnet checkbox.
  7. In the Private endpoint subnet list, select your created subnet.
  8. Click Done. Add additional authorized networks as needed.
Project metadata for secondary IP address ranges

When you create or upgrade a GKE cluster, GKE automatically adds project-level metadata entries like google_compute_project_metadata to track secondary IP address range usage, including in Shared VPC environments. This metadata verifies that GKE correctly allocates IP addresses for Pods and Services, which helps prevent conflicts.

GKE automatically manages this metadata.

Warning: Don't manually modify or remove this metadata, because it might cause issues with the IP address allocation and disrupt the operation of your GKE cluster. Note: If you use Infrastructure as Code (IaC) tools, such as Terraform, you must configure your IaC tool to ignore these metadata entries to prevent configuration drift.

The metadata has the following format:

key:   gke-REGION-CLUSTER_NAME-GKE_UID-secondary-ranges
value: pods:SHARED_VPC_NETWORK:SHARED_VPC_SUBNETWORK:CLUSTER_PODS_SECONDARY_RANGE_NAME

where:

Note: The VPC_NETWORK and VPC_SUBNETWORK variables refer to the network and subnetwork used by the cluster, which could be a Shared VPC host network or the cluster's own VPC network. Create a cluster with dual-stack networking

You can create a cluster with IPv4/IPv6 dual-stack networking on a new or existing dual-stack subnet. Dual-stack subnet is available in Autopilot clusters version 1.25 or later, and Standard clusters version 1.24 or later. Dual-stack subnet is not supported with Windows Server node pools.

Note: You can configure your cluster to have nodes with internal (private) or external (public) access by using the enable-private-nodes flag. The enable-private-nodes flag only affects the IPv4 address of the nodes in your cluster. Therefore, this flag doesn't affect the configuration of the IPv4/IPv6 dual-stack networking that you define in this section.

Before setting up dual-stack clusters, we recommend that you complete the following actions:

In this section, you create a dual-stack subnet first and use this subnet to create a cluster.

  1. To create a dual-stack subnet, run the following command:

    gcloud compute networks subnets create SUBNET_NAME \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --network=NETWORK_NAME \
    --range=PRIMARY_RANGE \
    --region=COMPUTE_REGION

    Replace the following:

  2. To create a cluster with a dual-stack subnet, either use the gcloud CLI or the Google Cloud console:

gcloud Console
  1. In the Google Cloud console, go to the Create an Autopilot cluster page.

    Go to Create an Autopilot cluster

    You can also complete this task by creating a Standard cluster.

  2. In the Standard or Autopilot section, click Configure.
  3. Configure your cluster as needed.
  4. From the navigation pane, under Cluster, click Networking.
  5. Under Control Plane Access, configure access to the control plane endpoints.
  6. In the Cluster networking section, in the Network list, select the name of your network.
  7. In the Node subnet list, select the name of your dual-stack subnet.

  8. For Standard clusters, select the IPv4 and IPv6 (dual stack) radio button. This option is available only if you selected a dual-stack subnet.

    Autopilot clusters default to a dual-stack cluster when you use a dual-stack subnet.

  9. Click Create.

Create a dual-stack cluster and a subnet simultaneously

You can create a subnet and a dual-stack cluster simultaneously. GKE creates an IPv6 subnet and assigns an external IPv6 primary range to the subnet.

If using Shared VPC, you can't simultaneously create the cluster and subnet. Instead, a Network Admin in the Shared VPC host project must create the dual-stack subnet first.

Update the stack type

You can change the stack type of an existing cluster or a update an existing subnet to a dual-stack subnet.

Update the stack type on an existing cluster

Before you change the stack type on an existing cluster, consider the following limitations:

To update an existing VPC-native cluster, you can use gcloud CLI or the Google Cloud console:

gcloud

Run the following command:

  gcloud container clusters update CLUSTER_NAME \
      --stack-type=STACK_TYPE \
      --location=COMPUTE_LOCATION

Replace the following:

Console

  1. Go to the Google Kubernetes Engine page in the Google Cloud console.

    Go to Google Kubernetes Engine

  2. Next to the cluster you want to edit, click more_vert Actions, then click edit Edit.

  3. In the Networking section, next to Stack type, click edit Edit.

  4. In the Edit stack type dialog, select the checkbox for the cluster stack type you need.

  5. Click Save Changes.

Update an existing subnet to a dual-stack subnet (available in Autopilot clusters version 1.25 or later, and Standard clusters version 1.24 or later).

Update an existing subnet to a dual-stack subnet

To update an existing subnet to a dual-stack subnet, run the following command. Updating a subnet does not affect any existing IPv4 clusters in the subnet.

gcloud compute networks subnets update SUBNET_NAME \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --region=COMPUTE_REGION

Replace the following:

Verify the stack type, Pod, and Service IP address ranges

After you create a VPC-native cluster, you can verify its Pod and Service ranges.

gcloud

To verify the cluster, run the following command:

gcloud container clusters describe CLUSTER_NAME

The output has an ipAllocationPolicy block. The stackType field describes the type of network definition. For each type, you can see the following network information:

Console

To verify the cluster, perform the following steps:

  1. Go to the Google Kubernetes Engine page in the Google Cloud console.

    Go to Google Kubernetes Engine

  2. In the cluster list, click the name of the cluster you want to inspect.

The secondary ranges are displayed in the Networking section:

Delete your cluster

To delete your cluster, follow the steps in Deleting a cluster.

GKE tries to clean up the created subnetwork when the cluster is deleted. But if the subnetwork is being used by other resources, GKE does not delete the subnetwork, and you must manage the life of the subnetwork yourself.

Advanced configuration for internal IP addresses

The following sections show how to use non-RFC 1918 private IP address ranges and how to enable privately used public IP address ranges.

Use non-RFC 1918 IP address ranges

GKE clusters can use IP address ranges outside of the RFC 1918 ranges for nodes, Pods, and Services. See valid ranges in the VPC network documentation for a list of non-RFC 1918 private ranges that can be used as internal IP addresses for subnet ranges.

This feature is not supported with Windows Server node pools.

Non-RFC 1918 private ranges are subnet ranges — you can use them exclusively or in conjunction with RFC 1918 subnet ranges. Nodes, Pods, and Services continue to use subnet ranges as described in IP ranges for VPC-native clusters. If you use non-RFC 1918 ranges, keep the following in mind:

Destinations outside your cluster might have difficulties receiving traffic from private, non-RFC 1918 ranges. For example, RFC 1112 (class E) private ranges are typically used as multicast addresses. If a destination outside of your cluster can't process packets whose sources are private IP addresses outside of the RFC 1918 range, you can do the following:

Enable privately used external IP address ranges

GKE clusters can privately use certain external IP address ranges as internal, subnet IP address ranges. You can privately use any external IP address except for certain restricted ranges as described the VPC network documentation. This feature is not supported with Windows Server node pools.

Your cluster must be a VPC-native cluster in order to use privately used external IP address ranges. Routes-based clusters are not supported.

Privately used external ranges are subnet ranges. You can use them exclusively or in conjunction with other subnet ranges that use private addresses. Nodes, Pods, and Services continue to use subnet ranges as described in IP ranges for VPC-native clusters. Keep the following in mind when re-using external IP addresses privately:

GKE by default implements SNAT on the nodes to external IP destinations. If you have configured the Pod CIDR to use external IP addresses, the SNAT rules apply to Pod-to-Pod traffic. To avoid this you have 2 options:

For Standard clusters, if the cluster version is 1.14 or later, both options will work. If your cluster version is earlier than 1.14, you can only use the second option (configuring ip-masq-agent).

What's next

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-08-07 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[],[]]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4