キューブオンキューブ、メタクラスター、ハニカム、リソース分散

米。 1. Alibaba Cloud 上の Kubernetes エコシステム

2015 年以来、Alibaba Cloud Container Service for Kubernetes (ACK) は、Alibaba Cloud で最も急速に成長しているクラウド サービスの XNUMX つです。 多数の顧客にサービスを提供しており、アリババの内部インフラストラクチャや会社の他のクラウド サービスもサポートしています。

世界クラスのクラウドプロバイダーによる同様のコンテナサービスと同様に、当社の最優先事項は信頼性と可用性です。 したがって、スケーラブルでグローバルにアクセス可能なプラットフォームが、数万の Kubernetes クラスター用に作成されました。

この記事では、クラウド インフラストラクチャ上で多数の Kubernetes クラスターを管理した経験と、基盤となるプラットフォームのアーキテクチャを共有します。

エントリー

Kubernetes は、クラウド内のさまざまなワークロードの事実上の標準になっています。 図に示すように。 上記の 1 に示すように、ステートフル アプリケーションとステートレス アプリケーション、およびアプリケーション マネージャーなど、ますます多くの Alibaba Cloud アプリケーションが Kubernetes クラスター上で実行されるようになりました。 Kubernetes 管理は、インフラストラクチャを構築および保守するエンジニアにとって、常に興味深く深刻な議論のテーマです。 Alibaba Cloud のようなクラウド プロバイダーに関しては、スケーリングの問題がクローズアップされます。 この規模で Kubernetes クラスターを管理するにはどうすればよいでしょうか? 10 ノードの巨大な Kubernetes クラスターを管理するためのベスト プラクティスについてはすでに説明しました。 もちろん、これは興味深いスケーリング問題です。 しかし、別の尺度、つまり量があります。 クラスター自体.

私たちはこのトピックについて多くの ACK ユーザーと議論してきました。 そのほとんどは、数百ではないにしても、数十の中小規模の Kubernetes クラスターを実行することを選択しています。 これには十分な理由があります。潜在的な損害を制限する、異なるチーム用にクラスターを分離する、テスト用の仮想クラスターを作成するなどです。 ACK がこの使用モデルで世界中のユーザーにサービスを提供することを目指す場合、20 を超えるリージョンにわたる多数のクラスターを確実かつ効率的に管理する必要があります。

米。 2. 膨大な数の Kubernetes クラスターの管理の問題

この規模でクラスターを管理する際の主な課題は何ですか? 図に示すように、対処すべき問題は XNUMX つあります。

• 異質性

ACK は、標準、サーバーレス、エッジ、Windows、その他いくつかのクラスターを含む、さまざまなタイプのクラスターをサポートする必要があります。 クラスターが異なれば、必要なオプション、コンポーネント、ホスティング モデルも異なります。 一部のお客様は、特定のケースに合わせたカスタマイズに関するサポートを必要としています。

• さまざまなクラスターサイズ

クラスターのサイズは、数個のポッドを備えたいくつかのノードから、数千のポッドを備えた数万のノードまでさまざまです。 リソース要件も大きく異なります。 不適切なリソース割り当ては、パフォーマンスに影響を与えたり、障害を引き起こしたりする可能性があります。

• 異なるバージョン

Kubernetes は非常に急速に進化しています。 新しいバージョンは数か月ごとにリリースされます。 顧客は常に新しい機能を試してみたいと考えています。 そのため、彼らはテスト負荷を Kubernetes の新しいバージョンに配置し、運用負荷を安定したバージョンに配置したいと考えています。 この要件を満たすために、ACK は安定したバージョンを維持しながら、新しいバージョンの Kubernetes を顧客に継続的に提供する必要があります。

• セキュリティコンプライアンス

クラスターはさまざまなリージョンに分散されます。 そのため、さまざまな安全要件と公的規制に準拠する必要があります。 たとえば、ヨーロッパのクラスターは GDPR に準拠する必要がありますが、中国の金融クラウドには追加の保護層が必要です。 これらの要件は必須であり、クラウド プラットフォームのクライアントに大きなリスクをもたらすため、無視することは容認できません。

ACK プラットフォームは、上記の問題のほとんどを解決するように設計されています。 現在、世界中で 10 を超える Kubernetes クラスターを確実かつ安定して管理しています。 いくつかの主要な設計/アーキテクチャ原則を通じて、これがどのように達成されたかを見てみましょう。

デザイン

キューブオンキューブとハニカム

集中型の階層とは異なり、セルベースのアーキテクチャは通常、単一のデータセンターを超えてプラットフォームを拡張したり、災害復旧の範囲を拡大したりするために使用されます。

Alibaba Cloud の各リージョンは複数のゾーン (AZ) で構成され、通常は特定のデータセンターに対応します。 広い地域 (黄州など) では、ACK を実行している Kubernetes クライアント クラスターが数千個も存在することがよくあります。

ACK は、Kubernetes 自体を使用してこれらの Kubernetes クラスターを管理します。つまり、クライアント Kubernetes クラスターを管理するために Kubernetes メタクラスターが実行されています。 このアーキテクチャは「kube-on-kube」（KoK）とも呼ばれます。 KoK アーキテクチャでは、クラスタの展開がシンプルかつ決定的であるため、クライアント クラスタの管理が簡素化されます。 さらに重要なのは、ネイティブの Kubernetes 機能を再利用できることです。 たとえば、デプロイメントを通じて API サーバーを管理し、etcd オペレーターを使用して複数の etcd を管理します。 このような再帰は常に特別な喜びをもたらします。

クライアントの数に応じて、複数の Kubernetes メタクラスターが XNUMX つのリージョン内にデプロイされます。 これらのメタクラスターをセルと呼びます。 ゾーン全体の障害から保護するために、ACK は単一リージョンでのマルチアクティブ デプロイメントをサポートします。メタクラスターは Kubernetes クライアント クラスター マスター コンポーネントを複数のゾーンに分散し、それらを同時に (つまりマルチアクティブ モードで) 実行します。 マスターの信頼性と効率を確保するために、ACK はコンポーネントの配置を最適化し、API サーバーと etcd が互いに近くにあることを保証します。

このモデルにより、Kubernetes を効率的、柔軟、かつ確実に管理できます。

メタクラスターのリソース計画

すでに述べたように、各リージョンのメタクラスターの数はクライアントの数によって異なります。 しかし、どの時点で新しいメタクラスターを追加するのでしょうか? これは典型的なリソース計画の問題です。 原則として、既存のメタクラスターがすべてのリソースを使い果たした場合、新しいメタクラスターを作成するのが通例です。

ネットワークリソースを例に考えてみましょう。 KoK アーキテクチャでは、クライアント クラスターの Kubernetes コンポーネントがメタクラスター内のポッドとしてデプロイされます。 を使用しております ターウェイ (図3)は、Alibaba Cloudがコンテナネットワーク管理のために開発した高性能プラグインです。 豊富なセキュリティ ポリシー セットを提供し、Alibaba Cloud Elastic Networking Interface (ENI) を介して顧客の Virtual Private Cloud (VPC) に接続できるようにします。 メタクラスター内のノード、ポッド、サービス全体にネットワーク リソースを効果的に分散するには、仮想プライベート クラウドのメタクラスター内でのそれらの使用状況を注意深く監視する必要があります。 ネットワーク リソースが終了すると、新しいセルが作成されます。

各メタクラスター内のクライアントクラスターの最適な数を決定するために、コスト、密度要件、リソース割り当て、信頼性要件、および統計も考慮します。 新しいメタクラスターを作成するかどうかは、これらすべての情報に基づいて決定されます。 小規模なクラスターは将来的に大幅に拡大する可能性があるため、クラスターの数が変わらない場合でもリソースの消費量が増加することに注意してください。 通常、各クラスターが成長するのに十分な空き領域を残しておきます。

米。 3. 地上波ネットワークアーキテクチャ

クライアント クラスタ間でのウィザード コンポーネントのスケーリング

ウィザード コンポーネントにはさまざまなリソースが必要です。 これらは、クラスター内のノードとポッドの数、APIServer と対話する非標準のコントローラー/オペレーターの数によって異なります。

ACK では、各 Kubernetes クライアント クラスターのサイズとランタイム要件が異なります。 ウィザード コンポーネントを配置するための汎用構成はありません。 大規模なクライアントに対して誤って低いリソース制限を設定すると、そのクラスターは負荷に対処できなくなります。 すべてのクラスターに対して控えめに高い制限を設定すると、リソースが無駄になります。

信頼性とコストの間の微妙なトレードオフを見つけるために、ACK は型システムを使用します。 つまり、小、中、大の XNUMX 種類のクラスターを定義します。 各タイプには個別のリソース割り当てプロファイルがあります。 タイプは、ウィザード コンポーネントの負荷、ノード数、その他の要因に基づいて決定されます。 クラスターのタイプは時間の経過とともに変化する可能性があります。 ACK はこれらの要因を継続的に監視し、それに応じてタイプをアップ/ダウンできます。 クラスターのタイプが変更されると、ユーザーの介入を最小限に抑えて、リソース割り当てが自動的に更新されます。

私たちは、これらの変更がよりスムーズに行われ、より経済的に意味のあるものになるように、よりきめ細かいスケーリングとより正確なタイプ更新によりこのシステムを改善するよう取り組んでいます。

米。 4. インテリジェントな多段式スイッチング

大規模なクライアント クラスターの進化

前のセクションでは、多数の Kubernetes クラスターの管理のいくつかの側面について説明しました。 ただし、解決する必要がある別の問題、それはクラスターの進化です。

Kubernetes はクラウド世界の「Linux」です。 継続的に更新され、よりモジュール化されています。 私たちは常に新しいバージョンを顧客に提供し、脆弱性を修正し、既存のクラスターを更新するだけでなく、多数の関連コンポーネント (CSI、CNI、デバイス プラグイン、スケジューラー プラグインなど) を管理する必要があります。

Kubernetes コンポーネント管理を例に挙げてみましょう。 まず、これらすべての接続されたコンポーネントを登録および管理するための集中システムを開発しました。

米。 5. 柔軟でプラグイン可能なコンポーネント

先に進む前に、更新が成功したことを確認する必要があります。 これを行うために、コンポーネントの機能をチェックするシステムを開発しました。 チェックはアップデートの前後に実行されます。

米。 6. クラスタコンポーネントの事前確認

これらのコンポーネントを迅速かつ確実に更新するために、継続的展開システムは部分的な進行 (グレースケール)、一時停止、その他の機能のサポートと連動します。 標準の Kubernetes コントローラーは、この使用例にはあまり適していません。 したがって、クラスター コンポーネントを管理するために、プラグインと補助制御モジュール (サイドカー管理) を含む一連の特殊なコントローラーを開発しました。

たとえば、BroadcastJob コントローラーは、各ワーカー マシン上のコンポーネントを更新したり、各マシン上のノードをチェックしたりするように設計されています。 ブロードキャスト ジョブは、DaemonSet などのクラスター内の各ノードでポッドを実行します。 ただし、DaemonSet は常にポッドを長時間実行し続けますが、BroadcastJob はポッドを折りたたみます。 また、ブロードキャスト コントローラーは、新しく参加したノードでポッドを起動し、必要なコンポーネントでノードを初期化します。 2019年XNUMX月には、私たち自身も社内で使用しているOpenKruise自動化エンジンのソースコードを公開しました。

米。 7. OpenKurise は、すべてのノードでのブロードキャスト タスクの実行を組織します。

お客様が適切なクラスター構成を選択できるように、サーバーレス、エッジ、Windows、ベア メタル プロファイルなどの事前定義されたプロファイルのセットも提供しています。 状況が拡大し、お客様のニーズが高まるにつれて、面倒なセットアップ プロセスを簡素化するためにプロファイルをさらに追加していきます。

米。 8. さまざまなシナリオに対応する高度で柔軟なクラスター プロファイル

データセンター全体にわたるグローバルな可観測性

以下の図に示すように。 9 日、Alibaba Cloud Container クラウド サービスは世界 XNUMX の地域に展開されました。 この規模を考慮すると、ACK の主な目標の XNUMX つは、実行中のクラスターの状態を簡単に監視して、クライアント クラスターに問題が発生した場合にその状況に迅速に対応できるようにすることです。 言い換えれば、すべてのリージョンのクライアント クラスターから統計をリアルタイムで効率的かつ安全に収集し、結果を視覚的に表示できるソリューションを考え出す必要があります。

米。 9. Alibaba Cloud Container サービスを XNUMX の地域でグローバルに展開

多くの Kubernetes 監視システムと同様に、私たちは Prometheus をメインツールとして使用します。 Prometheus エージェントは、メタクラスターごとに次のメトリクスを収集します。

• ホスト リソース (CPU、メモリ、ディスクなど) やネットワーク帯域幅などの OS メトリック。
• metacluster およびクライアント クラスター管理システム (kube-apiserver、kube-controller-manager、kube-scheduler など) のメトリック。
• kubernetes-state-metrics および cadvisor からのメトリクス。
• ディスク書き込み時間、データベース サイズ、ノード間の接続のスループットなどの etcd メトリクス。

グローバル統計は、典型的な多層集計モデルを使用して収集されます。 各メタクラスターからの監視データは、まず各リージョンで集約され、全体像を示す中央サーバーに送信されます。 すべてはフェデレーション メカニズムを通じて機能します。 各データセンターの Prometheus サーバーはそのデータセンターからメトリクスを収集し、中央の Prometheus サーバーは監視データの集約を担当します。 AlertManager は中央の Prometheus に接続し、必要に応じて DingTalk、電子メール、SMS などを介してアラートを送信します。 視覚化 - Grafana を使用します。

図 10 では、監視システムは XNUMX つのレベルに分割できます。

• 境界レベル

中心から最も遠い層。 Prometheus Edge Server は各メタクラスター内で実行され、同じネットワーク ドメイン内のメタクラスターとクライアントクラスターからメトリクスを収集します。

• カスケードレベル

Prometheus カスケード レイヤーの機能は、複数のリージョンから監視データを収集することです。 これらのサーバーは、中国、アジア、ヨーロッパ、アメリカなどのより大きな地理単位のレベルで動作します。 クラスターが成長するにつれて、リージョンが分割される可能性があり、その後、新しい大きなリージョンごとにカスケード レベルの Prometheus サーバーが表示されます。 この戦略を使用すると、必要に応じてスムーズに拡張できます。

• 中央レベル

中央の Prometheus サーバーはすべてのカスケード サーバーに接続し、最終的なデータ集約を実行します。 信頼性を確保するために、XNUMX つの中央 Prometheus インスタンスが異なるゾーンで起動され、同じカスケード サーバーに接続されました。

米。 10. Prometheus フェデレーション メカニズムに基づくグローバル マルチレベル監視アーキテクチャ

サマリー

Kubernetes ベースのクラウド ソリューションは、業界を変革し続けています。 Alibaba Cloud コンテナ サービスは、安全で信頼性が高く、パフォーマンスの高いホスティングを提供します。これは、最高の Kubernetes クラウド ホスティングの XNUMX つです。 Alibaba Cloud チームは、オープンソースとオープンソース コミュニティの原則を強く信じています。 私たちは今後もクラウド テクノロジーの運用および管理の分野における知識を共有していきます。

出所： habr.com