先來看看阿里云官方對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更劃算，小公司總要考慮一下成本問題。
你以為這樣就結束了，其實并沒有，因為這個事情被阿里的“領導”上了一課，感受了一次阿里的企業文化。
感興趣的可以訪問《被阿里”領導”上了一課，感受了一次阿里文化》娛樂娛樂。
