KubeSphere に基づく Peanut Haoche のマイクロサービスアーキテクチャの実践

[Yuan Chuang Conference プレビュー] 1024 プログラマーズデー (2 日前)、オープンソース中国オフィスに集合、AI について話しましょう! >>>

会社概要

Peanut Haoche は 2015 年 6 月に設立され、沈下市場における自動車旅行ソリューションの最初のブランドの構築に取り組んでいます。自社で構築した直販チャネルにより沈下市場をターゲットに、ダイレクトリース、卸販売、リースバック、新エネルギー車小売の4大事業を核とした新たな自動車小売プラットフォームを形成し、現在ではさらに多くの事業を展開しています。 400 以上の都市に合計 25 の中央倉庫があります。現在、40万人を超えるユーザーに高品質の自動車サービスを提供しており、オムニチャネルの利点と製品の豊富さで業界の先頭に立つことに成功しています。

背景の紹介

同社では、自社で構築したIDCコンピュータ室の物理サーバーの基盤となる仮想マシン管理としてkvmを利用していますが、業務の拡大に伴いシステムに問題が発生するようになり、今回の基盤インフラ変革の導入が始まりました。

のように：

使用率が飽和していない: さまざまな種類のサーバーの CPU 使用率は一般に飽和しておらず、アイドル時間中の使用率は低く、ビジー状態とアイドル状態は不均等です。
高いエネルギー消費: サーバーの需要が大きく、キャビネット、ネットワーク、サーバーなどの使用率が低い。
基本的なリソースは複雑です。基礎となる標準化には一貫性がなく、継承することはできません。
不十分なリソース共有: 煙突建設モデル、リソースが互いに分離されており、固定投資コストが高いビジネスのピークに対応するには、大量のデータ拡張サーバー製品を購入する必要があります。
ストレージ容量は増加し続け、論理ストレージデバイスは増加し、管理はより複雑かつ集約的になっています。
ビジネスネットワークには全体的な開発計画が欠如しており、一部のシステムまたはプラットフォームの機能的位置付けが不明確で、部門間、地域間、およびシステム間のプロセスインターフェイスがあいまいです。
システムの開発と立ち上げのサイクルは長く、その後のメンテナンスと問題特定のコストは高くつきます。プラットフォームの独立した構築は、ほとんどが煙突型の構築と独立したソリューションです。
ビジネスプロセス、プラットフォーム構造、インターフェースには統一された仕様や要件がありません。

プラットフォームの選択

DevOps 運用および保守チームとして、私たちはセルフサービスの包括的な運用および保守プラットフォームを提供する必要があります。オープンソースプラットフォームを選択する際、同社は最終的に KubeSphere を選択しました。

完全なオープンソースで料金は発生せず、二次開発も可能です。
機能が豊富で、インストールが簡単で、ワンクリックのアップグレードと拡張をサポートし、完全な DevOps ツールチェーンを備えています。
マルチクラスター管理をサポートしており、ユーザーは直接または間接接続を使用して Kubernetes クラスターをインポートできます。
統合された可観測性により、必要に応じて監視したいインジケーターやアラーム、ログクエリを追加できます。
役割と監査機能をカスタマイズして、その後のデータ分析を容易にします。

他のプラットフォームと比較して、KubeSphere は Kubernetes 自体の複雑さを回避し、さまざまなオープンソースツールを統合する作業負荷を軽減します。これにより、基盤となるインフラストラクチャとサービスを個別に管理する必要がなくなり、運用とメンテナンスの自動化とセルフサービスプラットフォームの構築により集中できるようになります。フルスタックの IT 自動運用およびメンテナンス機能を提供して、企業の DevOps ワークフローを簡素化します。したがって、KubeSphere が会社のニーズを満たす最良の選択肢となりました。

練習の流れ

インフラの建設と計画

Kubernetes クラスター

ビジネス上のニーズにより、相互影響を避けるためにテスト環境と運用環境を分離しています。上図に示すように、本番環境は 3 つの Matsre ノードで構成されており、現在 13 個のノードノードがあります。ここでは、マスターノードに過剰な負荷がかかるなどの状況を避けるために、マスターノードにテイントのマークを付けてポッドをスケジュール不能にしています。

運用環境では、公式に推奨されている Keepalived と HAproxy を使用して高可用性 Kubernetes クラスターを作成します。高可用性 Kubernetes クラスターにより、アプリケーションの実行中にサービスが中断されないことが保証されます。これは運用環境の要件の 1 つでもあります。

上の画像は公式ドキュメントです。詳細な紹介についてはそれを参照してください。

リリースワークフロー図:

基盤となるストレージ環境

基盤となるストレージ環境については、コンテナ化された方法ではなく、従来の方法でデプロイされました。これも効率を高めるために行われており、インターネットビジネスでは、ストレージサービスには、同時実行性の高いシナリオに対処するための特定のパフォーマンス要件があります。したがって、ベアメタルサーバーにデプロイすることが最良の選択です。

MySQL、Redis、および NFS はすべて、単一点の問題を回避するために高可用性を実装しています。Ceph は、kubeSphere StorageClass ストレージクラスとして cephfs を通じてマウントされています。現在、それらのほとんどはステートレスアプリケーションです。その後のステートフルアプリケーションのデプロイメントにより、ストレージがさらに最適化されます。

監視プラットフォーム

KubeSphereを日常的に効率よく利用するために、統合監視アラームを設定していますが、現時点ではほとんどのアラームで十分に使用可能であり、ノードに関しては個別のPMM監視を通じて日々の問題を把握できます。

アラームの例:

監視例：

効果

KubeSphere の導入により、企業の R&D の継続的統合と継続的展開の負担が大幅に軽減され、本番環境の R&D チーム全体のプロジェクト実施効率が大幅に向上しました。R&D チームは、ローカルで機能を実装してバグを修正し、コードを git にコミットし、Jenkins に基づいてテスト環境/本番環境プロジェクトをリリースするだけで、CI/CD 継続的インテグレーションデリバリーのワークフロー全体が完全に完了します。完了し、残りの共同デバッグ作業は研究開発に委ねられます。

KubeSphere に基づいて DevOps を実装すると、次のような最大の効率性が実現しました。

統合されたプラットフォーム管理: サービス機能の反復に関しては、KubeSphere プラットフォームにログインして、担当するプロジェクトをクリックするだけで済み、デプロイメントの作業負荷が大幅に軽減されます。また、KubeSphere と Jenkins を組み合わせてプロジェクトの配信を実現することもできます。しかし、全体のプロセスが比較的煩雑であり、Jenkins プラットフォームの構築だけでなく、KubeSphere の配信結果にも注意を払う必要があり、多大なご迷惑をおかけし、本来の配信の意図から逸脱してしまいます。、統合管理のために KubeSphere 独自のカスタムパイプラインを使用する場合があります。
リソース使用率の大幅な向上: KubeSphere と Kubernetes を組み合わせることで、システムリソースの使用率がさらに最適化され、使用コストが削減され、DevOps リソースの使用率が最大化されます。

今後の計画（改善）

現在、この運用プロジェクトに KubeSphere クラウドネイティブプラットフォームの実践を導入することにより、マイクロサービスのデプロイメントと管理の問題が実際に解決されたことがわかりました。KubeSphere プラットフォームの機能に基づいたクラウドネイティブアーキテクチャの移行により、大幅な効果が得られました。私たちの利便性が向上しました。ロードバランシング、アプリケーションルーティング、自動拡張と縮小、DevOpsなど。

このプラットフォームのおかげで、研究開発と運用保守の効率が大幅に向上しました。私たちは、KubeSphere のクラウドネイティブプラットフォーム、サービスグリッドガバナンス、カナリア、グレースケールパブリッシング、およびリンクトラッキングを使用することが、同社の次のビジネス成長のための強固な基盤となると信じています。

この記事は、複数の記事を公開するブログOpenWriteによって公開されています。