I've commented on this before in a different k8s thread (one about a k8s outage) but something that bears repeating is that the entire job market is Kubernetes.
My personal experience is that it is very, very hard to find a job right now if your professional experience is primarily non-k8s orchestration systems. Most job positions out there require deep Kubernetes knowledge as well as hands-on experience with different supporting products like ArgoCD and Flux.
I chose Nomad for a large initiative at my current employer and it is honestly pretty amazing given the use case but I regret choosing it because I feel like I'm unhirable now given that every devops/SRE/platform engineering position open on the market (each one with hundreds of applicants) is heavily Kubernetes focused.
A lot of smaller SaaS companies avoid k8s like the plague and only start using it once they scale to a certain size. K8s might be ubiquitous past a certain scale, but there are many jobs operating below the threshold for which the complexity of your system with k8s outweighs the complexity of your system without k8s.
If you find yourself on the Google cloud for some reason, GKE Autopilot is such a great hands-off solution that most alternative solutions will probably be more complex.
I only recently had to use AWS EKS, and am pretty sure that many people dislike k8s because that's the main incarnation of it they experience (how is there no pre-installed ingress, and even the setup for their own load balancer is a 10+ step manual process?).
It is really weird that the AWS Load Balancer Controller isn't an EKS Addon, and the permissions requirements being in the base requirements for EKS. Also, the only officially supported CNI is the VPC CNI.
And if you want to use EKS-A (EKS-Anywhere) it's even more effort to do the AWS IRSA setup.
Installing an ingress controller that will do SSL is a steep cliff preventing use with so many cloud Kubernetes offerings. I don't know why it needs to have dozens of steps, roles, and resource definitions.
Yeah, though I have to admit that even though you get SSL certificates "out of the box" with a GKE + GCP load balancer setup, their provisioning has always been really slow for me (usually 1-2h, sometimes half a day). In comparison self-installed nginx-ingress + Let's Encrypt provisions in minutes.
Cloud Run is just Knative which is also Kubernetes, so in the end it comes out to about the same. I used to use Cloud Run, but in the end there were usually always some things that ended up making GKE the more convenient choice (e.g. access to Helm charts).
If that is so then the industry has a lot to recon with soon because that would mean most at chasing a shiny new thing for absolutely all the wrong reasons.
K8s is complete overkill at best for the majority of companies/workloads and introduces lots of other dependencies on teams in terms of workflows and architectures to make things not be a dumpster fire for all but very mature teams.
I keep hearing this viewpoint, but I really don’t understand it. I use k3s for all sorts of personal projects, specifically because it makes things easier for me. I don’t have to worry about the underlying OS. I can focus on the application that’s actually providing value for me.
On the professional side, k8s handles orchestration issues far better than anything else I’ve worked with. Using autoscaling instances is a nightmare by comparison, and requires most of the same initial effort to do it right.
There is probably a middle ground where it requires a certain amount of complexity in the K8s configuration that isn’t worth it compared to other platforms (especially on bare metal), but I haven’t found it, yet.
I think it’s easy to forget how much goes into running even a simple application with high uptime requirements. Kelsey Hightower makes some great points about this here:
My personal experience is that it is very, very hard to find a job right now if your professional experience is primarily non-k8s orchestration systems. Most job positions out there require deep Kubernetes knowledge as well as hands-on experience with different supporting products like ArgoCD and Flux.
I chose Nomad for a large initiative at my current employer and it is honestly pretty amazing given the use case but I regret choosing it because I feel like I'm unhirable now given that every devops/SRE/platform engineering position open on the market (each one with hundreds of applicants) is heavily Kubernetes focused.