Not gonna happen because it takes 3 master nodes to have a quorum and 1 separate worker node. The requirements are also pretty high with 2GB of memory per virtual machine. Don't think people have 4 extra machines or 10 GB of free memory to run VMs.
Not gonna happen because it takes 3 master nodes to have a quorum and 1 separate worker node. The requirements are also pretty high with 2GB of memory per virtual machine. Don't think people have 4 extra machines or 10 GB of free memory to run VMs.
You don't, strictly speaking, need separate worker nodes. You just need to untaint the masters.
Or you can just run the masters on raspberry pis - under $200 for a properly redundant cluster. (Masters and workers do not have to share a CPU architecture)
Management processes shouldn't take 2GB. What are they doing in there?
Very important thing to know about memory: Kubernetes nodes have no swap. Kubernetes will refuse to install if the system has a swap, gotta remove it.
This means nodes better have a safe margin of memory, because there is no swap to use when under memory pressure (things will crash). Hence the minimum requirement of 2 GB.
I tried to run complete clusters with 5+ machines in VmWare, with as little memory as possible because I don't have that much ram on my desktop, and all I got was virtual machines crashing under memory pressure.
For example, I picked up about 96 GB of DDR3 ECC ram for around 75 euros. A quick check on ebay, and the same amount of DDR4 is selling for at least _twice_ as much. I imagine it's pretty economical to buy this older hardware and just assemble a single beefy server, instead of buying multiple physical machines.
The added benefit is that this older hardware doesn't end up in a landfill, and even though older CPUs generally consume more power than their current gen equivalent, I reckon a single machine would consume about the same, or less, than multiple NUCs (I have no source to back that up though, it's just my assumption).
I agree the NUC is a great platform, but if you could spend less cash and get more bang for your buck, and perhaps have the added benefit of having a platform with ECC memory (not sure if the NUC supports ECC, I'm assuming it doesn't), then I think the latter is what most people would go for (or well, at least what I would go for :p).
We're also talking about home _servers_, so it doesn't seem that odd to me to use actual server hardware. The homelab[0] subreddit has a bunch of folks running actual server hardware for example.
I had plans to build a noise isolated data closet in the basement (tied into the furnace air return) but I never ended up with the right sort of basement.
Previously I used hand-crafted, Ansible, Salt, Puppet and Docker setups (that last one died two weeks ago prompting me to start the K3s setup). But they all ended up becomming snowflakes, making them to much hassle to maintain. What I like best about the K3s setup is that I can just flash K3OS[1] to a SD card with near zero configuration and just apply the Kubernetes resources (through Terraform in this case, but Helm is also a great timesaver).
I still have to figure out a nice way to do persistent storage. But for now since it's one node (the IoT cluster does not have state) the local-path Persistent Volumes work well enough. Might have a look into Rook.
I will admit it's not trivial to get started with Kubernetes, but since I already needed to study it for work this provides me with a nice training ground. Alternatively Hashicorp offers nice solutions in this space as well with Consul and Nomad. But it needs a little bit more assembly, whereas K3s comes with batteries included (build in Traefik reverse proxy, load balancer and DNS).
Can you explain that more? I had a single-node cluster running: the master needs to be untainted so work gets scheduled on it, and then it runs. There is no need for a quorum because there is nothing to decide on.
Kubernetes depends on etcd which requires an odd numbers of instances. There might be ways to run a one or two nodes cluster for testing (see minikube) but that's not how it's going to run in a company.
Most companies won't be running their own etcd clusters anyway, except for on-prem clusters. Cloud users will generally use a managed Kubernetes cluster. If you do need to learn how to run etcd, you can learn the basics in about a day. In our org, the etcd portion of the training is less than half an hour long thanks to good documentation.
For a homelab, consider running something like k3s which can use a SQL database instead of etcd.
Some Kubernetes-based distributions, like OpenShift, require 3 masters at minimum, but that's not the norm across K8s installations.