v0.10.0

Description

Terraform 1.0 upgrade: We have verified that this repo is compatible with Terraform 1.0.x!

• From this release onward, we will only be running tests with Terraform 1.0.x against this repo, so we recommend updating to 1.0.x soon!
• To give you more time to upgrade, for the time being, all modules will still support Terraform 0.15.1 and above, as that version has several features in it (required_providers with source URLs) that make it more forwards compatible with 1.0.x.
• Once all Gruntwork repos have been upgrade to work with 1.0.x, we will publish a migration guide with a version compatibility table and announce it all via the Gruntwork Newsletter.

Related links

• #127

v0.9.1

Description

• Add Ubuntu image + remove gcloud update from CircleCI config
• Implement Terraform validate test
• Replace gofmt with goimports

Related links

• #124
• #125
• #126

v0.9.0

Modules affected

• gke-cluster
• gke-service-account

Description

• Terraform 0.14 upgrade: We have verified that this repo is compatible with Terraform 0.14.x!
  • From this release onward, we will only be running tests with Terraform 0.14.x against this repo, so we recommend updating to 0.14.x soon!
  • To give you more time to upgrade, for the time being, all modules will still support Terraform 0.12.26 and above, as that version has several features in it (required_providers with source URLs) that make it more forwards compatible with 0.14.x.
  • Once all Gruntwork repos have been upgrade to work with 0.14.x, we will publish a migration guide with a version compatibility table and announce it all via the Gruntwork Newsletter.

Related links

• #122

v0.8.0

Modules affected

• gke-cluster [BACKWARDS INCOMPATIBLE]

Description

This release fixes an issue (see #118) when creating GKE clusters using the gke-cluster module by using var.services_secondary_range_name instead of defaulting to var.cluster_secondary_range_name. It also adds additional options for the vpc-network module to each example in order to support backwards compatibility.

Background

Before March 3, 2021, GCP had no validation check for clusters using the same secondary range for Pods and Services on user-managed Secondary range assignment methods. This causes the cluster to be created with Pods and Services having the same IP address. If this happens, traffic destined to a Service will reach the Pod and the traffic will not work. Since then GCP has added a validation check during cluster creation that prevents this invalid configuration.

In order to prevent issues derived from clusters with Pods and Services having the same IP, you will need to delete your existing cluster if it was created with the same secondary range and recreate the cluster by using a different secondary range IPs for Pods and another different one for Services as soon as possible for your operation.

Migration Guide

With this update, you must set the following variables to their old values if you have already deployed a GKE cluster using one of the examples. Important: Failing to do this will recreate your existing GKE cluster!

• var.public_subnetwork_secondary_range_name
• var.public_services_secondary_range_name
• var.vpc_secondary_cidr_block
• var.public_services_secondary_cidr_block
• var.private_services_secondary_cidr_block
• var.secondary_cidr_subnetwork_spacing
• var.secondary_cidr_subnetwork_width_delta

You can find the values for each of these variables by simply running terraform plan within the respective example's folder. Once you have the values they can be updated in a terraform.tfvars file before running terraform apply:

public_subnetwork_secondary_range_name = "public-cluster-old"
public_services_secondary_range_name   = "gke-example-private-cluster-services-39652167"
vpc_secondary_cidr_block               = "10.4.0.0/20"
public_services_secondary_cidr_block   = "10.114.208.0/20"
private_services_secondary_cidr_block  = "10.4.16.0/20"
secondary_cidr_subnetwork_spacing      = 4
secondary_cidr_subnetwork_width_delta  = 0

This new release will add additional secondary_ip_range resources and also modify the firewall rules.

Note: If these variables weren't specified in the past then GCP may have automatically assigned values.

Special thanks

Special thanks to @brianpham for their contributions!

Related links

• #121

v0.7.0

Modules affected

• gke-cluster

Description

This release enables the Workload Identity Feature. With Workload Identity, you can configure a Kubernetes service account to act as a Google service account.

Special thanks

Special thanks to @lerms and @MeNsaaH for their contributions!

Related links

• #105

v0.6.0

Modules affected

• (none)

Description

• Terraform 0.13 upgrade: We have verified that this repo is compatible with Terraform 0.13.x!
  • From this release onward, we will only be running tests with Terraform 0.13.x against this repo, so we recommend updating to 0.13.x soon!
  • To give you more time to upgrade, for the time being, all modules will still support Terraform 0.12.26 and above, as that version has several features in it (required_providers with source URLs) that make it more forwards compatible with 0.13.x.
  • Once all Gruntwork repos have been upgrade to work with 0.13.x, we will publish a migration guide with a version compatibility table and announce it all via the Gruntwork Newsletter.
• This PR also fixes a problem with the root example where it was deploying a private cluster instead of a public one.

Related links

• #104

v0.5.0

Modules affected

• gke-cluster

Description

This release upgrades the examples and tests to use Helm 3 instead of Helm 2 with Tiller. It also adds support for adding resource labels to GKE clusters and fixes a bug where setting var.enable_network_policy to false was causing the cluster creation to fail.

Special thanks

Special thanks to @autero1, @jsirianni and @ulm0 for their contributions!

Related links

• #88
• #98
• #99

v0.4.3

Modules affected

• gke-cluster

Description

This release adds an optional variable to the gke-cluster module called services_secondary_range_name that allows you to specify the name of the secondary range within the subnetwork for the services to use.

Special thanks

Special thanks to @Eugst for their contribution!

Related links

• #86

v0.4.2

Modules affected

• gke-cluster

Description

This release fixes usage of the enable_legacy_abac where it was not properly being passed through to the GKE cluster.

Special thanks

Special thanks to @vscoder for their contribution!

Related links

• #80

v0.4.1

Modules affected

• gke-cluster

Description

This release adds the ability to enable vertical pod autoscaling on the cluster. Refer to the official documentation for more information.

Special thanks

Special thanks to @jsirianni for their contribution!

Related links

• #84