Live data from Hacker News

Kubernetes for Developers Who Know How to Develop

blog.ali.dev

51–60 of 106 posts

Re: Kubernetes for Developers Who Know How to Develop

#51
post #18

Why does everyone keep thinking developers need to now about K8S? Just be glad if your infra/DevOps/platform teams abstract this away from you and you don't have to deal with this insanity.

Sounds like the devops team is really just an ops team and you’re not actually doing devops.

Re: Kubernetes for Developers Who Know How to Develop

#52

I’ve been working on a Kubernetes cluster for my home network. I know a lot of people hate on Kubernetes, but it’s pretty cool and not too bad to even get started from scratch with Kubeadm. I think the constant thought in the back of my mind is… Docker containers and Nginx is definitely enough for my needs. At work, it’s a different story, but more most things, it can be over kill.

My biggest issue with Kubernetes is huge costs of running it. It's 3 servers with 4 GB RAM. It's almost $100/month just for Kubernetes alone. And you need one load balancer for control nodes which is another $25 for my hoster. And you need second load balancer for production workloads which is another $25. So you have to pay $150/month for the privilege of using Kubernetes. And they double your costs for your applica…

Three machines with 4GB of RAM for $100? I don't know where you rent your servers but that's ridiculous. You can easily get that kind of compute for a third or lower.

You won't get a private LAN (so you'll need some firewall rules on the hoster side) and you'll have to do some setup to get everything served up on the right public IP address(es), but you don't need a dedicated load balancer product. Unless you expect your virtual servers to go down randomly, I suppose.

I've set up k0s on Oracle's free service to mess with. It doesn't need nearly as much as 12GiB of RAM. Give it 500MiB per machine to be happy and it _should_ run fine with 10.5GiB to spare unless you're adding tons of overlays and additional services on top of your applications.

As far as I can tell, the biggest cost with Kubernetes is maintaining the system and keeping up to date with the advancements and deprecations in the Kubernetes field. You can't just upgrade the Kubernetes version and expect everything to work, and every new concept that replaces anything old comes with Kubernetes layers of complexity.

I honestly don't know what so many companies are using all those resources Kubernetes provides for. I have a feeling people are so caught up in the "modern server management" world that they've forgotten how powerful and reliable a $25 VPS is these days.

Re: Kubernetes for Developers Who Know How to Develop

#53

k8s is making a lot of the same “write once run anywhere” promises that were made by Jav- hit in the neck with a blow dart -Agggghhhh!…

For some reason, I'm hearing this in my head as you saying this right before your back is cracked by a chiropractor. So something along the lines of "Jav-ahhhhhhhhhh."

Re: Kubernetes for Developers Who Know How to Develop

#54
post #10
post #5

Earlier quoted context omitted.

I am very much aware of this, but that's exactly what I am arguing. Articles setting out to explain Kubernetes should not perpetuate the false equality of docker and containers.

If you use `docker build/run` in your bash, it will actually be more confusing IMO saying k8s "dropped docker(shim) support". This fact should be a footnote for the curious reader, surely on an introduction article.

It would do the industry a world of good to move past conflating Docker with Linux containers, containerization, images, etc.

There are tons of ways to build containers without Docker. You're effectively encouraging propagating confusion.

Re: Kubernetes for Developers Who Know How to Develop

#55
post #17

I'm going to post my unsolicited opinion about K8s here, as an SWE+SRE who used it heavily for about 1.5 years on GCP. It's a very cool system. I completely understand why people half-jokingly call it a "distributed operating system." It does a lot of things related to the lifecycles of various state (secrets, storage, config, deployments, etc). However, I believe it goes way too far into putting infrastructure into…

With the best possible intentions, the above is very much not a good overview of the current K8s ecosystem.

K8s is hugely supported and invested in by Alibaba, and TONS of companies you've never heard of.

All of these companies have huge, mission critical reasons not to use AWS/Azure/GCP and invest in K8s.

From an end user's standpoint, I am certainly not going to dispute your criticisms about Helm.

Google's original design of K8s seems like it was originally designed to be generically worse than GCP.

However, from an ecosystem standpoint, K8s is a project I'm very confident will be around for a long time.

Re: Kubernetes for Developers Who Know How to Develop

#56

Earlier quoted context omitted.

> remove support for docker So I can't use Dockerfiles and `docker build` to build things for k8s?

This is not correct. Kubernetes used docker engine under the hood in the past. Now they abstracted useful part of this engine into API. There's implementation from the docker (containerd), there's implementation from Redhat (CRI-O), may be others. Docker don't have to be installed for Kubernetes to work anymore. Building container images is a different topic. Kubernetes does not have anything to offer here. So you pr…

This is correct.

K8s abstracted out containerization in preparation for the anticipated long term migration of the ecosystem to Podman et al (lots and lots of people are invested in moving "containers" away from "Docker").

Re: Kubernetes for Developers Who Know How to Develop

#57
post #17

I'm going to post my unsolicited opinion about K8s here, as an SWE+SRE who used it heavily for about 1.5 years on GCP. It's a very cool system. I completely understand why people half-jokingly call it a "distributed operating system." It does a lot of things related to the lifecycles of various state (secrets, storage, config, deployments, etc). However, I believe it goes way too far into putting infrastructure into…

The problem is that few people seem to understand the infrastructure as code concept, and essentially break the core k8s declarative architecture with imperative workflows that look just like the bash script install insanity we left behind. Workflows that are encouraged by tools like Helm and examples that create k8s objects on the fly without even creating much less retaining the "code" part of IaC.

It turns a tool that escaped the tyranny of endlessly mutating blessed servers with immutable, contained services and unified declarative life cycles, back into an imperative mess of magical incantations that must be spoken in just the right way.

Kubernetes is simple when used as designed, but staggeringly complicated when forced into the mutable imperative workflows it was expressly designed to prevent.

Re: Kubernetes for Developers Who Know How to Develop

#58
post #18

Why does everyone keep thinking developers need to now about K8S? Just be glad if your infra/DevOps/platform teams abstract this away from you and you don't have to deal with this insanity.

You'll still have to write all the yamls to deploy your app to k8s. Your ops team wont be analysing those requirements for your app.

Re: Kubernetes for Developers Who Know How to Develop

#59
post #18

Why does everyone keep thinking developers need to now about K8S? Just be glad if your infra/DevOps/platform teams abstract this away from you and you don't have to deal with this insanity.

Honest question: why do we need wholly separate devops/infra teams as opposed to just one expert to teach the other devs if K8s was supposed to make IaC so efficient?

Re: Kubernetes for Developers Who Know How to Develop

#60
post #18

Why does everyone keep thinking developers need to now about K8S? Just be glad if your infra/DevOps/platform teams abstract this away from you and you don't have to deal with this insanity.

Honest question: why do we need wholly separate devops/infra teams as opposed to just one expert to teach the other devs if K8s was supposed to make IaC so efficient?

The same reason frontend and backend teams exist. At a certain point it makes sense to have centralized teams focus on specific verticals than requiring everyone to learn/know about everything. As with any tools, there are right and wrong ways of using it and using the wrong tool for the job can sometimes be more painful than not using it at all.
Post reply on HN