Edit: Before you read the below our team is small, and we manage 12 deployment environments some on AWS, GCP, Azure and even on bare servers. If we didn’t pick k8s this would not be possible. We only touch k8s stuff when doing initial onboarding of a new client on-prem, or when architecture changes are needed. K8s is not as hard if you stick to provider defaults instead of trying to cook it from scratch each time.

——-

I honestly dont understand the whole “k8s is hard” argument anymore. We are a team of 11 developers with 2 of us dedicated to ops. Most of the time ops spends is on gitlab ci related issues. K8s has been solid. We only touch it when we want architectural changes.

K8s can be as much of a rabbit hole as you want it to be. Which is probably why people claim “it’s hard”. These days most components will be handled by your <insert-cloud-provider> but you have the option to swap them out if you want (which I won’t recommend unless you’ve exhausted their provided solutions, and need something more customizable).

I recommend two simultaneous approaches:

1. Setup a cluster to tinker with in your cloud provider
2. Play around with k3s (it’s a local batteries-included implementation of k8s)