T3 モビリティ クラウド ネイティブのコンテナ化されたプラットフォームの実践

会社概要

T3モビリティは、南京凌興科技有限公司が開発したスマートモビリティエコロジカルプラットフォームです。中国一汽集団有限公司、東風汽車集団有限公司、重慶長安汽車有限公司によって開始されました。テンセントやアリババなどのインターネット企業が共同出資。同社は、「最も信頼される旅行サービス企業になる」をブランドビジョンに、「科学技術が快適な旅行に導く」を使命とし、「信頼できる、より自由な」旅行コンセプトを提唱し、ユーザーに「信頼できる、信頼できる」旅行を提供することを約束します。安全で高品質な旅行サービスを提供し、より自由な旅行体験を提供します。

背景紹介

T3 の旅行ビジネスの量は増加し続けているため、サービスの安定性には体系的な保証が必要です。コンテナの変換により、標準化された環境が提供され、アプリケーションの動作環境に基づいた完全なバージョン管理が実現され、開発から本番までの環境の違いが解消され、アプリケーションのライフサイクル内で環境の一貫性と標準化が保証されます。同時に、コンテナ化された環境では、サービスがコンピューティング リソースを共有できるようになり、ハイブリッド モードによって全体的なコンピューティング リソースの使用率が向上し、エンタープライズ アプリケーションのインフラストラクチャ運用コストが削減されます。

コンテナ化の前は、T3 Travel は従来の仮想マシン モデルであり、すべてのビジネスは仮想マシン上に展開され、すべての生産と研究は要塞マシン、従来の監視システム、ログ プラットフォームなどを通じて実行され、毎日のアプリケーションの運用と保守が実行されます。サービスのコンテナ化が始まると、必然的にクラウド ネイティブのコンテナ化された管理プラットフォームが必要になるため、T3 Travel の全体的な生産と研究は、従来の仮想マシン操作モードからクラウド ネイティブ操作モードに変更されます。同時に、以前の日常的なアプリケーションの操作と保守モードでは、コラボレーションのために複数のプラットフォームを使用する必要があり、アプリケーションのパフォーマンスの問題を特定するための生産と研究では、多くの場合、複数のプラットフォームを切り替える必要がありました。したがって、コンテナ化されたプラットフォームは、ログ閲覧システムや監視システムなどの周辺支援機能を統合し、生産と研究が日常の運用と保守作業を 1 つのプラットフォームで可能な限り完了できるようにすることを望んでいます。プラットフォーム プロジェクトの一部であるため、本番環境と研究者は、基盤となるアーキテクチャの知識を知らなくても、ベースライン以外の環境を作成、更新、および削除するための十分な権限を持つことができます. セルフサービス環境機能により、R&D は開発とテストを並行して行うことができ、最終的にはビジネスを迅速かつ効率的に成長させます。

選択手順

基本的には、機能、UI体験、コミュニティ活動、学習コストの4点で選定を考えています。まず第一に、コンテナ プラットフォーム (背景の紹介で説明) に対するニーズを満たす必要があり、次にコミュニティの活動とエコロジー、そして最後に UI エクスペリエンスが必要です. UI エクスペリエンスには、ユーザーの学習コストが含まれます. 低学習コストでT3 トラベルの研究開発をより迅速にコンテナ プラットフォームで開始できるようにする方法であり、運用と保守の観点も備えているため、研究開発の適用観点の自由度を満たすだけでなく、次の次元も満たします。クラスターの運用と保守の観点から。
選定期間中、Rancher、Openshift、KubeSphere を比較し、最終的に T3 Travel クラウドネイティブ コンテナ プラットフォームとして KubeSphere を選択しました。KubeSphere は、使いやすいインターフェースを提供するアプリケーション中心のコンテナー プラットフォームとして位置づけられており、ユーザーがこれらの技術的な詳細を保護し、学習コストをある程度削減するのに役立ちます。同時に、Kubesphere は優れたコンテナー管理機能、マルチクラスター サポート機能、マルチテナント機能、自然な統合オブザーバビリティ機能などを備えているため、日常の運用と保守のニーズを 1 つのプラットフォームで満たすことができます。

練習プロセス

複数のクラスターの統合管理

KubeSphere マルチクラスターでの役割は、1 つのメイン クラスターと複数のメンバー クラスターで構成されるメイン クラスターとメンバー クラスターに分けられます。これは、当初のクラスター計画と一致しています。メイン クラスタはメンバー クラスタのコントロール プレーンとして存在し、さまざまな管理ポリシーがメイン クラスタを介してメンバー クラスタに配信されます。メンバー クラスターについても、異なる環境と異なるテナント プロパティに従って、異なるクラスターに分割します。たとえば、環境に応じて、開発クラスター、テスト クラスター、運用前クラスター、および運用クラスターがあり、テナントの性質に応じて、サードパーティ ビジネスに接続するいくつかのクラスターがあります。

プロジェクト管理

多くの従来の DevOps プラットフォームでは、プロジェクトとの連携はなく、サービスは組織構造のみに関連付けられていることが多く、組織構造が変化すると、サービスのメタ情報が不正確になります。また、プロジェクトは部門を超えて連携するケースが多いのですが、業務リリースの視点はそれぞれの部門の下にあり、プロジェクトメンバーはプロジェクトの業務を一元的に見ることはできません。 、多くの通信費が増加しました。一方、KubeSphere は、プロジェクト ディメンションに基づいてコンテナー サービスを管理します. KubeSphere では、プロジェクトは Kubernetes Namespace に対応します. テナントのビューは分離されており、テナントは毎日、独自のプロジェクト ビューでコラボレーションするだけで済みます.

当社のDevOpsプラットフォームは、プロジェクト統合の方向に徐々に発展しています.現在、私たちはビジネスドメインに従って一元管理を行っています.ビジネスドメインは、KubeSphere内のプロジェクトを表します.ビジネスドメインの下には、組織構造に関係なく、複数の関連するビジネスサービスがあります. . どのように変革しても、事業ドメインは変わらない。

マルチテナント管理

KubeSphere でのマルチテナント管理は、プロジェクト、DevOps プロジェクト、アプリケーション テンプレート、およびアプリケーション ウェアハウスを管理するために使用される論理ユニットであるエンタープライズ スペース ディメンションに基づいています。企業スペース内のリソースへのアクセスを制御し、チーム内でリソースを安全に共有できます。エンタープライズ スペースは、複数のクラスター内の複数のプロジェクトに関連付けることができ、エンタープライズ スペース内のメンバーの権限を管理できます.公式の KubeSphere マップを引用すると、誰もが直感的に理解しやすいです:

事業ドメインをプロジェクト次元として一元管理しているため、KubeSphereのテナント管理の最小単位であるエンタープライズスペースは、事業ドメインごとに自然に分割されています。したがって、現在の T3 のマルチテナント管理ロジックは、エンタープライズ スペース (ビジネス ドメイン) → クラスター (開発、テストなど) → プロジェクト (ビジネス ドメイン) です。同時に、エンタープライズ スペースでは、部門管理の自由度も抽象化されています. KubeSphere の部門管理を使用して、さまざまなクラスター (環境) 操作権限をさまざまな担当者に付与することが便利です.

社内 DevOps プラットフォームと KubeSphere の組み合わせ

T3 コンテナー化の前には、DevOps プラットフォームがあり、この DevOps プラットフォームによって提供される製品は仮想マシンにデプロイされていました。コンテナ化プロジェクトの前提条件は、コンテナパブリッシングをサポートすることです.既存のDevOpsプラットフォームをクラウドネイティブのDevOpsプラットフォームに変換すると、ワークロードが膨大になり、プロジェクトのリスクが制御不能になるため、最終的にDevOpsプラットフォームとKubeSphereの組み合わせを選択しました. . 社内のDevOpsプラットフォームには、コンテナサービスのみをリリースし、Podのコピー数を増減するコンテナリリース機能が新たに搭載されており、リリースされたコンテナはKubeSphereが引き継ぎ、コンテナリリース後の申請状況をR&D担当者に提示するため、 R&D 担当者がコンテナと対話するのを助けることができること。

KubeSphere は T3 コンテナ化リリースの後半を引き継いでいると言えます.R&D 担当者がリリースを実行した後、KubeSphere に来て、ログの閲覧、監視の閲覧、コンテナ コンソールへの入力、コンテナー イベントの表示など。

効果

  • T3 Mobility のビジネスは完全にコンテナ化されており、すべてのクラスターは KubeSphere によって管理されており、KubeSphere プラットフォームに基づいて、生産および研究の日常的なアプリケーション保守作業を実行する必要があります。
  • KubeSphere のアプリケーション中心の設計のおかげで、ユーザーは基礎となる技術的な詳細を隠すことができます. 現在、T3 のすべての旅行制作と研究は、KubeSphere をセルフサービスの方法で日常業務に使用できます。従来のアプリケーション メンテナンス モードから、クラウド ネイティブなアプリケーション メンテナンス モデルに変わりました。
  • KubeSphere は、監視、ログ、およびイベントを統合し、T3 の生産と研究の日常的な人間の効率を向上させます。
  • KubeSphere クラスター レベルでの可観測性は、クラスター リソースの使用率を改善するための参考資料です。

これからの計画

  1. 社内の DevOps プラットフォームは KubeSphere と深く統合されており、T3 の制作と研究により優れたエクスペリエンスをもたらします。
  2. T3 ベースのビジネス シナリオは、より優れたオープン ソース プロジェクトを採用し、コミュニティと共に成長します。
  3. FinOps とサーバーレスの調査と実践。

おすすめ

転載: blog.csdn.net/zpf17671624050/article/details/129437718
おすすめ