I understand their rationale. We manage thousand Kubernetes clusters and end-users can find lots and lots of creative way to shoot themselves in the foot: - I can store anything in a secret? Let's have thousands of cat images. Etcd then stops working because we have over 2GB of funny cats in the key store. - I can run a root Pod? Lets mount the docker socket and start building images with it. Oh and by the way, I nev…
> I can store anything in a secret? Let's have thousands of cat images. Why would someone want to store non-secret information as a secret?
Google admits Kubernetes container tech is too complex
121–130 of 449 posts
Re: Google admits Kubernetes container tech is too complex
#122I understand their rationale. We manage thousand Kubernetes clusters and end-users can find lots and lots of creative way to shoot themselves in the foot: - I can store anything in a secret? Let's have thousands of cat images. Etcd then stops working because we have over 2GB of funny cats in the key store. - I can run a root Pod? Lets mount the docker socket and start building images with it. Oh and by the way, I nev…
> I can store anything in a secret? Let's have thousands of cat images. Why would someone want to store non-secret information as a secret?
— Douglas Adams
Re: Google admits Kubernetes container tech is too complex
#123I can understand the use of kubernetes in very large orgs to manage clusters of hundreds of nodes, but it seems to me the complexity isn’t justified if you only have 1-100 say. There are lots of possibilities between 1 server and 100, and lots of ways to have simple replicable deploys if your needs are simple (probably 95% of businesses). Simple load balancers without auto-scaling work fine! For smaller non-critical…
No, but it’s not just complexity. We’re a small company, but after spending about a month to setup our GKE a couple of years ago (incl learning terraform in the process), it’s been rock solid, low involvement and reliable. Declarative resource specification is a legitimate game changer and you couldn’t pay me to go back.
I guess the ultimate goal of services like GKE autopilot is for you not to have to worry about kubernetes at all, just give them your workload and have it run on whatever resources they think is appropriate?
I do think it's important to recognise though that there are lots of ways to host services, and simpler with less abstractions is often better and more reliable and certainly easier to debug when things go wrong.
Re: Google admits Kubernetes container tech is too complex
#124What I miss the most is having my infrastructure defined as code, instead of via the GUI. But given that I have only four services (out of which two use preemptible VMs and only one needs to scale) it’s not really a problem — it wouldn’t take me many minutes to replicate this setup at another cloud provider.
Re: Google admits Kubernetes container tech is too complex
#125What happened to "focus on the business logic / application"? Are we just making rabbit holes out of rabbit holes of abstraction using kubernetes? I just use and push code to Heroku and I'm done for the day, simple. NoOps I call it. I wish more tools and platforms were like this.
Mind blowing to me that "Heroku but with docker images" doesn't seem to exist. Would love to be corrected!
Re: Google admits Kubernetes container tech is too complex
#126Not seeing anyone mention it, so I'll just share: https://k8slens.dev/ Lens has been a huge boon for helping us manage our kube cluster and regular devops operations, and even 15 minutes with it helped me grok a number of complex kubernetes concepts that I've struggled with for awhile now. Everyone who works with k8s for a living should at least know of this tool imho its fantastic with prometheus
Re: Google admits Kubernetes container tech is too complex
#127Earlier quoted context omitted.
They have a quote from the GKE lead directly saying "Despite 6 years of progress, Kubernetes is still incredibly complex." But it is a surprisingly negative headline. Autopilot sounds like a cool tool to simplify container orchestration!
> But it is a surprisingly negative headline. That's the Register's schtick, they're snarky about everything.
Re: Google admits Kubernetes container tech is too complex
#128Putting on my Asbestos Longjohns: The more I look into k8s ecosystem, the more I'm convinced that it's one of those things that suits FAANG etc, but the regular Joe developer has caught on the fad and wants to add it to his repertoire, even though it's an overkill. After all no one got fired for buying IBM and recommending Kubernetes. Most teams need a simpler deployment strategies that other's have succinctly mentio…
Re: Google admits Kubernetes container tech is too complex
#129This was glaringly obvious from day one. Containers add vast complexity, add another layer of complexity on top.
Containers don’t have to be complex. Docker and docker-compose are very simple to use. Docker swarm (rip) and Nomad are similar to kubernetes but orders or magnitude simpler.
This was years ago, so maybe they greatly simplified things. But somehow I doubt it =/
[1] " Docker, by default, punches massive holes through your firewall in non-obvious ways. People don't realize that with a default Docker configuration, containers are ignoring any normal firewall rules you may have setup with iptables or ufw." - https://news.ycombinator.com/item?id=25834444
Re: Google admits Kubernetes container tech is too complex
#130What happened to "focus on the business logic / application"? Are we just making rabbit holes out of rabbit holes of abstraction using kubernetes? I just use and push code to Heroku and I'm done for the day, simple. NoOps I call it. I wish more tools and platforms were like this.
My background is in embedded, so I admittedly know extremely little about web development, but whenever I'm curious and sit down to read about microservices and containers and orchestration and all that stuff, my mind starts to numb and I can't help but conclude that 99% of companies that use it probably don't need to. And that they're just a complex way for engineers to keep themselves spinning their wheels and not…