非容器应用与K8s工作负载的服务网格化实践

序
本系列将包含如下篇章：

ASM-VM-PROXY的安装
基于ASM的Workload Entry实践
基于ASM的POD和VM互访实践-HTTP协议篇
基于ASM的POD和VM互访实践-GRPC协议篇
基于ASM的POD和VM混合流量转移实践
基于ASM的VM应用动态落迁实践
基于ASM的POD和VM可观测性实践

ASM-VM-PROXY是虚拟机网格化的通道，第1篇将介绍ASM-VM-PROXY的安装和使用。
WorkloadEntry是k8s集群与ecs集群通信的基础，本系列的第2篇将通过两个实践示例，把WorkloadEntry的用途和作用展示清楚，为后续pod和vm的互访、pod和vm混合场景中的流量转移打好理论基础。
接下来分别介绍基于http/grpc通信协议的POD和VM互访。各种编程语言实现的服务普遍通过http协议提供服务和彼此通信，因此http篇的目的是希望展示ecs网格化过程中最经典的场景。 grpc篇的目的有两个，一个是单纯地展示基于grpc通信协议服务的网格化方案，另一个是希望为ecs上使用了其他服务发现方式的遗留服务，提供一种更简单的网格化思路——使用k8s作为唯一服务发现的模式，代替复杂且实现成本颇高的多服务发现模式。这种方案最大的好处是让envoy不被修改，安静且优雅地保持与社区发展一致。
POD和VM混合的场景是非容器应用的网格化最常见的场景，解决了这种场景下的流量转移，会让用户有信心将跑在ecs上的非容器应用进行网格化。虽然很多用户意愿上早就想网格化，但没有一篇这样的示例，会让用户多少有些不安。这是第4篇的初衷，这篇也是本系列的核心篇章。
VM应用动态落迁是指动态地将非容器服务加入和移出服务网格。第6篇的目的是展示如何对非容器应用进行流量控制、蓝绿部署，甚至最终将全部非容器应用都容器化，且这些热操作都是流量无损的。
第7篇可观测性的目的是展示非容器应用如何像POD中的服务一样，在网格化后具备全链路追踪、监控等能力的。
希望有kubernetes容器化迁移诉求的同学，能够通过本系列的各篇非容器应用网格化实践，完成如下图所示的迁移过程。

本文插图
声明

本系列前提是已经创建了一个ACK集群、一个ECS实例、一个ASM实例，且VM与ACK集群在同一个VPC和安全组内。可在本文基础上参考相关文档实现跨安全组和VPC的需求。出于稳定性和性价比考虑，建议尽量在同一VPC和安全组内实现。
本系列示例没有启用DNS组件。可在本文基础上使用DNS组件代替手动配置hosts 。
本系列只将配置了WorkloadEntry的VM视为网格化，手动配置ServiceEntry但没有配置WorkloadEntry的VM不视为网格化。

【非容器应用与K8s工作负载的服务网格化实践 - 序】 本文为阿里云原创内容，未经允许不得转载。