先来看看阿里云官方对Terway的介绍：
什么是Terway网络插件
Terway是阿里云开源的基于专有网络VPC的容器网络接口CNI（Container Network Interface）插件，支持基于Kubernetes标准的网络策略来定义容器间的访问策略。您可以通过使用Terway网络插件实现Kubernetes集群内部的网络互通。本文介绍如何使用阿里云容器服务Kubernetes版ACK集群的Terway网络插件。
Terway网络插件是ACK自研的网络插件，将原生的弹性网卡分配给Pod实现Pod网络，支持基于Kubernetes标准的网络策略（Network Policy）来定义容器间的访问策略，并兼容Calico的网络策略。
在Terway网络插件中，每个Pod都拥有自己网络栈和IP地址。同一台ECS内的Pod之间通信，直接通过机器内部的转发，跨ECS的Pod通信、报文通过VPC的弹性网卡直接转发。由于不需要使用VxLAN等的隧道技术封装报文，因此Terway模式网络具有较高的通信性能。
Terway网络模式图：
Terway与Flannel对比
在创建集群时，ACK提供Terway和Flannel两种网络插件：
Terway：是阿里云容器服务ACK自研的网络插件。Terway将阿里云的弹性网卡分配给容器，支持基于Kubernetes标准的网络策略来定义容器间的访问策略，支持对单个容器做带宽的限流。Terway拥有更为灵活的IPAM（容器地址分配）策略，避免地址浪费。如果您不需要使用网络策略（Network Policy），可以选择Flannel，其他情况建议选择Terway。
Flannel：使用的是简单稳定的社区Flannel CNI插件。配合阿里云的VPC的高速网络，能给集群高性能和稳定的容器网络体验。Flannel功能偏简单，支持的特性少。例如，不支持基于Kubernetes标准的网络策略（Network Policy）。
我们的kubernetes集群一直使用社区的Flannel CNI网络插件，其实在第一次迁移的时候也考虑过使用阿里云自研的Terway，但是考虑成本原因和第一次迁移不想使用一个未使用过的网络插件，最后还是选项了Flannel 。
使用Terway网络插件以后，单节点所支持的最大Pod数取决于该节点的弹性网卡（ENI）数，而阿里云低配服务器，支持的弹性网卡都比较少。
POD公式：
共享ENI支持的最大Pod数=（ECS支持的ENI数-1）×单个ENI支持的私有IP数
独占ENI支持的最大Pod数=ECS支持的ENI数－1
由于这个原因，特别不适用于非生产环境。
最近刚好生产服务器快到期了，所以决定把生产环境更换为网络性能无损、更安全并且支持网络策略的Terway。
迁移之前也做了各项评估，做好了迁移方案，因为迁移不涉及数据库、MQ等这些中间件，也不涉及代码更新，所以直接采用蓝绿方式平滑迁移。
先创建一个Terway的集群，把所有的服务部署成功，然后再通过本地host或者本地DNS解析的方式，测试一下新的集群各种功能，正常以后修改网关的解析，然后两个集群并行运一段时间，等解析完全生效以后，停掉原来的集群就可以了。
迁移以后踩到了第一个Terway网络插件的坑，这个坑也是排查了一些时间。
A服务器上面的kubernetes容器内部，无法访问A服务器上面采用docker运行容器的端口（直接docker run 或者 docker-compose方式运行），采用kubernetes编排启动在A服务器上面的容器不影响，但是可以正常ping 通。
但是B服务器上面的kubernetes容器内部，可以访问A服务器上面采用docker运行容器的端口（直接docker run 或者 docker-compose方式运行）。
由于我们刚好有个组件还未迁移到kubernetes，所以暂时采用的docker-compose方式手动编排在了其中两台服务器上面。这导致了这两台服务器上面的kubernetes容器，都访问不了当前服务器上面的这个组件，但是可以访问另外一台服务器的组件。
虽然也可以使用，但是有大量的警告日志，访问超时。
我当时也很费解，怎么会出现这样的问题，带着疑问提交了一个工单咨询，得到的结果是Terway网络插件不支持这样的场景。
没办法只能暂时部署在其他服务器，后面有时间了迁移到kubernetes集群。
踩的第二个Terway网络插件的坑，就比较惨了，是我已经修改解析以后才爆出来的。
我在看链路追踪的时候发现了大量调用高德API超时的请求，当时也引起了我的注意，然后马上问相关服务的开发，高德那边是不是配置了IP白名单之类的。
经过排查，高德那边没有开启白名单，然后开发本地测试一切正常。
我马上复制高德API本地ping了一下，可以ping通，然后马上远程到集群的其中一个节点，ping也可以ping通，但是exec进入容器内部再ping的时候，发现不通。
一开始我以为是高德API的CDN节点故障，但是我复制IP到本地ping却没问题。
此时我有点方了，容器内部难道无法访问外网，于是马上ping www.baidu.com 和 ping 114.114.114.114果然都不通。
验证了我的推论以后，我更方了，服务器都可以上网，容器内部为啥不能上网？我又进入测试环境集群中的一个容器，ping测试了一下，访问外网正常。
这两个集群唯一不同的就是kubernetes的网络插件，现在这个使用的Terway，难道插件的问题？马上又提交工单咨询。
结果工单磨磨唧唧，半个小时以后就问了我句集群节点可不可以访问公网。
还好提交工单以后我在他们的文档 容器网络FAQ找到了答案。
Terway网络模式下增加了虚拟交换机后，集群无法访问公网怎么办？
问题现象：在Terway网络下，因Pod没有IP资源而手动增加虚拟交换机，在增加虚拟交换机后，发现集群不能正常访问公网。
问题原因：Pod IP所属的虚拟交换机不具备公网访问的能力。
解决方法：您可以通过NAT网关的SNAT功能，为Pod IP所属的虚拟交换机配置公网SNAT规则。
然后按照文档创建了一个SNAT规则以后正常了，到此第二个坑就算解决了。
为什么这次我创建集群的时候没有勾选SNAT呢？因为当初提交工单咨询过，给我的答复是只要节点有公网IP能上网，容器里面就能上网。
而本身这个SNAT一年也不便宜，服务器不多的时候每个节点配置一个公网IP更划算，小公司总要考虑一下成本问题。
你以为这样就结束了，其实并没有，因为这个事情被阿里的“领导”上了一课，感受了一次阿里的企业文化。
感兴趣的可以访问《被阿里”领导”上了一课，感受了一次阿里文化》娱乐娱乐。
