aggregationConfig 不生效是因为 Kubernetes 1.22+ 默认禁用 API 聚合层，必须显式启用聚合器并确保证书链完整、requestheader 配置正确（如 OU 匹配、headers 名称适配 1.25+ 变更）。
为什么 aggregationConfig 不生效？Kubernetes 1.22+ 的配置陷阱
新版 Kubernetes（1.22 起）默认禁用 API 聚合层，光写 aggregationConfig 文件或配 --enable-aggregator-routing=true 没用。核心是：API Server 启动时必须显式启用聚合器，且证书链必须完整。
-
--requestheader-client-ca-file和--proxy-client-cert-file必须指向真实、可验证的 CA 和代理客户端证书；自签名但未被 kube-apiserver 信任的证书会导致403 Forbidden或no endpoints available for service -
--requestheader-allowed-names必须包含你自定义 API Server 的subject.OU（不是 CN），常见漏掉导致x509: certificate signed by unknown authority实际却是 OU 不匹配 - Kubernetes 1.25+ 中
--requestheader-group-headers默认值从X-Remote-Group改为X-Remote-Groups，若你的聚合 server 仍按旧逻辑发头，会丢失 RBAC 组信息
如何让 CustomResourceDefinition 和聚合 API 共存不冲突？
CRD 和聚合 API 本质不同：CRD 是声明式资源，聚合 API 是独立运行的 HTTP server。它们能共存，但路径和权限容易打架——尤其当你用相同 group 名（如 example.com）时。
- 聚合 API 的
APIService对象里spec.group必须全局唯一，不能和已有 CRD 的spec.group重名，否则 kube-apiserver 拒绝注册并报错：the APIService "v1alpha1.example.com" is invalid: spec.group: Invalid value: "example.com": group name conflicts with an existing resource - 如果你只是想扩展 CRD 行为（比如加个
/status子资源或自定义验证 webhook），优先用CustomResourceValidation+ConversionWebhook，而不是上聚合层——后者要维护额外进程、证书、RBAC，复杂度高一个量级 - 真要用聚合 API 替代部分 CRD 功能（如需要非 RESTful 接口、流式响应、长连接），确保
APIService.spec.version和你 server 响应的apiVersion严格一致，大小写敏感
Go 中实现 http.Handler 时，为什么 k8s.io/apiserver 包比裸写 net/http 更稳？
直接用 net/http 写 handler 看似简单，但会漏掉 Kubernetes API 协议的关键契约：认证透传、请求审计、版本协商、Content-Type 自适应、甚至 basic error formatting（比如返回标准 metav1.Status 结构）。用 k8s.io/apiserver/pkg/server 提供的框架能省掉大量胶水代码。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须继承
apiserver.InstallAPIGroup流程，否则APIService注册后 kube-apiserver 不会把请求路由过来，现象是curl -k https://localhost:6443/apis/example.com/v1alpha1/xxx返回404 page not found -
GenericAPIServer初始化时需调用InstallLegacyAPIGroup或InstallAPIGroup，并传入你自己的APIGroupInfo，其中VersionedResourcesStorageMap要填满——哪怕只读，也得给每个 version 返回一个空rest.Storage实现，否则启动失败 - 别自己解析
Authorization: Bearer xxx；用authenticationclient.NewImpersonatingClient复用集群认证链，否则无法支持impersonate场景，kubectl --as=system:serviceaccount:default:test会静默失败
调试 APIService “FailedDiscoveryCheck” 状态的三步定位法
APIService 卡在 FailedDiscoveryCheck，说明 kube-apiserver 尝试访问你的聚合 server 的 /openapi/v2 或 /swagger.json 失败，但错误日志藏得深，不能只看 kubectl get apiservice。
立即学习“go语言免费学习笔记（深入）”；
- 先查
kubectl get apiservice v1alpha1.example.com -o yaml，看status.conditions里的message字段，常含具体 HTTP 状态码（如503 Service Unavailable）或 TLS 握手失败提示 - 用
kubectl cluster-info dump | grep -A5 -B5 "example.com"搜 kube-apiserver 日志片段，重点关注failed to retrieve openapi spec后面的 URL 和 timeout 值（默认 10s，超时即判失败） - 手动模拟 kube-apiserver 请求：
curl -k --cert /var/run/secrets/kubernetes.io/serviceaccount/tls.crt --key /var/run/secrets/kubernetes.io/serviceaccount/tls.key https://<your-service>.default.svc.cluster.local:443/openapi/v2</your-service>，注意必须用 service account 证书，且 host 必须匹配 server 证书的dnsNames
最常被忽略的是：聚合 server 的 HTTPS 服务必须监听 0.0.0.0:443（不是 127.0.0.1），且证书的 dnsNames 至少包含 your-service.default.svc 和 your-service.default.svc.cluster.local ——少一个，kube-apiserver 就拒绝建连。
