K8S マルチクラスターのジャーニー

おい、ハブル！

私たちはExnessプラットフォームチームを代表しています。 以前、私たちの同僚がすでに次のような記事を書いていました。 k8s の本番環境対応イメージ。 今日は、サービスを Kubernetes に移行した経験を共有したいと思います。

まず、議論される内容をよりよく理解するために、いくつかの数字を示します。

• 当社の開発部門は 100 人以上で構成されており、その中には自給自足の QA、DevOps、スクラム プロセスを持つ 10 を超える異なるチームが含まれます。 開発スタック - Python、PHP、C++、Java、Golang。 
• テスト環境と実稼働環境のサイズは、それぞれ約 2000 コンテナーです。 彼らは VMware の下で独自の仮想化上で Rancher v1.6 を実行しています。 

動機

よく言われるように、永遠に続くものはなく、Rancher はかなり前にバージョン 1.6 のサポート終了を発表しました。 はい、1.6 年以上かけて、私たちはそれを準備し、発生する問題を解決する方法を学びましたが、決して修正されない問題に直面することがますます増えています。 Rancher XNUMX には、権利を発行するための硬直化したシステムもあり、ほとんどすべてのことを実行できるか、何も実行できないかのどちらかです。

独自の仮想化により、データ ストレージとそのセキュリティをより細かく制御できるようになりましたが、会社の絶え間ない成長、プロジェクトの数、およびそれらに対する要件を考慮すると、受け入れがたい運用コストが課せられました。

私たちは、IaC 標準に従い、必要に応じて、地理的な場所を問わず、ベンダー ロックなしで容量を迅速に取得し、すぐに放棄できるようにしたいと考えていました。

最初のステップ

まず第一に、チームが開発サイクルを短縮し、電力を提供するプラットフォームとのやり取りにかかる運用コストを最小限に抑えることができる最新のテクノロジーとソリューションに依存したいと考えました。 
 
もちろん、私たちの頭に最初に浮かんだのは Kubernetes でしたが、私たちは興奮せず、それが正しい選択であるかどうかを確認するために少し調査しました。 私たちはオープンソース ソリューションのみを評価しましたが、不公平な戦いでは Kubernetes が無条件で勝利しました。  

次に、クラスターを作成するツールを選択するという問題が生じました。 最も人気のあるソリューションである kops、kubespray、kubeadm を比較しました。

まず、kubeadm はあまりにも複雑な道であり、むしろある種の「自転車」の発明者のように見え、kops には十分な柔軟性がありませんでした。

そして勝者は次のとおりでした。

私たちは独自の仮想化と AWS の実験を開始し、全員が同じ「クラスター」を共有する以前のリソース管理パターンとほぼ同じものを再現しようとしました。 そして今、10 台の小さな仮想マシンからなる最初のクラスターができました。そのうちの XNUMX 台は AWS にあります。 私たちはチームをそこに移行しようと試み始めましたが、すべてが「良好」であるように見え、物語は終了する可能性がありましたが...

最初の問題

Ansible は kubespray の基盤であり、IaC に従うことを可能にするツールではありません: ノードのコミッショニング/デコミッション時に常に何か問題が発生し、何らかの介入が必要になり、異なる OS を使用すると、プレイブックの動作が異なります。 。 クラスター内のチームとノードの数が増えるにつれて、プレイブックの完了にますます時間がかかっていることに気づき始めました。その結果、私たちの記録は 3,5 時間になりました。あなたの記録はどうですか? 🙂

そして、kubespray は単なる Ansible であり、一見するとすべてが明らかであるように見えますが、次のとおりです。

移行の開始時点では、AWS と仮想化のみでキャパシティーを立ち上げることがタスクでしたが、その後、よくあることですが、要件が変わりました。
 


これを考慮すると、クラスターが非常に離れていて、異なるプロバイダーによって管理されている場合、リソースを XNUMX つのオーケストレーション システムに結合するという古いパターンは適切ではないことが明らかになりました。 

さらに。 すべてのチームが同じクラスター内で作業している場合、NodeSelector が正しくインストールされていないさまざまなサービスが別のチームの「外部」ホストに飛んでそこのリソースを利用する可能性があります。また、テイントが設定されている場合は、いずれかのサービスが動作していないという要求が常に発生します。人的要因により正しく配布されていません。 もう XNUMX つの問題は、特にノード間でサービスを分散する際の問題を考慮したコストの計算でした。

別の話は、従業員への権利の発行でした。各チームはクラスターの「先頭に立って」クラスターを完全に管理したいと考えていましたが、チームは基本的に互いに独立しているため、完全な崩壊を引き起こす可能性がありました。

何をするか？

上記と、より独立性を高めたいというチームの要望を考慮して、XNUMX つのチーム - XNUMX つのクラスターというシンプルな結論を下しました。 

そこで XNUMX 番目のものを取得しました。

そして XNUMX 番目のクラスター: 

そこで私たちは考え始めました。XNUMX 年以内に、私たちのチームに複数のクラスターができたとしますか? たとえば、地理的に異なる地域にあるのか、それとも異なるプロバイダーの管理下にあるのか? また、一部のテストでは、一時的なクラスターを迅速にデプロイできるようにしたいと考えています。 

完全な Kubernetes が登場するでしょう! これはある種の MultiKubernetes であることが判明しました。 

同時に、私たち全員が何らかの方法でこれらすべてのクラスターを維持し、それらへのアクセスを簡単に管理できるだけでなく、手動介入なしで新しいクラスターを作成したり、古いクラスターを廃止したりできるようにする必要があります。

Kubernetes の世界への旅を始めてからしばらく時間が経過したため、利用可能なソリューションを再検討することにしました。 Rancher 2.2 はすでに市場に存在していることが判明しました。

私たちの調査の最初の段階で、Rancher Labs はすでにバージョン 2 の最初のリリースを作成していましたが、いくつかのパラメーターを使用して外部依存関係なしでコンテナーを起動するか、公式の HELM チャートを使用することで非常に迅速にリリースできましたが、それは粗雑に見えました。そして、それが開発されるか、すぐに放棄されるかにかかわらず、この決定を信頼できるかどうかはわかりませんでした。 UI 自体のクラスター = クリックのパラダイムも私たちには合わず、RKE はかなり狭い範囲に焦点を当てたツールであるため、RKE に縛られることは望んでいませんでした。 

バージョン Rancher 2.2 はすでにより実用的な外観を備えており、以前のバージョンと合わせて、多くの外部プロバイダーとの統合、権利と kubeconfig ファイルの単一配布ポイント、kubectl の起動など、すぐに使える興味深い機能を多数備えていました。 UI であなたの権利を持つイメージ、ネストされた名前空間、別名プロジェクト。 

Rancher 2 を中心にすでにコミュニティが形成されており、それを管理するために HashiCorp Terraform というプロバイダーが作成され、すべてをまとめるのに役立ちました。

どうしたの

その結果、Rancher を実行する XNUMX つの小さなクラスターが完成しました。このクラスターは、他のすべてのクラスターだけでなく、それに接続されている多くのクラスターにもアクセスでき、どのクラスターへのアクセスも、ユーザーを ldap ディレクトリに追加するだけで許可されます。それがどこにあるか、どのプロバイダーのリソースが使用されているか。

gitlab-ci と Terraform を使用して、クラウドプロバイダーまたは独自のインフラストラクチャに任意の構成のクラスターを作成し、Rancher に接続できるシステムを作成しました。 これはすべて IaC スタイルで行われ、各クラスターはリポジトリによって記述され、その状態はバージョン管理されます。 同時に、ほとんどのモジュールは外部リポジトリから接続されるため、残っているのは変数を渡すかインスタンスのカスタム構成を記述することだけであり、コードの繰り返しの割合を減らすのに役立ちます。

もちろん、私たちの旅は終わったわけではなく、クラスターのログとメトリクスを扱う単一ポイント、サービス メッシュ、マルチクラスターでの負荷を管理するための gitops など、多くの興味深いタスクがまだ残っています。 私たちの経験が興味深いものであることを願っています。 

この記事は、プラットフォーム エンジニアの A. Antipov、A. Ganush によって執筆されました。 

出所： habr.com