🆕 The Cloud Native Computing Foundation (#CNCF) has welcomed #k0s into its Sandbox program!
k0s - a lightweight, zero-friction Kubernetes distribution - has been gaining adoption in edge computing and resource-constrained environments, and it now joins fellow lightweight distribution k3s in the Sandbox.
Dive deeper: https://bit.ly/3HoLWhV
Що не так з #k3s ?
Раніше я писав, що у мене є питання до k3s.
Ось на скріні одне з них.
Після оновлення proxmox, k3s в LXC перестав запускатись з дивними проблемами.
Вилікував просто:
Відновив LXC контейнер з бакапів на 3 дні раніше.
І саме лікування також додає питання до k3s.
За #k0s продовжую спостерігати.
Питань поки немає.
🚀 Since k0s v1.33, you can now build #k0s on #RISCV! We don't ship precompiled executables yet (still working on proper CI support), but if you've got a RISC-V box, just clone the repo, run make, and launch k0s: #Kubernetes like on any mainstream hardware. Give it a spin and let us know how it goes! @ncopa
These are good news for all of us developers we implement applications on top of Kubernetes 👇🏼
https://www.cncf.io/blog/2025/05/20/a-milestone-for-lightweight-kubernetes-k0s-joins-cncf-sandbox/
вирішив перенести свої сервіси з k3s на k0s.... і зіштовхнувся з дивовижними проблемами...
На лоад-балансері блокується порт 80 та 993...
Може ще якісь блокуються, складно сказати, але що з цим робити поки зовсім не знаю.
Якось воно працює дуже дивно.
Якщо хтось може щось підказати - буду радий.
I now have a tiny #Kubernetes to play with. I'm using #k0s with one controller VM and two workers, one VM and one bare metal, all running on Debian.
So far I installed cilium (although I'm not sure why I did that, tbh) and set up democratic-csi such that I can create PersistentVolumeClaims on my big ZFS array over NFSv4.
I think my next step is to install the #Tailscale operator and actually spin up a service.
Everything has "test" in the name so probably after I get a service running I'll tear it all down and make a for-realsies cluster.
So I managed to get #Forgejo jobs running in a way that I'm happy enough with. The main concern is that they're isolated as possible. The current runner has a scary warning on it that it's in alpha and shouldn't be considered secure.
The runner instance is Debian running in an #lxd --vm on my laptop (I didn't want to consume resources on the server since it's small). In this instance I have #k0s running, which is a slimmed down #Kubernetes, which is running #Codeberg 's runner pod. This has three containers. One to register the runner, then two others that are always running, the runner itself and #Docker -in-Docker . You can replicate this entire setup so that each runner gets its own DinD which is completely separated from the others.
Each runner checks for a single job in a loop, and once a job is completed then the docker server is pruned, and the runner shuts down. Then k0s will automatically restart it. This isn't perfect but it's better than runner processes which never shut down, because the docker cache will linger and others can look at it to spy on your jobs.
From this week's ADMIN Update newsletter, @madkiss explores production-ready mini-Kubernetes installations
https://www.admin-magazine.com/Archive/2024/83/Production-ready-mini-Kubernetes-installations
#Kubernetes #containers #K8s #k0s #K3s
#k0s is finally on its way to becoming a #cncf project: The vote to accept it as a sandbox project has passed! https://github.com/cncf/sandbox/issues/125#issuecomment-2595023470
Deployed the first user-facing service to cons.town's kubernetes cluster:
https://hello.cons.town
The cool thing about the cluster that it's deployed delcaratively with Guix. metallb used for making services available outside of kubernetes. cert-manager for certificates management and nginx-ingress for tls termination.
Anything else cool I forget to mention?
Fully-declarative deployment of 2-nodes Kubernetes cluster :kubernetes: successfully done with Guix :guix:!
The only manual step was generating a worker token to connect a worker kubernetes node to the controller and copying it to the respective host. It can be automated, but not today.
Check out the source code: https://cons.town
Imagine, what kind of fun we can have with it now?
@bagder looks like the CFP is not open yet.
I wonder if something #AlpineLinux or #k0s/#kubernetes would be of interest for this event
Trying to deploy kubernetes cluster with Guix.
guix deploy fails multiple times in different ways :/
The most annoying part that it somehow makes ssh daemon to stop responding, so I have to restart VPS after such occasions. Also, the deploy of 0-diff system is very slow for some reason.
Another funny observation: shepherd doesn't respond to `herd status` during guix deploy.
Definitely need to find out why it happens, but today goal is to get k8s cluster running.
As #Kubernetes complexity has decreased (#k8s, #k3s, #k0s) and became more manageable, it can be recommend with more confidence.
Some time ago consultants would say:
> Kubernetes is not the right solution for your problem.
Then later:
> You probably need Kubernetes in the near future.
And nowadays its:
> We definitely recommend Kubernetes for your use case.
And because I'm bored, a twofer. Abusing tailscale to achieve k0s backups. https://slush.ca/posts/backup-auth-via-ts/ #k0s #tailscale
Finally, use LoadBalancer services on your bare metal k8s, and access externalIP just like you’d get on the cool kids clouds. https://slush.ca/posts/cilium-superpowers/ #k0s #cilium
Next week I'm open for another community pair programming session.
It's a nice opportunity to exchange knowledge, gather feedback and progress on a awaiting tasks.
There are three topics:
- Interactive development with Guile :: [n]REPLs, #emacs. What we can borrow from #clojure, #commonlisp?
- Guile Testing Framework :: srfi-64, clojure.test, kaocha for guile.
- Guix-based DevOps :: #kubernetes, #k0s, #k8s, #guix deploy.
Ping me if you want to work and brainshtorm on some of topics above.
Decided to avoid HashiCorp Nomad and go with k0s on top of Guix System.
The nomad's community is much smaller than kubernetes', probably so small that they didn't even fork the project after license change.
License is a actually a big deal. Source available software is a bit better than proprietary, but still very far from FOSS. The company potentially going bananas is only one of many problems.
