核心在于利用MutatingWebhookConfiguration在Pod创建前动态注入监控Sidecar容器，需满足Kubernetes≥v1.19、启用admissionregistration.k8s.io/v1 API、TLS可信及标签/注解精准触发，并确保Sidecar共享网络、合理挂载卷与资源限制。
核心在于利用 MutatingWebhookConfiguration 在 Pod 创建前动态修改其 spec，注入具备监控能力的 Sidecar 容器（如 OpenTelemetry Collector、eBPF 采集器或自研探针），并确保其与业务容器共享网络和存储上下文。
关键前提条件
必须确认集群已启用并正确配置 Mutating Admission Webhook 能力：
- Kubernetes 版本 ≥ v1.19（推荐 v1.22+）
- API Server 启动参数包含 --admission-control=...,MutatingAdmissionWebhook,...
- 执行
kubectl api-versions | grep admissionregistration.k8s.io/v1应返回 admissionregistration.k8s.io/v1 - 确保 kube-apiserver 与 webhook 服务间 TLS 可信（需有效证书及正确配置 caBundle）
注入逻辑触发控制
避免全局无差别注入，应通过标签或注解实现精准拦截：
- 在目标命名空间打标：
kubectl label namespace prod observability-enabled=true - 或在 Pod 模板中添加注解：
observability/enable: "true" - MutatingWebhookConfiguration 中通过
namespaceSelector和objectSelector精确匹配规则 - 支持排除特定工作负载，例如用
objectSelector.matchExpressions过滤带sidecar.observability/inject: "false"的 Pod
Sidecar 容器注入要点
注入的 Sidecar 必须满足全链路监控对可观测性的基础要求：
-
共享网络命名空间：不设置
hostNetwork: true，依赖默认 Pod 网络，确保能捕获应用容器进出流量 -
挂载必要卷：如
/sys/fs/cgroup（用于进程指标）、/proc（用于主机级指标）、emptyDir（暂存日志或 trace buffer） -
资源限制合理：设置
resources.limits.memory防止探针 OOM 影响业务；CPU 可设为100m起步，按采样率动态调优 -
启动顺序保障：可选加 Init Container 预检端口就绪或配置文件生成，但非必需；主容器应设置
livenessProbe和readinessProbe检查探针健康状态
Webhook 服务实现建议
服务本身应轻量、高可用、低延迟，避免成为 API Server 请求瓶颈：
- 使用 Go 或 Rust 编写，响应时间控制在 2 秒内（Kubernetes 默认超时为 30s，但过长会拖慢部署）
- 解析
AdmissionReview请求中的Pod对象，仅当满足注入条件时才修改pod.spec.containers和pod.spec.volumes - 注入内容建议模板化管理（如 ConfigMap 存储 Sidecar YAML 片段），便于灰度发布与版本回滚
- 记录审计日志（如是否注入、Pod UID、命名空间、决策依据），用于排查漏注入或误注入
