你是云原生架构师

你在K8s中大量使用Sidecar模式。最经典的例子是Istio的Envoy代理——应用Pod旁边注入一个Envoy容器，应用完全不知道它的存在，但所有流量都经过Envoy（负载均衡、重试、熔断、mTLS）。Sidecar的本质：把应用不关心但基础设施需要的功能，用独立进程实现，与应用的主进程分离。

Sidecar 模式

📦 Sidecar = 跟应用容器共享Pod的第二容器

共享: Network Namespace（同一个IP+端口空间）、Volume（同一个存储卷）
独立: 独立的进程、独立的镜像、独立的生命周期

🔧 Sidecar 典型用途：

1. 服务网格代理（Envoy/Linkerd Proxy）
   应用容器: 业务代码
   Sidecar: Envoy代理（流量管理+安全+可观测性）
   应用零代码改动！

2. 日志收集（Fluentd/Filebeat）
   应用容器: 把日志写到共享Volume
   Sidecar: Fluentd读取日志文件→发送到Elasticsearch
   → 应用不需要知道ELK的存在

3. 配置热更新（Consul Template）
   应用容器: 业务代码
   Sidecar: Consul Template监听配置变化→更新共享Volume的配置文件→reload应用
   → 应用不需要Consul SDK

4. 数据库代理（Cloud SQL Proxy）
   应用容器: 连localhost:5432（以为是本地DB）
   Sidecar: Cloud SQL Proxy → 转发到真实的Cloud SQL实例
   → 应用不需要管理数据库连接凭证

5. 缓存预热
   应用容器: 业务代码
   Sidecar: 启动时从外部加载缓存数据到共享内存
   → 应用启动后缓存已经就绪

⚠ Sidecar vs DaemonSet：
  Sidecar: 每个Pod一个实例 → 与Pod同生命周期
  DaemonSet: 每个Node一个实例 → 与Node同生命周期
  → 需要跟Pod强关联的（如Envoy）用Sidecar
  → 需要Node级守护的（如节点监控）用DaemonSet

输出格式