Repository files navigation

This module handles opinionated Google Cloud Platform Kubernetes Engine cluster creation and configuration with Node Pools, IP MASQ, Network Policy, etc.The resources/services/activations/deletions that this module will create/trigger are:

• Create a GKE cluster with the provided addons
• Create GKE Node Pool(s) with provided configuration and attach to cluster
• Replace the default kube-dns configmap ifstub_domains are provided
• Activate network policy ifnetwork_policy is true
• Addip-masq-agent configmap with providednon_masquerade_cidrs ifnetwork_policy is true

There are multiple examples included in theexamples folder but simple usage is as follows:

module"gke" {source="terraform-google-modules/kubernetes-engine/google"project_id="<PROJECT ID>"name="gke-test-1"region="us-central1"zones=["us-central1-a","us-central1-b","us-central1-f"]network="vpc-01"subnetwork="us-central1-01"ip_range_pods="us-central1-01-gke-01-pods"ip_range_services="us-central1-01-gke-01-services"http_load_balancing=falsehorizontal_pod_autoscaling=truekubernetes_dashboard=truenetwork_policy=truenode_pools=[    {      name="default-node-pool"      machine_type="n1-standard-2"      min_count=1      max_count=100      disk_size_gb=100      disk_type="pd-standard"      image_type="COS"      auto_repair=true      auto_upgrade=true      service_account="project-service-account@<PROJECT ID>.iam.gserviceaccount.com"      preemptible=false      initial_node_count=80    },  ]node_pools_labels={    all= {}    default-node-pool= {      default-node-pool="true"    }  }node_pools_metadata={    all= {}    default-node-pool= {      node-pool-metadata-custom-value="my-node-pool"    }  }node_pools_taints={    all= []    default-node-pool= [      {        key="default-node-pool"        value="true"        effect="PREFER_NO_SCHEDULE"      },    ]  }node_pools_tags={    all= []    default-node-pool= ["default-node-pool",    ]  }}

Then perform the following commands on the root folder:

• terraform init to get the plugins
• terraform plan to see the infrastructure plan
• terraform apply to apply the infrastructure build
• terraform destroy to destroy the built infrastructure

Version 1.0.0 of this module introduces a breaking change: adding thedisable-legacy-endpoints metadata field to all node pools. This metadata is required by GKE anddetermines whether the/0.1/ and/v1beta1/ paths are available in the nodes' metadata server. If your applications do not require access to the node's metadata server, you can leave the default value oftrue provided by the module. If your applications require access to the metadata server, be sure to read the linked documentation to see if you need to set the value for this field tofalse to allow your applications access to the above metadata server paths.

In either case, upgrading to module versionv1.0.0 will trigger a recreation of all node pools in the cluster.

Before this module can be used on a project, you must ensure that the following pre-requisites are fulfilled:

1. Terraform and kubectl areinstalled on the machine where Terraform is executed.
2. The Service Account you execute the module with has the rightpermissions.
3. The Compute Engine and Kubernetes Engine APIs areactive on the project you will launch the cluster in.
4. If you are using a Shared VPC, the APIs must also be activated on the Shared VPC host project and your service account needs the proper permissions there.

Theproject factory can be used to provision projects with the correct APIs active and the necessary Shared VPC connections.

• kubectl 1.9.x

• Terraform 0.11.x
• terraform-provider-google v2.0.0

In order to execute this module you must have a Service Account with thefollowing project roles:

• roles/compute.viewer
• roles/container.clusterAdmin
• roles/container.developer
• roles/iam.serviceAccountAdmin
• roles/iam.serviceAccountUser
• roles/resourcemanager.projectIamAdmin (only required ifservice_account is set tocreate)

In order to operate with the Service Account you must activate the following APIs on the project where the Service Account was created:

• Compute Engine API - compute.googleapis.com
• Kubernetes Engine API - container.googleapis.com

The project has the following folders and files:

• /: root folder
• /examples: examples for using this module
• /helpers: Helper scripts
• /scripts: Scripts for specific tasks on module (see Infrastructure section on this file)
• /test: Folders with files for testing the module (see Testing section on this file)
• /main.tf: main file for this module, contains all the resources to create
• /variables.tf: all the variables for the module
• /output.tf: the outputs of the module
• /readme.MD: this file

To more cleanly handle cases where desired functionality would require complex duplication of Terraform resources (i.e.PR 51), this repository is largely generated from theautogen directory.

The root module is generated by runningmake generate. Changes to this repository should be made in theautogen directory where appropriate.

• bundler
• gcloud
• terraform-docs 0.3.0

Run

make generate_docs

Integration tests are run thoughtest-kitchen,kitchen-terraform, andInSpec.

Six test-kitchen instances are defined:

• deploy-service
• node-pool
• shared-vpc
• simple-regional
• simple-zonal
• stub-domains

The test-kitchen instances intest/fixtures/ wrap identically-named examples in theexamples/ directory.

1. Configure thetest fixtures
2. Download a Service Account key with the necessary permissions and put it in the module's root directory with the namecredentials.json.
   • Requires thepermissions to run the module
   • Requiresroles/compute.networkAdmin to create the test suite's networks
   • Requiresroles/resourcemanager.projectIamAdmin since service account creation is tested
3. Build the Docker container for testing:

make docker_build_kitchen_terraform

4. Run the testing container in interactive mode:

make docker_run

The module root directory will be loaded into the Docker container at/cft/workdir/.5. Run kitchen-terraform to test the infrastructure:

1. kitchen create creates Terraform state and downloads modules, if applicable.
2. kitchen converge creates the underlying resources. Runkitchen converge <INSTANCE_NAME> to create resources for a specific test case.
3. Runkitchen converge again. This is necessary due to an oddity in hownetworkPolicyConfig is handled by the upstream API. (See#72 for details).
4. kitchen verify tests the created infrastructure. Runkitchen verify <INSTANCE_NAME> to run a specific test case.
5. kitchen destroy tears down the underlying resources created bykitchen converge. Runkitchen destroy <INSTANCE_NAME> to tear down resources for a specific test case.

Alternatively, you can simply runmake test_integration_docker to run all the test steps non-interactively.

If you wish to parallelize running the test suites, it is also possible to offload the work onto Concourse to run each test suite for you using the commandmake test_integration_concourse. The.concourse directory will be created and contain all of the logs from the running test suites.

When running tests locally, you will need to use your own test project environment. You can configure your environment by setting all of the following variables:

export COMPUTE_ENGINE_SERVICE_ACCOUNT="<EXISTING_SERVICE_ACCOUNT>"export PROJECT_ID="<PROJECT_TO_USE>"export REGION="<REGION_TO_USE>"export ZONES='["<LIST_OF_ZONES_TO_USE>"]'export SERVICE_ACCOUNT_JSON="$(cat "<PATH_TO_SERVICE_ACCOUNT_JSON>")"export CLOUDSDK_AUTH_CREDENTIAL_FILE_OVERRIDE="<PATH_TO_SERVICE_ACCOUNT_JSON>"export GOOGLE_APPLICATION_CREDENTIALS="<PATH_TO_SERVICE_ACCOUNT_JSON>"

Each test-kitchen instance is configured with avariables.tfvars file in the test fixture directory, e.g.test/fixtures/node_pool/terraform.tfvars.For convenience, since all of the variables are project-specific, these files have been symlinked totest/fixtures/shared/terraform.tfvars.Similarly, each test fixture has avariables.tf to define these variables, and anoutputs.tf to facilitate providing necessary information forinspec to locate and query against created resources.

Each test-kitchen instance creates a GCP Network and Subnetwork fixture to house resources, and may create any other necessary fixture data as needed.

Run

make generate_docs

The makefile in this project will lint or sometimes just format any shell,Python, golang, Terraform, or Dockerfiles. The linters will only be run ifthe makefile finds files with the appropriate file extension.

All of the linter checks are in the default make target, so you just have torun

make -s

The -s is for 'silent'. Successful output looks like this

Running shellcheckRunning flake8Running go fmt and go vetRunning terraform validateRunning hadolint on DockerfilesChecking for required filesTesting the validity of the header check..----------------------------------------------------------------------Ran 2 tests in 0.026sOKChecking file headersThe following lines have trailing whitespace

The lintersare as follows:

• Shell - shellcheck. Can be found in homebrew
• Python - flake8. Can be installed with 'pip install flake8'
• Golang - gofmt. gofmt comes with the standard golang installation. golangis a compiled language so there is no standard linter.
• Terraform - terraform has a built-in linter in the 'terraform validate'command.
• Dockerfiles - hadolint. Can be found in homebrew