GA の Amazon EKS Windows にはバグがありますが、最速です

こんにちは。Windows コンテナ用の AWS EKS (Elastic Kubernetes Service) サービスのセットアップと使用に関する私の経験を共有したいと思います。むしろ、その使用の不可能性と、AWS システム コンテナで見つかったバグについて説明したいと思います。 Windows コンテナー用のこのサービスに興味がある場合は、cat の下にアクセスしてください。

Windows コンテナーが人気のトピックではなく、使用している人がほとんどいないことは承知していますが、kubernetes と Windows に関する Habré に関する記事がいくつかあり、そのような人がまだいるため、この記事を書くことにしました。

開始

すべては、Windows 70%、Linux 30% の社内サービスを kubernetes に移行することが決まったときに始まりました。 この目的のために、AWS EKS クラウド サービスが可能な選択肢の 8 つとして検討されました。 2019 年 1.11 月 XNUMX 日まで、AWS EKS Windows はパブリック プレビューでした。私はそれを使い始めました。そこでは kubernetes の古い XNUMX バージョンが使用されていましたが、とにかくそれをチェックして、このクラウド サービスがどの段階にあるのか、機能しているかどうかを確認することにしました。結局のところ、いいえ、ポッドの削除の追加にバグがあり、古いポッドは Windows ワーカー ノードと同じサブネットからの内部 IP 経由で応答を停止していました。

そのため、AWS EKS の使用を放棄し、同じ EC2 上の kubernetes 上の独自のクラスターを使用することが決定されました。これにより、すべてのバランシングと HA を CloudFormation 経由で自分たちで記述するだけで済みます。

Amazon EKS Windows コンテナのサポートが一般提供開始

マーティン・ビービー著 | 08 年 2019 月 XNUMX 日

自分のクラスターの CloudFormation にテンプレートを追加する前に、このニュースを目にしました。 Amazon EKS Windows コンテナのサポートが一般提供開始

もちろん、私はすべての仕事を脇に置き、彼らが GA に対して何をしたのか、そしてパブリック プレビューですべてがどのように変わったのかを研究し始めました。 はい、AWS はうまくいきました。Windows ワーカー ノードのイメージをバージョン 1.14 に更新しました。また、クラスター自体 (EKS のバージョン 1.14) も Windows ノードをサポートするようになりました。 パブリック プレビューによるプロジェクト ギタベ 彼らはそれを隠蔽し、ここにある公式ドキュメントを使用するように言いました。 EKS Windows サポート

EKS クラスターを現在の VPC およびサブネットに統合する

上記の発表のリンクとドキュメントのすべてのソースで、独自の eksctl ユーティリティまたはその後の CloudFormation + kubectl を介してクラスターをデプロイし、Amazon のパブリック サブネットのみを使用し、新しいクラスターには別の VPC を使用します。

このオプションは多くの人には適していません。まず、別個の VPC は、そのコストと現在の VPC へのピアリング トラフィックの追加コストを意味します。 すでに AWS に独自の複数の AWS アカウント、VPC、サブネット、ルートテーブル、トランジットゲートウェイなどを備えた既製のインフラストラクチャを持っている人は何をすべきでしょうか? もちろん、これらすべてを中断したりやり直したりする必要はありません。既存の VPC を使用して、新しい EKS クラスターを現在のネットワーク インフラストラクチャに統合する必要があります。分離するには、クラスター用に新しいサブネットを作成するだけです。

私の場合、このパスが選択され、既存の VPC を使用し、新しいクラスターに 2 つのパブリック サブネットと 2 つのプライベート サブネットのみを追加しました。もちろん、ドキュメントに従ってすべてのルールが考慮されています。 Amazon EKS クラスター VPC を作成する.

また、EIP を使用するパブリック サブネットにワーカー ノードがないという条件も XNUMX つありました。

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 --approve

3. vpc コントローラーを含むシステム コンテナーが Linux ワーカー ノードで正常に起動したら、あとは 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 ワーカー ノードでポッドを実行しようとすると、次のエラーが発生します。

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 コントローラーが何らかの理由でその役割を果たせず、ポッドが使用できるように新しい IP アドレスをインスタンスに追加できなかったことは明らかです。

vpc-controller ポッドのログを見てみましょう。次のことがわかります。

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.

Google で検索しても何もヒットしませんでした。どうやらまだ誰もそのようなバグを発見していないか、問題を投稿していないようだったので、最初に自分で選択肢を考える必要がありました。 最初に思いついたのは、おそらく vpc コントローラーが ip-10-xxx.ap-xxx.compute.internal を解決できず、そこに到達できないため、エラーが発生するのではないかということでした。

はい、確かに、私たちは VPC でカスタム DNS サーバーを使用しており、原則として Amazon のサーバーは使用しません。そのため、この ap-xxx.compute.internal ドメインには転送さえも設定されていませんでした。 このオプションをテストしましたが、結果が得られませんでした。おそらくテストがクリーンではなかったため、さらにテクニカルサポートと連絡を取るときに、彼らの考えに屈しました。

特にアイデアはなかったので、すべてのセキュリティ グループは eksctl 自体によって作成されたため、その保守性に疑いの余地はありませんでした。ルート テーブルも正しく、nat、dns、ワーカー ノードによるインターネット アクセスも存在していました。

さらに、-node-private-networking を使用せずにワーカー ノードをパブリック サブネットにデプロイすると、このノードは vpc コントローラーによってすぐに更新され、すべてが時計のように動作しました。

次の XNUMX つのオプションがありました。

1. あきらめて、誰かが AWS でこのバグについて説明し、修正するまで待ちましょう。そうすれば、AWS EKS Windows は GA でリリースされたばかりなので (この記事を書いている時点で 8 日が経過しています)、安全に使用できるようになります。おそらく、多くの人がそうするでしょう。私と同じ道をたどってください。
2. AWS サポートに手紙を書き、あらゆる場所からの大量のログを使って問題の本質を伝え、VPC とサブネットを使用しているときにサービスが機能しないことを証明してください。ビジネス サポートを受けていたのは無駄ではありません。少なくとも一度は:)

AWSエンジニアとのコミュニケーション

ポータルでチケットを作成した後、誤って Web (電子メールまたはサポート センター) 経由で返信することを選択してしまいました。このオプションを使用すると、私のチケットに重大度 - システム障害があるにもかかわらず、数日後に回答してもらえます。これは 12 時間以内に応答することを意味し、ビジネス サポート プランには 24 時間年中無休のサポートがあるため、最善を望みましたが、結果はいつもどおりでした。

私のチケットは金曜日から月曜日まで未割り当てのままでした。その後、もう一度手紙を書くことにし、チャット応答オプションを選択しました。 しばらく待った後、ハルシャド・マダフが私に会うように指名され、それから始まりました...

私たちはオンラインで 3 時間連続でデバッグし、ログを転送し、問題をエミュレートするために AWS ラボに同じクラスターをデプロイし、私側でクラスターを再作成するなどしました。私たちが到達した唯一のことは、ログを見ると、AWS の内部ドメイン名がリゾルで機能していないことは明らかでした。これについては上で書きましたが、Harshad Madhav から転送を作成するように頼まれました。私たちはカスタム DNS を使用しているため、これが問題になる可能性があると言われています。

輸送

ap-xxx.compute.internal  -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)

Harshad Madhav はそれを確認するために返信し、うまくいくはずですが、いいえ、解決策はまったく役に立ちませんでした。

その後、さらに 2 人のエンジニアとコミュニケーションがあり、XNUMX 人は複雑なケースを恐れてチャットから退出しました。XNUMX 人目は再びデバッグ、ログの送信、両側でのクラスタの作成の全サイクルに一日を費やしました。最後に彼は「うまくいきました、それは私にとってはうまくいきます、ここにいます、私は公式ドキュメントですべてを段階的に実行します、そしてあなたもあなたも成功するでしょう」と言いました。

私は彼に、問題がどこにあるのかわからない場合は、その場を離れて私のチケットを他の人に割り当てるように丁寧に頼みました。

決勝

3 日目に、新しいエンジニアの Arun B. が私に割り当てられました。彼とのコミュニケーションの最初から、これが前の 1 人のエンジニアではないことがすぐにわかりました。 彼は履歴全体を読み、すぐに自分の github にある psXNUMX 上の独自のスクリプトを使用してログを収集するように依頼しました。 この後、クラスターの作成、コマンド結果の出力、ログの収集が繰り返し行われましたが、Arun B. は私に尋ねられた質問から判断すると、正しい方向に進んでいます。

vpc コントローラーで -stderrthreshold=debug を有効にする段階に達したのはいつですか? 次に何が起こったのでしょうか? もちろん機能しません) ポッドは単にこのオプションでは起動せず、-stderrthreshold=info のみが機能します。

私たちはここで終了し、Arun B. は、同じエラーが発生するために私の手順を再現しようとすると言いました。 翌日、Arun B から返信を受け取りました。彼はこのケースを放棄しませんでしたが、vpc コントローラーのレビュー コードを取り上げ、それがどこにあるのか、なぜ機能しないのかを見つけました。

したがって、VPC でメイン ルート テーブルを使用する場合、デフォルトでは、vpc コントローラーに必要な必要なサブネットとの関連付けがありません。パブリック サブネットの場合、カスタム ルート テーブルがあります。それには関連性があります。

メイン ルート テーブルと必要なサブネットの関連付けを手動で追加し、ノードグループを再作成することで、すべてが完全に機能します。

Arun B. がこのバグを EKS 開発者に本当に報告し、すべてがそのまま動作する新しいバージョンの vpc-controller が登場することを願っています。 現在の最新バージョンは: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
にはこの問題があります。

最後まで読んでいただいた皆さん、実装前に本番環境で使用するすべてのものをテストしてください。

出所： habr.com