Everything I know about Kubernetes I learned from a cluster of Raspberry Pis
41–50 of 80 posts
Re: Everything I know about Kubernetes I learned from a cluster of Raspberry Pis
#42This seems like a fun project and a great way to learn Kubernetes, but if I'm dropping this much money on it, I'd like it to have some productive purpose afterwards. I'm a full-stack web dev primarily using node/react/postgres. I've also got some projects currently hosted on a Linode instance. Ideas on fun/productive uses for this cluster after I've built it and messed around with Kubernetes?
Re: Everything I know about Kubernetes I learned from a cluster of Raspberry Pis
#43This seems like a fun project and a great way to learn Kubernetes, but if I'm dropping this much money on it, I'd like it to have some productive purpose afterwards. I'm a full-stack web dev primarily using node/react/postgres. I've also got some projects currently hosted on a Linode instance. Ideas on fun/productive uses for this cluster after I've built it and messed around with Kubernetes?
Consider the fact that, if you make improvements to the cluster, all of your apps will see that same lift. So if you were to set up backups on the cluster's persistent volumes and its databases, you'd get free backups for all of the projects you've moved. Same with monitoring, autoscale, and so on.
Re: Everything I know about Kubernetes I learned from a cluster of Raspberry Pis
#44Earlier quoted context omitted.
Not directly, rook provides a storage backend for in-cluster workload persistent volumes. In theory you could manage kvm machines with kubevirt and back the machines with PVCs from rook. I have not tried this and would be curious how the performance is.
I would say they're functionality quite equivalent, you just wouldn't pull them in as a root volume. You should be able to point your default StorageClass at Ceph and have it create RBD block storage devices for you, which would auto create pvc, that you mount you actual data in in your kube manifests.
> Does Rook give you the equivalent of EBS root volumes for your nodes then?
I think we are saying the same thing if i'm not mistaken?
Re: Everything I know about Kubernetes I learned from a cluster of Raspberry Pis
#45Earlier quoted context omitted.
Kind is explicitly not for production workloads[0]: Non-Goals: Being “production workload ready” - kind is meant to be used: for testing Kubernetes itself for testing against Kubernetes (EG in CI on Travis, Circle, etc.) for “local” clusters on developer machines NOT to host workloads serving user traffic etc. K3s seems happy to support production workloads. It's a single binary and gets you a cluster in one command:…
What are the benefits you find in using Kubernetes for a single-node cluster on a vps?
Re: Everything I know about Kubernetes I learned from a cluster of Raspberry Pis
#46This seems like a fun project and a great way to learn Kubernetes, but if I'm dropping this much money on it, I'd like it to have some productive purpose afterwards. I'm a full-stack web dev primarily using node/react/postgres. I've also got some projects currently hosted on a Linode instance. Ideas on fun/productive uses for this cluster after I've built it and messed around with Kubernetes?
Re: Everything I know about Kubernetes I learned from a cluster of Raspberry Pis
#47Re: Everything I know about Kubernetes I learned from a cluster of Raspberry Pis
#48Earlier quoted context omitted.
_Technically_ 1GB is the limit, but yeah, at 1GB I was hitting OOM errors every day or so (this was on the Pi 3 B+). I was very happy when I found out the Pi 4 had 2 or 4GB models! No matter what, you should also make sure to not schedule Pods on the master node(s) when you have limited memory (or in most cases, really...).
Or set tight resource limits. Setting resource requests also enables the use of HorizontalPodAutoscalers.
Re: Everything I know about Kubernetes I learned from a cluster of Raspberry Pis
#49Re: Everything I know about Kubernetes I learned from a cluster of Raspberry Pis
#50A good method for learning how clusters work and playing with them without having to spend a lot of time re-building when you break things is kind ( https://kind.sigs.k8s.io/ ). Each node is a Docker container, but the version of Kubernetes running inside it is vanilla Kubeadm, so it's quite representative of what "real" clusters would look like. The great thing about it is you can spin up a cluster in < 2 mins local…
I use Kind (and Minikube, and a number of other solutions too), but this is kind of my "Kubernetes-the-really-hard-way" fun project. Note that I maintain a parallel configuration that runs a multi-node cluster on Vagrant for local development [1] as well as a docker environment built for CI purposes[2] using almost all the same images, with the same Ansible playbooks to configure them all across platforms. [1] https:…