Kubernetes升級IPv6，雙棧過渡是最佳選擇，大型物聯網使用者很重視
在Kubernetes誕生之前很久，大約20年前就已經指定了有限數量的公共IPv4地址和IPv6地址空間來解決網際網路定址問題。Kubernetes最初是在Google內部開發的，而且近年來才開始支援像Google和AWS這樣的雲服務，所以Kubernetes最初只支援IPv4。
對於已經致力於使用IPv6的企業而言，這可能是一個問題，而且對於需要太多IP地址的物聯網裝置而言更加重要。“物聯網客戶使用IPv6部署各種裝置和邊緣裝置，”微軟首席軟體工程師Khaled Henidak指出，他致力於Azure的容器服務，並協調微軟對Kubernetes的上游貢獻。
運營商和電信公司也對採用Kubernetes感興趣，比如美國最大運營商AT＆T正在使用Kubernetes作為其用於執行5G和公共安全網路服務的Airship專案的基礎。但他們已經部署了大量的IPv6，尤其是行動網路。大約90％的T-Mobile USA和Verizon Wireless流量已經是IPv6；對康卡斯特和AT＆T而言，這個比例約為70％。
截至2017年，全球IP地址註冊商只有3個新的IPv4地址可供分配（其中沒有一個在美國，因此任何需要更多IPv4地址的人，都必須找到願意出售他們的人）。
這意味著即使是那些因為使用像NAT這樣的技術來解決地址短缺，而放慢IPv4速度的企業也會遇到問題，Google Cloud的首席軟體工程師Tim Hockin表示。“Kubernetes非常自由地使用IP地址（每個Pod一個IP），這簡化了系統並使其更易於使用和理解。對於非常大的安裝，IPv4可能很難。發現大型企業已經“切斷”其網路中的私有IPv4空間並不罕見，因此為Kubernetes叢集尋找空間可能很難或不可能。IPv6使IP空間實際上是無限的。”
Kubernetes 1.9中添加了支援IPv6的叢集的支援作為alpha功能，而對於版本1.13，Kubernetes預設DNS伺服器更改為具有完全IPv6支援的CoreDNS。
“從支援[IPv6支援]回到測試版和遺傳演算法的唯一方面是與我們的自動化測試進行更深層次的整合，這是由我們的開發人員社群推動的，”Hockin說。
Kubernetes中的內建橋接網路使用Linux iptables功能實現; “iptables一段時間以來一直是對IPv6友好的，”Henidak指出。如果你正在使用容器網路介面（CNI）堆疊進行聯網，那麼像Project Calico這樣的外掛可讓你禁用IPv4併為pod啟用IPv6。
他指出，遷移到IPv6叢集不應該做很多工作，但有一些事情需要注意。“如果你的網路基礎設施和應用程式已經為IPv6做好準備，那麼改變Kubernetes使用純IPv6對於Kubernetes（dev或ops）使用者來說應該不是特別困難。每個主要的作業系統都支援IPv6，大多數開源應用程式都可以在IPv6環境中執行。可能需要稽核執行網路相關內容的自定義應用程式，以確保它們對IPv6安全。例如，IPv4地址通常儲存在32位整數變數中，但IPv6地址不適合。”
雙棧
但是，僅僅支援單個地址系列，無論是IPv4還是IPv6，都是不夠的，因為它不能讓Kubernetes輕鬆適應它需要整合的所有其他基礎設施。
“Kubernetes並不孤立地執行；它在本地執行，需要與其他應用程式進行互動，或者主要是在雲上執行，”Henidak指出。“如果我有一個應用程式，並通過負載均衡將其提供給外部，我在外部有一個IP，如果我的Kubernetes叢集是IPv4或IPv6，那麼該地址將只是IPv4或IPv6。如果我的網路僅使用一個地址空間和一個地址系列，則所有內容都必須位於同一系列中。如果我將我的節點作為IPv6，那麼節點的客戶端必須是IPv6，資料庫必須是IPv6。這會產生問題，因為實際上很少有人將100％的所有內容用作IPv6。”
使用IPv6裝置的物聯網客戶可以執行IPv6 Kubernetes叢集供他們連線，但正如他指出的那樣，“但這些叢集還需要連線到內部執行或在另一個叢集中執行的後端應用程式，甚至連線到只能與IPv4通訊的雲服務。”
在網路中沒有複雜的IPv4/IPv6轉換機制的情況下進行這項工作需要雙棧網路，其中每個pod都分配了IPv4和IPv6地址，因此它可以與IPv6系統以及使用IPv4的傳統應用和雲服務進行通訊。
AWS擁有最廣泛的IPv6支援，但並未涵蓋所有服務。15個AWS區域對EC2例項提供IPv6支援，為Elastic Load Balancing提供可公共路由的IPv6地址，通過雙棧端點訪問S3儲存，對從裝置傳遞到AWS IoT服務的訊息提供IPv6支援，為公共和私有提供雙棧支援具有Route Connect的虛擬介面，具有Route 53的IPv6端點的IPv6 DNS查詢和執行狀況檢查，以及對CloudFront，Web應用程式防火牆和S3傳輸加速的IPv6支援。
自2016年以來，大多數Azure區域都通過負載均衡支援雙棧VM ，並且私有預覽了完整的IPv6雙棧支援;一旦可用，Henidak表示將推出AKS和AKS Engine等工具（它使用Azure Resource Manager模板在Azure IaaS上引導Kubernetes叢集。
“GCP在VPC網路中沒有IPv6支援，但是，”Hockin指出，谷歌員工在GitHub上討論了有關雙棧支援的問題，該服務正在測試GCE內部的一些原型雙棧配置。
為Kubernetes新增雙棧支援需要比單獨支援IPv6更多的工作，並且社群已經在一段時間內致力於Kubernetes增強建議。而不是採用簡單的方法只為pod和節點提供雙棧地址，而是使用單個系列 ，所有IPv4或所有IPv6，用於叢集中的服務IP，這是一個真正的雙棧實現，支援兩個pod的IPv4和IPv6和服務。
由於應用程式使用完全限定的域名進行服務發現，因此叢集中的DNS需要知道它是執行IPv4，IPv6還是雙棧。
增強專案將使用Bridge和PTP CNI外掛以及Host-Local IPAM外掛測試雙棧功能。“有多個網路提供商都有自己的基於CNI堆疊的解決方案，”Henidak指出。“他們可能依賴於本機Linux核心功能或他們自己的實現，當Kubernetes遷移到IPv6雙棧時，他們需要提供自己的雙棧實現。”
像NGINX這樣的Ingress控制器也需要提供雙棧支援；在這兩種情況下，網路提供商可能已經在其他環境中支援IPv6，但之前沒有將它帶到Kubernetes，因為它不是雙棧。
“目前的考慮是，服務將有一個ID，上面寫著'我希望將其提供為IPv4或IPv6'，”他解釋道。這是你為互操作性做出的選擇。“如果我的Kubernetes應用程式在雙棧模式下執行，那麼它們有來自不同家族的多個IP地址；如果我將此作為IPv4公開，則意味著僅具有IPv4功能的客戶端將能夠與此服務進行通訊，或者對於IPv6進行通訊。這樣，人們可以從指向同一個應用程式的兩個不同系列中獲取兩個IP地址，從而支援多個客戶端。無論客戶端能夠做什麼，他們都能夠進入叢集。”
目的是在不中斷現有實現和部署的情況下新增新功能。“主要原則不是打破任何東西，”Henidak說。“Kubernetes上有很多工具，很多客戶都在呼叫Kubernetes API，他們期望從服務中獲得某些輸入和輸出。我們想要轉移到雙棧的新工作，而不會破壞任何這一點，同時允許客戶端的最大價值。”
這意味著該專案將在未來版本的Kubernetes中經歷通常的alpha，beta和GA階段，以便有時間進行測試，但這需要一些時間。“對Kubernetes的雙棧IPv6支援或多或少是設計完整的，”Hockin說。“我們有一個非常好的Kubernetes增強建議，但這項工作已經停滯不前了。在完成這項工作之前，還將有一些釋出。”
如果在更改達到Kubernetes的釋出版本（Henidak估計將需要大約9個月）之前需要雙棧IPv6支援，你可以在IPv6模式下執行叢集並通過設定有狀態NAT64和DNS64伺服器來處理地址轉換連線到外部，僅限IPv4的伺服器，雙棧入口控制器，負載平衡到叢集中的僅IPv6端點，以及具有IPv4到IPv6對映的無狀態NAT64伺服器，以便僅IPv4外部客戶端訪問Kubernetes容器或他們公開的服務。
Henidak預測，新提案的最早採用者將是大型物聯網使用者。“我有客戶說，‘我想要IPv6，我現在想要它'。即使是在早期階段測試它並提供反饋，那些人也會立即接受，社群中的使用者都希望與這些早期採用者接觸。“
“然後有些人現在對IPv4很瞭解，但他們知道將來他們需要跟蹤提案的IPv6。他們告訴我們‘我的網路上的IPv4空間不足，我已經將我的內部網路轉換為IPv6，我需要雙堆疊來與我的雲託管Kubernetes整合。”