我以为我对 Service Mesh 已经足够了解，毕竟过去几年我们在云原生环境中部署 Istio 已经得心应手。直到那一天，我们公司收购了一家香港的数据服务公司，它的核心业务还运行在几台位于香港的物理服务器上，没有 Kubernetes，甚至没有统一的网络策略。我们的目标是让这些“传统”服务器接入现有的 Service Mesh —— 也就是我们的 Istio 控制面（Control Plane），以便统一服务治理、流量控制和监控。

听起来像是挑战？没错。但实践之后，我意识到，这其实是一次深入理解 Service Mesh 架构边界的绝佳机会。下面，我将从实操角度详细讲解如何将香港物理服务器接入到现有的 Istio 网格中，并深入解析其中关键技术点和性能风险。

场景描述与挑战分析

• 我们当前的 Service Mesh 架构如下：
• 控制面部署在 AWS EKS 上，使用 Istio 1.22+
• 数据平面服务容器化运行在 Kubernetes 集群中

目标：将香港物理服务器上的 Java 服务（Tomcat）纳入 Service Mesh，实现流量可控、遥测可视、统一认证等能力

挑战主要包括：

• 物理服务器上无 Kubernetes 环境
• 跨区域、跨网络访问，存在延迟与安全隐患
• Istio Sidecar 模式如何在非 K8s 环境中落地
• 性能开销控制与监控能力缺失

步骤一：准备香港物理机环境

我们在物理服务器上安装的是 Ubuntu 20.04，服务进程是一个常规的 Spring Boot 应用，运行在 Tomcat 之上。

第一步，是确保物理服务器可以访问控制面。我们通过以下方式建立基础网络互通：

配置 VPN 隧道，从香港物理机到 AWS VPC

在 Istio 控制面所在集群中暴露必要的 Pilot、Telemetry 服务（或使用 Gateway 做转发）

关键点是：Istio 的控制面组件（特别是 istiod）必须能够和物理机上的 Sidecar 进行 XDS 通信。

步骤二：手动部署 Istio Sidecar 到物理服务器

虽然 Kubernetes 中的 Pod 会自动注入 Envoy Sidecar，但在物理服务器上，我们需要手动部署和配置 Envoy。

1. 下载 Envoy Binary

在物理服务器上，下载与 Istio 控制面版本匹配的 Envoy 代理：

wget https://github.com/envoyproxy/envoy/releases/download/v1.28.0/envoy-v1.28.0-linux-x86_64.tar.gz
tar -xzf envoy-v1.28.0-linux-x86_64.tar.gz
sudo mv envoy /usr/local/bin/

2. 创建 Bootstrap 配置文件

Istio 提供了 istio-agent 工具来生成配置，但在物理服务器上无法直接运行，我们采用以下策略：

• 在集群中运行临时 Pod，通过 istioctl proxy-config bootstrap 获取样板配置
• 替换 Pod IP 为物理机 IP
• 使用 Secret 将证书导出到物理机（istio-certs）

示例 Envoy 启动命令：

envoy -c /etc/envoy/envoy.yaml --service-cluster my-service --service-node my-service-node-id --log-level info

确保在 /etc/envoy/envoy.yaml 中指定了正确的 Cluster ID 和 XDS Server 地址。

步骤三：服务接入与流量代理

Envoy 部署完成后，我们需要将服务的流量劫持到 Sidecar：

方法一：修改服务启动脚本

将服务的监听地址改为 127.0.0.1:8080，让 Envoy 来监听外部端口（如 80 或 443），再将流量转发到本地服务。

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 15001

或者使用 Envoy 配置中的 listener 明确绑定端口，并设置为入口点。

方法二：使用 Nginx 作为本地反向代理（备选）

出于可观测性控制，我们决定全程使用 Envoy，不额外引入 Nginx。

步骤四：遥测与策略接入

关键问题在于物理服务器上的服务不在 K8s 注册中心中，Istio 无法自动识别。这可以通过以下方式解决：

ServiceEntry：在集群中创建一个静态 ServiceEntry 资源，声明该物理机服务

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: hk-legacy-service
spec:
  hosts:
  - hk-legacy.service.local
  addresses:
  - 10.100.1.25
  ports:
  - number: 80
    name: http
    protocol: HTTP
  location: MESH_EXTERNAL
  resolution: STATIC
  endpoints:
  - address: 10.100.1.25

WorkloadEntry + WorkloadGroup（推荐）：如果使用了 Istio WorkloadEntry 机制，则可以将物理服务器作为动态注册的 workload。

Prometheus 遥测适配：配置 Prometheus 将物理 Sidecar 的指标暴露在 /metrics 并纳入 Mesh 统一监控。

性能风险点解读

连接物理服务器进入 Service Mesh，确实可以带来治理统一，但需要关注如下风险点：

1. 延迟引入风险

VPN 网络存在不确定性，可能导致服务间 RTT 增加 20~80ms

Sidecar 转发本身引入约 3~10ms 开销

2. Sidecar 资源竞争

物理机资源固定，Envoy 代理进程可能与主服务争用 CPU 与内存。需设置：

envoy:
  concurrency: 2  # 限制线程数

3. 证书同步与轮换机制缺失

Sidecar 使用的 mTLS 证书通常由 Istio Agent 自动轮换。在非 K8s 环境中需要自行构建：

• 自动同步 SDS（Secret Discovery Service）
• 使用 cron job 从 Kubernetes 导出证书（非理想，但可行）

4. 故障诊断困难

物理节点无法接入集群日志、事件系统，建议部署自托管的 Fluent Bit，将 Envoy 和应用日志汇总到集中日志平台（如 Loki）。

结语：Service Mesh 不是只有“云原生”

这次接入香港物理服务器的实战让我更加认识到：Service Mesh 的设计初衷虽然是为 K8s 服务设计的，但它并不局限于“云原生”。只要你理解了它的通信模型、XDS 架构和 Envoy 行为，它也完全可以服务于“遗留”系统。

当然，这样的集成并不适用于所有情况，但对于正在进行云原生转型的企业来说，是一种非常实用的混合网格过渡方案。