Provisioning Compute Resources

Kubernetes requires a set of machines to host the Kubernetes control plane and the worker nodes where containers are ultimately run. In this lab you will provision the compute resources required for running a secure and highly available Kubernetes cluster across a single compute zone.

Ensure a default compute zone and region have been set as described in the Prerequisites lab.

Networking

The Kubernetes networking model assumes a flat network in which containers and nodes can communicate with each other. In cases where this is not desired network policies can limit how groups of containers are allowed to communicate with each other and external network endpoints.

Setting up network policies is out of scope for this tutorial.

Virtual Private Cloud Network

In this section a dedicated Virtual Private Cloud (VPC) network will be setup to host the Kubernetes cluster.

Create the kubernetes-the-hard-way custom VPC network:

  1. gcloud compute networks create kubernetes-the-hard-way --mode custom

A subnet must be provisioned with an IP address range large enough to assign a private IP address to each node in the Kubernetes cluster.

Create the kubernetes subnet in the kubernetes-the-hard-way VPC network:

  1. gcloud compute networks subnets create kubernetes \
  2.   --network kubernetes-the-hard-way \
  3.   --range 10.240.0.0/24

The 10.240.0.0/24 IP address range can host up to 254 compute instances.

Firewall Rules

Create a firewall rule that allows internal communication across all protocols:

  1. gcloud compute firewall-rules create kubernetes-the-hard-way-allow-internal \
  2.   --allow tcp,udp,icmp \
  3.   --network kubernetes-the-hard-way \
  4.   --source-ranges 10.240.0.0/24,10.200.0.0/16

Create a firewall rule that allows external SSH, ICMP, and HTTPS:

  1. gcloud compute firewall-rules create kubernetes-the-hard-way-allow-external \
  2.   --allow tcp:22,tcp:6443,icmp \
  3.   --network kubernetes-the-hard-way \
  4.   --source-ranges 0.0.0.0/0

Create a firewall rule that allows health check probes from the GCP network load balancer IP ranges:

  1. gcloud compute firewall-rules create kubernetes-the-hard-way-allow-health-checks \
  2.   --allow tcp:8080 \
  3.   --network kubernetes-the-hard-way \
  4.   --source-ranges 209.85.204.0/22,209.85.152.0/22,35.191.0.0/16

An external load balancer will be used to expose the Kubernetes API Servers to remote clients.

List the firewall rules in the kubernetes-the-hard-way VPC network:

  1. gcloud compute firewall-rules list --filter "network kubernetes-the-hard-way"

output

  1. NAME                                         NETWORK                  DIRECTION  PRIORITY  ALLOW                 DENY
  2. kubernetes-the-hard-way-allow-external       kubernetes-the-hard-way  INGRESS    1000      tcp:22,tcp:6443,icmp
  3. kubernetes-the-hard-way-allow-health-checks  kubernetes-the-hard-way  INGRESS    1000      tcp:8080
  4. kubernetes-the-hard-way-allow-internal       kubernetes-the-hard-way  INGRESS    1000      tcp,udp,icmp

Kubernetes Public IP Address

Allocate a static IP address that will be attached to the external load balancer fronting the Kubernetes API Servers:

  1. gcloud compute addresses create kubernetes-the-hard-way \
  2.   --region $(gcloud config get-value compute/region)

Verify the kubernetes-the-hard-way static IP address was created in your default compute region:

  1. gcloud compute addresses list --filter="name=('kubernetes-the-hard-way')"

output

  1. NAME                     REGION    ADDRESS        STATUS
  2. kubernetes-the-hard-way  us-west1  XX.XXX.XXX.XX  RESERVED

Compute Instances

The compute instances in this lab will be provisioned using Ubuntu Server 16.04, which has good support for the CRI-O container runtime. Each compute instance will be provisioned with a fixed private IP address to simplify the Kubernetes bootstrapping process.

Kubernetes Controllers

Create three compute instances which will host the Kubernetes control plane:

  1. for i in 0 1 2; do
  2.   gcloud compute instances create controller-${i} \
  3.     --async \
  4.     --boot-disk-size 200GB \
  5.     --can-ip-forward \
  6.     --image-family ubuntu-1604-lts \
  7.     --image-project ubuntu-os-cloud \
  8.     --machine-type n1-standard-1 \
  9.     --private-network-ip 10.240.0.1${i} \
  10.     --scopes compute-rw,storage-ro,service-management,service-control,logging-write,monitoring \
  11.     --subnet kubernetes \
  12.     --tags kubernetes-the-hard-way,controller
  13. done

Kubernetes Workers

Each worker instance requires a pod subnet allocation from the Kubernetes cluster CIDR range. The pod subnet allocation will be used to configure container networking in a later exercise. The pod-cidr instance metadata will be used to expose pod subnet allocations to compute instances at runtime.

The Kubernetes cluster CIDR range is defined by the Controller Manager’s --cluster-cidr flag. In this tutorial the cluster CIDR range will be set to 10.200.0.0/16, which supports 254 subnets.

Create three compute instances which will host the Kubernetes worker nodes:

  1. for i in 0 1 2; do
  2.   gcloud compute instances create worker-${i} \
  3.     --async \
  4.     --boot-disk-size 200GB \
  5.     --can-ip-forward \
  6.     --image-family ubuntu-1604-lts \
  7.     --image-project ubuntu-os-cloud \
  8.     --machine-type n1-standard-1 \
  9.     --metadata pod-cidr=10.200.${i}.0/24 \
  10.     --private-network-ip 10.240.0.2${i} \
  11.     --scopes compute-rw,storage-ro,service-management,service-control,logging-write,monitoring \
  12.     --subnet kubernetes \
  13.     --tags kubernetes-the-hard-way,worker
  14.  done

Verification

List the compute instances in your default compute zone:

  1. gcloud compute instances list

output

  1. NAME          ZONE        MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP     STATUS
  2. controller-0  us-west1-c  n1-standard-1               10.240.0.10  XX.XXX.XXX.XXX  RUNNING
  3. controller-1  us-west1-c  n1-standard-1               10.240.0.11  XX.XXX.X.XX     RUNNING
  4. controller-2  us-west1-c  n1-standard-1               10.240.0.12  XX.XXX.XXX.XX   RUNNING
  5. worker-0      us-west1-c  n1-standard-1               10.240.0.20  XXX.XXX.XXX.XX  RUNNING
  6. worker-1      us-west1-c  n1-standard-1               10.240.0.21  XX.XXX.XX.XXX   RUNNING
  7. worker-2      us-west1-c  n1-standard-1               10.240.0.22  XXX.XXX.XX.XX   RUNNING

Next: Provisioning a CA and Generating TLS Certificates