1. 课程导论：为什么需要跨命名空间网络策略？Helm 在其中的角色

1.1 从单命名空间到多命名空间：网络隔离的演进

在 Kubernetes 集群中，命名空间（Namespace）是资源隔离的基本单元。早期实践通常将整个应用部署在单一命名空间内，网络策略（NetworkPolicy）只需管理 Pod 之间的入站（Ingress）和出站（Egress）规则。然而，随着微服务架构的普及和团队职责的划分，多命名空间部署成为标准模式：

• 环境隔离：dev、staging、prod 分别使用独立命名空间。
• 团队边界：不同业务线（如支付、用户、订单）拥有各自的命名空间。
• 安全合规：敏感服务（如数据库、密钥管理）必须与前端服务严格隔离。

这种架构带来了一个核心挑战：跨命名空间的 Pod 通信必须被显式控制。默认情况下，Kubernetes 集群内所有 Pod 可以互相通信（扁平网络），这显然不符合最小权限原则。网络策略（NetworkPolicy）正是解决这一问题的原生机制，但手动编写跨命名空间的 YAML 规则极易出错且难以维护。

1.2 跨命名空间网络策略的核心要素

一个典型的跨命名空间 NetworkPolicy 包含以下关键字段：

以下是一个允许 frontend 命名空间中带有 app: web 标签的 Pod 访问 backend 命名空间中带有 app: api 标签的 Pod 的 80 端口的策略示例：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: frontend
          podSelector:
            matchLabels:
              app: web
      ports:
        - protocol: TCP
          port: 80

1.3 Helm 在跨命名空间网络策略中的角色

Helm 作为 Kubernetes 的包管理器，在跨命名空间网络策略管理中扮演三个关键角色：

1. 模板化与参数化：将命名空间名称、标签选择器、端口号等可变部分抽象为 values.yaml 中的参数，避免硬编码。
2. 依赖管理与发布顺序：通过 Helm Chart 的依赖机制，确保网络策略在目标服务部署之前或同时被应用。
3. 多环境一致性：同一套 Chart 模板，通过不同的 values 文件适配 dev/staging/prod 环境，减少重复劳动。

下图展示了 Helm 如何将抽象的 Chart 模板转化为具体的跨命名空间网络策略资源：

1.4 不使用 Helm 的痛点对比

为了更直观地理解 Helm 的价值，下表对比了手动管理跨命名空间网络策略与使用 Helm 管理的差异：

1.5 本课程的学习路径

本课程将围绕以下主线展开：

• 基础篇（第 2-5 章）：深入理解 NetworkPolicy 的 API 语义、跨命名空间选择器的工作原理、以及 Helm Chart 的基本结构。
• 实战篇（第 6-15 章）：从零构建一个跨命名空间的网络策略 Chart，涵盖参数化设计、依赖管理、多环境配置、CI/CD 集成。
• 进阶篇（第 16-25 章）：处理复杂场景——双向策略、大规模集群的性能优化、审计日志、与 Service Mesh 的协同。
• 案例篇（第 26-30 章）：真实企业案例：多租户 SaaS 平台的网络隔离、金融级合规策略、以及故障排查手册。