I run k3s on a single node. Used to be two, but I consolidated because this isn't a production usecase for me.
Availability isn't the point for me. If I have to turn the thing off for an hour ever year or two to fix something, sure, fine.
The real value I get is Infra as Code, and having access to the same powerful tools that are standard everywhere else.
I can drop my current (dedicated) hardware and go publish all my services on a new box in under an hour, which I did recently.
From my point of view, I already pay the complexity by virtue of k8s being The Standard. The two costs of complexity are 1) Learning the Damn Thing 2) Picking up the pieces when it breaks under its own weight.
1) I already pay regardless, and 2) I'm happy to pay for the flexibility I get in return.
Both k3s and MicroK8s support single node and multi node setups. Now, there's an open debate whether running K8s locally is the right approach for container development. Kelsey Hightower and James Strachan actually shared opposite opinions on this in a recent industry report published by Canonical. https://juju.is/cloud-native-kubernetes-usage-report-2021#ku...
tux3|4 years ago
The real value I get is Infra as Code, and having access to the same powerful tools that are standard everywhere else. I can drop my current (dedicated) hardware and go publish all my services on a new box in under an hour, which I did recently.
From my point of view, I already pay the complexity by virtue of k8s being The Standard. The two costs of complexity are 1) Learning the Damn Thing 2) Picking up the pieces when it breaks under its own weight. 1) I already pay regardless, and 2) I'm happy to pay for the flexibility I get in return.
achalkias|4 years ago
(Disclaimer: I work for Canonical)