kubernetes 不提供传统编程意义上的依赖注入机制，而是通过 configmap/secret 注入配置、init containers 等待依赖就绪、探针校验健康状态、service/dns 实现服务发现，以基础设施层编排实现声明式依赖管理。
Kubernetes 本身不提供传统编程意义上的“依赖注入（DI）”机制，比如像 Spring 或 Dagger 那样在运行时动态构造对象图并注入依赖实例。它管理的是容器化工作负载的**声明式依赖关系**，核心目标是确保服务可用、配置就绪、启动有序——这些都通过基础设施层的编排能力来实现，而非应用代码内的 DI 容器。
用 ConfigMap 和 Secret 注入配置依赖
这是最常用、最符合 Kubernetes 设计理念的方式。把数据库地址、API 密钥、功能开关等外部依赖参数，从镜像中剥离，以 ConfigMap 或 Secret 形式定义在集群中，再挂载进容器：
- 作为环境变量：在 Pod 模板中用 envFrom 引用 ConfigMap，或用 env.valueFrom.configMapKeyRef 精确注入单个键
- 作为文件挂载：用 volumes + volumeMounts 将整个 ConfigMap 挂载为 /etc/config 目录，应用直接读取文件
- Secret 同理，但内容自动 Base64 编码，适合敏感数据
用 Init Containers 实现启动时依赖等待
当一个 Pod 必须等另一个服务（如数据库、消息队列）已就绪才能启动主业务容器时，Init Container 是标准解法：
iTop - IT Service Management & CMDB
下载
iTop代表IT运营门户。它是一个完整的开源和基于Web的IT服务管理平台，包括一个完全可定制的配置管理数据库（CMDB），一个帮助台系统和一个文档管理工具。它符合ITIL标准，并且由于大量的附加组件和Web服务，可以轻松定制和扩展以与您的IT集成。iTop还提供了批量导入工具，以帮助您更加高效。项目源代码已迁移到https://github.com/Combodo/iTop
- 它会在主容器启动前顺序执行，失败则重试或阻断后续启动
- 可运行 curl -f http://mysql:3306/health、nc -zv redis:6379 或调用 k8s-wait-for 工具
- 无需修改业务代码，解耦清晰，运维友好
用探针（Probes）表达运行时依赖健康状态
Readiness Probe 和 Startup Probe 不是“注入”，但它们让 Kubernetes 知道：“这个容器是否已准备好承接依赖它的上游流量”：
- Readiness Probe：返回失败时，Kubernetes 自动从 Service 的 Endpoint 列表中剔除该 Pod，避免上游调用打到未就绪实例
- Startup Probe：适用于启动慢的应用（如 JVM），防止 Liveness Probe 过早杀死进程；只有它成功后，其他探针才开始工作
- 典型路径如 /health/ready 可主动检查下游 DB 连接、缓存连通性等，把依赖健康纳入自身就绪判断
用 Service 和 DNS 实现服务发现式依赖寻址
Kubernetes 内置 DNS 服务（CoreDNS）让容器能通过 service-name.namespace.svc.cluster.local 访问依赖服务，这是依赖注入的“地址层”基础：
- 业务容器只需写死 service 名（如 postgres），无需知道后端 Pod IP 或端口
- Service 的 ClusterIP 或 Headless 模式配合 Endpoints，自动完成负载均衡与故障转移
- 配合 NetworkPolicy，还能限制哪些 Pod 能访问哪些依赖服务，强化依赖边界
