K8sとDockerコンテナ管理プラットフォームをベースにしたMomoのアーキテクチャプラクティス

[51CTO.com からのオリジナル記事] コンテナ クラスター管理システムとコンテナ クラウド プラットフォームの選択は非常に重要です。コンテナ管理システムが先進的でインテリジェントであるかどうか、またコンテナ クラウド管理プラットフォームが柔軟で使いやすく効率的であるかどうかは、企業の開発と運用の効率と速度、およびリソースの利用レベルに直接影響します。激しい競争と急激な変化の時代において、アプリケーションの開発効率、安定性、拡張性、セキュリティが企業の競争力と市場価値を決定します。

現在、K8sは、スケーラビリティ、管理、ビッグデータ分析、ネットワークシナリオ、互換性、負荷分散、グレースケールアップグレード、障害冗長性、災害復旧、DevOpsなどの利点があるため、一部の企業に好まれています。最近、51CTOが主催した「Tech Neo」をテーマにした第16回テクノロジーサロ​​ンイベントで、Momo TechnologyのSREチーム責任者であるWang Jingxue氏が、K8sコンテナでのMomoのアプリケーションプラクティスの一部を共有しました。

K8s を選ぶ理由

k8s を使用する前、Momo はアプリケーションの公開と運用環境において次のような特定の問題に遭遇しました。

• アプリケーションのリリース時間は非常に長くなります。主な理由は、リリース プロセス中に分離、回復、およびその他のアクションが必要であり、実際のステータスとログを表示するにはログインする必要があるためです。
• 夕方のラッシュアワーなどの緊急事態が発生した場合、緊急の容量拡張が必要になります。このとき、ビジネス側はマシンを申請しますが、新しいマシンを初期化して構成する必要があり、効率が非常に低くなります。
• アプリケーション動作環境のソフトウェアバージョンに一貫性がなく、構成が複雑で、保守コストが比較的高くなります。
• ハードウェアリソースの利用率が不十分であり、全体的なコストが比較的高くなっています。

上記の問題に対応するため、アーキテクチャを変革し、次のような一連のアーキテクチャ改善目標を設定することにしました。

• サービスの可用性と管理性を向上します。可用性とは、マシンがダウンした場合に、自動的に他のマシンに切り替わることを意味します。管理性とは、アプリケーションを拡張する必要があるときに、オペレーティング環境と関連する構成を自動的に展開することです。開発ではサーバーの問題を考慮する必要がなくなりました。
• リソースの分離を改善し、ハイブリッド サービスの展開を実現します。
• アプリケーション レベルの監視により、マシンの拡張が必要な​​場合に、どのアプリケーションが原因であるかが自動的にチェックされます。
• スムーズなサービス移行。

これらの問題と目標を考慮して、Momo は Kubernetes を使用して Docker クラスターを管理することを選択しました。 Kubernetes がニーズを満たせない場合は、デプロイメント プラットフォーム上で対応する機能を開発して、ログの表示、監視、アラームの開発ニーズを満たし、ホストとコンテナへのログインを回避することができます。

Momoのコンテナ管理プラットフォームのアーキテクチャの進化

Momo は 2015 年後半に Docker の研究と実践を開始し、2016 年初頭に K8s の研究を開始し、自社開発のディストリビューション システムと K8s、OVS、Docker をベースにアーキテクチャの改善とコンテナ管理プラットフォームの構築に取り組んできました。開発者が独自のアプリケーションを簡単にデプロイできるように、Docker クラスターに基づくデプロイメント システムが実装されています。最終的な目標は、繰り返し可能なデプロイメント、迅速な拡張、およびロールバックを可能にする、クリーンかつ一貫性のあるデプロイメント環境を実現することです。

次の図は、コンテナ管理プラットフォームのアーキテクチャ図です。

コンテナ管理プラットフォームの主な機能には、クラスターの管理とステータス表示、グレースケールリリースとコードロールバック、コンポーネントテンプレート、アプリケーション管理、イメージリポジトリ、権限管理などがあります。フロントエンドとバックエンドを分離したアーキテクチャを採用しており、フロントエンドでは JS レンダリングを使用し、バックエンドでは Python を使用して API を提供します。これにより、開発者は操作を迅速にリリースおよびロールバックできます。

コンテナ管理プラットフォームは、アプリケーションのリリースプロセス、クラスターのスケジューリング戦略、k8s ノードのネットワーク アーキテクチャ、Alibaba Cloud のサポート、基本的な監視指標などの点で最適化および改善されています。

アプリケーションリリースプロセス

Momo の以前のバージョンリリースシステムはシリアルであり、個別に置き換える必要がありました。次の図は、新しいアーキテクチャにおけるアプリケーションのリリース プロセスを示しています。

新しい公開システムでは、ユーザーがコードを送信した後、公開システムにデプロイするコミットを選択し、「ビルド」をクリックします。システムは自動的にコンパイルし、イメージにパッケージ化して、イメージ リポジトリにプッシュします。ビルドが成功した場合、ユーザーはクリックしてインスタンスの新しいバージョンをリリースし、グレースケール、フルバージョンに問題はなく、インスタンスの古いバージョンはオフラインになります。ロールバックする場合、コードをビルドする必要がなく、古いバージョンのインスタンスを直接リリースできます。一定期間、古いバージョンと新しいバージョンが同時に存在します。

クラスタースケジューリング戦略

Momo のクラスター スケジューリング戦略は、アプリケーションのデフォルトの場所 (クラスター タグ) を構成することです。オンライン アプリケーションの場合、アプリケーションは場所を申請し、正式なクラスター (コンピューター ルームの要件と十分なリソース) に展開される必要があります。ここでは、アプリケーションがクラスターを独占することはできず、ハイブリッド展開アプローチが採用されています。

同じクラスター内で異なるグループが分割され、グループ ラベルが定義されます。アプリケーションは排他的なマシンをサポートし、同じグループ内のアプリケーション インスタンスは自由にドリフトできます。

IDC ネットワーク ノード

IDC ネットワークノード構築部分では、Momo はグローバル IP アドレスを使用し、コンテナとコンテナとホストが相互接続されます。この方法では、通信にカプセル化テクノロジを使用する必要がないため、比較的効率的で、既存のネットワークの変更にほとんど影響を与えません (トランクのみをカプセル化すればよく、他のプロトコルや MTU などは変更されません)。

次の図は、IDC ネットワーク ノード アーキテクチャ図です。

このようなアーキテクチャでは、各マシンの IP アドレス セグメントが事前に静的に構成されているため、ネットワークの展開と拡張は比較的簡単です。

ここで注目すべきは、サーバーがデュアルリンクされており、トランクが物理スイッチに接続されており、レイヤー 2 ループを合理的に回避する必要があることです。

この方法の欠点は、コンテナの数が多いと MAC アドレスの数が増え、物理スイッチの Mac アドレス テーブルに負担がかかることです。ブロードキャスト ドメインの拡張には、VLAN ロール関連情報の厳密な計画が必要です。

Alibaba Cloud サポート

現在、Momo K8s マスター クラスターの下のノードには、次の図に示すように、IDC、Alibaba Cloud、およびこれら 2 つの混合が含まれています。

Alibaba Cloud が採用しているネットワーク モードは Host-gw です。 MomoはIDCとAlibaba CloudのVPC間に専用回線を構築し、VPCの仮想ルーティングを静的に構成しました。 IDC ノードと Alibaba Cloud ノードの両方のアプリケーションは、動的な IP 変更に適応する必要があります。

基本的な監視指標

Momo の監視ソリューションのほとんどは、Kublet cadvisor メトリック インターフェースを使用したデータ集約に基づいています。当初、Momo は Python スクリプトを使用してインターフェースを呼び出し、CPU メモリ、ネットワーク、トラフィック データを取得し、それらを ES に保存し、分析後に表示していました。後続のアラーム システムは、Java アプリケーションを使用して Kublet cadvisor メトリック インターフェイスを呼び出してデータを収集します。

基本的な監視指標には、主にメモリ (合計、RSS、キャッシュ)、トラフィック (着信、発信)、ネットワーク パケット (ドロップ、エラー、合計) などが含まれます。

アプリケーションの移行

アプリケーションの移行に関しては、Momo は多くの適応作業を行っており、アプリケーションをあまり変更せずにシームレスに移行できます。具体的な適応内容は以下のとおりです。

• アプリケーションは動的な IP 変更に適応します。
• ビルド プロセス (build.sh) をカスタマイズします。
• アプリケーションは、さまざまなサービス検出フレームワーク (nginx、rpc) (start.sh) を使用します。
• アプリケーションの破棄 (stop.sh) 中にいくつかの追加処理が実行されます。

アプリケーションの移行プロセス中に、スワップ、CPU ソフト割り込みの最適化、リソース使用率、IP ホワイトリスト、イントラネットへの適用性などの問題もいくつか発生しました。

現在、Momo のコンテナ事業には約 400 台のサーバー、6,000 個のオンライン コンテナ、700 個以上のアプリケーションがあります。アプリケーションタイプはjava+php+node+python+tomcatです。

今後の展望

運用保守では、アプリケーションのリクエスト量、スレッド数、トラフィックなどの指標を監視できることが期待されます。ベンチマーク値の部分は、単一のインスタンスが処理できるリクエストの量、スレッド数、およびトラフィックです。スケーリングの観点では、保持されるインスタンスの最小数と拡張されるインスタンスの最大数が達成されます。拡張および削減する必要があるインスタンスの数は、監視フィードバックとベンチマーク値に基づいて計算され、各クラスターのリソースマージンに比例してスケーリングされます。

【ゲストプロフィール】

Momo の Wang Jingxue が現在の SRE チーム リーダーです。彼は以前、運用および保守関連の仕事に携わっており、自動化、仮想化、Docker、K8s に精通しています。

テックネオテクノロジーサロ​​ン | 11月25日、Jiuzhou Cloud/ZStackはクラウド時代のネットワーク境界管理の実践について議論します。今すぐ登録するには画像をクリックしてください。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]