Istio 将虚拟机纳入服务网格：混合环境下的零信任与安全通信实践

Istio 作为云原生领域的明星服务网格，其核心价值在于提供统一的流量管理、可观测性、安全策略等能力。传统上，Istio 主要管理 Kubernetes (K8s) 集群中的微服务。然而，在企业实践中，大量的应用仍然运行在虚拟机 (VM) 上，如何将这些 VM 应用无缝地纳入 Istio 服务网格，实现混合环境下的统一治理，尤其是零信任安全通信，成为了一个迫切的需求。

本文将深入探讨 Istio 如何扩展其能力至虚拟机，以及实现过程中需要关注的操作细节、对现有 VM 应用的改造要求、性能及运维复杂度的影响，并重点解析 K8s 与 VM 之间在 mTLS 零信任要求下的安全通信实践。

1. Istio 如何将虚拟机纳入服务网格管理

Istio 实现对 VM 的管理，核心思想是让 VM 上的服务也能拥有一个与 K8s Pod 类似的服务网格身份，并运行一个 Envoy Sidecar 代理。这样，VM 上的服务就可以像 K8s Pod 一样，被 Istio 控制平面统一纳管。

基本原理与组件：

• Envoy Sidecar: VM 上的每个应用实例都需要部署一个 Envoy Sidecar 代理，负责拦截进出应用的所有流量。这与 K8s Pod 中的 Sidecar 作用相同。
• WorkloadEntry 资源: 这是 Istio 用于描述非 Kubernetes 工作负载（如 VM 上的服务）的关键资源。通过 WorkloadEntry，Istio 控制平面能够知晓 VM 上的服务实例信息（IP 地址、端口、标签等）。
• ServiceEntry 资源: 如果 VM 上的服务需要被 K8s 集群内的服务访问，或者 VM 上的服务需要访问 K8s 集群外的服务，可能需要配合 ServiceEntry 来定义这些外部服务，以便 Istio 能够正确路由和应用策略。
• 注册机制: VM 上的 Envoy Sidecar 需要一种机制来向 Istio 控制平面注册，并获取配置。这通常通过一个代理代理（如 istio-agent）或直接配置控制平面地址来完成。

操作步骤概览：

1. 安装 Istio 控制平面: 确保你的 K8s 集群中已部署 Istio 控制平面。
2. 准备 VM 环境: 确保 VM 具备网络连通性，能够访问 K8s 集群的 API Server 和 Istio 控制平面。可能需要配置防火墙规则。
3. 创建 WorkloadGroup 和 WorkloadEntry:
   • WorkloadGroup 是一个模板，定义了 VM 工作负载的通用配置，如网络、标签、身份等。
   • WorkloadEntry 描述了单个 VM 上的服务实例。你可以手动创建，也可以通过自动注册工具（如 istioctl x workload entry configure 配合 istio-agent）来生成。
4. 在 VM 上安装 istio-agent 和 Envoy Sidecar: Istio 提供了一系列工具来简化这个过程。
   • 使用 istioctl x workload entry configure 命令生成一个 VM 专属的配置文件，它包含了必要的证书、istio-agent 配置以及 Envoy 启动参数。
   • 将这些文件拷贝到 VM 上，并运行 istio-agent 和 Envoy Sidecar。istio-agent 负责 VM 的身份认证和证书管理，并与 Istio 控制平面通信。
5. 配置流量劫持: 确保 VM 上应用的进出流量能够被 Envoy Sidecar 拦截。这通常通过修改 iptables 规则实现。

2. 对现有 VM 应用的改造要求

将现有 VM 应用纳入 Istio 服务网格，通常需要满足以下要求：

• 网络要求: VM 需要能够通过 IP 地址访问 K8s 集群的 Istio 控制平面组件（如 istiod 的 15012 端口用于 xDS 配置，9443 端口用于 CA 认证）。
• 流量劫持: 这是核心要求。VM 上的应用本身无需修改代码，但其网络流量必须能够被 Istio Sidecar 拦截和代理。这通常通过在 VM 上配置 iptables 规则来完成，将出站流量重定向到 Sidecar，将入站流量从 Sidecar 路由到应用。
• DNS 配置 (可选但推荐): 为了让 VM 上的服务能够像 K8s Pod 那样通过服务名访问其他服务，可能需要配置 VM 的 DNS 解析，使其能够解析 K8s 集群内部的服务域名。否则，VM 上的应用可能需要继续使用 IP 地址或其他外部 DNS 机制。
• 身份和证书管理: VM 上的 istio-agent 会处理与 Istio CA 的通信，获取并刷新 Sidecar 所需的 SPIFFE 证书。这要求 VM 上的 istio-agent 能够安全地存储这些证书。
• 无代码侵入: Istio 的设计哲学是无代码侵入。这意味着大多数情况下，你不需要修改 VM 应用的代码。但如果应用本身有硬编码的 IP 地址、自定义的 TLS 逻辑，或者不兼容 Envoy 代理的协议，则可能需要进行调整。

3. 性能与运维复杂度的影响

将 VM 纳入服务网格会带来显著的好处，但同时也需要权衡性能和运维复杂度。

性能影响：

• Sidecar 代理开销: 每个 VM 上的 Envoy Sidecar 都会消耗 CPU 和内存资源。对于资源紧张的 VM，这可能是一个需要考虑的因素。Sidecar 还会增加网络跳数，带来微秒级的额外延迟。
• 网络延迟: 流量经过 Sidecar 代理会增加少量的网络延迟。在对延迟极其敏感的场景下，需要进行严格的性能测试。
• mTLS 加解密: 启用 mTLS 后，流量在 Sidecar 层进行加密和解密，会增加 CPU 负载。现代 CPU 通常有硬件加速，但仍需评估。
• 控制平面负载: 随着 VM 数量的增加，Istio 控制平面（特别是 istiod）需要管理更多的 Sidecar，处理更多的配置分发和证书签发请求，可能需要扩容。

运维复杂度：

• 异构环境管理: 同时管理 K8s Pod 和 VM 工作负载，意味着运维团队需要同时熟悉两种不同的部署和管理范式。虽然 Istio 试图统一管理，但底层基础设施的差异依然存在。
• VM 生命周期管理: VM 的创建、销毁、扩缩容、更新等操作，需要与 Istio 的 WorkloadEntry 生命周期保持同步。手动管理 WorkloadEntry 会非常繁琐，因此自动化工具或脚本是必需的。
• 故障排查: 当出现问题时，需要在 K8s 集群（控制平面）和 VM（Sidecar、应用、网络配置）两个层面进行排查，这会增加复杂性。
• 安全加固: 需要确保 VM 本身的安全，防止未经授权的访问篡改 Sidecar 或 istio-agent 配置。
• 资源消耗监控: 需要监控 VM 上的 Sidecar 资源使用情况，以及 Istio 控制平面的负载。

4. K8s 与 VM 之间的零信任 mTLS 安全通信实践

零信任原则要求“永不信任，始终验证”。在 Istio 服务网格中，mTLS (Mutual TLS) 是实现零信任安全通信的核心机制。Istio 利用其 CA (Certificate Authority) 为每个工作负载（无论是 K8s Pod 还是 VM）颁发唯一的身份证书，并通过这些证书实现双向认证和加密。

实现机制：

1. 统一身份颁发: Istio CA 为 K8s Pod 和 VM 上的 Sidecar 颁发基于 SPIFFE (Secure Production Identity Framework for Everyone) 标准的短生命周期证书。这些证书包含了工作负载的唯一身份。
2. Sidecar 代理加密: 当 K8s Pod 中的服务 A 尝试访问 VM 中的服务 B 时：
   • 服务 A 的 Sidecar 拦截请求。
   • 服务 A 的 Sidecar 与服务 B 的 Sidecar 建立 mTLS 连接，双方通过证书进行双向身份验证。
   • 连接建立后，所有流量都在 TLS 加密通道中传输。
3. PeerAuthentication 资源: 通过 PeerAuthentication 资源，你可以定义服务网格中 mTLS 的行为。
   • 在网格级别或命名空间级别设置 mode: STRICT，可以强制所有服务间通信都使用 mTLS。
   • 可以针对特定服务或工作负载设置例外。

配置步骤示例（假设已将 VM 纳入网格）：

1. 确保 Istio CA 可用: 默认情况下，Istio 会部署一个内部 CA。对于生产环境，可能需要与外部 CA 集成。
2. 创建 WorkloadEntry for VM: 确保 VM 上的服务有正确的 WorkloadEntry，并关联了正确的 serviceAccount (用于身份标识)。

   apiVersion: networking.istio.io/v1beta1
   kind: WorkloadEntry
   metadata:
     name: my-vm-service-a
     namespace: default
   spec:
     serviceAccount: vm-app-sa # 对应K8s ServiceAccount，用于身份识别
     address: 192.168.1.100 # VM 的 IP 地址
     labels:
       app: vm-service-a
       tier: backend
     ports:
       http: 8080
   

3. 配置 PeerAuthentication 强制 mTLS:
   • 网格范围强制:

     apiVersion: security.istio.io/v1beta1
     kind: PeerAuthentication
     metadata:
       name: default
       namespace: istio-system # 网格级别策略通常放在 istio-system
     spec:
       mtls:
         mode: STRICT
     

   • 命名空间或特定服务强制: 如果你只想在 default 命名空间中强制 mTLS，或者只针对 vm-service-a 强制，可以创建更细粒度的 PeerAuthentication。

     # 针对 default 命名空间强制
     apiVersion: security.istio.io/v1beta1
     kind: PeerAuthentication
     metadata:
       name: default-namespace-mtls
       namespace: default
     spec:
       mtls:
         mode: STRICT
     

     # 针对特定服务强制
     apiVersion: security.istio.io/v1beta1
     kind: PeerAuthentication
     metadata:
       name: vm-service-a-mtls
       namespace: default
     spec:
       selector:
         matchLabels:
           app: vm-service-a
       mtls:
         mode: STRICT
     

K8s-VM 安全通信的关键挑战与注意事项：

• 网络连通性: 确保 K8s Pod 和 VM 之间网络是可达的。如果它们在不同的网络子网，可能需要配置路由或打通隧道。
• 防火墙规则: 确保 VM 的防火墙允许 Istio Sidecar 监听所需的端口，并允许出站流量到 K8s 集群内的服务。
• 服务发现: VM 上的服务如何发现 K8s 内部的服务，以及 K8s 内部的服务如何发现 VM 上的服务，是需要解决的问题。ServiceEntry 扮演了关键角色。
• 身份一致性: WorkloadEntry 中 serviceAccount 的选择至关重要，它定义了 VM 工作负载在 Istio 中的身份。确保其与 K8s 中的 ServiceAccount 有逻辑上的关联，方便策略管理。
• 证书轮换: Istio CA 会自动轮换 Sidecar 证书。需要确保 istio-agent 在 VM 上正常运行，能够及时获取并更新证书。

总结

将虚拟机纳入 Istio 服务网格是实现混合云环境下统一治理和零信任安全策略的有效途径。它通过在 VM 上部署 Envoy Sidecar 和 istio-agent，配合 WorkloadEntry 等资源，实现了 VM 工作负载的网格化。虽然这带来了运维复杂性和一定的性能开销，但通过统一的流量管理、可观测性以及 K8s 和 VM 之间基于 mTLS 的零信任安全通信，能够显著提升整个系统的安全性、弹性和可管理性。在实施过程中，需要周密规划，充分考虑网络连通性、应用改造要求、性能测试以及自动化运维机制。