Creating our first cluster

Browser exercise: inspect your prepared cluster

Your simulated cluster is ready. Run these commands in the course terminal, one at a time:

kubectl cluster-info
kubectl get nodes
kubectl get pods
kubectl get pods -n kube-system

The default namespace has no application Pods yet; the system namespace does. Notice how changing the namespace changes what you see. That distinction matters when investigating a missing workload at work.

Browser learners: you can continue to the next lesson now. The setup below is optional and runs on your own computer, not in this terminal.

Optional local setup

For the local project, we use k3d to run k3s, a small Kubernetes distribution, inside Docker containers. It supports single- and multi-node clusters. Minikube and Kind are other local options.

To install k3d:

It is going to come in handy to have a local cluster running so let's set one up.

To set up a local Kubernetes cluster with k3d, open your terminal and enter the following command:

k3d cluster create localk8s

What did we create?

We just created a single-node, lightweight Kubernetes cluster inside docker. If you run kubectl cluster-info you should see:

kubectl cluster-info
Kubernetes control plane is running at https://0.0.0.0:49606
CoreDNS is running at https://0.0.0.0:49606/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Metrics-server is running at https://0.0.0.0:49606/api/v1/namespaces/kube-system/services/https:metrics-server:https/proxy

You can view our node by running kubectl get nodes:

kubectl get nodes
NAME                    STATUS   ROLES                  AGE   VERSION
k3d-localk8s-server-0   Ready    control-plane          13m   v1.31.2+k3s1

When we are done using our cluster we can stop it to avoid wasting resources. You can stop the cluster with:

k3d cluster stop localk8s and remove it with k3d cluster delete localk8s

Run kubectl get pods to check the default namespace. It has no application workloads yet. Kubernetes system workloads run in a separate namespace; inspect them with kubectl get pods -n kube-system.

kubectl get pods -n kube-system
local-path-provisioner-957fdf8bc-dcsjm   1/1     Running     0          18h
coredns-77ccd57875-vb7ff                 1/1     Running     0          18h
helm-install-traefik-crd-8gjxr           0/1     Completed   0          18h
helm-install-traefik-g7dzq               0/1     Completed   1          18h
metrics-server-648b5df564-6pqp2          1/1     Running     0          18h
traefik-64f55bb67d-kwnv4                 1/1     Running     0          18h

These are workloads that ran or are running to maintain our cluster operational.

Finally we are going to create the container registry that will store the containers that we will end up orchestrating with Kubernetes. Note that we pass --registry-use when creating the cluster so it can pull images from the registry:

k3d registry create localk8s --port 12345
k3d cluster delete localk8s
k3d cluster create localk8s --registry-use k3d-localk8s:12345

We can view the registry we created by invoking k3d registry list.

This registry is named k3d-localk8s and we can communicate with it by querying localhost:12345. Let's query this registry for its current catalogue:

curl -X GET localhost:12345/v2/_catalog
{"repositories":[]}

As expected there are no repositories yet for our container registry but that will soon change.

Note: By default localhost is configured as the host for the registry and it is accessible on port number 12345 like we configured. If you would like to use the name of the registry as the host and access it via k3d-localk8s:12345 you will have to add a mapping in the /etc/hosts file, more on that here.

Now that we have a cluster and registry setup we can start to deploy something to it.