Configuration to automatically restart API servers like K8s?

[TheOnlyWei]

Is there a configuration or simple code change to automatically restart K3s API servers, i.e., k3s.service, when we do a service account signing key rotation by following the instructions in the link below?
https://docs.k3s.io/cli/certificate#service-account-issuer-key-rotation

Currently, we need to do this manually, which requires a pod with host access to make a restart call via chroot or D-bus, which requires elevated permissions for the pod, especially if AppArmor is present. To minimize the security privileges of my pod, I am trying to figure out if there is some simple code or configuration that I can make so that my K3s control plane nodes will automatically restart its API servers or k3s.service just like when rotating the service account signing key by modifying /etc/kubernetes/manifests/kube-apiserver.yaml and /etc/kubernetes/manifests/kube-controller-manager.yaml in K8s clusters.

[brandond]

The k3s apiserver is embedded in the main k3s process, along with all the other Kubernetes components. In order to restart it, you'll need to restart the k3s service itself.

[TheOnlyWei]

What about a feature for the "watching" feature used by secrets encryption but for service account signing key rotation? Does that comply with K3s designs? If so, should I make a feature request for it?

[dereknola]

Secrets encryption also doesn't restart the k3s service. Upstream k8s supports a hot reload of the encryption-config.json, that's how we able to support the newer k3s secrets-encrypt rotate-keys that comes with alot less restarts than the old prepare, rotate, reencrypt workflow. But its still on the admin to restart the k3s service at the end of the rotate-keys process.

[TheOnlyWei]

@dereknola Is it expected that an admin is the one to always run k3s certificate rotate-ca? If so, wouldn't it make sense to do the API server or k3s.service restart on the admin's behalf automatically since rotation doesn't apply until the API server is restarted? Or is there a use case for the interim state where the API server has not been restarted after a k3s certificate rotate-ca call?

Also, since the requirement is that k3s.service should not be restarted by K3s CLI, would it be feasible to separate the API server from the k3s.service? That way the API server can be automatically restarted during key rotations without requiring the admin to run another command to restart the k3s.service.

[brandond]

would it be feasible to separate the API server from the k3s.service

No. If you want that, don't use K3s. The entire point of K3s is that everything all runs together in one process.