The current kubernetes module only allows you to set a single DNS
resolver for the kubelet. Historically, this has not mattered as the
value was passed to a cli argument as a string and as per the kubelet's
configuration parsing mechanism, multiple values could be passed as a
comma-delimited string. However, recently, the module was refactored to
make configure kubernetes components via configuration files rather than
the deprecated command-line arguments. These files more strongly-typed
than CLI arguments and to pass multiple values, one must define a list
in the file. When this change was made, an incorrect assumption was made
that only a single DNS server could be specified and forced a
single-item list into this configuration file. We need to introduce a
breaking change to the module in order to allow the user to supply their
own list with however many dns resolvers they wish to use.
Every now and then, kubernetes adds new configuration parameters to the
kubelet configuration. Since this is defined using a nix attrset which
is then converted to json/yaml, it would be nice to have an escape hatch
similar to the extraOpts one that exists for additional CLI arguments.
The typical use case would be to configure new settings before they are
officially supported in the nixos module.
This is a breaking change, requiring users of `featureGates` to change
from a `listOf str` to `attrsOf bool`.
Before:
```nix
featureGates = [ "EphemeralContainers" ];
extraOpts = pkgs.lib.concatStringsSep " " (
[
"--container-runtime=remote"
''--feature-gates="CSIMigration=false"''
});
```
After:
```nix
featureGates = {EphemeralContainers = true; CSIMigration=false;};
```
This is much nicer, and sets us up for later work of migrating to
configuration files for other services, like e.g. has been happening
with kubelet (see: #290119).
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
Allow to set kubelet configuration parameters
via an option. Additionally, expose the
respective options for graceful node
shutdown directly, as it is anticipated to
be used frequently.
This contribution extends the k3s module to
enable the usage of Helm charts and container
images in air-gapped environments. Additionally,
the manifests option allows to specify arbitrary
manifests that are deployed by k3s automatically.
It is now possible to deploy Kubernetes workloads
using the k3s module.
Set assertions to avoid obvious errors.
Eliminate the conflict between default CNI (`cana`) and `NetworkManager`.
Determine whether optional can be used for agent.
Add the option `cisHardening` to enable CIS Hardening.
Set kernel parameters by `boot.kernel.sysctl`.
Using `lib.escapeShellArgs` to make `ExecStart` more resilient to escaping issues.
Using a list of `str` to extra flags.
these changes were generated with nixq 0.0.2, by running
nixq ">> lib.mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> Inherit >> mdDoc[remove]" --batchmode nixos/**.nix
two mentions of the mdDoc function remain in nixos/, both of which
are inside of comments.
Since lib.mdDoc is already defined as just id, this commit is a no-op as
far as Nix (and the built manual) is concerned.
The `authority.file.path` field of a cert spec is
[defined as follows]
(https://github.com/cloudflare/certmgr/tree/v3.0.3#pki-specs):
> if this is included, the CA certificate will be saved here.
It follows the same file specification format above. Use this
if you want to save your CA cert to disk.
So certmgr fails, because each certmgr spec (apiserver,
addonManager, ...) wants to manage the file at the `cert.caCert`
location. However, the `authority.file.path` field is not needed
for generating a certificate, as the certificate is generated by
the CA, which is reachable at `authority.remote` (e.g.
https://localhost:8888 with `easyCerts = true`). The
`authority.file.path` field just saves the certificate of the CA
to disk.
