阿里云ACK网络插件Terway踩坑记

2021年11月12日18:02:12 发表评论 1,378 ℃

先来看看阿里云官方对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网络模式图:

阿里云ACK网络插件Terway踩坑记

Terway与Flannel对比

在创建集群时,ACK提供Terway和Flannel两种网络插件:

Terway:是阿里云容器服务ACK自研的网络插件。Terway将阿里云的弹性网卡分配给容器,支持基于Kubernetes标准的网络策略来定义容器间的访问策略,支持对单个容器做带宽的限流。Terway拥有更为灵活的IPAM(容器地址分配)策略,避免地址浪费。如果您不需要使用网络策略(Network Policy),可以选择Flannel,其他情况建议选择Terway。

Flannel:使用的是简单稳定的社区Flannel CNI插件。配合阿里云的VPC的高速网络,能给集群高性能和稳定的容器网络体验。Flannel功能偏简单,支持的特性少。例如,不支持基于Kubernetes标准的网络策略(Network Policy)。

阿里云ACK网络插件Terway踩坑记

我们的kubernetes集群一直使用社区的Flannel CNI网络插件,其实在第一次迁移的时候也考虑过使用阿里云自研的Terway,但是考虑成本原因和第一次迁移不想使用一个未使用过的网络插件,最后还是选项了Flannel 。

使用Terway网络插件以后,单节点所支持的最大Pod数取决于该节点的弹性网卡(ENI)数,而阿里云低配服务器,支持的弹性网卡都比较少。

POD公式:

共享ENI支持的最大Pod数=(ECS支持的ENI数-1)×单个ENI支持的私有IP数

独占ENI支持的最大Pod数=ECS支持的ENI数-1

阿里云ACK网络插件Terway踩坑记

由于这个原因,特别不适用于非生产环境。

最近刚好生产服务器快到期了,所以决定把生产环境更换为网络性能无损、更安全并且支持网络策略的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网络插件不支持这样的场景。

阿里云ACK网络插件Terway踩坑记

没办法只能暂时部署在其他服务器,后面有时间了迁移到kubernetes集群。

踩的第二个Terway网络插件的,就比较惨了,是我已经修改解析以后才爆出来的。

我在看链路追踪的时候发现了大量调用高德API超时的请求,当时也引起了我的注意,然后马上问相关服务的开发,高德那边是不是配置了IP白名单之类的。

经过排查,高德那边没有开启白名单,然后开发本地测试一切正常。

我马上复制高德API本地ping了一下,可以ping通,然后马上远程到集群的其中一个节点,ping也可以ping通,但是exec进入容器内部再ping的时候,发现不通。

阿里云ACK网络插件Terway踩坑记

一开始我以为是高德API的CDN节点故障,但是我复制IP到本地ping却没问题。

阿里云ACK网络插件Terway踩坑记

此时我有点方了,容器内部难道无法访问外网,于是马上ping www.baidu.com 和 ping 114.114.114.114果然都不通。

验证了我的推论以后,我更方了,服务器都可以上网,容器内部为啥不能上网?我又进入测试环境集群中的一个容器,ping测试了一下,访问外网正常。

这两个集群唯一不同的就是kubernetes的网络插件,现在这个使用的Terway,难道插件的问题?马上又提交工单咨询。

结果工单磨磨唧唧,半个小时以后就问了我句集群节点可不可以访问公网。

阿里云ACK网络插件Terway踩坑记

还好提交工单以后我在他们的文档 容器网络FAQ找到了答案。

阿里云ACK网络插件Terway踩坑记

Terway网络模式下增加了虚拟交换机后,集群无法访问公网怎么办?

问题现象:在Terway网络下,因Pod没有IP资源而手动增加虚拟交换机,在增加虚拟交换机后,发现集群不能正常访问公网。

问题原因:Pod IP所属的虚拟交换机不具备公网访问的能力。

解决方法:您可以通过NAT网关的SNAT功能,为Pod IP所属的虚拟交换机配置公网SNAT规则。

然后按照文档创建了一个SNAT规则以后正常了,到此第二个坑就算解决了。

为什么这次我创建集群的时候没有勾选SNAT呢?因为当初提交工单咨询过,给我的答复是只要节点有公网IP能上网,容器里面就能上网。

阿里云ACK网络插件Terway踩坑记

而本身这个SNAT一年也不便宜,服务器不多的时候每个节点配置一个公网IP更划算,小公司总要考虑一下成本问题。

你以为这样就结束了,其实并没有,因为这个事情被阿里的“领导”上了一课,感受了一次阿里的企业文化。

感兴趣的可以访问《被阿里”领导”上了一课,感受了一次阿里文化》娱乐娱乐。

精选全网爆款产品,爆品销量榜单,全场低至0元起,还有更多云产品免费试用,带你0门槛上云

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: