ArgoCD on RaspberryPi 4

Introduction

I wanted a local development environment for Kubernetes. I got a Raspberry Pi 4 to host a “cluster” (1 node) on - which has served me excellently well for testing, quick local development and for hosting parts of this website.

Since I want everything in GitHub the best tool for deployment on Kubernetes seems a combination of Helm and ArgoCD will do the job. That’s also thanks to the fact that I have experience with them, which may or may not make me biased. :)

To that end, the following technologies will be used: Kubernetes will be used for the orchestration of the containers, ArgoCD for deployment, everything will be nicely packed in Helm charts, and the code will all be on GitHub. Anything more will be application specific.

Quick links

Deployed in this article: https://gitea.adrian-docs.com/ (taken down for performance, RPi will also be used as a WiFi bridge) Repositories used:

• https://github.com/aliasboink/raspberrypi_argocd_charts
• https://github.com/aliasboink/raspberrypi_argocd_module

How to use Kubernetes with Raspberry Pi?

Here there are several options. The ones I gave a brief look at being the following:

• MicroK8s
• k3s
• minikube
• kind
• k0s
• kubeadm
• and more…

Two of these are best fit for local development (minikube and kind). The rest are a good depending on what you want. I didn’t verify all of them in-depth, but briefly investigated it and landed on k3s. The official documentation is nice and comprehensive with simple illustrations. Great documentation is slowly becoming of the major reasons why I like a new technology.. It’s advertisment for IoT deployments - it fits the bill just fine.

The installation itself was quite easy using the official documentation. There were a couple of hiccups that were easily fixed.

ArgoCD on K3s

ArgoCD and Kubernetes make a surprisingly good pair - one strange benefit I enjoy a fair bit is that I can look at the configuration or logs of the applications both with ArgoCD and with Kubernetes tools, specifically k9s in my case.

Design

For the purpose of using GitHub as much as possible - I needed to create the “root app”. Some quick Googling lead to the fact that this is a very common well known pattern documented by ArgoCD right here!

The reason why this pattern is powerful is because it allows you to have applications picked up from a git repository that you can easily modify. You can add applications, you can remove applications, you can add a few extra resources that may be required for this specific cluster - you can do whatever all via traceable git commits.

You can choose the amount of root apps you have. This is useful due to the fact that if you mess up the manifest of any one application - the root app will not sync nor update any of the other applications. This is an issue when working with other people on the same cluster on different applications.

In my case - one root app is enough. I don’t ever see myself allowing anyone else to deploy applications on the Raspberry Pi 4 K3s cluster. Not willingly at least.

Installation

The process I followed here was the following:

1. Manually deploy on a local kind cluster
2. Manually deploy on the K3s cluster
3. Manually deploy on the K3s cluster with the GitHub repository code

I prefer to have (1) due to two reasons: I am comfortable running kind clusters locally and an amd64 architecture may prove easier to work with initally. For (2) I followed the exact same steps in (1) successfully. For (3) the “code” writing starts here. The only caveat is that I have a small script to load the ssh_keyas an environment variable - this has to be ran before the deployment. Normally this would be better pulled from an external vault, but given the scale of the project I’d rather a small extra step.

Set up Gitea

Perfect. I got ArgoCD running. What to do now?

The answer is: scroll through the Bitnami helm charts to find something interesting to deploy. Mastodon seems nice, but it would be entirely useless. Discourse seems quite nice for building a small community, but it doesn’t have arm64 support. Gitea seems quite good if I wish to ever back up my code from GitHub in case… it goes down along with the entire internet? Sounds good to me even if it may never get use!

I managed to successfully deploy Gitea and wishing to further tinker with it I had realized that it only allways for one replica. Thus, I scratched this and went for the gitea/helm-chart on Gitea.

Configure Gitea

Set it up, changed the ports around a bit, and got it successfully running in the cluster. The setup works!

Now, since I don’t wish for my Raspberry Pi 4 to be set aflame I have to make Gitea be invite only. For the sake of security, I also wish for the credentials of the admin user to not be part of the values.yaml file. Gitea allows giving the credentials via a Kubernetes Secret, but unfortunately for some reason it doesn’t allow you to set the admin email in the Kubernetes Secret as well. That has to be done through the values.yaml file.

Connect the Raspberry Pi 4 to the internet

The first thought that came to mind was port forwarding. This would come with the “downside” of having to harden my local network - but all in all it sounds like a fun challenge. Unfortunately, my internet provider seems to be using CGNAT and to be able to expose my Raspberry Pi 4 a number of calls with the internet provider and possibly a chance of routers would be necessary - thus another option was chosed.

CloudFlare Tunnels fit the bill perfectly well. At the risk of sounding like an advertisment - the tunnel was extremely easy to set up and requires no further hardening as everything goes through a CloudFlare Proxy. Should be good if you trust CloudFlare with your traffic data. :)

Where is Gitea accessible?

You can access Gitea here!