As mentioned in another entry, I decided I wanted to get more in touch with Kubernetes and, especially, Knative. The presentations at this year's W-JAX conference with regard to that topic were very inspiring, so I got started with that.
I had played a little with micro-k8s before, but neither did it feel "right" nor did I spend too much time with it. This time, I thought it would be a good idea to deploy a local (i.e., workstation) K8S environment that would resemble a production installation as closely as possible.
Safe that I only created a single node and therefore had no intention to go scaling any direction - my focus right now is on Knative, after all.
People can bootstrap their K8S cluster fairly easy these days - for Debian-based systems, you need to add the `https://apt.kubernetes.io/ kubernetes-xenial main` repository to your apt sources.
Afterwards, you can simply `apt install kubeadm kubelet kubectl` to get hold of the bootstrapping tools.
By default, I would assume readers to already be familiar with docker and have it already installed (btw, K8S supports other container tech as well). Docker does require a little tweak to be ready for K8S - the cgroups configuration should get adapted to use "native.cgroupdriver=systemd" and you should also make `overlay2` your default storage-driver.
After applying the docker config with `systemctl daemon-reload && systemctl restart docker`, things should be set.
Installing and instantiating K8S for the first time is a royal pain. There is a multitude of options, and these can easily bring you down. This adds on-top to the already very intriguing complexity of Kubernetes itself - K8S has a very flexible and powerful approach and this leads to a vast field of possible problems and peculiarities.
This blog post cannot, by far, attempt to be as thorough and precise as the official documentation. Also, the docs are very good, but quite a lot to read.
I decided to go with `flannel` as the network add-on, adding `istio` for ingress. Also, istio is a dependency of Knative - I decided to use its ingress capabilities and not use a separate ingress controller.
The ingress is, by the way, the component that is responsible for directing requests/traffic to its destination. That destination typically is a *service*, where a service can consist of several so-called pods.
A pod is a group of containers deployed together. Such pod would typically have, in the simplest form, one container holding the actual application. Many systems exist that deploy further "helper" containers in a pod - these containers are called "sidecars" (e.g. a container providing a proxy or a watchdog).
Istio is its own level of complexity. Its typical purpose is to provide a service-mesh platform for K8S. Knative uses only parts of it.
When network-plugin, ingress and istio are in place, it's time to install Knative in the cluster!
At least on my machine, the `monitoring.yml` of the official install guideline failed to install - I decided to skip that aspect for the time being.