クラウドネイティブによるグレースケールシステム構築

[[399091]]

1 週間前、「大規模な K8s クラスターに直面した際に、ユーザーよりも先に問題を発見する方法」を紹介しました。

本記事では、引き続き、ASI SRE（ASI、Alibaba Serverless Infrastructure、クラウドネイティブアプリケーション向けに設計されたAlibabaの統合インフラストラクチャ）が、Kubernetesシステム下の大規模クラスターシナリオにおいて、ASI独自のインフラストラクチャのグレースケール変更機能を構築する方法を模索している様子を紹介します。

私たちが直面しているもの

ASI は、Alibaba Group がクラウドに全面的に移行したときに誕生しました。グループのインフラストラクチャの大部分をクラウドネイティブに完全移行する一方で、そのアーキテクチャと形式も絶えず進化しています。

ASI は一般的に Kube-on-Kube アーキテクチャを採用しています。最下層にコア Kubernetes メタクラスターを維持し、クラスター内の各テナント クラスターのマスター管理コンポーネント (apiserver、controller-manager、scheduler、etcd) をデプロイします。各ビジネス クラスターには、ASI のさまざまな機能をサポートするために、コントローラーや Webhook などのさまざまなアドオン コンポーネントがデプロイされています。データ プレーン コンポーネント レベルでは、一部の ASI コンポーネントは DaemonSet の形式でノードにデプロイされ、その他のコンポーネントは RPM パッケージの形式でデプロイされます。

同時に、ASI はグループおよび販売エリアのシナリオで数百のクラスターと数十万のノードをサポートします。 ASI 構築の初期段階でも、その管轄下にあるノードの数は数万に達しました。 ASI 独自のアーキテクチャが急速に発展する中で、コンポーネントとオンラインの変更が頻繁に発生しました。初期の頃は、ASI コンポーネントの変更は 1 日に数百回に達することもありました。ただし、CNI プラグイン、CSI プラグイン、etcd、Pouch など、ASI のコア基本コンポーネントのいずれかに誤った変更を加えると、クラスター レベル全体で障害が発生し、上位層のビジネスに回復不可能な損失をもたらす可能性があります。

つまり、大規模なクラスター規模、多数のコンポーネント、頻繁な変更、複雑なビジネス フォームは、ASI またはその他の Kubernetes インフラストラクチャ レイヤーでグレースケール機能を構築し、システムを変更する際のいくつかの深刻な課題です。当時、ASI/Sigma は Alibaba 内にすでにいくつかの変更システムを導入していましたが、それらにはいずれも一定の制限がありました。

Tianji: 一般的なノード公開機能がありますが、クラスターやノードセットなどの ASI メタデータ情報は含まれていません。 UCP: 荒廃したシグマ 2.0 の初期リリース プラットフォーム。 sigma-deploy: イメージ パッチの形式でデプロイメント/デーモンセットを更新する、sigma 3.x のリリース プラットフォームです。 asi-deploy: ASI 独自のコンポーネントを管理する ASI の早期リリース プラットフォーム。イメージ パッチのみをサポートし、Aone の CI/CD パイプラインにのみ適合します。複数の異なる環境間のグレースケールもサポートしていますが、グレースケールの粒度は比較的粗いです。

そのため、私たちは、以前の世代のシグマ/ASIのリリースプラットフォームの歴史から学び、変更の時点から始めて、システム機能に焦点を当て、その後プロセス仕様を補完し、ASIシステムの下でグレースケールシステムを徐々に構築し、Kubernetesテクノロジースタックの下で運用および保守変更プラットフォームを構築して、数千の大規模クラスターの安定性を確保したいと考えています。

プリセットとアイデア

ASI 独自のアーキテクチャと形式の開発は、独自のグレースケール システムの構築方法に大きな影響を与えます。したがって、ASI の開発の初期段階で、私たちは ASI の将来の形について次のような大胆な仮定を立てました。

ACK ベース: ACK (Alibaba Cloud Container Service) は、さまざまなクラウド機能を提供します。 ASIはこれらのクラウド機能を再利用し、アリババグループ内で蓄積された先進的な経験をクラウドにフィードバックします。大規模なクラスター スケール: クラスター リソースの使用率を向上させるために、ASI は大規模なクラスターの形で存在し、単一のクラスターが複数のセカンド パーティ テナントをホストするためのパブリック リソース プールを提供します。多数のクラスター: ASI は、クラスターを地域別に分割するだけでなく、ビジネス パーティやその他のディメンション別に独立したクラスターを分割します。多数のアドオン: Kubernetes システムは、多数のオペレーターを派生するオープン アーキテクチャであり、これらのオペレーターは ASI コア コンポーネントと連携して、外部にさまざまな機能を提供します。複雑な変更シナリオ: ASI コンポーネントの変更シナリオはイメージのリリース形式だけではありません。Kubernetes の宣言型オブジェクト ライフサイクル管理により、変更シナリオは複雑になる傾向があります。

上記の仮定に基づいて、ASI 構築の初期段階で解決する必要があるいくつかの問題をまとめることができます。

単一の大規模クラスター内の変更に対してグレースケール機能を構築するにはどうすればよいでしょうか?複数のクラスターにわたって大規模なグレースケール変更機能を確立するにはどうすればよいでしょうか?コンポーネントとタイプが多数ある場合、コンポーネント管理を確実に行い、各コンポーネントのリリースがオンライン環境に影響を与えないようにするにはどうすればよいでしょうか。

視点を変えて、クラスターの次元から離れ、コンポーネントの観点から変更の複雑さを解決してみましょう。各コンポーネントのライフサイクルは、要件および設計フェーズ、研究開発フェーズ、リリースフェーズに大まかに分けられます。各段階を標準化し、Kubernetes 自体の特性に対応して、固定仕様をシステムに実装し、システム機能を使用してグレースケールプロセスを保証したいと考えています。

ASI の形態と変化のシナリオの特殊性を考慮し、次のアイデアに基づいて ASI のグレースケール システムを体系的に構築します。

需要と設計フェーズでのソリューションの技術レビュー、コンポーネントのオンライン変更のレビュー、コンポーネント開発フェーズでの標準化されたコンポーネント開発プロセス、コンポーネントのリリースと変更フェーズでのコンポーネントの大規模な管理のためのコンポーネントワークベンチ機能の提供、ASIメタデータの構築とグレースケールユニットの改良、ASIの単一クラスタとクラスタ間のグレースケール機能の構築

グレースケールシステム構築

1. 研究開発プロセスの標準化

ASI コアコンポーネントの研究開発プロセスは、次のように要約できます。

ASI 独自のコア コンポーネントについては、品質技術チームの学生と協力して、ASI コンポーネントの e2e テスト プロセスを構築しました。コンポーネント自体の単体テストと統合テストに加えて、ASI 全体の定期的な機能検証と e2e テスト用に別の e2e クラスターを構築しました。

単一コンポーネントの観点から開始し、各コンポーネントの新機能が開発され、コードレビューに合格して開発ブランチにマージされると、e2e プロセスがすぐにトリガーされます。コーラス（クラウドネイティブテストプラットフォーム）システムによってイメージが構築された後、ASIOps（ASI運用保守管理プラットフォーム）によって対応するe2eクラスターにデプロイされ、標準のKubernetes適合スイートテストタスクが実行され、Kubernetesスコープ内の機能が正常かどうかが検証されます。すべてのテスト ケースに合格した場合にのみ、コンポーネントのバージョンをプッシュ可能なバージョンとしてマークできます。それ以外の場合は、後続のリリースは制御制限の対象になります。

しかし、前述のように、Kubernetes のオープン アーキテクチャは、管理、制御、スケジューリングなどのコア コンポーネントが含まれているだけでなく、クラスターの機能は、一緒に実装される上位レベルのオペレーターに大きく依存しています。したがって、Kubernetes 内のホワイト ボックス テストでは、ASI の適用可能なシナリオをすべてカバーすることはできません。基盤となるコンポーネントの機能の変更は、上位レベルの演算子の使用に大きな影響を与えます。そのため、上位レベルの PaaS から開始されるスケーリング、リリースリンクのクォータ検証、クラスター内で通常実行されるその他の機能など、さまざまなオペレーター自体の機能検証を含む、ホワイトボックス適合性に基づくブラックボックステストケースを追加しました。

2. コンポーネントスケール管理

複数コンポーネント、複数クラスタを持つASIの特性を考慮し、従来のasi-deploy機能を拡張し、コンポーネントをエントリポイントとして、複数クラスタ間のコンポーネントの管理機能を強化し、イメージ管理からYAML管理へと進化しました。

Helm テンプレートの機能に基づいて、コンポーネントの YAML をテンプレート、イメージ、構成の 3 つの部分に抽出します。これらはそれぞれ次の情報を表します。

テンプレート: apiVersion、kind など、すべての環境で固定される YAML の情報。イメージ: 単一の環境またはすべてのクラスターで一貫性が維持されることが期待される、YAML 内のコンポーネント イメージに関連する情報。構成: 単一の環境または単一のクラスターにバインドされた YAML の情報。これにより、多様なコンテンツが可能になり、異なるクラスターの構成は異なる場合があります。

したがって、完全な YAML はテンプレート、イメージ、および構成によってレンダリングされます。 ASIOps は、YAML 内のイメージ情報と構成情報をクラスターと時間 (複数のバージョン) の観点から管理し、複数のクラスターにおけるコンポーネントの現在のバージョン情報の分布と、単一クラスターにおけるコンポーネント バージョンの一貫性を計算します。

イメージバージョンについては、バージョンが低すぎるためにオンラインの問題が発生しないように、システムの観点からバージョンの統一を推進しています。構成バージョンについては、管理の観点から複雑さを簡素化し、構成エラーがクラスターに送信されないようにしています。

コンポーネントの基本的なプロトタイプでは、「ワークロード内の画像フィールドを置き換える」といった単純なもの以上のものをリリースしたいと考えています。現在、イメージ以外の構成コンテンツを含む YAML 情報全体を管理しており、イメージの変更以外の変更をサポートする必要があります。したがって、私たちは YAML を kubectl apply にできるだけ近い方法で配布するように努めています。

YAML 仕様情報の 3 つの部分を記録します。

クラスター仕様: 現在のクラスター内の指定されたリソースのステータス。ターゲット仕様: クラスターに公開される YAML 情報。 DB 仕様: 最後に成功したデプロイメントの YAML 情報。これは、kubectl apply によってアノテーションに保存された last-applied-configuration と同じ機能を持ちます。

イメージ、構成、テンプレートで構成された YAML の場合、上記の 3 種類の Spec 情報を収集し、差分を実行してリソース差分パッチを取得します。次に、フィルターを実行して、変更が許可されていない危険なフィールドを削除します。最後に、パッチ全体を戦略的マージ パッチまたはマージ パッチの形式で API サーバーに送信し、ワークロードが調整プロセスに再度入るようにトリガーして、クラスター内のワークロードの実際のステータスを変更します。

さらに、ASI コンポーネント間の相関関係が強いため、複数のコンポーネントを同時にリリースする必要があるシナリオも数多くあります。たとえば、クラスターを初期化するときや、クラスターの全体的なリリースを行うときなどです。そこで、単一コンポーネントのデプロイメントをベースとしたアドオンリリースの概念を追加し、コンポーネントのコレクションを使用して ASI 全体のリリースバージョンを示し、各コンポーネントの依存関係に基づいてデプロイメントフローを自動的に生成して、全体的なリリースプロセス中に循環依存関係が発生しないようにしました。

3. 単一クラスターグレースケールの能力構築

クラウドネイティブ環境では、アプリケーションのデプロイメント形式を最終状態の形式で記述し、Kubernetes はさまざまなワークロードの最終状態を維持する機能を提供します。オペレーターは、ワークロードの現在の状態と最終状態のギャップを比較し、状態を調整します。この調整プロセス、つまりワークロードのリリースまたはロールバックのプロセスは、この「最終状態シナリオ内のプロセス指向のフロー」を処理するためにオペレーターによって定義されたリリース戦略によって処理できます。

Kubernetes の上位層のアプリケーション負荷と比較すると、基盤となるインフラストラクチャ コンポーネントは、リリース プロセス中のコンポーネント自体のグレースケール リリース戦略とグレースケール一時停止機能に重点を置いています。つまり、コンポーネントの種類に関係なく、機能の検出、意思決定、ロールバックに十分な時間を確保するために、リリース プロセス中にリリースを適時に停止する機能が必要です。具体的には、これらの機能は次のカテゴリに分類できます。

updateStrategy: ストリーミング アップグレード/ローリング アップグレード pause/resume: 一時停止/再開機能 maxUnavailable: 使用できないレプリカの数が特定の値に達したときにアップグレードをすぐに停止します。partition: アップグレードの一時停止機能。一度に一定数のレプリカのみをアップグレードし、一定数の古いバージョンのレプリカを保持します。

ASI は、Kubernetes のネイティブ ワークロードとノードの機能を強化しました。クラスター内の Kruise や KubeNode などのオペレーターの機能と、上位レベルの管理および制御プラットフォーム ASIOps との連携に依存して、Kubernetes インフラストラクチャ コンポーネントに対する上記のグレースケール機能のサポートを実装しました。 Deployment / StatefulSet / DaemonSet / Dataplane タイプのコンポーネントの場合、単一のクラスターでリリースされたときにサポートされる機能は次のとおりです。

次の記事では、さまざまなワークロード タイプ向けのコンポーネントのグレースケール実装について簡単に紹介します。実装の詳細については、弊社のオープンソース プロジェクト OpenKruise と、今後オープンソース化される予定の KubeNode にご注目ください。

1) オペレータプラットフォーム

ほとんどの Kubernetes オペレーターは、Deployment または StatefulSet としてデプロイされます。 Operator のリリース プロセス中にイメージ フィールドが変更されると、すべての Operator コピーがアップグレードされます。このプロセス中に新しいバージョンに問題が発生すると、取り返しのつかない問題が発生します。

このタイプのオペレーターの場合、コントローラー ランタイムをオペレーターから分離し、集中型コンポーネント オペレーター マネージャー (OpenKruise オープン ソース実装のコントローラー メッシュ) を構築します。同時に、各オペレータ ポッドにオペレータ ランタイム サイドカー コンテナが追加され、gRPC インターフェースを介してコンポーネントのメイン コンテナにオペレータのコア機能が提供されます。

オペレーターが APIServer への Watch 接続を確立すると、APIServer はイベントをリッスンし、オペレーターによって調整および処理されるタスク フロー (つまり、オペレーター トラフィック) に変換します。オペレータ マネージャは、すべてのオペレータのトラフィックを集中管理し、ルールに従ってトラフィックをスライスし、さまざまなオペレータ ランタイムに配布する役割を担います。ランタイム内のワーカーキューは、実際のオペレーターの調整タスクをトリガーします。

グレースケール プロセス中、operator-manager は、名前空間レベルとハッシュ シャーディングによって、オペレーターのトラフィックを新旧バージョンの 2 つのレプリカに割り当てることをサポートします。これにより、2 つのレプリカによって処理されるワークロードを使用して、グレースケール リリースに問題があるかどうかを確認できます。

2) 高度なデーモンセット

コミュニティのネイティブ DaemonSet は RollingUpdate をサポートしていますが、ローリング アップグレード機能は maxUnavailable のみをサポートしており、これは単一クラスター内に数千または数万のノードがある ASI には受け入れられません。イメージが更新されると、すべての DaemonSet Pod がアップグレードされ、一時停止できなくなります。これらは、maxUnavailable 戦略によってのみ保護できます。 DaemonSet のバグのあるバージョンがリリースされ、プロセスが正常に開始できるようになると、maxUnavailable は有効になりません。

さらに、コミュニティでは onDelete メソッドが提供されており、これを使用すると、手動で Pod を削除して新しい Pod を作成できます。リリース順序とグレースケールはリリースプラットフォームセンターによって制御されます。このモデルでは、単一のクラスター内で自己閉ループを実現できず、すべての圧力がリリース プラットフォームにかかることになります。上位層の公開プラットフォームに Pod の削除を実行させることは非常に危険です。最善の方法は、ワークロードがクローズド ループでコンポーネント更新機能を提供することです。そのため、Kruise では DaemonSet の機能を強化し、上記の重要なグレースケール機能をサポートするようにしました。

以下は、基本的な Kruise Advanced DaemonSet の例です。

apiVersion: apps.kruise.io/v1alpha1kind: DaemonSetspec: # ... updateStrategy: type: RollingUpdate rollingUpdate: maxUnavailable: 5 パーティション: 100 一時停止: false

パーティションは、イメージの古いバージョンを保持する Pod コピーの数を指します。ローリング アップグレード プロセス中に、指定された数の Pod コピーがアップグレードされると、新しい Pod のイメージはアップグレードされなくなります。上位層 ASIOps のパーティション値を制御して DaemonSet のアップグレードを展開し、他の UpdateStrategy パラメータを使用してグレースケールの進行状況を確認し、新しく作成された Pod で方向検証を実行します。

3) マシンコンポーネントセット

MachineComponentSet は、KubeNode システム内のワークロードです。 ASI 内の Kubernetes 外部のノード コンポーネント (Kubernetes 独自のワークロードを使用してリリースできないコンポーネント)、たとえば Pouch、Containerd、Kubelet はすべてこのワークロードを通じてリリースされます。

ノード コンポーネントは、Kubernetes のカスタム リソース MachineComponent によって表され、指定されたバージョンのノード コンポーネント (たとえば、pouch-1.0.0.81) のインストール スクリプト、インストール環境変数、およびその他の情報が含まれます。 MachineComponentSet はノード コンポーネントとノード セット間のマッピングであり、マシンのバッチでこのバージョンのノード コンポーネントをインストールする必要があることを示します。センターのマシン オペレーターは、このマッピング関係を調整し、ノード上のコンポーネント バージョンと最終状態のターゲット バージョンの違いを比較して、指定されたバージョンのノード コンポーネントをインストールしようとします。

グレースケール リリース部分では、MachineComponentSet の設計は Advanced DaemonSet に似ており、partition や maxUnavailable などの RollingUpdate 機能を提供します。たとえば、MachineComponentSet の例を次に示します。

apiVersion: kubenode.alibabacloud.com/v1kind: MachineComponentSetmetadata: labels: alibabacloud.com/akubelet-component-version: 1.18.6.238-20201116190105-cluster-202011241059-d380368.conf コンポーネント: akubelet 名: akubelet-machine-component-setspec: componentName: akubelet セレクター: {} updateStrategy: maxUnavailable: 20% パーティション: 55 一時停止: false

同様に、ノード コンポーネントのグレースケール アップグレードを制御する場合、上位層 ASIOps はクラスター側の Machine-Operator と対話して、ローリング アップグレード用に指定された MachineComponentSet のパーティションやその他のフィールドを変更します。

従来のノード コンポーネント リリース モデルと比較して、KubeNode システムでは、Kubernetes クラスター内のノード コンポーネントのライフ サイクルも閉じられ、グレースケール リリースの制御がクラスター側に移されるため、センターがノード メタデータを管理する負担が軽減されます。

4. クラスター間グレースケール機能の構築

Alibaba は、クラウド製品と基本製品向けに Change Red Line 3.0 を社内で策定し、コントロールプレーン コンポーネントとデータプレーン コンポーネントの変更操作のバッチ グレースケール、制御間隔、可観測性、一時停止可能性、ロールバックに関する要件を設定しました。ただし、リージョン内の変更オブジェクトをグレー表示することは、ASI の複雑なシナリオに対応しません。したがって、ASI のコントロール プレーンとデータ プレーンの変更が属する変更単位の種類を絞り込むように努めます。

クラスターの基本単位を上方向と下方向に抽象化して、次の基本単位を取得します。

クラスター グループ: ビジネス パーティ (ASI が担当するセカンド パーティ ユーザー)、ネットワーク ドメイン (営業エリア/OXS/グループ)、環境 (e2e/テスト/プレリリース/カナリア/小規模トラフィック/本番) 情報が共通であるため、監視、アラーム、検査、リリースなどの構成が共通です。クラスター: Kubernetes クラスター プランに対応する ASI クラスター コンセプト。ノード セット: リソース プール、サブビジネス プール、その他の情報など、共通の特性を持つノードのコレクション。名前空間: 単一のクラスター内の単一の名前空間。通常、ASI 内の 1 つの上位層サービスは 1 つの名前空間に対応します。ノード: 単一のホスト ノードが Kubernetes ノードに対応します。

各リリース モード (制御コンポーネント、ノード コンポーネント) では、最小爆発半径の原則を使用して、対応するグレースケール ユニットを調整および接続し、グレースケール プロセスをシステムに固めることができます。コンポーネントの開発は、リリース時のプロセスに従い、ユニットごとに展開する必要があります。手配プロセスでは、主に以下の要素を考慮します。

ビジネス属性 環境（テスト、プレローンチ、低トラフィック、本番） ネットワークドメイン（グループ V、販売エリア、OXS） クラスタスケール（ポッド/ノードの数） ユーザー属性（ユーザーの GC レベル） ユニット/センターコンポーネントの特性

同時に、各ユニットに重み付けし、ユニット間の依存関係を調整します。たとえば、以下は ASI 監視コンポーネントのリリース パイプラインです。この監視コンポーネントはすべての ASI シナリオで同じソリューションを使用するため、すべての ASI クラスターにプッシュされます。プッシュ プロセスでは、まず汎電子商取引トランザクション クラスターによって検証され、次にグループ VPC 内の 2 つのパーティにリリースされ、最後に販売エリア クラスターにリリースされます。各クラスターでは、このコンポーネントは、前のセクションで説明した単一クラスター内のグレースケール方式に従って、1/5/10 のバッチでリリースされます。

グレースケール ユニットを配置すると、コンポーネント レベリング パイプラインの基本的な骨組みが得られます。スケルトン上の各グレースケール ユニットについては、事前チェックと事後チェックを強化して、リリースごとにグレースケールの成功を確認し、効果的な変更ブロックを実行できるようにします。同時に、単一バッチに対して一定のサイレント期間を設定し、事後検証を実行するのに十分な時間を確保し、コンポーネント開発に十分な検証時間を提供します。現在、単一バッチの検証前および検証後のコンテンツには以下が含まれます。

グローバルリスクルール（ネットワークブロッキング、サーキットブレーキングなど）リリースタイムウィンドウ（週末のリリースを禁止するASIトライアルルール）KubeProbeクラスタブラックボックス検出カナリアタスク（Normandyによって開始されたASIフルリンク拡張および縮小タスク）コア監視インジケーターダッシュボードコンポーネントログ（コンポーネントパニックアラームなど）アクティブ診断タスク（リリースプロセス中に対応する監視情報が大幅に変更されたかどうかをアクティブに照会）

マルチクラスターのリリース プロセス全体を連結することで、開発、テストからオンライン リリースまでコンポーネントが通過するイベントを確認できます。次の図は、プロセス全体で実行されるイベントを示しています。

パイプライン オーケストレーションの実装に関しては、コミュニティ内の既存の Tekton と Argo の選択調査を実施しました。ただし、リリース プロセスのロジックの多くはコンテナーだけでの実行には適しておらず、リリース プロセスでの要件は CI/CD だけではないこと、そして設計当初はこれら 2 つのプロジェクトがコミュニティ内で安定していなかったことを考慮すると、そのため、Tekton の基本設計 (task/taskrun/pipeline/pipelinerun) をベースに実装し、コミュニティと同じ設計方向性を維持しました。今後は、コミュニティにさらに近づき、よりクラウドネイティブになるようにアプローチを調整していきます。

結果

約 1 年半の構築を経て、ASIOps は現在、約 100 の管理および制御クラスター、約 1,000 のビジネス クラスター (ASI クラスター、Virtual Cluster マルチテナント仮想クラスター、Sigma 2.0 仮想クラスターなど)、および 400 を超えるコンポーネント (ASI コア コンポーネント、セカンド パーティ コンポーネントなど) をホストしています。同時に、ASIOps には約 30 個のプッシュ パイプラインとプル パイプラインが含まれており、ASI 自体と ASI が担うビジネス パーティのさまざまなリリース シナリオに適しています。

同時に、毎日約 400 件のコンポーネント変更 (イメージ変更と構成変更を含む) が行われ、パイプラインを通じてプッシュされるコンポーネント変更の数は 7,900 件以上に達しています。同時に、リリース効率を向上させるために、事前チェックと事後チェックが完了した状態で、単一クラスター内での自動グレースケール機能を有効にしました。現在、この機能はほとんどの ASI データ プレーン コンポーネントで使用されています。

以下は、ASIOps 経由でバージョン管理されるコンポーネントの例です。

同時に、ASIOps でのバッチ グレースケールとチェック後の変更ブロックも、コンポーネントの変更によって発生する特定の障害を防ぐのに役立ちました。たとえば、Pouch コンポーネントがグレースケールの場合、バージョンの非互換性によりクラスターは使用できなくなりました。この現象は、リリース後に行われたリリース後検査によって発見され、グレースケール処理がブロックされました。

ASIOps 上のコンポーネントのほとんどは、ASI/Kubernetes の基盤となるインフラストラクチャ コンポーネントであり、過去 1 年半の間にコンポーネントの変更による障害は発生していません。当社では、システム機能を通じて指定された仕様を固め、変更のレッドラインを超える変更を削減・排除し、変更によって引き起こされる低レベルの障害から、コードバグ自体によって引き起こされる複雑な障害まで、障害の発生を徐々に右にシフトさせることに努めています。

見通し

ASI がカバーするシナリオが徐々に拡大するにつれて、管理および制御プラットフォームとしての ASIOps は、より複雑なシナリオ、より多くのクラスターおよびコンポーネントの課題に対応する必要が生じます。

まず第一に、安定性と効率性のトレードオフを早急に解決する必要があります。 ASIOps で管理するクラスターの数が一定レベルに達すると、コンポーネントをフラット化するのに多くの時間がかかります。私たちは、十分な事前検証機能と事後検証機能を構築した後、プラットフォームがリリース範囲内でコンポーネントを自動的にプッシュし、効果的な変更ブロックを実行して、Kubernetes インフラストラクチャ レベルでの CI/CD 自動化を真に実現することで、完全に管理された変更機能を提供したいと考えています。

同時に、現在はグレースケール単位を手動で配置し、グレースケールの順序を決定する必要があります。将来的には、ASI 全体の完全なメタデータを構築し、各リリースの範囲内ですべてのユニットを自動的にフィルタリング、スコアリング、および配置したいと考えています。

最後に、ASIOps は現在、コンポーネントに関連する変更をグレースケール化する機能しかありませんが、ASI の範囲内の変更はコンポーネントをはるかに超えています。グレースケール システムはユニバーサル カテゴリである必要があり、グレースケール パイプラインを有効にして、リソース操作と保守、および計画実行の他のシナリオに挿入できるようにする必要があります。さらに、管理および制御プラットフォーム全体のグレースケール機能は Alibaba と密接に結合されておらず、Kruise/KubeNode などのワークロードに基づいて完全に構築されています。将来的には、機能セット全体をオープンソース化し、コミュニティにエクスポートすることを検討します。