从 AWS App Mesh 迁移到 Istio 全面指南

本文为 Jimmy Song 原创。转载请注明来源： https://jimmysong.io/blog/migrating-from-aws-app-mesh-to-istio-a-comprehensive-guide/

查看本文大纲

随着 AWS 宣布将在 2026 年 9 月 30 日停用 AWS App Mesh，许多企业正在评估继续使用服务网格的替代方案。如果您也在寻找替代方案，Istio 将是一个强大且功能丰富的选项，尤其适合 Kubernetes 原生环境。在本文中，我将介绍从 AWS App Mesh 迁移到 Istio 的过程，对比这两种服务网格，并介绍我们开发的 Tetrate Istio 迁移工具，帮助简化这一迁移过程。

App Mesh vs Istio：迁移准备

由于 AWS App Mesh 即将停用，了解 App Mesh 和 Istio 之间的相似性和差异对于成功迁移至关重要。以下是一些关键比较点，帮助您将当前的基础设施与 Istio 提供的功能对齐：

全面的功能：App Mesh 和 Istio 都提供流量管理、可观测性和安全功能，但 Istio 提供了更多可自定义的选项，包括高级流量路由和增强的遥测。
云无关性：与紧密集成 AWS 的 App Mesh 不同，Istio 是云无关的，可在多云或混合环境中提供更大的灵活性。
高级安全：Istio 默认支持 mTLS，与 App Mesh 相比，提供了更广泛的安全功能和策略。

AWS 建议 ECS 客户迁移到 Service Connect 而 EKS 客户迁移到 VPC Lattice。对于一个功能丰富的开源解决方案，Istio 是一个很有吸引力的选择。接下来，让我们深入了解从 AWS App Mesh 迁移到 Istio 的过程，并使用 Tetrate 的迁移工具进行支持。

比较 App Mesh、Service Connect、VPC Lattice 和 Istio

在开始迁移之前，了解 AWS App Mesh、Service Connect、VPC Lattice 和 Istio 之间的关键区别非常重要：

功能	App Mesh	Service Connect	VPC Lattice	Istio
网络可靠性	使用 Envoy 作为 Sidecar 代理，进行异常检测、健康检查和重试，支持精细调整。	使用 Envoy 作为 Sidecar 代理，仅支持超时调整。	内置健康检查和重试，由 AWS 管理的可靠性，不需要 Sidecar 代理。	支持 Sidecar 和 Ambient 模式，使用 Envoy 并完全支持精细化调整。
高级流量路由	支持高级流量路由，如 A/B 测试和金丝雀发布。	不支持高级流量路由。	支持基本的流量路由和负载均衡。	支持包括 A/B 测试和金丝雀发布在内的高级流量控制。
可观测性	需要手动收集和监控指标。	自动将指标发送到 Amazon CloudWatch。	集成 AWS CloudWatch 和 X-Ray 监控。	开箱即用的可观测性，支持 Prometheus、Grafana 和 Jaeger。
服务发现	集成 AWS Cloud Map。	使用 AWS Cloud Map。	使用 AWS 服务发现机制。	使用 Kubernetes 原生的服务发现机制。
安全性	支持与 AWS PCA 的 TLS 和双向 TLS（mTLS）。	支持 TLS，不支持 mTLS。	支持 mTLS。	支持 mTLS 和细粒度的安全策略。
资源共享	可以跨多个 AWS 账户共享网格。	不支持跨账户共享命名空间。	可以跨多个 AWS 账户共享资源。	可以跨多个集群和云部署。

介绍 Tetrate 的 Istio 迁移工具

为了使迁移过程更加顺利，Tetrate 开发了一个 Istio 迁移工具包，目前处于私有状态，但可供内部或经过批准的客户通过此表单申请使用。该工具包帮助自动转换 AWS App Mesh 配置为 Istio 的等效配置，包括 Virtual Nodes、Virtual Routers 和其他网络结构。

关键考量

服务发现：App Mesh 和 Istio 的服务发现方式不同。Istio 依赖 Kubernetes 原生的服务发现，而 App Mesh 则集成 AWS Cloud Map。迁移过程中，需相应调整服务定义。
安全性：Istio 原生支持服务之间的 mTLS。虽然 AWS App Mesh 也支持 mTLS，但迁移至 Istio 需要配置 CA（证书颁发机构）并更新证书以适应 Istio 的安全模型。
流量管理：Istio 的 Virtual Services 和 Destination Rules 提供了比 App Mesh 的 Virtual Routers 和 Nodes 更高级的流量路由能力。迁移过程中，需额外配置以建立类似的路由行为。

使用 Tetrate 迁移工具逐步完成迁移

下面是使用此工具的有效步骤：

前提条件

开始迁移之前，确保已安装以下工具：

确保在 EKS 集群上正确安装和配置 AWS App Mesh。您还需要一个名为 tetrate-tis-creds 的 Kubernetes secret，用于 Istio 安装，详见工具文档。

该工具还提供预检查命令，以识别迁移前的任何潜在阻碍因素。

运行预检查

为确保设置准备就绪，运行以下命令：

tim precheck

此命令将扫描 App Mesh 环境，标出任何需要调整的项，以确保成功迁移。

迁移过程

安装 Istio

使用 Istio 迁移工具包生成 IstioOperator 配置并安装 Istio：
```
tim generate iop | istioctl install –skip-confirmation -f –
```
应用 Istio 网络规则

接下来，生成并应用 Istio 网络规则：
```
tim generate networking | kubectl apply -f –
```
移除 AWS App Mesh 标签

从命名空间中移除现有的 App Mesh 标签。例如，对于 default 命名空间：
```
kubectl label namespace default "appmesh.k8s.aws/sidecarInjectorWebhook-"
```
启用 Istio Sidecar 注入

添加标签以启用 Istio 的自动 Sidecar 注入：
```
kubectl label namespace default istio-injection=enabled
```
重启部署

为应用更改并启动新的 Envoy Sidecar 注入，重启部署：
```
kubectl rollout restart deployment <deployment-name> -n <deployment-namespace>
```

迁移策略

从 AWS App Mesh 迁移到 Istio 时，可以使用如原地迁移、金丝雀发布、蓝绿部署等策略，这些策略与迁移到 VPC Lattice 的策略相似。合适的策略取决于应用需求，如是否需要零停机或安排维护窗口。

原地迁移：用配置为 Istio 的新 Pods 替换当前 App Mesh 的 Kubernetes Pods，适合可容忍迁移过程中的停机的应用。
蓝绿部署：在新命名空间中配置为 Istio 的应用副本，而原始部署继续运行 App Mesh，无停机地逐步将流量从 App Mesh 迁移到 Istio。
金丝雀发布：与 App Mesh 并行部署 Istio，逐步将少量流量转移到 Istio，监控性能和稳定性，逐步增加流量。
分阶段迁移：逐步迁移组件或服务，而非一次性迁移，以减少风险并帮助识别潜在问题。
测试和验证：在完全切换前，进行全面测试，验证服务功能、安全性和性能指标符合或超出预期。

结论

从 AWS App Mesh 迁移到 Istio 可以解锁流量管理、可观测性和安全方面的新功能。Tetrate 的 Istio 迁移工具简化了过程，提供了分步骤方法，减少手动配置，确保平稳过渡。

如果您有兴趣试用 Tetrate 的 Istio 迁移工具，欢迎联系我们——该工具目前可私密使用，我们将很乐意讨论访问权限。

此次迁移不仅是采用新的服务网格，更是一个充分利用 Istio 全面功能、支持多云部署、增强基础设施弹性的机会。

本文最初发表于 tetrate.io。