This is what happens when non-engineers try to do engineering related things. There's a lesson here for all the not-coms in SF pretending to be software companies.
What a colossal waste of tax payer money - not that SF or the wider general California population care.
Pretty sure that the engineers involved in the project were all working for top tier firms in their respective domains. How is your comment at all relevant?
Corey is so right on this. It's only a matter of time before all these vc funded k8s shops die. (They won't be acquired.) All the k8s users themselves will have to return to their barista jobs.
I think we are going to start seeing quite a lot more 'k8s is insecure' posts in the future (not that we haven't seen quite a bit this past year alone).
I'm really upset with the way Google let their marketing team run roughshod all over the place with that software. Kubernetes is almost never the tool to use. It's entirely insecure, overly complicated and almost never fits the intended supposed benefit. Worse it feels that the entire CNCF ecosystem is ran entirely by marketing people with "developer evangelists" that have never coded a single line of code in their day - it's a real shame and quite honestly an insult to professional engineers.
K8s is not about configuration management, it’s about dynamic application management.
Some parts infringe on areas where CM tools work as well, but k8s is all about managing containerized applications.
Trying to set up flows for ”works on my laptop”-dev, ci/cd, loadtesting, a/b tests, canary releases, autoscaling and rollbacks for multiple teams of devs?
K8s really simplifies these things.
The idea is that you have one api spec to rule the whole stack (from a dev perspective).
If you go down a more light-weight stack, a lot can still be achieved. More duct tape required though. That being said- I love duct tape!
Never use Ansible, Puppet or Chef. Those are old dead tools.
Those are tools for configuration management. If you instead use packer, docker, you can build your vm/image at build time, and use Terraform to setup vm with that image. Use etcd (in the image set to pull config) or similar key-value for distributing configuration.
Not "setup base vm with terraform" and then "ansible to install and configure it". Just build your vm/container image with the software you want already installed, and a etcd or other pull-configuration from a pre-set source. Done.
Now you dont need configuration-management, and dynamically changing infrastructure, since you moved it to the build-step.
I don't think configuration management tools are dead.
I use puppet to build my image with packer. It's way easier than build with a bunch of shell scripts. I agree that you shouldn't use it on live servers.
what is the psychosis in the k8s community where they feel the need to talk about losing thousands of dollars? it's a recurring theme with this community that they think somehow makes them look cool - wouldn't that be a clear sign that they should not be using k8s to begin with?
this community is ripe for implosion - what a joke
Most infrastructure folks love to talk about the expensive costs that occur from incidents like fires, the lazy infra engineers who don't do anything, hurricane shut down my data center, etc.
Devs like to focus on costs related to lost time. This is a pretty common trend and not really sure why you think that there's anything pathological about k8s. Maybe there's something pathological about infra folks in general and dev folks.
serious question, what do you use for deploying your services? scp fat bins on bare metal? podman and buildah? Maybe lxc? Ansible, etc? I've seen your posts but all I see are complaints, not remedies for what you seem to think is the scourge of kubernetes and docker.
it might surprise you that most devops/sysadmins don't use k8s/docker and think it's a disease - some of us are brave enough to speak our minds against the brownshirts that want to tear us down
What a colossal waste of tax payer money - not that SF or the wider general California population care.