Overview
Introduction
Kubernetes is a container orchestrator. In some sense, a multi-host operating system for containers. It also takes a declarative stance in that you describe what you want and instruct Kubernetes to "Make it so!". Kubernetes will then construct any required entities and, importantly, re-construct them if they fail or the underlying host fails.
Warning
caveat implementor
Based on experience, if you are reading this after it was written then it is probably out of date.
Generously, it might be said that the rapid pace of development has far outstripped the Internet's collective ability to document it. kubernetes.io itself is mostly correct, albeit using reference material to discover wholesale techniques and methods is tricky.
However, the ideas and possibilities raised by the Internet at large are, generally, woefully out of date. APIs have changed names (let alone versions), fundamental changes to access control (RBAC and TLS) and even the container mechanisms have changed.
Good luck!
Architecture
Broadly, your Kubernetes implementation will consist of one (or more) master nodes and one (or more) worker nodes. In extremis you can run worker tasks on your master node(s) but it's generally frowned upon -- the master node(s) will be doing enough as it is.
In (roughly) Kubernetes version 1.20 two fairly big changes were made:
the control plane (master(s) and worker nodes) communicate over TLS -- with accompanying general annoyance as we shall see
Kubernetes stopped being directly tied to Docker and switched to a neutral container runtime which can be manipulated through the command crictl (rather than the command docker per se).
A good thing, although you'll be reading lots of tutorials which assume you have docker installed on your Kubernetes nodes. Which you won't.
We will need to use docker to generate some images a little later for which you can provision a spare machine (VM) for that purpose.
In the meanwhile, Kubernetes supports a number of constructions from Ingresses (external visibility), Services (nominal service endpoints), Deployments (implementations of Services), Pods (groups of containers created by the Deployment), ConfigMaps, Secrets, Volumes and so on.
There is a subtle distinction between Services and the Pods (wrapping the containers). As worker nodes come and go (or the Deployment is removed and re-added) the physical locations of the Pods will change and so the control plane (IP) addresses for the Pods will change. Even though there is an internal DNS, the Pod instance names are usually templated (name-XXXXXX, say) and so there would be some careful alignment needed to match things up. A Service does that alignment for you and internally keeps track of where the Pods are.
Correspondingly, there are two high level CIDRs involved, one for Services and one for Pods. You can chose what those CIDRs are, usually in 10/8. All of the nodes have routes to all of the resultant networks.
Load Balancer
One thing that Kubernetes does not provide (and neither does the networking component, next) is a Load Balancer. Kubernetes does support a LoadBalancer concept but the expectation is that there is an external-to-Kubernetes Load Balancer (as-a) service which can be configured by Kubernetes to do the actual load balancing.
This partly reflects an unhandled expression of how the outside world can interact with the services being run by Kubernetes. These Services and Pods are running on some local 10/8 network, right, so something has to map external addresses into internal ones.
You can force the "ExternalIP" of Services be the IP address of (any) one of the nodes which will result in some potential rewriting of packets and redirection to the node where the service is actually running. Curiously, and on reflection, obviously, the source IP address that the service sees will reflect whether or not that rewriting occurred.
We don't have an external Load Balancer so we'll bodge away where necessary.
Networking
Kubernetes requires something to handle networking. Not just the CIDRs mentioned above but a raft of networking-related functions like an IPAM to manage chunking off bits of those CIDRs, the internal DNS and so on.
We'll use Calico for no especially good reason other than it was mentioned in a few tutorials and, importantly, seems to work just fine.
Container Runtime
As noted, Kubernetes wants a container runtime to, uh, manage containers. There's a choice of a few, as seen in that link.
Note, however, that you will probably have to pick through the documentation, or, in desperation, strace the binary, to figure out some subtleties when we add a private repository later.
We'll use containerd because, well, again, no good reason and it works just fine.
Implementations
There are lots of implementations from the cloud-based, the enterprise-wrapped, the plausible home-brewed through to the simple single stop variants.
We'll be in the home-brewed camp, of course, which does allow you to be fairly free with your implementation. Craig Johnson, for example, encourages you to implement a Production Hobby Cluster utilising multiple (off-site) virtual private servers, WireGuard and other mechanisms.
As we have an OpenStack cluster we can just spin up some VMs and get cracking.
There is now a question about the resources for those VMs -- usually a little trickier when using "low end" VPS' -- which ultimately revolves around what you are going to do with your cluster. Probably, not much and containers are titchy! The great thing about Kubernetes is that is should allow you to migrate "services" between nodes which can have been resized accordingly.
In the meanwhile, a suggestion was for the master node(s) to have 2 vCPU and 4GB of RAM and each worker node to have 4 vCPU and 16GB of RAM. In practice, 2GB of RAM should be fine (probably).
kubeadm
Using kubeadm to install Kubernetes seems to satisfy a pleasant spot allowing for multiple master nodes and handling the basic inter-node setup (mostly).
It's also very simple as you perform the useful configuration on the master and you are given a command to run on the other nodes.
SWAP
Warning
DO NOT IGNORE
For reasons not made terribly clear other than dark warnings about impending doom, Kubernetes does not like running on systems with swap enabled. In any way. It will check the contents of /proc/swaps and will throw a hissy fit if there's anything there.
SELinux
Kubernetes does not like SELinux, either.
Document Actions