It’s been a year since I wrote about bootstrapping a cluster with Argo and using Argo Rollouts for canary deploys based on Prometheus metrics. Since then many things have changed. I moved from Digital Ocean to Linode (mostly because Linode has a Tokyo region) and from a single-node k3s “cluster” to a 4-node one. But most of how I use Argo CD for GitOps hasn’t changed.
kubectl has the feature to select objects by filtering on labels using the
-l flag. Labels are key-value pairs attached to objects as metadata and they don’t have to be unique. I’ve most often seen them used to identify what project or app an individual resource belongs to. Helm uses labels to mark resources with the app, chart and revision they belong to.
But wait, if they’re not unique and there is a way to select multiple values with set operators, how does that work? The database backing Kubernetes by default, etcd is a key-value store. While it can natively select multiple records by prefix matching, it’d be hard to imagine labels working like that. There are many of them and the selectors are complex.
So I dove into Kubernetes’s source code to figure out how it works.
I wish it could be completely automated… But for now I’ve just automated as much as possible (and convenient). The ingredients:
- Sealed Secrets
- Argo CD and Argo Rollouts
- Prometheus and Grafana
I have a repository for the purposes of playing around with Kubernetes tooling like this – and hopefully turn it into an actual application eventually. I have big plans and lots of stuff I want to try out, but time is limited. All the code examples in this post use the namespaces and naming choices in the repository. The folder structure (relevant to this bit) is like…
system ├┬ apps │└─ (bootstrapped Argo CD app manifests) ├┬ argo │└─ the local "umbrella chart" for Argo CD and Argo Rollouts ├┬ bootstrap │└─ boilerplate project and application manifests └┬ manifests └─ manifests I didn't bother turning into a Helm chart referenced by the raw-manifests.yaml application
I’ve had most of my stuff running a k3s “cluster” for the past half a year or so. The whole setup runs on a single $5-a-month Digital Ocean droplet with 1vCPU and 1GB of memory.
Needless to say, it doesn’t take much to bring the whole thing to its knees. While it has no issues dealing with the little traffic my blog receives, I would accidentally bring it down occasionally when I install a Helm chart that turned out to be much heavier than I’d thought.
Having played around with the managed Kubernetes offerings of various cloud players (DO, AWS, GCP), I was wondering if it was possible to do this cheap. My site doesn’t have much traffic or anything complicated really, so running it off a $5 DO droplet is reasonable. Sadly managed Kubernetes offerings won’t come out so cheap. (Sure I could leech off the starting $300 GCP credit for a year then keep hopping accounts, but…)
Then I read about k3s. The people behind Rancher made it as a lightweight (but functionally complete) Kubernetes distro. Lightweight, they say… Just how light? (Imagine a weird maniac light in my eyes here.) Could I run it on a $5 droplet?
I think many people of my profession got recommended a certain article by Medium in their weekly digest. The launch-introduction post by Garden got my attention too. I’ve been trying to figure out how to deal with developing on Kubernetes, so every drop of information in that regard is much welcome.
Tagsahol álmomban jártam ale anime art beer blog clojure code coffee concoct english fansub fest filozófia gaming geek hegymász ipa kaja kocsma kubernetes kultúra lager league of legends literature live magyar politika python rant seven summits stout study travel társadalom ubuntu university weather work zene 就活 日本 日本語 百名山 艦これ