k3s

Expected Behaviour

Change the default cron spec in --etcd-snapshot-schedule-cron (default: "0 */12 * * *"):

--k3s-extra-args '--etcd-snapshot-schedule-cron * * * * *'

Problem

I would like to be able to have different names for my node to help with discovery in tools like k9s.

If I (a) create the cluster and then (b) create the nodes I can achieve this.

But if I need to create the cluster and nodes at the same time i.e. via -agents flag then this is not possible.
And some use cases e.g. per-node volumes are only possible using this approach

Expected Behaviour

When using K8s 1.22 and newer, use the new namespace for ingress, for older use the deprecated API (apiVersion: extensions/v1beta1)

Several apps gener

Is your feature request related to a problem?

Mutating webhooks often use label selectors to determine which resources to process. Since vcluster mutates all the labels on synced resources, this can prevent webhooks in the physical cluster from being able to mutate the physical resources.

In particular we've encountered this issue for synced pods.

Which solution do you suggest?

What we need

In the case of using openelb as the Kubernetes load balancing implementation, the allocation of openelb external-ip-pool can only be viewed on the terminal interface by accessing Kubernetes resources with kubectl. However, more and more kubernetes users are using specific dashboards to operate and manage clusters or workloads, such as KubeSphere. Therefore, the current usage is n

k3s_airgap does not support multiarch. It is possible to specify only one binary for airgap installation. It should be per arch.

If someone were to accidently zarf init --components=k3s twice (it doesn't have to be back-to-back, just before Zarf destroys the first cluster), weird stuff happens that Zarf doesn't handle in the best way.

One of the files that gets copied to the host during the installation of the k3s component is an 'empty-file' that gets placed in the /root/.kube/config. Since k3s/zarf is already runni

Some clusters can be stopped when k3x is started. Users could think the current cluster should be ready, but they would really need to "start" it. We should show a warning saying something like "the current cluster is stopped".