>Can you expand on how this is different from traditional networking? Not OP, but I can chime in here. It's not that it's solved in this specific deployment,

>Can you expand on how this is different from traditional networking? Not OP, but I can chime in here. It's not that it's solved in this specific deployment, but it's solved in yaml files that you can re-deploy to any environment. Once I get my bundle of yaml files, I can just point it to any cluster (or namespace) et voila, it'll be deployed. It's "infrastructure-as-code"[0]. To be clear, Kubernetes doesn't have a monopoly on this approach, but it certainly follows it. Another idea is treating your servers like cattle, not pet. I used to have Linux VMs in my house named after Greek myths – these are pets. I named and loved each of 'em. And yes, after being setup, they worked. In Kubernetes, they're cattle – and you kill your cattle. You don't name and grow to love and nurture a specific VM. You can wipe your deployments and reprovsion a new one in a blink. >I used to run a FreeBSD router with a ZFS storage setup and various other stuff on my home network >From some coworkers who are closer to the cluster, keeping up with K8s version changes doesn't seem like a small effort. You're not wrong here though. Sometimes there are maintenance tasks you have to do on the whole cluster (make sure there's enough storage, everything is updated, certs are good, etc). But this is orthogonal to having your infrastructure-as-code in yaml files. The yaml files assume a healthy cluster/namespace, but besides that any cluster should be fungible. This is treating your servers like cattle, instead of pets. [0] https://docs.microsoft.com/en-us/azure/devops/learn/what-is-infrastructure-as-code https://docs.microsoft.com/en-us/azure/devops/learn/what-is-...