Live data from Hacker News

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

benhouston3d.com

421–430 of 436 posts

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

#421

Earlier quoted context omitted.

I want to use them because I'm not paying for it and managing your own hardware is a pain in the ass I'd rather avoid when I could just code instead. Which is not to say that using your own hardware isn't smart, but it is definitely miserable.

But you don't "manage your own hardware" if you are renting VMs, which was the question here. Also managing a cloud infrastructure is a lot more complex than running Debian and Ansible on a VM.

Sorry, I think I must have miscommunicated. I was communicating why I was arguing for using the cloud.

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

#422
post #392

OP I'm on firefox 131 on Ubuntu and your site is basically unreadable. Dark background and the text is the faintest of shades lighter. I don't mean this in a nitpicky way. Normally I'm fine with most sites. I have to highlight the text to read it.

Chrome on macOS is the same, bailed when I couldn't read the text.

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

#423

Earlier quoted context omitted.

What about your integration makes it a huge pita?

It's just a lot of stuff; we have a couple hundred services, and when I've had to add shit, it ends up with me updating like two hundred files. Infrastructure as code is great, but lets be honest, most people are not thoroughly reading through a PR with 200+ files. There's of course tpl files to help reduce duplication, and I'm grateful for that stuff when I can get it, but for one reason or another, I can't always d…

Yeah ew sounds like a mess. I'm sorry, thanks for sharing. Death by a thousand paper cuts is never fun. The solution in looking at for my problem in this area is to add another layer of indirection and make a config generator so that there's only one config file for users to define their service in, and the program goes off and makes all the necessary changes to the pile of yaml files.

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

#424

Earlier quoted context omitted.

Kubernetes in Action

A book from 2017? Is that still relevant to understand a modern Kubernetes cluster? The CNCF ecosystem looked a lot different back then.

Yup it's a great introduction as you can fly through it (3-4 hours to read most of it), at least if you already have a grasp of networking, linux, processes, threads, containers etc.

Then you can hit other resources (in my case working with a team who've been using K8S for a few years).

If you (or anyone else) has suggestions for something newer and covering more than just the core (like various different components you can use, Helm, Argo, ISTIO etc etc) then I'd appreciate it :-)

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

#425

Earlier quoted context omitted.

Kubernetes in Action

A book from 2017? Is that still relevant to understand a modern Kubernetes cluster? The CNCF ecosystem looked a lot different back then.

The second edition is being worked on for a long time: https://www.manning.com/books/kubernetes-in-action-second-ed...

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

#426
post #162
post #158

Earlier quoted context omitted.

Is nomad still around?

Thanks, hadn't heard of that. Seems pretty active per its commit activity: https://github.com/hashicorp/nomad/graphs/commit-activity But the fact that I hadn't heard of it before makes it sound not very popular, at least not for the bubble I live in :). Does anyone have any practical experiences to share about it?

If that's practical experience that you need, I remember reading some studies comparing the reliability and efficiency of nomad vs k8s under load (spoiler: they do not look very good for k8s).

If that's popularity that you need, then sure, nobody ever got fired for choosing kubernetes.

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

#427

Earlier quoted context omitted.

Yaml is declarative, you tell k8s what you want and how it looks. For shell scripts, try proper error handling. You start doing some catch hooks, you have issues cehcking error codes of different tools, debugging is hard too. In one infra project we swtiched from shell scripts to golang just to have a lot more control/stability of our scripts.

YAML is not declarative, it's a format. Well, according to Wikipedia it's a "data serialization language". IMO It's also bad choice for this, and those files become unreadable and hard to work with. Agree that shell scripts are also hard to work with, especially if you did not write them yourselves. I guess it's a combo of the language features of, say bash, and that no one who writes them really know bash. I mean, a…

Yes sry i was not precise but k8s is declaritive and in that particular case, i find it very fitting. I dont love it, but its direct.

What i like with that declaritive setup: The other side, the executer, can be actually something reasonable to build and be reused. This strategy or architecture, feels a lot better than the classical approach especially because its so so often always the same thing.

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

#428
post #86
post #76

Earlier quoted context omitted.

I can imagine. Do you have complete automation setup around maintaining the cluster? We are now on-prem using “pet” clusters with namespace as a service automated on it. This causes all kinds of issues with different workloads with different performance characteristics and requirements. They also share ingress and egress nodes so impact on those has a large blast radius. This leads to more rules and requirements. Hav…

> This causes all kinds of issues with different workloads with different performance characteristics and requirements. Most of these issues can be fixed by setting resource requests equal to limits and using integer CPU values to guarantee QoS. You should also have an interface with developers explaining which nodes in your datacenter have which characteristics, using node labels and taints, and force developers to…

For the different workloads it is more that all the nodes in the cluster are the same and mixing memory with cpu intensive or io intensive workloads is hard to schedule or to get to a proper utilisation rate. Next to that when indeed setting request and limit properly it means that our Java apps use/reserve multiple cores even when handling little traffic and basically idling. Golang apps scale better there, especially towards 0.

When running on “bare” VMs each VM is its own member in the network. The pods in the cluster use an overlay network and egress is limited to egress nodes which are now shared by all workloads.

Having dedicated K8s clusters would reduce the sharing of network ingress and egress as well as choose the vm size for my workloads.

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

#429
post #65

People talk about Kubernetes as container orchestration, but I think that's kind of backwards. Kubernetes is a tool for creating computer clusters. Hence the name "Borg" (Kubernetes's grandpa) referring to assimilating heterogeneous hardware into a collective entity. Containers are an implementation detail. Do you need a computer cluster? If so k8s is pretty great. If you don't care about redundancy and can get all t…

This has got to be the most out there k8s take I've read in a while. k8s doesn't save you from learning your cloud providers infrastructure, you have to learn k8s in addition to your cloud provider's infrastructure. It's all ALBs, ASGs, Security Groups, EBS Volumbes and IAM policy underneath and k8s, while very clever, isn't so clever as to abstract much of any of it away from you. On EKS you get to enjoy more odd li…

The same argument can be made about Borg. Someone at Google needs to know about things like Juniper switches and hard drive bays. Someone needs to repair or replace defective compute nodes and power switches. Before they had software load balancing, someone had to manage the hardware load balancers.

But the idea of Borg is that all of that's abstracted away for the typical developer. It's the same with k8s. The infrastructure team in your org needs to understand the implementation details, but really only a few.

You can also configure load balancers, IAM groups & policy etc as k8s CRDs. So all that stuff can be in one place in the code base alongside the rest of your infrastructure. So in that sense it does abstract those concepts. You still need to know something about them, but you don't have to configure them programmatically yourself since k8s will do that.

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

#430

Earlier quoted context omitted.

Just because you're using VMs doesn't mean you're now dealing with state. It's 100% possible to have stateless VMs running in an auto-scaling instance group (in GCP speak, I forget what AWS calls them)

Once you have the tools to manage all of that, you effectively have kubernetes. Container vs VM is largely irrelevant to what the op is complaining about when it comes to k8s. People that don’t like k8s tend to be fine with docker. It’s usually that they don’t like declarative state or thinking in selectors and other abstractions.

Quite the contrary, I support declarative configuration and code-reviewable infrastructure changes but k8s is just too much for me.

I paired with one of our platform engineers several months ago. For a simple app that listens on Kafka, stores stuff in PostgreSQL and only has one exposed port... and that needed at least 8 YAML files. Ingress, service ports and whatever other things k8s feels should be described. I forgot almost all of them the same day.

I don't doubt that doing it every day will have me get used to it and even find it intuitive, I suppose. But it's absolutely not coming natural to me.

I'd vastly prefer just a single config block with a declarative DSL in it, a la nginx or Caddy, and describe all these service artifacts in one place. (Or similar to a systemd service file.)

Too many files. Fold stuff in much less of them and I'll probably become an enthusiastic k8s supporter.

Post reply on HN