Creating and maintaining a GKE cluster

Once you have a workload suitable and ready to deploy to GKE, you need a place to deploy it. As with most things GCP, you have a choice whether to perform the cluster creation via APIs or the portal. When repeatability, testability, and automation are a concern, you should always go with scripting your configuration and executing actions via GCP APIs or the CLI. When working in a prototyping or R&D environment, it's totally acceptable to perform actions, such as GKE cluster creation, using the portal since you are likely to be tweaking the settings.

When creating a GKE cluster, the bulk of the configuration is centered around the machine type supporting your cluster, the number of nodes, and what zones or regions the cluster will be deployed to. For instance, this is a three-node cluster deployed to the us-east-1b zone running on n1-standard-1 machine:

gcloud container clusters create my-gke-cluster --zone us-east-1b --machine-type n1-standard-1

There are also many configuration settings for managing a cluster's logging, monitoring, resiliency, and scalability.

Much of a cluster's configuration is immutable, meaning that those settings cannot be changed after the cluster is created without deleting the cluster and recreating it with a different configuration.

The high-level constructs that make up a GKE cluster include:

• Container clusters, which are deployable units that can be created, scheduled, and managed. They are a logical collection of containers that belong to an application.  Each cluster is meant to run a single application.
• Nodes, which are workers that run tasks as delegated by the master. Nodes can run one or more container clusters. Each provides an application-specific virtual host in a containerized environment.
• Cluster master is the central control point that provides a unified view of the cluster. There is a single master node that controls multiple nodes.