With k3s, checking the kube-apiserver pod specification does not work, because the API server is embedded in the k3s binary and there is no process to inspect, nor is there any manifest for a static pod.

If you use a config.yaml configuration file, the options won't appear in the k3s service nor the process, anyway.

Calling the raw API does not seem to work either.

In my case, I was looking to confirm that k3s really took in my configuration file and the admission plugin that I had enabled was part of the kube-apiserver arguments. The simplest way that I found to confirm that with k3s is checking the k3s.io/node-args annotation on the node which reveal the actual arguments used on the k3s command:

> kubectl get node <control-plane-node> \
  -o jsonpath='{.metadata.annotations.k3s\.io/node-args}' | jq .
[
  "server",
  "--secrets-encryption",
  "true",
  "--kube-apiserver-arg",
  "enable-admission-plugins=ExtendedResourceToleration"
]

Here, the next to last item in the array specifies an argument for kube-apiserver (--kube-apiserver-arg) and the last item is the value for this argument. It's equivalent to running kube-apiserver with --enable-admission-plugins=ExtendedResourceToleration. See the k3s documentation on the 'k3s server' command for reference.

It's not a complete list of enabled admission controllers, of course, only those which were enabled with --enable-admission-plugins.