3. 蓝绿发布原理：蓝绿环境定义、流量切换机制、网络隔离要求

蓝绿发布是一种零停机部署策略，通过维护两套完全独立的生产环境（蓝环境与绿环境）来实现安全、快速的版本切换。理解其核心原理是设计CNI网络自动化回滚与防护方案的前提。本章从环境定义、流量切换机制和网络隔离要求三个维度进行深度解析。

3.1 蓝绿环境定义与资源模型

在Kubernetes集群中，蓝绿环境并非物理集群的拆分，而是通过命名空间、标签选择器、Service与Ingress的精准指向，在逻辑上构建的两套互不干扰的应用副本集。

3.2 流量切换机制

流量切换是蓝绿发布的核心动作，其本质是修改流量入口的路由规则，将用户请求从蓝环境平滑迁移至绿环境。切换粒度可分为DNS切换、负载均衡器切换和Kubernetes Service切换三种模式。

3.2.1 基于Kubernetes Service的切换（最常用）

通过更新Service的selector字段，将标签选择器从version: blue改为version: green，实现秒级流量切换。

# 切换前：Service指向蓝环境
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
    version: blue   # 指向蓝环境
  ports:
  - port: 80
    targetPort: 8080

# 切换后：Service指向绿环境
# kubectl patch service myapp-service -p '{"spec":{"selector":{"version":"green"}}}'
spec:
  selector:
    app: myapp
    version: green  # 指向绿环境

3.2.2 流量切换的原子操作步骤

1. 预热验证：绿环境Pod启动后，通过预发Ingress或ClusterIP进行功能、性能与网络连通性验证。
2. 暂停自动扩缩容：锁定蓝绿两环境的HPA（水平自动扩缩容），防止切换过程中因指标波动导致异常扩缩。
3. 执行切换：更新Service selector或修改Ingress后端Service名称。
4. 观察期：保持蓝环境在线，持续监控错误率、延迟、4xx/5xx状态码，观察期通常为10-30分钟。
5. 清理/回滚准备：若观察期无异常，逐步缩容蓝环境；若异常，立即执行回滚（将selector改回blue）。

3.3 网络隔离要求

蓝绿发布对网络隔离的要求远高于普通部署。隔离不当会导致流量错乱、数据污染甚至生产故障。核心隔离要求包括以下三个层面：

3.3.1 东西向流量隔离（Pod间通信）

绿环境Pod在预热阶段不应被蓝环境Pod或集群内部其他服务访问。必须通过Kubernetes NetworkPolicy实现严格的隔离策略。

# 绿环境隔离策略：拒绝所有来自蓝环境的入站流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: green-isolation
spec:
  podSelector:
    matchLabels:
      app: myapp
      version: green
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: myapp
          version: green   # 仅允许绿环境内部通信
    - namespaceSelector:
        matchLabels:
          name: monitoring # 允许监控系统访问

3.3.2 南北向流量隔离（外部访问）

绿环境在切换前不应接收生产用户流量。通过Ingress规则或负载均衡器监听器实现隔离：

• 预发Ingress：绑定独立的域名或Header路由规则，仅允许内部测试人员访问。
• 负载均衡器：为绿环境创建独立的监听器（如端口10080），不绑定生产DNS。
• IP白名单：在CNI或负载均衡层面，限制绿环境的入站源IP仅为测试网段。

3.3.3 数据层隔离

蓝绿环境通常共享同一套数据库或缓存集群。网络隔离要求绿环境在预热阶段不能写入生产数据表：

• 数据库连接：通过配置中心或环境变量，让绿环境连接独立的Schema或带有版本前缀的表。
• 缓存隔离：使用不同的Key前缀（如green:user:123），避免与蓝环境缓存冲突。
• 消息队列：绿环境消费独立的Topic或Consumer Group，防止消息重复消费或丢失。

3.4 网络隔离策略的自动化生命周期

在自动化蓝绿发布流程中，CNI网络策略的创建、激活、切换和回收必须与发布流水线深度集成。下表展示了网络策略在发布各阶段的状态变化：

3.5 网络隔离的常见陷阱与防护建议

• 陷阱1：NetworkPolicy未覆盖所有Pod副本。 绿环境扩容时，新Pod可能因未匹配NetworkPolicy的podSelector而处于无策略状态。防护：使用namespaceSelector或全局默认拒绝策略兜底。
• 陷阱2：Service的externalTrafficPolicy导致源IP透传异常。 切换后绿环境Pod可能无法正确获取客户端源IP，影响日志审计。防护：切换前验证externalTrafficPolicy: Local的兼容性。
• 陷阱3：CNI插件版本差异导致策略语法不兼容。 例如Calico的GlobalNetworkPolicy与Cilium的CiliumNetworkPolicy在规则表达上存在差异。防护：在CI/CD流水线中加入策略语法校验步骤。
• 陷阱4：忽略kube-proxy的iptables规则残留。 频繁切换可能导致iptables规则堆积，影响网络性能。防护：切换后执行iptables规则清理或使用IPVS模式。