如何在含/不含Calico的k3s/k3d中查找kube-apiserver并配置准入控制器

在kube-system命名空间的Pod列表中找不到kube-apiserver，是K3s发行版的架构设计决定的：

• K3s作为轻量级Kubernetes发行版，将所有控制平面核心组件（kube-apiserver、kube-controller-manager、kube-scheduler、内嵌etcd）打包为单二进制可执行文件，直接以系统进程的形式运行在节点上，而非像原生K8s那样以静态Pod的形式部署在kube-system命名空间下，因此通过kubectl get pods查询时，自然不会在Pod列表中看到对应组件。
• 针对k3d场景：k3d的本质是将K3s服务托管在Docker容器内，每个k3d server节点对应的Docker容器，就是一个运行了完整K3s进程的节点环境，所有控制平面组件都在这个容器的进程空间内运行，不属于K8s自身管理的Pod资源范畴，因此同样不会出现在Pod列表中。

如果需要定位kube-apiserver进程，可通过以下方式验证：

• 裸机/虚拟机部署的单机K3s：在节点上执行ps aux | grep kube-apiserver，即可看到对应进程的完整启动参数
• k3d部署的集群：先通过k3d cluster list获取server节点对应的Docker容器名，执行docker exec -it <容器名> ps aux | grep kube-apiserver即可定位运行中的kube-apiserver进程。

K3s没有像原生K8s那样通过静态Pod清单暴露kube-apiserver的独立配置文件，所有kube-apiserver的启动参数都可以通过K3s自身的配置入口透传，无需手动修改原生K8s场景下的静态Pod yaml文件。
具体操作分两类场景：

新建k3d集群时配置 #

在执行k3d cluster create命令时，通过--k3s-arg参数将准入控制器相关配置透传给K3s server进程，示例命令：

k3d cluster create test-cluster \
  --k3s-arg "--kube-apiserver-arg=enable-admission-plugins=NamespaceLifecycle,NodeRestriction@server:*" \
  --k3s-arg "--kube-apiserver-arg=disable-admission-plugins=MutatingAdmissionWebhook@server:*"

参数末尾的@server:*标识，代表将该配置应用到集群所有server节点上，避免多节点场景下配置不一致的问题。

已创建的k3d集群修改配置 #

对于运行中的k3d集群，可直接进入server节点的Docker容器，修改K3s的全局配置文件/etc/rancher/k3s/config.yaml，加入对应准入控制器配置：

kube-apiserver-arg:
  - "enable-admission-plugins=NamespaceLifecycle,NodeRestriction"
  - "disable-admission-plugins=EventRateLimit"

修改完成后重启容器内的k3s进程，配置即可生效。由于k3d本身定位为轻量化测试环境，直接删除原集群、用带配置的命令重新创建的操作成本更低，也是测试场景下更常用的处理方式。

重要提示：K3s默认会自动启用一批通用准入控制器，手动指定enable-admission-plugins参数时，需要将原有默认启用的插件一并加入配置列表，避免K3s用自定义列表覆盖默认规则，导致原有准入逻辑失效。

内容的提问来源于stack exchange，提问作者Don Rhummy