4. 跨命名空间通信场景：微服务架构中的命名空间隔离、跨命名空间服务发现、DNS解析限制

在微服务架构中，命名空间（Namespace）是 Kubernetes 实现多租户隔离的核心单元。然而，业务服务往往需要跨越命名空间边界进行通信，例如前端服务调用后端服务、支付服务调用订单服务。这种跨命名空间通信在带来灵活性的同时，也引入了网络策略配置、服务发现机制和 DNS 解析限制等关键挑战。本章将深入剖析这些场景，并给出 Helm Chart 中的最佳实践。

4.1 命名空间隔离的动机与粒度

命名空间隔离并非简单的“一刀切”。合理的隔离策略需要在安全性与运维效率之间取得平衡。下表对比了常见的隔离粒度及其适用场景：

4.2 跨命名空间服务发现机制

Kubernetes 的 DNS 服务（CoreDNS）默认支持跨命名空间的服务发现。服务 my-service 在命名空间 ns-a 中，可以被 ns-b 中的 Pod 通过 my-service.ns-a.svc.cluster.local 访问。然而，这种机制存在两个关键限制：

• DNS 记录可见性： 默认情况下，所有命名空间中的 Pod 都可以解析任意命名空间的服务 DNS 记录。这可能导致信息泄露或未经授权的服务探测。
• 网络策略不感知 DNS： 即使 DNS 解析成功，实际的网络流量仍可能被网络策略（NetworkPolicy）拦截。DNS 解析成功 ≠ 通信成功。

下图展示了跨命名空间服务发现与网络策略的交互流程：

4.3 DNS 解析限制与策略

为了增强安全性，Kubernetes 1.20+ 引入了 CoreDNS 的 dnsPolicy 和 dnsConfig 字段，允许更精细地控制 Pod 的 DNS 解析行为。在跨命名空间场景中，常见的限制策略包括：

• 限制跨命名空间 DNS 查询： 通过配置 CoreDNS 的插件（如 kubernetes 插件的 namespace 过滤），仅允许查询特定命名空间的服务。
• 使用私有 DNS 域： 为每个命名空间分配独立的 DNS 后缀（如 svc.ns-a.cluster.local），通过网络策略控制跨域查询。
• 禁用默认的 cluster.local 解析： 在 Pod 的 dnsConfig 中设置 nameservers 指向自定义 DNS 服务器，绕过 CoreDNS 的默认行为。

下表总结了不同 DNS 策略对跨命名空间通信的影响：

4.4 Helm Chart 中的跨命名空间通信配置

在 Helm Chart 中，跨命名空间通信的配置通常涉及以下三个层面：

1. 网络策略（NetworkPolicy）： 在源命名空间的 Chart 中定义出站规则，在目标命名空间的 Chart 中定义入站规则。
2. 服务发现（Service Discovery）： 通过 values.yaml 参数化目标服务的完整 DNS 名称（如 service-b.backend.svc.cluster.local）。
3. DNS 配置（dnsConfig）： 在需要限制 DNS 解析的 Pod 中，通过 dnsConfig 字段覆盖默认行为。

以下是一个 Helm Chart 中跨命名空间网络策略的示例片段：

# templates/networkpolicy-egress.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: {{ include "my-chart.fullname" . }}-egress-backend
  namespace: {{ .Values.global.namespace }}
spec:
  podSelector:
    matchLabels:
      app: {{ .Values.app.name }}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: {{ .Values.backend.namespace }}
      podSelector:
        matchLabels:
          app: {{ .Values.backend.appName }}
    ports:
    - protocol: TCP
      port: {{ .Values.backend.port }}

# templates/networkpolicy-ingress.yaml (部署在目标命名空间)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: {{ include "my-chart.fullname" . }}-ingress-frontend
  namespace: {{ .Values.global.namespace }}
spec:
  podSelector:
    matchLabels:
      app: {{ .Values.app.name }}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: {{ .Values.frontend.namespace }}
      podSelector:
        matchLabels:
          app: {{ .Values.frontend.appName }}
    ports:
    - protocol: TCP
      port: {{ .Values.service.port }}

4.5 跨命名空间通信的常见模式与避坑

下表列出了跨命名空间通信中常见的几种模式及其对应的 Helm Chart 配置策略：

4.6 本章小结

跨命名空间通信是微服务架构中不可避免的需求，但也是网络策略配置中最容易出错的环节。核心要点包括：

• 命名空间隔离粒度决定了网络策略的复杂度和运维成本，建议在 Helm Chart 中通过参数化支持多种隔离模式。
• DNS 解析成功不等于通信成功，网络策略是最终的流量控制层。
• Helm Chart 应同时管理入站和出站规则，并使用 namespaceSelector 实现跨命名空间匹配。
• 调试跨命名空间通信需要从 DNS、网络策略、端口监听三个维度逐一排查。