Kubernetes
-
Helm feels utterly broken, am I the only one?
I've been working with Kubernetes since 2015 and I've mangled with handcrafted manifests including almost duplicate manifests for staging/production environments, played around with stuff like Cue, built lots glue (mostly shell script) to automate manifest-handling and -generation and I also enjoy parts of Kustomize. When Helm started to appear it seemed like a terrible hack, especially since it came with the Tiller-dependency to handle Helm-managed state-changes inside of the clusters. And while they dropped Tiller (thankfully), I still haven't made my peace with Helm.
Go-templating it awful to read, a lot of Helm charts don't really work out of the box, charts can be fed values that aren't shown via
helm show values ./chart
, debuggingHelmChart $namespace/$release-$chartname is not ready
involves going over multiple logs spread over different parts of the cluster and I could go on and on. And yet, almost every project that goes beyond offeringDockerfile+docker-compose.yaml
just releases a Helm Chart for their app.Am I the only one who is annoyed by Helm? Have I been using it wrongly? Is there something I've been missing?
In case you're a Helm maintainer: Please don't take it personally, my issue is not with the people behind Helm!
-
Flux v2 just dropped 4d ago
github.com Release v2.0.0 · fluxcd/flux2Highlights This is the first General Availability (GA) release of Flux v2. Flux v2.0.0 comes with the promotion of the GitOps related APIs to v1 and adds horizontal scaling & sharding capabilities ...
- thenewstack.io The First Kubernetes Bill of Materials Standard Arrives
Software Bills of Materials are becoming commonplace as a brick in the wall of code security defense. Now, there's one just for Kubernetes.
The KBOM project provides an initial specification in JSON and has been constructed for extensibilty across various cloud service providers (CSPs) as well as DIY Kubernetes.
-
Asking for advice: Releasing a custom rolling immutable simple distro for Kubernetes
Hello world!
I want to release to internet my custom immutable rolling-release extreme-simple Linux distribution for Kubernetes deployments.
I was using this distribution for about the last 6 years on production environments (currently used by a few startups and two country's public services). I really think that it could be stable enough to be public published to internet before 2024.
I'm asking for advice before the public release, as licensing, community building, etc.
A few specs about the distribution:
-
Rolling release. Just one file (currently less than ~40Mb) that can be bootable from BIOS or UEFI (+secure boot) environments. You can replace this file by the next release or use the included toolkit to upgrade the distribution (reboot/kexec it). Mostly automated distribution releases by each third-party releases (Linux, Systemd, Containerd, KubeAdm, etc).
-
HTTP setup. The initial setup could be configured with a YAML file written anywhere in a FAT32 partition or through a local website installer. You can install the distribution or configure KubeAdm (control-plane & worker) from the terminal or the local website.
-
Simple, KISS. Everything must be simple for the user, this must be the most important aspect for the distribution. Just upstream software to run a production ready Kubernetes cluster.
-
No money-driven. This distribution must be public, and it must allow to be forked at any time by anyone.
A bit of background:
I was using CoreOS before Redhat bought them. I like the immutable distro and A/B release aspect of the CoreOS distribution. After the Redhat acquisition, the CoreOS distribution was over-bloated. I switched to use my own distribution, built with Buildroot. A few years later, I setup the most basic framework to create a Kubernetes cluster without any headache. It's mostly automated (bots checking for new third-party releases as Linux, Systemd, Containerd, KubeAdm, etc; building, testing & signing each release). I already know that building a distribution is too expensive, because of that I programmed few bots that made this job for me. Now days, I only improve the toolkits, and approve the Git requests from thats bots.
Thank you for your time!
-
-
What's the best way for an experienced engineer to learn Kubernetes at depth?
Looking for the best way to learn kubernetes, given that I have plenty of years of engineering (Java, python) and a solid experience with AWS.
any format works - paid/free courses, working through articles, getting started guides, etc..
-
Understanding Kubernetes Pods
For benefit of anyone who needs to go back to the basics. Certainly a need I sense in the Kubernetes community around me.
-
Longhorn: Cloud native distributed block storage for Kubernetes
Tried it out in the past couple of days to manage k8s volumes and backups on s3 and it works surprisingly well out of the box. Context: k3s running on multiple raspberry pi
-
KubeCon + CloudNative North America 2022
CNCF has posted their playlist from all the talks at the 2022 conference in Detroit
- www.zdnet.com Qualys partners with Red Hat to improve Linux and Kubernetes security
Security company Qualys is partnering with Red Hat to bring built-in Cloud Agent security to Red Hat Enterprise Linux CoreOS and Red Hat OpenShift.
-
Kubernetes Ingress Controllers Compared
docs.google.com Kubernetes Ingress ControllersComparison Product/Project,<a href="https://github.com/kubernetes/ingress-nginx">Ingress Nginx </a>,<a href="https://docs.konghq.com/kubernetes-ingress-controller/latest/">Kong</a>,<a href="https://github.com/apache/apisix-ingress-controller">Apache APISIX</a>,<a href="https://azure.microsoft.c...
Kubernetes Ingress Controllers Compared. warning takes you to Google docs