下午好，我想與大家分享我為 Windows 容器設定和使用 AWS EKS（Elastic Kubernetes Service）服務的經驗，或者更確切地說，關於使用它的不可能性，以及在 AWS 系統容器中發現的錯誤。誰對Windows 容器的這項服務感興趣，請在cat 下。
我知道 Windows 容器不是一個熱門話題，很少有人使用它們，但我仍然決定寫這篇文章，因為 Habré 有幾篇關於 kubernetes 和 Windows 的文章，而且仍然有這樣的人。
開始
這一切都是從決定將我們公司的服務遷移到kubernetes開始的，其中70%是Windows，30%是Linux。 為此，AWS EKS 雲端服務被認為是可能的選擇之一。 直到8年2019月1.11日，AWS EKS Windows處於公共預覽版，我開始使用它，那裡使用舊的XNUMX版本的kubernetes，但我決定無論如何檢查一下，看看這個雲端服務處於什麼階段，是否正常工作事實證明，不，在刪除Pod 的過程中存在一個錯誤，而舊的Pod 則停止透過與Windows 工作節點位於同一子網路的內部IP 來回應。
因此，我們決定放棄使用 AWS EKS，轉而在同一 EC2 上的 kubernetes 上使用我們自己的集群，只是我們必須透過 CloudFormation 自行描述所有平衡和 HA。
Amazon EKS Windows 容器支援現已全面推出
作者：馬丁比比 | 08 年 2019 月 XNUMX 日
在我有時間為自己的叢集向 CloudFormation 添加範本之前，我看到了這則新聞
當然，我把所有的工作放在一邊，開始研究他們為 GA 做了什麼，以及公開預覽版如何改變一切。 是的，AWS 做得很好，將 Windows 工作節點的鏡像更新到了 1.14 版，而 EKS 中的叢集本身（1.14 版）現在支援 Windows 節點。 專案公開預覽於 他們掩蓋了它並說現在使用這裡的官方文件：
將EKS集群整合到目前VPC和子網中
在所有來源中，在公告的上述連結以及文件中，建議透過專有的 eksctl 實用程式或透過 CloudFormation + kubectl 部署集群，僅使用 Amazon 中的公共子網，並建立一個為新集群提供單獨的 VPC。
此選項並不適合許多人；首先，單獨的 VPC 意味著其成本 + 當前 VPC 的對等流量會產生額外費用。 那些已經在 AWS 中擁有現成基礎設施並擁有自己的多個 AWS 帳戶、VPC、子網路、路由表、中轉網關等的人應該做什麼？ 當然，您不想破壞或重做這一切，您需要將新的 EKS 叢集整合到目前的網路基礎架構中，使用現有的 VPC，並且為了分離，最多為叢集建立新的子網路。
在我的例子中，選擇了這條路徑，我使用了現有的VPC，只為新集群添加了2個公共子網和2個私有子網，當然，根據文檔考慮了所有規則 .
還有一個條件：公共子網路中沒有使用 EIP 的工作節點。
eksctl 與 CloudFormation
我會立即預約，我嘗試了兩種部署叢集的方法，在這兩種情況下，情況都是一樣的。
我將展示一個僅使用 eksctl 的範例，因為這裡的程式碼會更短。 使用eksctl，分3步驟部署叢集：
1. 我們建立叢集本身 + Linux 工作節點，稍後將託管系統容器和同樣不幸的 vpc 控制器。
eksctl create cluster
--name yyy
--region www
--version 1.14
--vpc-private-subnets=subnet-xxxxx,subnet-xxxxx
--vpc-public-subnets=subnet-xxxxx,subnet-xxxxx
--asg-access
--nodegroup-name linux-workers
--node-type t3.small
--node-volume-size 20
--ssh-public-key wwwwwwww
--nodes 1
--nodes-min 1
--nodes-max 2
--node-ami auto
--node-private-networking為了部署到現有的 VPC，只需指定子網路的 ID，eksctl 將確定 VPC 本身。
為了確保工作節點僅部署到私有子網，您需要為節點群組指定 --node-private-networking。
2. 我們在叢集中安裝 vpc-controller，然後它將處理我們的工作節點，計算空閒 IP 位址的數量以及實例上 ENI 的數量，並新增和刪除它們。
eksctl utils install-vpc-controllers --name yyy --approve3.系統容器在 Linux 工作節點（包括 vpc-controller）上成功啟動後，剩下的就是使用 Windows 工作節點建立另一個節點群組。
eksctl create nodegroup
--region www
--cluster yyy
--version 1.14
--name windows-workers
--node-type t3.small
--ssh-public-key wwwwwwwwww
--nodes 1
--nodes-min 1
--nodes-max 2
--node-ami-family WindowsServer2019CoreContainer
--node-ami ami-0573336fc96252d05
--node-private-networking當您的節點成功連接到叢集並且一切似乎都正常後，它處於就緒狀態，但事實並非如此。
vpc 控制器錯誤
如果我們嘗試在 Windows 工作節點上執行 pod，我們將收到錯誤：
NetworkPlugin cni failed to teardown pod "windows-server-iis-7dcfc7c79b-4z4v7_default" network: failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address]如果我們深入觀察，我們會發現 AWS 中的實例如下所示：
它應該是這樣的：
由此可見，vpc-controller 由於某種原因沒有履行其職責，無法向實例添加新的 IP 位址以便 Pod 可以使用它們。
讓我們來看看 vpc-controller pod 的日誌，我們看到的是：
kubectl 日誌-n kube 系統
I1011 06:32:03.910140 1 watcher.go:178] Node watcher processing node ip-10-xxx.ap-xxx.compute.internal.
I1011 06:32:03.910162 1 manager.go:109] Node manager adding node ip-10-xxx.ap-xxx.compute.internal with instanceID i-088xxxxx.
I1011 06:32:03.915238 1 watcher.go:238] Node watcher processing update on node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.200423 1 manager.go:126] Node manager failed to get resource vpc.amazonaws.com/CIDRBlock pool on node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxxx
E1011 06:32:08.201211 1 watcher.go:183] Node watcher failed to add node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxx
I1011 06:32:08.201229 1 watcher.go:259] Node watcher adding key ip-10-xxx.ap-xxx.compute.internal (0): failed to find the route table for subnet subnet-0xxxx
I1011 06:32:08.201302 1 manager.go:173] Node manager updating node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.201313 1 watcher.go:242] Node watcher failed to update node ip-10-xxx.ap-xxx.compute.internal: node manager: failed to find node ip-10-xxx.ap-xxx.compute.internal.在谷歌上的搜尋沒有得到任何結果，因為顯然還沒有人發現這樣的錯誤，或者還沒有在上面發布問題，我必須先自己考慮選項。 我首先想到的是，vpc-controller 可能無法解析 ip-10-xxx.ap-xxx.compute.internal 並存取它，因此會發生錯誤。
是的，確實，我們在 VPC 中使用自訂 DNS 伺服器，原則上我們不使用 Amazon 的 DNS 伺服器，因此甚至沒有為此 ap-xxx.compute.internal 網域配置轉送。 我測試了這個選項，它沒有帶來結果，也許測試不乾淨，因此，進一步，在與技術支援溝通時，我屈服於他們的想法。
由於沒有任何想法，所有安全群組都是 eksctl 自己創建的，因此它們的可服務性毫無疑問，路由表也正確，nat、dns、工作節點的網路存取也在那裡。
此外，如果您在不使用 —node-private-networking 的情況下將工作節點部署到公共子網，則該節點會立即由 vpc-controller 更新，並且一切都像發條一樣運作。
有兩個選擇：
- 放棄它，等到有人描述 AWS 中的這個錯誤並修復它，然後您就可以安全地使用 AWS EKS Windows，因為它們剛剛在 GA 中發布（在撰寫本文時已經過去了 8 天），很多人可能會走和我一樣的路。
- 寫信給AWS Support，用來自各地的一大堆日誌告訴他們問題的本質，並向他們證明他們的服務在使用你的VPC和子網時不起作用，我們有業務支持不是沒有意義的，你應該使用至少一次:)
與AWS工程師溝通
在入口網站上建立票證後，我錯誤地選擇透過網路 - 電子郵件或支援中心回覆我，透過此選項，他們可以在幾天後回覆您，儘管我的票證嚴重程度 - 系統受損，這意味著在12 小時內得到回复，並且由於業務支援計劃有24/7 支持，我希望得到最好的結果，但結果一如既往。
從週五到週一，我的票一直沒有分配，然後我決定再次寫信給他們並選擇聊天回覆選項。 等了一小會兒，哈沙德·馬達夫被指定來見我，然後事情就開始了…
我們連續在線調試了3個小時，傳輸日誌，在AWS實驗室部署相同的集群來模擬問題，我自己重新創建集群等等，我們唯一得出的結果是日誌很明顯，resol 無法正常工作AWS 內部域名（我在上面寫過），Harshad Madhav 要求我建立轉發，據稱我們使用自訂DNS，這可能是一個問題。
轉發
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)就這樣，一天結束了。Harshad Madhav 回信檢查，應該可行，但不，決議根本沒有幫助。
然後又和另外兩個工程師進行了溝通，其中一個直接退出了聊天，顯然他害怕複雜的情況，第二個又花了我一天的時間進行完整的調試，發送日誌，在雙方創建集群，在最後他只是說好，這對我有用，我在這裡，我按照官方文檔一步一步做所有事情，你和你都會成功。
如果您不知道在哪裡尋找問題，我禮貌地請他離開並指派其他人來處理我的票。
決賽
第三天，我被指派了一位新工程師Arun B.，從一開始與他溝通就清楚這不是之前的三位工程師。 他閱讀了整個歷史記錄，並立即要求在 ps3 上使用他自己的腳本收集日誌，該腳本位於他的 github 上。 接下來又是創建叢集、輸出命令結果、收集日誌的所有迭代，但從向我提出的問題來看，Arun B. 正在朝著正確的方向前進。
我們什麼時候開始在他們的 vpc-controller 中啟用 -stderrthreshold=debug ，接下來發生了什麼？ 當然它不起作用）Pod 根本不使用此選項啟動，只有 -stderrthreshold=info 起作用。
我們到這裡就完成了，Arun B. 說他會嘗試重現我的步驟以獲得相同的錯誤。 第二天我收到了Arun B的回复，他並沒有放棄這個case，而是拿起他們的vpc-controller的review代碼，找到了它在哪裡以及為什麼不起作用：
因此，如果您在VPC 中使用主路由表，那麼預設情況下它不會與必要的子網路關聯，而這對於vpc-controller 來說是非常必要的，在公共子網路的情況下，它有一個自訂路由表有一個關聯。
透過手動新增主路由表與必要子網路的關聯，並重新建立節點群組，一切都可以完美運作。
我希望 Arun B. 能夠真正向 EKS 開發人員報告此錯誤，我們將看到新版本的 vpc-controller，其中一切都可以開箱即用。 目前最新版本是：602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
有這個問題。
感謝所有讀到最後的人，在實施之前測試您將在生產中使用的所有內容。
來源： www.habr.com