Dustin C. Hatch
0592f450c4
[Sealed Secrets] will allow us to store secret values in the Git repository, since the actual secrets are encrypted and can only be decrypted using the private key stored in the Kubernetes cluster. I have been looking for a better way to deal with secrets for some time now. For one thing, having the secret files ignored by Git means they only exist on my main desktop. If I need to make changes to an application from another machine, I have to not only clone the repository, but also manually copy the secret files. That sort of makes my desktop a single point-of-failure. I tried moving all the secret files to another (private) repository and adding it as a submodule, but Kustomize did not like that; it will only load files from the current working directory, or another Kustomize project. Having to create two projects for each application, one for the secrets and one for everything else, would be tedious and annoying. I also considered encrypting all the secret files with e.g. GnuPG and creating Make recipies for each project to decrypt them before running `kubectl apply`. I eventually want to use Argo CD, though, so that prerequisite step would make that a lot more complex. Eventually, I discovered [KSOPS] and *Sealed Secrets*. KSOPS operates entirely on the client side, and thus requires a plugin for Kustomize and/or Argo CD in order to work, so it's not significantly different than the GnuPG/Make idea. I like that Sealed Secrets does not require anything on the client side, except when initially creating the manifests for the SealedSecret objects, so Argo CD will "just work" without any extra tools or configuration. [Sealed Secrets]: https://github.com/bitnami-labs/sealed-secrets [KSOPS]: https://github.com/viaduct-ai/kustomize-sops
Dustin's Kubernetes Cluster
This repository contains resources for deploying and managing my on-premises Kubernetes cluster
Cluster Setup
The cluster primarily consists of libvirt/QEMU+KVM virtual machines. The Control Plane nodes are VMs, as are the x86_64 worker nodes. Eventually, I would like to add Raspberry Pi or Pine64 machines as aarch64 nodes.
All machines run Fedora, using only Fedora builds of the Kubernetes components
(kubeadm, kubectl, and kubeadm).
See Cluster Setup for details.
Jenkins Agents
One of the main use cases for the Kubernetes cluster is to provide dynamic agents for Jenkins. Using the Kubernetes Plugin, Jenkins will automatically launch worker nodes as Kubernetes pods.
See Jenkins Kubernetes Integration for details.
Persistent Storage
Persistent storage for pods is provided by Longhorn. Longhorn runs within the cluster and provisions storage on worker nodes to make available to pods over iSCSI.
See Persistent Storage Using Longorn for details.