为何无法在同一集群中以ClusterIP服务运行ImagePolicyWebhook？

按照kube-image-bouncer的说明操作，但未在主机或Docker中部署，而是将其配置为同一集群内的ClusterIP服务（仅作为练习）。服务本身在Pod内访问正常：

mark@cks-master:~ $ k exec test -- curl -s https://kube-image-bouncer.kube-image-bouncer.svc/image_policy --cacert /webhook.pem && echo
{"message":"Method Not Allowed"}
mark@cks-master:~ $

完成所有必要配置并修改kube-apiserver静态Pod后，执行创建Pod命令时出现域名解析失败错误：

mark@cks-master:~ $ k run test2 --image nginx
Error from server (Forbidden): pods "test2" is forbidden: Post "https://kube-image-bouncer.kube-image-bouncer.svc/image_policy?timeout=30s": dial tcp: lookup kube-image-bouncer.kube-image-bouncer.svc on 168.63.129.16:53: no such host
mark@cks-master:~ $

原本以为准入控制器由kube-controller-manager运行（即运行在Pod中），应该能正常解析集群内服务域名，但实际出现了解析失败，需要解释原因。

• 调用准入webhook的是kube-apiserver，而非kube-controller-manager：你混淆了组件职责，准入控制器的触发逻辑是kube-apiserver负责的——当你提交创建Pod的请求时，kube-apiserver会直接调用配置的webhook服务，全程和kube-controller-manager无关。
• kube-apiserver静态Pod的DNS环境和普通Pod不同：kube-apiserver作为集群核心组件，它的静态Pod默认使用节点的系统DNS（也就是错误日志里的168.63.129.16这个外部DNS服务器），而非集群内部的CoreDNS服务。而kube-image-bouncer.kube-image-bouncer.svc是集群内部的服务域名，只有CoreDNS能解析，节点的外部DNS根本没有这条记录，自然解析失败。
• 普通Pod能解析的原因：集群内的普通Pod默认会把DNS服务器指向CoreDNS的ClusterIP（通常是10.96.0.10），所以可以正常解析集群内部的服务域名，这和kube-apiserver的DNS环境完全是两回事。

• 直接使用服务ClusterIP：把webhook配置里的域名替换成kube-image-bouncer服务的ClusterIP，kube-apiserver可以通过IP直接访问服务，跳过DNS解析环节。
• 修改kube-apiserver的DNS配置：在kube-apiserver的静态Pod YAML中添加--dns-server参数，指向集群CoreDNS的ClusterIP，让kube-apiserver使用集群内部DNS来解析服务域名。
• 改用NodePort/LoadBalancer暴露服务：但这不符合你将服务部署为ClusterIP的练习初衷，不推荐。

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