More GKE Documentation Updates

mmv1/third_party/terraform/website/docs/guides/using_gke_with_terraform.html.markdown

@@ -25,8 +25,7 @@ If the information on this page conflicts with recommendations available on
 
 ## Interacting with Kubernetes
 
-After creating a `google_container_cluster` with Terraform, authentication to
-the cluster are often a challenge. In most cases, you can use `gcloud` to
+After creating a `google_container_cluster` with Terraform, you can use `gcloud` to
 configure cluster access, [generating a `kubeconfig` entry](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#generate_kubeconfig_entry):
 
 ```bash
@@ -41,7 +40,7 @@ desirable.
 ### Using the Kubernetes and Helm Providers
 
 When using the `kubernetes` and `helm` providers,
-[statically defined credentials](https://www.terraform.io/docs/providers/kubernetes/index.html#statically-defined-credentials)
+[statically defined credentials](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs#credentials-config)
 can allow you to connect to clusters defined in the same config or in a remote
 state. You can configure either using configuration such as the following:
 
@@ -55,8 +54,6 @@ data "google_container_cluster" "my_cluster" {
 }
 
 provider "kubernetes" {
-  load_config_file = false
-
   host  = "https://${data.google_container_cluster.my_cluster.endpoint}"
   token = data.google_client_config.provider.access_token
   cluster_ca_certificate = base64decode(
@@ -66,7 +63,7 @@ provider "kubernetes" {
 ```
 
 Alternatively, you can authenticate as another service account on which your
-Terraform runner has been granted the `roles/iam.serviceAccountTokenCreator`
+Terraform user has been granted the `roles/iam.serviceAccountTokenCreator`
 role:
 
 ```hcl
@@ -82,8 +79,6 @@ data "google_container_cluster" "my_cluster" {
 }
 
 provider "kubernetes" {
-  load_config_file = false
-
   host  = "https://${data.google_container_cluster.my_cluster.endpoint}"
   token = data.google_service_account_access_token.my_kubernetes_sa.access_token
   cluster_ca_certificate = base64decode(
@@ -114,29 +109,48 @@ are GKE clusters that use [alias IP ranges](https://cloud.google.com/vpc/docs/al
 VPC-native clusters route traffic between pods using a VPC network, and are able
 to route to other VPCs across network peerings along with [several other benefits](https://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips).
 
-This is in contrast to [routes-based clusters](https://cloud.google.com/kubernetes-engine/docs/how-to/routes-based-cluster),
-which route pod traffic using GCP routes.
 
 In both `gcloud` and the Cloud Console, VPC-native is the default for new
-clusters and increasingly, GKE features such as [Standalone Network Endpoint Groups (NEGs)](https://cloud.google.com/kubernetes-engine/docs/how-to/standalone-neg#pod_readiness)
-have relied on clusters being VPC-native. In Terraform however, the default
+clusters and many managed products such as CloudSQL, Memorystore and others
+require VPC Native Clusters to work properly. In Terraform however, the default
 behaviour is to create a routes-based cluster for backwards compatibility.
 
 It's recommended that you create a VPC-native cluster, done by specifying the
-`ip_allocation_policy` block. Configuration will look like the following:
+`ip_allocation_policy` block or using secondary ranges on existing subnet. Configuration will look like the following:
 
 ```hcl
+resource "google_compute_subnetwork" "custom" {
+  name          = "test-subnetwork"
+  ip_cidr_range = "10.2.0.0/16"
+  region        = "us-central1"
+  network       = google_compute_network.custom.id
+  secondary_ip_range {
+    range_name    = "services-range"
+    ip_cidr_range = "192.168.1.0/24"
+  }
+
+  secondary_ip_range {
+    range_name    = "pod-ranges"
+    ip_cidr_range = "192.168.64.0/22"
+  }
+}
+
+resource "google_compute_network" "custom" {
+  name                    = "test-network"
+  auto_create_subnetworks = false
+}
+
 resource "google_container_cluster" "my_vpc_native_cluster" {
   name               = "my-vpc-native-cluster"
   location           = "us-central1"
   initial_node_count = 1
 
-  network    = "default"
-  subnetwork = "default"
+  network    = google_compute_network.custom.id
+  subnetwork = google_compute_subnetwork.custom.id
 
   ip_allocation_policy {
-    cluster_ipv4_cidr_block  = "/16"
-    services_ipv4_cidr_block = "/22"
+    cluster_secondary_range_name  = "services-range"
+    services_secondary_range_name = google_compute_subnetwork.custom.secondary_ip_range.1.range_name
   }
 
   # other settings...

mmv1/third_party/terraform/website/docs/r/container_cluster.html.markdown

@@ -331,7 +331,6 @@ The `addons_config` block supports:
 * `horizontal_pod_autoscaling` - (Optional) The status of the Horizontal Pod Autoscaling
     addon, which increases or decreases the number of replica pods a replication controller
     has based on the resource usage of the existing pods.
-    It ensures that a Heapster pod is running in the cluster, which is also used by the Cloud Monitoring service.
     It is enabled by default;
     set `disabled = true` to disable.