We can use the Kubernetes Engine dashboard in the GCP console or the gcloud CLI to launched and configure a cluster. Using the console is very straightforward and intuitive. However, using CLI is a more flexible way to make the operation repeatable or to integrate it with your existing pipeline. In this recipe, we'll walk through how to use gcloud to launch and set up a Kubernetes cluster, along with some importants concept in GCP.
In GCP, everything is associated with a project. A GCP project is the basic unit for using GCP services, billing, and permission control. At first, we'll have to create a project from the GCP console https://console.cloud.google.com.
The project ID is globally unique in GCP. After the project is properly created, we'll see there is a unique project number assigned. In the home dashboard, we'll have a clear view of how many resources we've used. We can set permissions, storage, network, billing, and other resources from here. Before we can move forward, we'll need to install gcloud. gcloud is part of Google Cloud SDK. Other than gcloud, which can do most common operations in GCP, Google Cloud SDK also includes other common GCP tools, such as gsutil (to manage Cloud Storage), bq (a command-line tool for BigQuery), and core (Cloud SDK libraries). The tools are available at the Google cloud SDK download page: https://cloud.google.com/sdk/docs/#install_the_latest_cloud_tools_version_cloudsdk_current_version.
After gcloud is installed, run gcloud init to log in to set up your identity with gcloud and create a project named k8s-cookbook-2e. We can use gcloud to manipulate almost all the services in Google Cloud; the major command group is:
gcloud container [builds|clusters|images|node-pools|operations] | $COMMAND $FLAG…
The gcloud container command line set is used to manage our containers and clusters in Google Kuberentes Engine. For launching a cluster, the most important parameters are network settings. Let's spend some time understanding network terminology in GCP here. Just like AWS, GCP has the VPC concept as well. It's a private and safer way to isolate your compute, storage, and cloud resources with the public internet. It can be peered across projects, or established as a VPN with on-premise datacenters to create a hybrid cloud environment:
// create GCP VPC, it might take few minutes.
# gcloud compute networks create k8s-network
Created [https://www.googleapis.com/compute/v1/projects/kubernetes-cookbook/global/networks/k8s-network].
NAME SUBNET_MODE BGP_ROUTING_MODE IPV4_RANGE GATEWAY_IPV4
k8s-network AUTO REGIONAL
Instances on this network will not be reachable until firewall rules are created. As an example, you can allow all internal traffic between instances as well as SSH, RDP, and ICMP by running:
$ gcloud compute firewall-rules create <FIREWALL_NAME> --network k8s-network --allow tcp,udp,icmp --source-ranges <IP_RANGE>
$ gcloud compute firewall-rules create <FIREWALL_NAME> --network k8s-network --allow tcp:22,tcp:3389,icmp
By default, the VPC is created in auto mode, which will create a one subnet per region. We can observe that via the subcommand describe:
// gcloud compute networks describe <VPC name>
# gcloud compute networks describe k8s-network
autoCreateSubnetworks: true
creationTimestamp: '2018-02-25T13:54:28.867-08:00'
id: '1580862590680993403'
kind: compute#network
name: k8s-network
routingConfig:
routingMode: REGIONAL
selfLink: https://www.googleapis.com/compute/v1/projects/kubernetes-cookbook/global/networks/k8s-network
subnetworks:
- https://www.googleapis.com/compute/v1/projects/kubernetes-cookbook/regions/australia-southeast1/subnetworks/k8s-network
- https://www.googleapis.com/compute/v1/projects/kubernetes-cookbook/regions/europe-west4/subnetworks/k8s-network
- https://www.googleapis.com/compute/v1/projects/kubernetes-cookbook/regions/northamerica-northeast1/subnetworks/k8s-network
- https://www.googleapis.com/compute/v1/projects/kubernetes-cookbook/regions/europe-west1/subnetworks/k8s-network
- https://www.googleapis.com/compute/v1/projects/kubernetes-cookbook/regions/southamerica-east1/subnetworks/k8s-network
- https://www.googleapis.com/compute/v1/projects/kubernetes-cookbook/regions/us-central1/subnetworks/k8s-network
- https://www.googleapis.com/compute/v1/projects/kubernetes-cookbook/regions/us-east1/subnetworks/k8s-network
- https://www.googleapis.com/compute/v1/projects/kubernetes-cookbook/regions/asia-east1/subnetworks/k8s-network
- https://www.googleapis.com/compute/v1/projects/kubernetes-cookbook/regions/us-west1/subnetworks/k8s-network
- https://www.googleapis.com/compute/v1/projects/kubernetes-cookbook/regions/europe-west3/subnetworks/k8s-network
- https://www.googleapis.com/compute/v1/projects/kubernetes-cookbook/regions/asia-southeast1/subnetworks/k8s-network
- https://www.googleapis.com/compute/v1/projects/kubernetes-cookbook/regions/us-east4/subnetworks/k8s-network
- https://www.googleapis.com/compute/v1/projects/kubernetes-cookbook/regions/europe-west2/subnetworks/k8s-network
- https://www.googleapis.com/compute/v1/projects/kubernetes-cookbook/regions/asia-northeast1/subnetworks/k8s-network
- https://www.googleapis.com/compute/v1/projects/kubernetes-cookbook/regions/asia-south1/subnetworks/k8s-network
x_gcloud_bgp_routing_mode: REGIONAL
x_gcloud_subnet_mode: AUTO
In GCP, each subnet is across a zone. A zone is an isolated location in a region, which is a similar concept to availability zones in AWS.
Alternatively, you could create a network in custom mode by adding the parameter --subnet-mode=custom, which allows you to define your desired IP range, region, and all the routing rules. For more details, please refer to the previous section.
Auto mode also helps you set up all default routing rules. A route serves to define the destination for certain IP ranges. For example, this route will direct the packet to virtual network 10.158.0.0/20:
There route which is used to direct the packet to the outside world. The next hop of this route is the default internet gateway, similar to the igw in AWS. In GCP, however, you don't need to explicitly create an internet gateway:
Another important concept in a GCP network is firewall rules, used to control the ingress and egress for your instance. In GCP, the association between firewall rules and VM instances is implemented by network tags.
A firewall rule can also be assigned to all instances in the network or a group of instances with a specific service account (ingress only). The service account is the identity of a VM instance in GCP. One or more roles can be assigned to a service account, so it can have access to other GCP resources. This is similar to AWS instance profiles.
One VM instance can have more than one network tags, which implies multiple network routes could be applied. This diagram shows how tags work. In the following diagram, the first firewall rule is applied to VM1 and VM2, and VM2 has two firewall rules associated with it:
In AWS, one or more ingress/egress rules are defined in a Security Group, and one or more Security Groups can be assigned to a EC2 instance. In GCP, on the other hand, one or more firewall rules are defined, which are associated with one or more tags. One or more tags can be assigned to an instance. By mapping network tags, firewall rules can control and limit access in and out of your instances.