Live data from Hacker News

I Didn't Need Kubernetes, and You Probably Don't Either

benhouston3d.com

241–250 of 436 posts

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#241
post #206
post #90

I’ve come to the conclusion that I hate “cloud shit”, and a small part of me is convinced that literally no one actually likes it, and everyone is playing a joke on me. I have set up about a dozen rack mount servers in my life, installing basically every flavor of Unix and Linux and message busses under the sun in the process, but I still get confused by all the Kubectl commands and GCP integration with it. I might j…

I have pretty much the exact same opinion, right down to “cloud shit” (I have even used that exact term at work to multiple levels of management, specifically “I’m not working on cloud shit, you know what I like working on and I’ll do pretty much anything else, but no cloud shit”). I have worked on too many projects where all you need is a 4-8 vCPU VM running nginx and some external database, but for some reasons the…

I mostly agree with you, but at least using Docker is something one should be doing even if one is on bare metal.

Pure bare metal IME only leads to people ssh'ing to hotfix something and forgetting to deploy it. Exclusively using Docker images prevents that. Also, it makes firewall management much, much easier as you can control containers' network connectivity (including egress) each on their own, on a bare-metal setup it involves loads of work with network namespaces and fighting the OS-provided systemd unit files.

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#242
post #161

Earlier quoted context omitted.

I'd prefer Ansible if I was running VM:s. Did that at a gig, controlled a vCenter cluster and hundreds of machines in it, much nicer experience than Kubernetes style ops. Easier to do ad hoc troubleshooting and logging for one.

until, as happened to us, you're in the middle of an upgrade cycle, with a mix of red-hat 6 and red-hat 8 servers, and ansible decide to require support for the latest available version of python on red-hat 8, which isn't available on red-hat 6, so we have no way of using ansible to manage both sets of servers. The python ecosystem is a cancer.

Well, you were free to install a version of Python3 on the CentOS6 machines, that's what we ended up doing and using for Ansible. Python 2.6 support of Ansible was a bad lie, multiple things broke already. 10 years of support without acknowledging changes of ecosystem just don't work.

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#244
post #165
post #87

I just use a single k3s install on a single bare metal from Hetzner or OVH, works like charm, very clean deployments, much more stable than docker-compose and 1/10 of the cost of AWS or similar.

Do you have a write-up about this that you have to share, even if it's someone else's? I'd be curious to try this out.

i was actually playing with hetzner and k3s over the weekend and found this https://github.com/vitobotta/hetzner-k3s to be super useful.

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#245
post #90

I’ve come to the conclusion that I hate “cloud shit”, and a small part of me is convinced that literally no one actually likes it, and everyone is playing a joke on me. I have set up about a dozen rack mount servers in my life, installing basically every flavor of Unix and Linux and message busses under the sun in the process, but I still get confused by all the Kubectl commands and GCP integration with it. I might j…

I'll let you in on the joke. The joke is the demand for 100% availability and instant gratification. we're making services where anything less than 4 nines, which is 5 minutes month, is deemed unacceptable. three nines is 10 minutes a week. two nines is 15 minutes a day. there are some things that are important enough that you can't take a coffee break and wait for, but Kubernetes lets you push four nines of availabi…

Most outages these days are also caused by "devops errors" that're much more likely to happen when working with complex infrastructure stacks. So there's real value in keeping things simple.

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#246
post #90

I’ve come to the conclusion that I hate “cloud shit”, and a small part of me is convinced that literally no one actually likes it, and everyone is playing a joke on me. I have set up about a dozen rack mount servers in my life, installing basically every flavor of Unix and Linux and message busses under the sun in the process, but I still get confused by all the Kubectl commands and GCP integration with it. I might j…

Kubernetes was developed by Google, and it seems to me it's a classic example of a technology that can work well in a resource-rich (people, money) environment. But in an averge business it becomes a time/money sink quite quickly.

Way too many businesses cargo-cult themselves into thinking that they need FAANG-class infra, even though they haven't got the same scale or the same level of resourcing. Devs and ops people love it because they get to cosplay and also get the right words on their CV.

If you're not Google-scale then, as you say, a few VMs or physical boxes are all you need for most systems. But its not sexy, so the business needs people who don't mind that.

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#247
I created [misterio](https://github.com/daitangio/misterio) to exactly solve the same issue described in the article.

So yes, if you have a simple setup you can use a "web" of docker servers.

But if your needs are just a bit more complex, or you have a mix of different technology (rubyonrails, python flask, java spring boot) and you want to standardize the communication, the security, the performance tracking and so on, K8s is the way.

The problem is the microservice architecture: the complexity is pushed to the infrastructure by the microservices, and K8s is a super-generic way to solve that complexity.

It is like unpacking (in a exploding-kitten mode) an application server on the your Intranet.

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#249
post #17

Except that all of this subjects you and all of your workloads to warrantless US government surveillance due to running in the big public clouds. I personally don’t want the federal government being able to peek into my files and data at any time, even though I’ve done nothing wrong. It’s the innocent people who have most to lose from government intrusion. It seems insane to me to just throw up one’s hands and store…

I've never heard of this. Can you share a link of what you are referring to? I care about this.

Here you are: https://www.brennancenter.org/our-work/analysis-opinion/sena...

Re: I Didn't Need Kubernetes, and You Probably Don't Either

#250
post #194

Earlier quoted context omitted.

I'm always kind of blown away by experiences like this. Admittedly, I've been using Kubernetes since the early days and I manage an Infra team that operates a couple thousand self-managed Kubernetes clusters so... expert blindness at work. Before that I did everything from golden images to pushing changes via rsync and kicking a script to deploy. Maybe it's because I adopted early and have grown with the technology i…

Those "necessary" add-ons and sidecars are out of control, but its the people problem. I'm part of the infra team and we manage just couple of k8s clusters, but those are quite big and have very high traffic load. The k8s + terraform code is simple, with no hacks, reliable and easy to upgrade. Our devs love it, we love it too and all of this makes my job pleasant and as little stressful as possible. But we recently h…

Service mesh is complicated, but the reason you use it integrate services across clusters. That and it has a bunch of useful reverse proxy features. On the other hand, It took me and 2 other guys two evenings of blood, sweat, and tears to understand what the fuck a virtual service actually does.

It’s not strictly necessary, but if you’ve had to put in the work elsewhere, I’d use it.

Post reply on HN