Sidecar注入必须依赖Kubernetes准入控制机制，如MutatingWebhookConfiguration或服务网格声明式注入（如linkerd.io/inject: enabled），手动写死Pod spec属静态绑定，无法支持动态策略、条件注入与版本灰度等生产需求。
Sidecar 注入不是“加个容器就完事”，它依赖 Kubernetes 的准入控制机制，必须走 MutatingWebhookConfiguration 或服务网格的声明式注入（如 linkerd.io/inject: enabled），手动写死在 Pod spec 里属于静态绑定，无法满足动态策略、条件注入、版本灰度等生产需求。
用 Linkerd 实现零配置 Sidecar 注入
Linkerd 是最轻量、对 Go 应用侵入最小的服务网格方案。它的注入完全基于 annotation，不依赖 Istio 那套复杂的 CRD 和 control plane。
- 注入只需在 Deployment 的
metadata.annotations中加一行：linkerd.io/inject: enabled - Linkerd 的
linkerd-proxysidecar 会自动注入到每个容器前，且默认启用 mTLS 和 metrics - Go 应用无需修改任何代码，HTTP/GRPC 流量默认被透明拦截（proxy 默认监听
localhost:4143）
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-go-app
annotations:
linkerd.io/inject: enabled # ← 关键开关
spec:
template:
spec:
containers:
- name: app
image: my-go-app:v1.2.0
ports:
- containerPort: 8080
注意：Linkerd 的 proxy 默认只劫持 outbound 流量；若 Go 应用需调用其他服务，确保它使用标准 HTTP client（如 http.DefaultClient），不要硬编码 localhost:port 直连。
自己写 MutatingWebhook 注入时，caBundle 怎么填
MutatingWebhookConfiguration 中的 caBundle 不是随便填的 Base64，它必须和 webhook server 的 TLS 证书链一致，否则 kube-apiserver 拒绝调用。
- 最可靠的方式是用
openssl提取 service 对应的 secret 中的 CA：kubectl get secret -n default mutating-webhook-server-secret -o jsonpath='{.data.ca\.crt}' | base64 -d - 如果用自签名证书，别漏掉中间 CA；用 cert-manager 签发的话，直接取
cert-manager.io/v1Certificate 的status.ca - 错误现象：
admission webhook "sidecar-injector-webhook.example.com" denied the request: failed to connect to webhook，基本就是caBundle不匹配或证书过期
Sidecar 容器和 Go 主容器之间怎么通信
它们共享同一个 Network namespace，所以：
- 可以直接用
localhost通信，比如 Go 应用向localhost:9090发日志，sidecar 在该端口监听 - 不要假设 sidecar 启动比主容器快；Go 应用启动时若立即连
localhost:9090，大概率失败 - 推荐做法：
- Go 主容器加
readinessProbe，探测 sidecar 是否 ready（例如 HTTP GET<a href="https://www.php.cn/link/614104ba3125943285d47bbd60f5b6ed">https://www.php.cn/link/614104ba3125943285d47bbd60f5b6ed</a>） - 或在 Go 启动逻辑里做重试（最多 5 秒，指数退避），避免 crashloop
- Go 主容器加
OpenKruise SidecarSet 适合什么场景
SidecarSet 是阿里云 OpenKruise 提供的集群级 Sidecar 管理能力，它绕过了 admission webhook，直接 patch Pod spec，适合：
- 需要统一管控大量 Pod 的 sidecar 版本（比如所有 Java/Go Pod 统一升级 log-agent 到 v2.3）
- 要求 sidecar 与业务 Pod 生命周期解耦（Pod 重建时 sidecar 配置可独立更新）
- 不想部署 webhook 服务，也不愿依赖服务网格控制平面
但要注意：SidecarSet 不支持 per-Pod 条件注入（比如只给带 env: prod label 的 Pod 注入），这种粒度还得靠 MutatingWebhook。
真正的难点不在“怎么加容器”，而在于：sidecar 的资源限制是否合理、退出行为是否影响主容器重启、日志和指标是否混在一起难以排查——这些细节一旦忽略，上线后问题会藏得很深。
