Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear friend, you have built a Kubernetes (2024)

macchaffee.com

Post reply on HN
Print view View original

91–100 of 183 posts

Re: Dear friend, you have built a Kubernetes (2024)

#91

Post by vbezhenar »

et1337 wrote: post #4

The saddest part about Kubernetes is… after you set it all up, you still need a hacky deploy.sh to sed in the image tag to deploy! And pretty soon you’re back to “my dear friend you have built a Helm”. And so the configuration clock continues ticking…

I don't understand you.

For very simple deployments, you don't need anything at all. Just write manifests and use `kubectl apply`. You can write `deploy.sh` but it'll be trivial.

If you want templating, there are many options. You can use `sed` for the most simple templating needs. You can use `cpp`, `m4`, `helm` or `kustomize`. I, personally, like `kustomize`, but `helm` probably not the worst template engine out there.

Kustomize is even somewhat included into basic kubernetes tooling, so if you want something "opinionated", it is there for you. It works.

Re: Dear friend, you have built a Kubernetes (2024)

#92

Post by r_lee »

wernerb wrote: post #34
Dedime wrote: post #23

PREACH! I run K8s at home. I used to do docker-compose - and I'd still recommend that to most people - but even for my 1 little NUC with 4vcpu / 16Gi Homelab, I still love deploying with K8s. It's genuinely simpler for me. If anyone's looking for inspiration, my setup: * ArgoCD pointed to my GitLab repos * GitLab repos contain Helm charts * Most of the Helm charts contain open-source charts as subcharts, with version…

A reason not to run k8s is if you want your server to reach C10 idle states. The k8s control plain with its polling and checking are quite heavy on the mostly idle server. I have reverted to just use Nixos and oci podman containers. Everything is declarative and reproducible

another one is swap. UnlimitedSwap was deprecated and you can now only use LimitedSwap which restricts how much swap you can use, so you can't take full advantage of zram, which sucks for those looking to run lean

Re: Dear friend, you have built a Kubernetes (2024)

#93

Post by vbezhenar »

supriyo-biswas wrote: post #24
srcreigh wrote: post #17

Earlier quoted context omitted.

Seems to be a case of the XY problem. What do you need cleanups and hooks for?

Cleanups: I want to do a `helm uninstall` and have all the manifests go away at once instead of looking around for N different resources. Hooks: I want to apply my database migrations and populate the database with static datasets before I deploy my application, without having my CI connect to the database cluster (at places I've worked, the CI cluster and K8s cluster were completely separate).

Regarding cleanups: I'm using flux CD with kustomize. It tracks resources that it created. If I delete manifest from my repository, flux will delete resources that were created from these manifests. For me that's pretty much the ideal workflow.

Regarding hooks: I don't know. All applications that I've used, implemented migrations internally (it's usually Java with Flyway), so I don't need to think about it. One possible approach could be to use flux CD with Job definition. I think that Flux will re-create Job when it changes. So if you change image tag, it'll re-create Job and it'll trigger Pod execution. But I didn't try this approach, so not sure if that would work for you.

Re: Dear friend, you have built a Kubernetes (2024)

#94

Post by r_lee »

stavros wrote: post #85
subhobroto wrote: post #84

Earlier quoted context omitted.

right - that's precisely what I meant. I read your comment "Containers are just statically-linked programs for the rest of us." as "containers can be replaced by statically-linked programs". If you didn't imply that, I apologize. If you did mean that, I disagree with you precisely because your point works if you only care about dependency management - it falls apart on system state. A static binary is a process on th…

Oh, no, I meant that containers serve the same purpose as statically linked programs for languages that can't do that. Eg if you want to deploy a Python codebase, a container is a good way to include all dependencies. I didn't mean "containers don't have any advantages compared to statically linked programs".

I 100% thought you were yelling a the clouds lol. see it way too often on HN

Re: Dear friend, you have built a Kubernetes (2024)

#96

Post by vbezhenar »

blindlobstar wrote: post #43

Why both posts mention docker compose and not mentioning docker swarm. Being using it for my projects for long time. And it's so nice. Similar syntax, easy networking, rollout strategy, easy to add nodes to cluster. You can have one template docker-compose.yaml file and separate deployment files for different envs, like: docker-compose.dev.yaml, docker-compose.prod.yaml I think swarm is really underrated

How do you solve persistence with swarm? Can I deploy postgres with network storage that will mount automatically on node where container is launched?

Re: Dear friend, you have built a Kubernetes (2024)

#98

Post by actionfromafar »

vbezhenar wrote: post #88
cortesoft wrote: post #11

This is obviously slightly exaggerated, but I do feel like this whenever people dismiss Kubernetes as either too complicated or not needed. The response I always got when suggesting Kubernetes is "you can do all those things without Kubernetes" Sure, of course. There are a million different ways to do everything Kubernetes does, and some of them might be simpler or fit your use case more perfectly. You can make diffe…

Yeah, I spent quite a bit of time learning Kubernetes, but now I'd use it to host a static webpage on a single server, over alternatives. It's so awesome.

This is truly interesting to me. Why?

Re: Dear friend, you have built a Kubernetes (2024)

#99

Post by 0x457 »

vbezhenar wrote: post #89
throwawaypath wrote: post #79

Earlier quoted context omitted.

>It is if you stick to standard Kubernetes resources "If you stick to standard C..." No one does, that's the issue. Helm charts that only support certain cloud providers, operators and annotations that end up being platform specific, etc. >now give you default storage classes and ingresses Ingress is being deprecated, it's Gateway now! Welcome to hell, er, Kubernetes.

> Ingress is being deprecated Do you have any links about Ingress being deprecated? Official docs here: https://kubernetes.io/docs/reference/kubernetes-api/service-... There are no mentions about this API being deprecated.

Ingress resource is bassicaly "implementation specific" and isn't portable. It's not deprecated now, but there plans to retire ingress-nginx: https://kubernetes.io/blog/2025/11/11/ingress-nginx-retireme...

Anyway, Ingress resource been in "Migrate to Gateway" state for awhile.

Re: Dear friend, you have built a Kubernetes (2024)

#100

Post by 0x457 »

subhobroto wrote: post #56
echelon wrote: post #40

Earlier quoted context omitted.

You can use k8s on $2/mo digital ocean projects. It probably even works on the free tier of a lot of providers. And there's zero setup. Just a deployment yaml that specifies exactly what you want deployed, which has the benefit of easy version control. I don't get why people are so bent on hating Kubernetes. The mental cost to deploy a 6-line deployment yaml is less than futzing around with FTP and nginx. Kube is the…

> Suddenly you have to become Sysadmin/SRE I don't you made that argument but could a valid conclusion of your comment be that, because Kubernetes is so ubiquitous, using it frees you from being a Sysadmin/SRE?

Frees you from being a sysadmin, but burndens you with being a k8s operator, still an SRE.
Post reply on HN