Forgive any potential misuse of terminology (not my primary field of expertise), "fully Kubernetes-native stack" here is meant to mean that all services and infrastructure (or as much as possible) are deployed within the cluster itself.<p>For example, rather than using any AWS/Google managed databases, queues, or caches, deploying open-source varieties using standard Kubernetes objects instead.<p>If so, does anyone have any useful guides/manifests/charts or advice for setting up and configuring something similar? I have a bunch of old devices I've been steadily repurposing as compute/storage for experimentation at home, and it'd be cool to develop closer to a real world distributed environment without footing as large a bill. I would guess I'm not the first person to have been interested in doing this, so at this point just trying not to duplicate any work if this is already a solved problem.
The keyword you're looking for here is Operator [1]. Kubernetes Operators are custom resources (e.g. Database, Load Balancer, ACME Certificate Entry) that manage themselves via a reconciliation loop. If you're looking for a specific piece of infrastructure, search for `<YOUR_TECHNOLOGY> + "operator"`, (e.g. "Postgres Operator", "Kafka Operator", etc...). Once you find an operator for the piece of infrastructure you need, just follow their instructions on how to set it up and configure it. Learning about how operators work is pretty neat and writing your own is fairly simple if you don't find an operator for your use case.<p>Personally I run my personal cluster on K3s [2], secure it with cert-manager [3] and route traffic via the Traefik Operator [4]. Right now I use Litestream for all of my DB needs, but I've heard good things about the Postgres Operator by CrunchyData [5].<p>1: <a href="https://kubernetes.io/docs/concepts/extend-kubernetes/operator/" rel="nofollow">https://kubernetes.io/docs/concepts/extend-kubernetes/operat...</a>
2: <a href="https://k3s.io/" rel="nofollow">https://k3s.io/</a>
3: <a href="https://cert-manager.io/" rel="nofollow">https://cert-manager.io/</a>
4: <a href="https://doc.traefik.io/traefik/providers/kubernetes-ingress/" rel="nofollow">https://doc.traefik.io/traefik/providers/kubernetes-ingress/</a>
5: <a href="https://github.com/CrunchyData/postgres-operator" rel="nofollow">https://github.com/CrunchyData/postgres-operator</a>
I guess that would really depend on your setup. It would differ significantly if you’re doing virtualised nodes ontop of vmware/proxmox/qemi/etc, if you’re doing single node with storage, or if you’re doing something more exotic like raspberry pis with either one node with storage or external nas.
I have a couple of different setups (mostly for fun), which are pretty simple. Main things I use are a csi driver to allow me to use my trunas scale as storage (<a href="https://github.com/democratic-csi/democratic-csi" rel="nofollow">https://github.com/democratic-csi/democratic-csi</a>), cloudflare’s argo tunnel to expose my clusters to the outside world (<a href="https://github.com/cloudflare/cloudflare-ingress-controller" rel="nofollow">https://github.com/cloudflare/cloudflare-ingress-controller</a>), an operator for managing external dns with cloudflare (<a href="https://github.com/kubernetes-sigs/external-dns/blob/master/" rel="nofollow">https://github.com/kubernetes-sigs/external-dns/blob/master/</a>...). Everything else is pretty much they way any other cluster would look.<p>In regards to databases I mainly stick to kubedb (<a href="https://kubedb.com/" rel="nofollow">https://kubedb.com/</a>) as my needs are not that great.