This afternoon, I fired up my k3s cluster for the first time in a while. When I ran apt update, I got an error message
about a missing Release file.
Because I’m running my k3s cluster on Raspberry Pi 4 nodes, and they’re ARM-64 (aarch64), I keep running into problems where applications are compiled for x86_64 (amd64) and don’t run.
If you’re using a NodePort service, and it has multiple replicas, how does it know which replica to use?
Wherein I finally bring together all we’ve learned so far and stand this thing up properly.
Installation with Helm, per https://longhorn.io/docs/1.2.3/deploy/install/install-with-helm/.
I forgot to disable Klipper, the K3s-provided load balancer.
Installation with Helm, per https://metallb.universe.tf/installation/#installation-with-helm.
To install other things, we’re going to want to use Helm. So let’s install that first.
Having reinstalled all of my nodes with Ubuntu, I need to go back and install k3s. Joy.
My Raspberry Pi 4 cluster is currently 32-bit. It’s got a 32-bit kernel with a 32-bit userland. But I need to run 64-bit software on it. I looked into upgrading it in place, but that’s infeasible. So I need to reinstall it.
Can I upgrade my Raspberry Pi 4-powered k3s cluster to arm64? Without rebuilding everything? tl;dr: no.
Persistent Volume Claims are namespace-scoped. Persistent Volumes are not:
Pushing a simple node.js-based image to my private docker registry failed.
Until just now, I didn’t get NodePort services.
In the previous post, we succeeded in giving our docker registry some persistent storage. However, it used (the default) dynamic provisioning, which means we don’t have as much control over where the storage is provisioned.
We need to give our Docker registry some persistent storage. Currently, if we restart it, it loses its stored data.
We need to give our Docker registry some persistent storage. Currently, if we restart it, it loses its stored data.
Let’s see if we can push an image to our new Docker Registry.
The default option for persistent volumes on k3s is local-path,
which provisions (on-demand) the storage on the node’s local disk. This
has the unfortunate side-effect that the container is now tied to that
particular node.
This morning, I grabbed my Raspberry Pi cluster out of the box and fired it up again.
About 2 years ago, I spent some time messing around with k3s on a cluster made from 5x Raspberry Pi 2 Model B nodes.
Note: This is basically the same as the node.js server.
Quick reference for installing Erlang and Elixir on a Raspberry Pi, using the Erlang Solutions packages.
Now that I’ve successfully run nginx on my cluster, I’m going to do the same with a simple node.js server.
Start nginx, with 3 replicas:
It’s at this point that I diverge from Scott’s blog post; he installs full-fat Kubernetes. I’m going to use k3s.
I downloaded Raspbian Buster Lite from the official site and wrote it to the SD cards (using dd).
I had a bunch of hardware lying around from an earlier abandoned side project: