-
-
Notifications
You must be signed in to change notification settings - Fork 15.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nixos/k3s: add initial k3s service #84783
Conversation
Looks very similar to what I have, nice work! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would like to see a package option exposed, but LGTM!
It might make sense to separate server and agent to corresponding modules (and probably systemd units).
|
e27a5b5
to
45f9f80
Compare
Thanks for all the help cleaning this up @misuzu! I think I made all the improvements you suggested, and it looks quite a bit better for it. On whether we should split agent and server, I'm not totally sure the right thing to do there. I do think it makes more sense to keep it as one systemd service at least. The upstream documentation / installer assumes it's "k3s.service", so it makes it less surprising if "systemctl status k3s.service" etc works on nixos too. Because of the above, I ended up with the single config structure and single module. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for you contribution! This is a nice first module;)
Could you add a NixOS test for this module? You could for instance look at the docker test implementation: https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/docker.nix
Type = "notify"; | ||
KillMode = "process"; | ||
Delegate = "yes"; | ||
LimitNOFILE = "infinity"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure we want infinity everywhere. Is it required to make k3s working? A user really wanting this could still override these values.
So, if this is not strictly required, could you remove all these infinity
values?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not strictly required, but it's often what you want I think.
If you're using the builtin containerd runtime in k3s, you'll hit nofile limits pretty quickly if you run a lot of pods. I removed it for now since I'm not totally confident in this.
245731b
to
17ce3ec
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just two small changes needed, but everything else seems ok. Thanks!
This is a single-node test. Eventually we should also have a multi-node test to verify the agent bit works, but that one's more involved.
Now that the assertion enforces their presence, we dont' need to use the typesystem for it.
I think I made the changes you requested @offlinehacker, and I also added a test (though I only ran it a couple times, so beware it may have some inconsistent flake or race). |
@euank You also need to reference the test in |
@GrahamcOfBorg test k3s |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution!
Motivation for this change
I thought that others might find this service definition handy! I'll use it whether we land it in the tree or not.
Things done
I added a k3s service with a few options that I personally find handy.
Note that this is my first nixos module, so it's very likely I'm missing something I should do. I don't know if I need to do more for docs, or if there's more testing I need to do.
I would definitely appreciate any pointers for stuff I might have missed or should do for a new module. If there's an exemplary pull request I could mimic, I'd be happy to take inspiration from that.
Testing done
I tested this on my nixos machine with the following config:
With that configuration, running
sudo k3s kubectl get pod
and such worked as I'd expect.