social.tchncs.de is one of the many independent Mastodon servers you can use to participate in the fediverse.
A friendly server from Germany – which tends to attract techy people, but welcomes everybody. This is one of the oldest Mastodon instances.

Administered by:

Server stats:

3.9K
active users

#k8s

19 posts15 participants0 posts today

Thank y'all for the first day of #Rejekts2025 with great talks and inspiring conversations!

I am excited that I got a spot for the #LightningTalk​s.
Looking forward to present you #Kubenix a tool leveraging #NixOS modules to declare #K8s workloads fully declarative.
I will also show how its #Helm integration essentially bridges the #CloudNative and #Nix ecosystem effectively, while offering additionally type safety.

See you at 18:15 in the hall #TheNash!

I don't use containerization ( #docker, #k8s or whatever) on my servers, I only use distrib packages or sources of the app I want to install... the old way, so.
Does dockerized applications need more resources? or is it insignificant?
Usually, I install small servers.

Dear #LazyWeb / #lazyfedi,

I'm new to #k8s and am wondering how to handle templating large amounts of config files. I couldn't find anything super useful in my search so I have an #Ansible sidecar I run to generate the kustomizations and config files. My most recent Ansible change was 30 lines, it resulted in changing 5,000 lines of YAML which will further be fed to Kustomize.

There has to be a better way?

I've heard about Helm, Yoke, KRO, and using an operator pattern. My understanding of those options is:

* Helm - My Org recommends avoiding (I don't know why)
* KRO - Not stable, but FFS neither is Kustomize
* Yoke - Almost kinda operator pattern
* Operator Pattern - This feels like reinventing a fucking config manager (ala #Ansible, #Puppet, #Chef, #Saltstack) for every fucking project. What new hell this is.

I'm hoping I'm missing something because the only workable flow for this workload is:
1) Create ansible roles/playbook to generate the kustomization.yaml and resources
2) Generate those kustomizations, check them into git
3) Use Kustomize via GitOps to expand the YAML even more
4) Push a metric fuckton of YAML to production

I'm losing my mind over here.

The new k8s bug has a lame name: IngressNightmare. *sigh* Where's the clever word play?

Too many people relying on simple appending Nightmare to the name of the attack surface these days... might as well get an LLM to name them if we're just going to copy the last bug name all over again.

Anyway, you can read about it here:

wiz.io/blog/ingress-nginx-kube

#threatintel, #k8s

wiz.io · Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz BlogWiz Research uncovered RCE vulnerabilities (CVE-2025-1097, 1098, 24514, 1974) in Ingress NGINX for Kubernetes allowing cluster-wide secret access.

🚀 #Kubernetes #monitoring Made Easy with VictoriaMetrics Cluster

Our technical #guide walks you through setting up a VictoriaMetrics cluster using Helm charts, collecting k8s metrics via service discovery, and visualizing your data effortlessly.

🟣 What you'll learn:

✅ Deploying #VictoriaMetrics in Kubernetes with #Helm

✅ Scraping #metrics from #k8s components

✅ Storing & visualizing data in VictoriaMetrics #tsdb

docs.victoriametrics.com/guide