Arphic Intelligent IoT クラウドネイティブコンテナ化プラットフォームの実践

著者: sekfung 氏、Shenzhen Wending Chuang Data Technology Co., Ltd. の R&D エンジニア。同社のモノのインターネットターミナルプラットフォームの開発、安定性の構築、コンテナ化されたクラウド作業を担当し、GO と Java を使用した分散システムの開発が得意。クラウドネイティブ、KubeSphere コントリビューター、KubeSphere コミュニティユーザー委員会のメンバーである深センステーションなど、分散型の最先端テクノロジーに引き続き注目してください。

会社概要

2006 年に設立された Shenzhen Wendingchuang Data Technology Co., Ltd. は、ネットワーク ID 認証とデータセキュリティに重点を置いたオンライン ID 認証ソリューションの世界有数のプロバイダーです。多くの国営商業銀行、国立株式会社銀行、都市商業銀行、地方商業銀行、地方自治体の税務、政府、主要な CA 機関、多国籍企業がサービスを蓄積 1 億人近いユーザーがおり、常に顧客の多様なニーズに対応。

同社は長年にわたって革新を続け、多数の発明特許、実用新案特許、製品外観特許を出願し、多数のコンピュータソフトウェアの著作権を登録しており、国家ハイテク企業でもあり、商業的地位を持っています。暗号化製品モデル証明書、暗号化テスト証明書、銀聯認証、ISO9001:2015 国際品質マネジメントシステム認証、ISO14001 環境マネジメントシステム認証、製品は CE/FCC 認証と RoHS 認証に合格しています。

同社は、International Online Fast Identity Verification Alliance (FIDO) の中心メンバーの 1 つとして、世界的に統一されたオンライン認証標準の実現に取り組んでおり、このテクノロジーを使用して、さまざまな地域の人々に平等で平等な認証を享受できる権利を提供していきます。安全なオンライン世界。

背景紹介

「文創インテリジェントIoT」は、深セン文頂データ技術有限公司がIoTアプリケーション向けに提供を開始したIoTソリューションで、統合IoTサービスプラットフォーム「クラウドプリンター」「決済クラウドスピーカー」「領収書クラウド」が含まれています。コードスキャンボックス」およびその傘下のその他の製品は、ユーザーのデータのセキュリティを保護します。

TO B ソリューションのハードウェアプロバイダーである同社は、「ハードウェアが主力、ソフトウェアが補助的」という長期的な開発モデルであるため、初期段階ではサーバーの開発、導入、アーキテクチャ設計に十分な注意が払われていませんでした。。従来のプロジェクトは単一のマシン (仮想マシン) のデプロイメントに留まり、手動でのパッケージ化とアップロードは時間と労力がかかるだけでなく、エラーが発生しやすく、その結果サービスが利用できなくなります。

K8s を採用する前に、docker-compose ソリューションも試しましたが、手動でのパッケージ化やデプロイメントと比較して、docker-compose は実際にいくつかの利便性をもたらしました。

オールインワン。面倒な導入プロセスを必要とせず、ワンクリックでソフトウェア導入ソリューションを提供します。
ホストシステムの違いを分離します。
これにより、運用保守担当者のバージョン反復作業が軽減され、操作ミスの可能性が軽減されます。

モノのインターネット業界向けに新製品やソリューションを発表した後、サービスの安定性と信頼性に新たな課題が生じています。既存の開発モデルではビジネスの繰り返しのニーズに対応できません。そのため、既存のフレームワークを早急に打破する必要があります。、一連の新しいソフトウェア反復プロセスを探索します。

選択手順

クラウドネイティブの導入を決定した際、市場のコンテナ管理プラットフォームについて調査を行ったところ、Rancher には海外のユーザーも多く、国内の KubeSphere がその先頭に立っていることがわかりました。コンテナ管理プラットフォームを選択するための基準はいくつかあります。

エコロジー: オープンソースプロジェクトのエコロジーが完全であるかどうかは非常に重要であり、周囲のサポートツールは優れたユーザーエクスペリエンスと保守性をもたらします。
コミュニティ活動: 公式ウェアハウス問題または Q&A コミュニティはタイムリーに応答しますか? コードの提出はアクティブですか?
営利企業または財団からのサポート: 営利企業またはオープンソース財団からのサポートの有無にかかわらず、それが個人プロジェクトの場合、後でメンテナンスが停止された場合、ユーザーに一定のリスクをもたらす可能性があります。
テクノロジースタック: テクノロジースタックはチームに合わせて使用されており、それを解決して維持できるか?
ユーザーエクスペリエンス：UI操作インターフェースはありますか？インターフェースは美しく、スムーズに使用できますか？
ローカリゼーション: 中国人の使用習慣に合わせてローカリゼーションを最適化しましたか?

モデルを調査して選択したところ、KubeSphere が要件を完全に満たすことができることがわかりました。KubeSphere チームのオープンソース KubeKey ツールは、KubeSphere クラスターを迅速に構築するのに役立ち、面倒で複雑なデプロイメントプロセスを排除し、OpenELB プロジェクトはローカルクラスターの負荷分散ソリューションを提供します。

使用中に見つかった問題については、基本的に中国語の Q&A コミュニティで対応する解決策を見つけることができます。KubeSphere のコンソールを使用すると、Kubernetes サービスの展開が簡素化され、K8 の使用経験のないチームの一部のメンバーでもすぐに使い始めることができます。

現在の構造

現在はマイクロサービス設計が採用されており、開発言語は主にGolangとJava、サービス間の通信にはgRPCが使用されています。

本番環境では、2 つの Tencent Cloud CLB を使用して、ビジネス端末と IoT 端末からのトラフィックにそれぞれアクセスします。ビジネスサービス全体が Tencent Cloud TKE クラスターにデプロイされ、KubeSphere を使用してアプリケーションの毎日のリリースが管理されます。クラスターのインフラは「買えるものは買う、買えないものは自分で作る」という原則に基づいています（資金が悪いわけではありませんが、中小企業には資金がたくさんあるのです）。運用と保守にプレッシャーがかかります）。アプリケーションのリリースの管理に TKE コンソールが使用されない理由は、主に TKE コンソールのエクスペリエンスがあまりフレンドリーではないためですが、もう 1 つの重要な理由は、アプリストアがサードパーティの Helm ウェアハウスのサポートが不十分で、フル活用できないことです。 Helm エコシステム。

練習のプロセス

ハードウェアリソース

テスト環境: 10 台の ESXI 仮想マシン、自己構築された Kubernetes クラスター。

本番環境: 7 Tencent Cloud CVM ノード、Kubernetes は Tencent Cloud を使用して TKE クラスターをホストします。

ストレージソリューション

テスト環境: 分散ストレージ Ceph の OSD ノードとして 3 つの ESXI 仮想マシンを使用します。

実稼働環境: コストと安定性を考慮して、Tencent Cloud CBS を K8s ストレージソリューションとして使用します。

最小限のインストール

運用環境とテスト環境にはすでに Prometheus や Logging などの外部サービスが存在するため、既存のリソースを最大限に活用するために、KubepShere のデプロイでは最小限のインストールが採用されています。

Monitor はプラグイン可能なコンポーネントではないことに注意してください。インストールが最小化されていても、KubeSphere はデフォルトでインストールされます。本番環境では、TKE 監視用にインストールされた prometheus-operator がそれと競合します。KubeSphere の Prometheus は次のことを行う必要があります。閉じるか手動でアンインストールしてください。

DevOps

開発の初期段階では、バージョンの反復は非常に面倒な作業であるため、開発者はローカルでコンパイルおよびパッケージ化した後、デプロイメントのためにサーバーに手動でアップロードします。さまざまな環境の違いや手動操作のミスから得た教訓を経験したチームは、既存のプロセスを変更することを決意し、チーム自身に適した DevOps システムを構築することにしました。

継続的インテグレーション (CI): 開発では、各コードをコミットする前に CI を実行して、コードの品質と一貫性を確保します。これには、単体テストの実行、コードの静的分析、コンパイルとビルドのプロセスなどが含まれます。CI が失敗すると、開発はただちにコードを修正し、再送信します。
継続的デリバリー (CD): コードは CI プロセスを通過すると、テストのためにテストチームに配信されます。テストチームは製品の品質を保証するためにテストを実施します。テスト環境では、Coding のカスタムノードが CI の自動ビルドとして使用され、ミラーバージョンの KubeSphere は CI が渡された後にスクリプトを通じて自動的に更新されます。本番環境では、リリースのレビュープロセス、構成の変更、さまざまなビジネスチームの調整により、リリース用のアプリケーションのバージョンを手動で変更することが一時的に運用保守担当者に引き継がれます。
監視とアラート: コードが運用環境にデプロイされたら、それを監視します。モニタリングにより、チームは問題を迅速に特定して解決し、製品の可用性とパフォーマンスを確保できます。

現在の DevOps プラクティスは主に、チームの次の問題点を解決します。

統合コンパイル環境: プロジェクト内に Dockerfile を記述し、コンパイルには Docker コンテナ内のコンパイル環境を使用することが規定されており、同時にコード送信イベントのトリガーにはローカルではなく Gitlab Runner を使用する必要があります。各開発マシン環境の違いを分離するために、開発マシンをコンパイルします。
リリースバージョンは遡ることができます。初期のプロジェクトのバージョン管理は非常に恣意的であり、開発者の気分に従って名前が付けられます。問題が発生したときにすぐに特定することはできません。このため、CI を構築する場合、イメージバージョンは次のような特定の命名形式を満たす必要があることに同意します。${VERSION}-${ENV}-\${CI_NUMBER}この命名形式は、特定の CI ビルドに問題がある場合に、特定の CI ビルドのバージョンを迅速に見つけるのに役立ちます。環境。
スムーズな反復: 初期のプロジェクトは 1 台のマシンにデプロイされていたため、反復中にサービスが短期間利用できなくなることが多く、その結果トラフィック損失が発生しました。コンテナ変換後、Kubernetes プローブを使用してサービスをスムーズに更新でき、サービスに異常がある場合は手動介入なしで自動的に再起動できるため、サービスの可用性が大幅に向上します。
O&M の効率: Kubernetes O&M システムとクラウドネイティブの可観測性プラクティスを最大限に活用して、マルチサービスおよびマルチ環境の O&M に対するプレッシャーを軽減します。サービス障害が発生した場合、それをすぐに感知できます。

効果

パイプライン構成

パイプラインはコーディングソリューションを使用します。これには次の考慮事項があります。

エンタープライズ WeChat との緊密な統合が可能であり、CI プロセスで問題が発生した場合は、IM ツールを通じて開発部門に適時に通知できます。
サポートツールは充実していますが、公式のJenkinsはクラウドネイティブの開発が遅れており、ニーズに合わせて一連のプラグインをインストールする必要があり、設定作業も非常に煩雑です。

アプリケーションのデプロイメント

「Wenting Chuang Intelligent IoT」プロジェクトはすべて Helm アプリケーションを使用してリリースされています。使用中、KubeSphere は比較的不親切なエクスペリエンスであることがわかりました。yaml ファイルの構成が間違っているためにアプリケーションのアップグレードが失敗した場合、アプリケーションのアップグレードはできません。再度アップグレードします。運用環境では、アプリケーションをアップグレードできないという非常に深刻な問題が発生しており、バグの発見後、修正コードがコミュニティに提出され、「失敗した状態で Helm アプリケーションを再アップグレードできない」という修正コードにマージされました。

クラスターリソースの監視

KubeSphere の組み込み監視システムは、運用および保守担当者によるクラスターの健全性の毎日の検査を満たします。同時に、KubeSphere はマルチレベルの監視を提供します。名前空間とサービス自体については、チームは開発者が監視できるように、サービス監視をより頻繁に使用します。独自の公開サービスのリソース使用量について学びます。

これからの計画

同社が検討している新しいプロジェクトとして、「Wenting Chuang Intelligent IoT」はコンテナ化作業を完全に完了し、KubeSphere クラスター上で実行されており、将来的には、従来の TO B プロジェクトをコンテナ化し、KubeSphere クラスターに移行して改善する予定です。プロジェクトの保守性と使いやすさ。
Service Mesh ソリューションを検討して、サービスのスムーズなリリースと可観測性をさらに向上させます。

この記事は、ブログ用のマルチポストプラットフォームであるOpenWriteによって公開されています。