Skip to content

Latest commit

 

History

History
247 lines (190 loc) · 9.13 KB

03-compute-resources.md

File metadata and controls

247 lines (190 loc) · 9.13 KB

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:

yc vpc network create kubernetes-the-hard-way

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:

yc vpc subnet create kubernetes --zone=ru-central1-a \
    --network-name=kubernetes-the-hard-way \
    --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:

yc vpc security-group create kubernetes-the-hard-way \
--network-name=kubernetes-the-hard-way \
--rule="description=allow-internal,direction=ingress,port=any,protocol=any,predefined=self_security_group"

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

yc vpc security-group update-rules kubernetes-the-hard-way \
--add-rule="description=allow-external-ssh,direction=ingress,port=22,protocol=tcp,v4-cidrs=[0.0.0.0/0]" \
--add-rule="description=allow-external-https,direction=ingress,port=6443,protocol=tcp,v4-cidrs=[0.0.0.0/0]" \
--add-rule="description=allow-external-icmp,direction=ingress,protocol=icmp,v4-cidrs=[0.0.0.0/0]"

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

Allow all output traffic from subnet:

yc vpc security-group update-rules kubernetes-the-hard-way \ --add-rule="description=allow-external,direction=egress,protocol=any,port=any,v4-cidrs=[0.0.0.0/0]"

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

yc vpc security-groups get kubernetes-the-hard-way

output

id: ################
folder_id: ################
created_at: "2024-01-19T15:59:04Z"
name: kubernetes-the-hard-way
network_id: ################
status: ACTIVE
rules:
  - id: ################
    description: allow-internal
    direction: INGRESS
    protocol_name: ANY
    protocol_number: "-1"
    predefined_target: self_security_group
  - id: ################
    description: allow-external-ssh
    direction: INGRESS
    ports:
      from_port: "22"
      to_port: "22"
    protocol_name: TCP
    protocol_number: "6"
    cidr_blocks:
      v4_cidr_blocks:
        - 0.0.0.0/0
  - id: ################
    description: allow-external-https
    direction: INGRESS
    ports:
      from_port: "6443"
      to_port: "6443"
    protocol_name: TCP
    protocol_number: "6"
    cidr_blocks:
      v4_cidr_blocks:
        - 0.0.0.0/0
  - id: ################
    description: allow-external-icmp
    direction: INGRESS
    protocol_name: ICMP
    protocol_number: "1"
    cidr_blocks:
      v4_cidr_blocks:
        - 0.0.0.0/0
  - id: ################
    description: allow-external
    direction: EGRESS
    protocol_name: ANY
    protocol_number: "-1"
    cidr_blocks:
      v4_cidr_blocks:
        - 0.0.0.0/0

Kubernetes Public IP Address

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

yc vpc address create --name kubernetes-the-hard-way --external-ipv4="zone=ru-central1-a"

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

yc vpc address list

output

+----------------------+-------------------------+----------------+----------+-------+
|          ID          |          NAME           |    ADDRESS     | RESERVED | USED  |
+----------------------+-------------------------+----------------+----------+-------+
| #################### | kubernetes-the-hard-way | XXX.XXX.XXX.XXX| true     | false |
+----------------------+-------------------------+----------------+----------+-------+

Compute Instances

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

SSH keys

Generate SSH key to access VMs and copy the path to the public part to the PUBLIC_SSH_KEY_PART variable:

ssh-keygen -t ed25519
PUBLIC_SSH_KEY_PART=$HOME/.ssh/my-key.pb

Kubernetes Controllers

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

SECURITY_GROUP_ID=$(yc vpc security-group get kubernetes-the-hard-way --format=json | jq -r .id)

for i in 0 1 2; do
  yc compute instance create controller-${i} \
    --async \
    --zone=ru-central1-a \
    --create-boot-disk="size=18GB,image-id=fd8m2ak64lipvicd94sf" \
    --network-interface="subnet-name=kubernetes,nat-ip-version=ipv4,ipv4-address=10.240.0.1${i},security-group-ids=$SECURITY_GROUP_ID"\
    --ssh-key=$PUBLIC_SSH_KEY_PART \
    --preemptible \
    --memory=2GB \
    --cores=2 \
    --hostname=controller-${i} \
    --core-fraction=20 \
    --service-account-name=dev-k8s-vm
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:

for i in 0 1 2; do
  yc compute instance create worker-${i} \
    --async \
    --zone=ru-central1-a \
    --metadata pod-cidr=10.200.${i}.0/24 \
    --create-boot-disk="size=18GB,image-id=fd8m2ak64lipvicd94sf" \
    --network-interface="subnet-name=kubernetes,nat-ip-version=ipv4,ipv4-address=10.240.0.2${i},security-group-ids=$SECURITY_GROUP_ID"\
    --ssh-key=$PUBLIC_SSH_KEY_PART \
    --preemptible \
    --memory=2GB \
    --hostname=worker-${i} \
    --cores=2 \
    --core-fraction=20 \
    --service-account-name=dev-k8s-vm
done

Verification

List the compute instances in your default compute zone:

yc compute instance list

output

+----------------------+--------------+---------------+---------+-----------------+-------------+
|          ID          |     NAME     |    ZONE ID    | STATUS  |   EXTERNAL IP   | INTERNAL IP |
+----------------------+--------------+---------------+---------+-----------------+-------------+
| xxxxxxxxxxxxxxxxxxxx | worker-1     | ru-central1-a | RUNNING | XXX.XXX.XXX.XX  | 10.240.0.21 |
| xxxxxxxxxxxxxxxxxxxx | controller-1 | ru-central1-a | RUNNING | XXX.XXX.XXX.XX  | 10.240.0.11 |
| xxxxxxxxxxxxxxxxxxxx | worker-2     | ru-central1-a | RUNNING | XXX.XXX.XXX.XX  | 10.240.0.22 |
| xxxxxxxxxxxxxxxxxxxx | worker-0     | ru-central1-a | RUNNING | XXX.XXX.XXX.XX  | 10.240.0.20 |
| xxxxxxxxxxxxxxxxxxxx | controller-0 | ru-central1-a | RUNNING | XXX.XXX.XXX.XX  | 10.240.0.10 |
| xxxxxxxxxxxxxxxxxxxx | controller-2 | ru-central1-a | RUNNING | XXX.XXX.XXX.XX  | 10.240.0.12 |
+----------------------+--------------+---------------+---------+-----------------+-------------+

Configuring SSH Access

SSH will be used to configure the controller and worker instances. When connecting to compute instances for the first time SSH keys will be generated for you and stored in the project or instance metadata as described in the connecting to instances documentation.

Test SSH access to the controller-0 compute instances. Get the external IP of the controller-0 and run:

ssh yc-user@CONTROLLER-0-EXTERNAL-IP

Next: Provisioning a CA and Generating TLS Certificates