Kubernetes は Meituan のクラウド インフラストラクチャをどのように変えるのでしょうか?

この記事は、KubeCon 2020 Cloud Native + Open Source Virtual Summit China 2020 での Meituan インフラストラクチャ部門の Wang Guoliang 氏の講演に基づいています。

1. 背景と現状

Kubernetes は、コンテナ アプリケーションを大規模な産業生産環境に導入できるようにするオープン ソース システムです。これは、クラスター スケジューリングの分野における事実上の標準でもあります。業界で広く受け入れられ、広く使用されています。 Kubernetes は Meituan のクラウド インフラストラクチャの管理エンジンになりました。効率的なリソース管理を実現するだけでなく、コストも大幅に削減します。これは、Meituan のクラウドネイティブ アーキテクチャの発展のための強固な基盤を築き、サーバーレスやクラウドネイティブ分散データベースなどのいくつかのプラットフォームをサポートして、コンテナ化とクラウドネイティブ構築を完了します。

美団は2013年以来、仮想化技術を中核としたクラウド インフラストラクチャ プラットフォームを構築してきました。 2016年にコンテナ技術の探究と社内実装を開始し、オリジナルのOpenStackリソース管理機能上にHulk1.0コンテナプラットフォームを構築しました。 2018年、MeituanはKubernetesテクノロジーをベースにしたHulk2.0プラットフォームの構築を開始しました。 2019年末までに、Meituanのクラウドインフラストラクチャのコンテナ化変革は基本的に完了しました。 2020 年、私たちは Kubernetes が将来のクラウド インフラストラクチャ標準であると確信し、クラウド ネイティブ アーキテクチャの実装と進化を模索し始めました。

現在、Meituan全体のサービスとアプリケーション管理をサポートするために、KubernetesやDockerなどのテクノロジーに代表されるクラウドインフラストラクチャを構築しています。コンテナ化率は98％以上に達しています。現在、さまざまなサイズの数十の Kubernetes クラスター、数万の管理ノード、および数十万の Pod が存在します。ただし、災害復旧を考慮して、単一クラスターの最大数は 5K ノードに設定されています。

下の図は、Kubernetes エンジンに基づく現在のスケジューリング システム アーキテクチャを示しています。 Kubernetesをコアとして統合リソース管理システムを構築し、さまざまなPaaSプラットフォームやビジネスに対応します。 Hulk コンテナ化を直接サポートするだけでなく、Serverless や Blade などのプラットフォームも直接サポートし、PaaS プラットフォームのコンテナ化とクラウドネイティブ化を実現します。

2. OpenStackからKubernetesへの移行の障害と利点

成熟したテクノロジースタックを持つ企業にとって、インフラストラクチャ全体の変革は順風満帆ではありません。 OpenStack クラウド プラットフォーム期間中に私たちが直面した主な問題には、次のような側面がありました。

• アーキテクチャが複雑で、運用と保守が困難: OpenStack アーキテクチャ全体のコンピューティング リソース管理モジュールは非常に大きく複雑であり、トラブルシューティングと信頼性が常に大きな問題となっていました。
• 環境の不一致の問題が顕著です。コンテナ イメージが登場する前は、環境の不一致は業界で一般的な問題であり、ビジネスの迅速な立ち上げや安定性につながっていませんでした。
• 仮想化自体は多くのリソースを消費します: 仮想化自体は、ホスト マシンのリソースの約 10% を消費します。クラスターが十分に大きい場合、これはリソースの大きな浪費になります。
• リソースの配信と回復のサイクルが長く、リソースを柔軟に割り当てるのは簡単ではありません。一方では、仮想マシンの作成プロセス全体が長くなります。一方、各種初期化や構成リソースの準備には時間がかかり、エラーが発生しやすいため、マシンリソースの適用から配信までのサイクル全体が長くなり、迅速なリソース割り当てが課題となります。
• 明らかなピークと落ち込み、深刻なリソースの浪費: モバイル インターネットの急速な発展に伴い、同社のビジネスにはますます多くのピークと落ち込みが生じています。サービスの安定性を確保するためには、最も高いリソース需要に応じてリソースを準備する必要があり、オフピーク時間帯に深刻なアイドルリソースが発生し、無駄が生じます。

2.1 コンテナ化のプロセスと障害

仮想マシンに存在する問題を解決するために、Meituan はより軽量なコンテナ テクノロジ、つまり Hulk1.0 プロジェクトの実装を検討し始めました。しかし、当時のリソース環境とアーキテクチャに基づいて、Hulk 1.0 は、オリジナルの OpenStack を基本的なリソース管理レイヤーとして実装したコンテナ プラットフォームでした。 OpenStack は、基盤となるホスト マシンのリソース管理機能を提供し、ビジネスの弾力性のあるリソースに対する要求を解決し、リソース配信サイクル全体を数分から数秒に短縮しました。

しかし、Hulk 1.0 の推進と実装により、いくつかの新たな問題も明らかになりました。

• 安定性が低い: OpenStack の基盤となるリソース管理機能が再利用されるため、拡張プロセス全体に 2 層のリソース スケジューリングが含まれ、データ同期プロセスが複雑になります。コンピューター室の隔離性も比較的低いです。 1 つのコンピュータ ルームで問題が発生すると、他のコンピュータ ルームの拡張や縮小にも影響が及びます。
• 機能不足: 多くのシステムが関与し、部門間の連携が図られているため、障害のあるノードの移行と回復機能を実現するのは容易ではなく、リソースの種類は比較的単一であり、全体的なトラブルシューティングとコミュニケーションの効率は低くなります。
• スケーラビリティが低い: Hulk1.0 の制御層では、基盤となるリソースの管理機能が限られており、シナリオやニーズに応じて迅速に拡張することができません。
• パフォーマンス: 企業は容量の拡張性とリソース配信速度の弾力性に対する要求が高まっており、コンテナ テクノロジの分離性が弱いために、ビジネス サービスの中断が増加し、否定的なフィードバックが増加しています。

上記の問題は、最適化と改善の期間を経ても完全には解決されていません。このような状況では、コンテナ プラットフォーム全体のアーキテクチャの合理性を再考する必要があります。現時点では、Kubernetes は業界で徐々に認知され、適用されるようになっています。その明確なアーキテクチャと先進的なデザインアイデアは私たちに希望を与えてくれます。そこで、Kubernetes をベースにした新しいコンテナ プラットフォームを構築しました。新しいプラットフォームでは、Hulk はネイティブ Kubernetes API に完全に基づいており、内部のリリースおよびデプロイメント システムは Hulk API を介して接続されます。このように、2 層 API によってアーキテクチャ全体が分離され、ドメインが明確になり、アプリケーション管理とリソース管理を独立して反復できるようになり、Kubernetes の強力なオーケストレーション機能とリソース管理機能が強調されます。

コンテナ化の核心的な考え方は、Kubernetes がリソースレベルの管理を適切に行えるようにし、上位制御層を通じて Meituan のアプリケーション管理システムと運用保守システムへの依存問題を解決し、Kubernetes のネイティブ互換性を維持し、その後の保守コストを削減し、リソース管理の迅速な収束のニーズを満たすことです。同時に、新しいプラットフォームに基づくリソースを申請するユーザーの学習コストも削減されます。これは非常に重要であり、その後のインフラストラクチャ リソースの迅速かつ大規模な移行の「基盤」でもあります。

2.2 コンテナ化プロセスの課題と対処戦略

2.2.1 複雑で柔軟性があり、動的で構成可能なスケジューリング戦略

Meituan には多様な事業分野とアプリケーション機能を備えた製品が多数あるため、リソースの種類とスケジュール戦略についてもそれに応じた需要があります。たとえば、ビジネスによっては特定のリソース タイプ (SSD、大容量メモリ、大容量 IO など) が必要であり、ビジネスによっては特定の断片化戦略 (コンピューター ルーム、サービス依存関係など) が必要になります。そのため、こうした多様なニーズにいかにうまく応えていくかが大きな課題となっています。

これらの問題を解決するために、容量拡張リンクにポリシー エンジンを追加しました。企業は独自のアプリケーション APPKEY のポリシー要件をカスタマイズできます。同時に、ビッグデータで分析したサービスプロファイルをもとに、ビジネス特性や企業のアプリケーション管理ポリシーに基づいたビジネスポリシーの推奨も行います。最終的に、これらのポリシーはポリシー センターに保存されます。拡張プロセス中に、対応する需要タグがアプリケーション インスタンスに自動的に追加され、最終的に Kubernetes で有効になり、期待されるリソース配信が完了します。

2.2.2 洗練されたリソーススケジュールと運用

洗練されたリソースのスケジュールと操作。運用を洗練させる理由は、主にビジネス リソースの需要シナリオが複雑であることと、リソースが不足するケースが多いことという 2 つの考慮事項によるものです。

複数の Kubernetes クラスターを展開するために、プライベート クラウドとパブリック クラウドのリソースに依存しています。これらのクラスターの一部は一般的なサービスを実行し、他のクラスターは特定のアプリケーション専用です。コンピュータルームの分割やマシンモデルの差別化など、クラスターレベルでクラウドリソースを割り当てます。クラスターの下に、さまざまなビジネス ニーズに応じてさまざまなビジネス タイプ専用の領域を構築し、ビジネス ニーズを満たすためにリソース プールを分離します。より詳細なレベルでは、アプリケーション レベルのリソース要件、災害復旧要件、および安定性に基づいて、クラスター レベルのリソース スケジューリングを実行します。最後に、基盤となるハードウェアとソフトウェアに基づいて、CPU、MEM、ディスクのよりきめ細かいリソース分離とスケジューリングを実装します。

2.2.3 アプリケーションの安定性の向上と管理

VM であっても、元のコンテナ プラットフォームであっても、アプリケーションの安定性には常に問題がありました。そのためには、アプリケーションの SLA を確保するためにさらに努力する必要があります。

2.2.3.1 コンテナの再利用

実稼働環境では、ホスト マシンの再起動は非常に一般的なシナリオです。アクティブな再起動またはパッシブな再起動の場合があります。ただし、ユーザーの観点から見ると、ホスト マシンの再起動は、一部のユーザー システム データが失われる可能性があることを意味し、これは比較的コストがかかります。コンテナの移行や再構築を避け、直接再起動して回復する必要があります。しかし、Kubernetes では、Pod 内のコンテナに対して Always、OnFailure、Never といういくつかの再起動戦略があることは誰もが知っています。ホストを再起動するとコンテナが再作成されます。

この問題を解決するために、コンテナ再起動戦略タイプに再利用戦略を追加しました。プロセスは次のとおりです。

• kubelet が SyncPod 内にある場合、再起動戦略が Reuse であれば、終了した対応する Pod の App コンテナを取得します。存在する場合は、最新のアプリ コンテナーがプルアップされます (複数存在する場合があります)。存在しない場合は、直接新しいものを作成します。
• アプリ コンテナ マッピングの pauseID を新しい一時停止コンテナ ID に更新して、新しい一時停止コンテナと Pod の下の元のアプリ コンテナ間のマッピングが確立されるようにします。
• アプリ コンテナを再起動すると、Pod ステータスの同期が完了します。ホストを再起動したり、カーネルをアップグレードしたりしても、コンテナのデータは失われません。

2.2.3.2 ヌマの知覚と結合

ユーザーにとってのもう 1 つの問題点は、コンテナのパフォーマンスと安定性に関連しています。同じ構成のコンテナでもパフォーマンスに大きな違いがあり、主に一部のコンテナのリクエスト待ち時間が長いという形で現れるというビジネス フィードバックが引き続き寄せられています。テストと詳細な分析の結果、これらのコンテナは Numa ノードを介して CPU にアクセスすることがわかりました。コンテナの CPU 使用率を同じ Numa ノードに制限すると、問題は解消されます。したがって、遅延に敏感な一部のビジネスでは、アプリケーション パフォーマンスの一貫性と安定性を確保し、スケジューリング側で Numa ノードの使用状況を把握できる必要があります。

この問題を解決するために、ノード層でNumaノードの分散状況を収集し、スケジューラ層でNumaノードの認識とスケジューリングを追加し、リソース使用のバランスを確保しました。ノードにバインドする必要がある一部の機密アプリケーションでは、適切なノードが見つからない場合、拡張は失敗します。 Numa ノードにバインドする必要のない一部のアプリケーションでは、可能な限りニーズを満たす戦略を選択できます。

2.2.3.3 その他の安定性の最適化

スケジューリング レベルでは、負荷認識とサービス プロファイル アプリケーション機能に基づく断片化および最適化戦略をスケジューラに追加しました。

障害のあるコンテナの検出と処理に関しては、機能ライブラリに基づくアラーム自己修復コンポーネントが数秒でアラームを検出、分析、処理できます。

高 IO や高メモリなどの特別なリソース要件を持つ一部のアプリケーションでは、他のアプリケーションへの影響を避けるために専用領域の分離が使用されます。

2.2.4 プラットフォームベースのビジネスコンテナ化

ToBビジネスに携わったことのある学生なら、どんな製品にも大きな顧客計画があることを理解しているはずだと私は思います。Meituanのような企業では、社内にもこのような状況が存在します。プラットフォーム型ビジネスのコンテナ化の特徴は、インスタンスが数千から数万と多数存在するため、リソースコストが比較的高いことです。事業ステータスは比較的高く、一般的に非常に中核的な事業であり、パフォーマンスと安定性に対する要求も高いです。したがって、そのようなビジネスの問題を単一のソリューションで解決しようとするのは、やや非現実的です。

ここでは、MySQL プラットフォームを例に挙げます。データベースビジネスでは、安定性、パフォーマンス、信頼性に対する要件が非常に高くなります。ビジネス自体は主に物理的なマシンをベースとしているため、コスト圧力が非常に高くなります。データベースのコンテナ化では、主にホスト側でのリソース割り当てのカスタマイズと最適化から始まります。

CPU リソースの割り当てでは、Pod 間の競合を避けるために排他的な CPU セットが使用されます。

短期間の高トラフィックを処理するためにカスタム SWAP サイズを許可し、Numa Node と PageCache を無効にすることで安定性が向上しました。

ディスク割り当てでは、Pod専用ディスクを使用してIOPSを分離し、ディスクを事前に割り当ててフォーマットすることで、拡張の速度とリソース配信の効率が向上します。

スケジューリングでは、容量削減のリスクを回避するために、独自の分割戦略と容量削減確認をサポートします。

最終的に、データベースのスループットを 60 倍向上させることができ、ほとんどの場合、以前の物理マシンよりもパフォーマンスが向上しました。

2.2.5 ビジネスリソースの優先保証

企業にとって、コストを考慮するとリソースが常に不足するため、リソースの供給と割り当てを確実にすることが非常に重要です。

事業予算の割り当てによってリソースの供給が決定され、専用リソースは特別ゾーンを通じてのみ使用されます。

突然のリソース需要に対応するために、弾力性のあるリソース プールを構築し、パブリック クラウドに接続します。

ビジネスとアプリケーションの種類の優先順位に応じてリソースの使用を保証し、コアビジネスが最初にリソースを取得できるようにします。

複数の Kubernetes クラスターと複数のコンピューター ルームは、クラスターまたはコンピューター ルームの障害に対処するための災害復旧に使用されます。

2.2.6 クラウドネイティブアーキテクチャの実装

Kubernetes に移行した後、クラウドネイティブ アーキテクチャをさらに実装しました。

クラウドネイティブ アプリケーション管理の障害を解決するために、Meituan 独自のクラウドネイティブ アプリケーション管理エンジンである KubeNative を設計および実装しました。これにより、アプリケーションの構成と情報管理がプラットフォームに対して透過的になります。ビジネス プラットフォームでは、ネイティブ Pod リソースを作成するだけでよく、アプリケーション情報の同期や管理の詳細に注意を払う必要はありません。また、各 PaaS プラットフォームをサポートし、制御層の機能を拡張して独自の Operator を実行できます。

下の図は、Hulk コンテナ プラットフォーム、Serverless、TiDB などのプラットフォームの実装をすでにサポートしている、現在のクラウド ネイティブ アプリケーション管理アーキテクチャ全体を示しています。

2.3 インフラ移行のメリット

社内業務の98％のコンテナ化を完了し、リソース管理の効率と業務の安定性が大幅に向上しました。

• Kubernetes の安定性は 99.99% を超えています。
• Kubernetes は Meituan の社内クラスター管理プラットフォームの標準になりました。

3. 大規模Kubernetesクラスタ運用の課題と戦略

インフラ移行プロセス全体において、これまでの課題の解決やシステム構築に加え、Kubernetes クラスターの規模と数が急速に拡大するにつれて、大規模な Kubernetes クラスターをいかに安定的かつ効率的に運用するかという新たな課題に直面しています。過去数年間の Kubernetes 運用において、私たちは実証済みの運用経験を徐々に探求してきました。

3.1 コアコンポーネントの最適化とアップグレード

当初は Kubernetes バージョン 1.6 を使用していましたが、パフォーマンスと安定性が比較的低かったです。 1K ノードに達したときに徐々に問題が発生し、5K ノードに達したときに基本クラスターが使用できなくなりました。たとえば、スケジューリングのパフォーマンスが非常に悪く、クラスターのスループットが比較的低く、時々「雪崩」が発生し、リンクの拡張と縮小に必要な時間も増加しています。

コア コンポーネントの分析と最適化は、kube-apiserver、kube-scheduler、etcd、コンテナーの 4 つの側面からまとめられています。

• kube-apiserver では、再起動プロセス中の長期的な 429 リクエストの再試行を減らすために、マルチレベルのトラフィック制御を実装し、利用不可ウィンドウを 15 分から 1 分に短縮し、外部システムでのリスト操作を減らして回避することでクラスターの負荷を軽減し、内部 VIP を使用してノードの負荷を分散し、制御ノードの安定性を確保しました。
• kube-scheduler レイヤーでは、スケジューリング認識戦略が強化され、スケジューリング効果が以前よりも安定しました。スケジューリングパフォーマンスを最適化するために提案された事前選択された中断とローカル最適戦略もコミュニティに統合され、一般的な戦略になりました。
• etcd 操作の場合、独立したイベント クラスターを分割することでメイン データベースへの負荷が軽減され、高構成の SSD 物理マシンに基づく展開により、毎日の高トラフィック アクセスを 5 倍に処理できます。
• コンテナ レベルでは、コンテナの再利用によりコンテナのフォールト トレランスが向上し、CPU 割り当ての改良によりアプリケーションの安定性が向上します。また、コンテナのディスクを事前にマウントすることで、ノードの障害回復速度も向上します。

さらに、コミュニティ バージョンの反復は非常に高速で、上位バージョンでは安定性と機能サポートが向上します。バージョンのアップグレードは避けられませんが、特にリソースを転送するための十分な Buffer リソースがない場合、アップグレードの成功を確実にする方法は大きな課題です。

業界におけるクラスターのアップグレードの一般的なソリューションは、元のクラスターを直接アップグレードすることです。このソリューションには次の問題があります。

• バージョンアップには制限があり、メジャーバージョンをまたいでのアップグレードはできません。低いバージョンから高いバージョンへ少しずつアップグレードすることしかできず、時間と労力がかかり、成功率も低くなります。
• コントロール プレーンのアップグレードのリスクは制御不能です。特に API が変更されると、以前のデータが上書きされ、元に戻せなくなる可能性もあります。
• ユーザーは、新しいコンテナを構築する必要があり、コストと影響が大きいことを認識しています。これは痛い点であり、新しいコンテナの構築は避けられません。

そこで、Kubernetesのコンテナレベルでの制御方式を徹底的に研究し、コンテナデータを低バージョンクラスタから高バージョンクラスタへスムーズに移行できるソリューションを設計・実装しました。クラスターのアップグレードを改良し、ノード レベルで各ホスト上のコンテナーのインプレース ホット アップグレードを実現しました。このアップグレードはいつでも一時停止したりロールバックしたりできます。新しいソリューションは、主に外部ツールを使用して、ノードと Pod のデータを低バージョンのクラスターから高バージョンのクラスターに移行し、Pod オブジェクトとコンテナー間の互換性の問題を解決します。中心となるアイデアは 2 つあります。低バージョンの API を高バージョンの API と互換性のあるものにし、コンテナのハッシュを更新しても Pod の下のコンテナが更新されないようにすることです。ツールを使用して、Pod および Node リソース データを低バージョン クラスターから高バージョン クラスターに移行します。

このプログラムのハイライトは主に次の 4 つの側面です。

• 大規模な本番環境でのクラスターのアップグレードはもはや問題ではありません。
• これにより、既存の技術ソリューションにおける制御不能なリスクの問題が解決され、ホスト マシン レベルのリスクが軽減され、アップグレードがより安全になります。
• 汎用性が高く、任意のバージョンにアップグレードでき、ソリューションのライフサイクルが長いです。
• アップグレード プロセス中に新しいコンテナーを作成するという問題を巧みに解決し、インプレース ホット アップグレードを真に実現します。

3.2 プラットフォーム化と運用効率

大規模クラスタの運用は非常に困難です。ビジネスの急速な発展とユーザーのニーズに対応することも、チームにとって大きな試練となります。クラスターの運用と研究開発能力をさまざまな側面から検討する必要があります。

Kubernetes および etcd クラスターの全体的な運用保守能力の構築において、当社は安全な運用、効率的な運用保守、標準化された管理、コスト削減に重点を置いています。そのため、Kubernetes および etcd クラスターでは、機能拡張、パフォーマンスと安定性、日常の運用と保守、障害回復、データ操作、セキュリティ制御の 6 つの側面をカバーするプラットフォームベースの管理と運用が完了しました。

非パブリック クラウド ビジネスの Kubernetes チームの場合、人材は依然として非常に限られています。クラスターの日々の運用に加え、研究開発業務もあるため、運用効率の向上には非常に気を配っています。私たちは日々の運用と保守を徐々に統合、変革し、Meituan 内に Kubernetes クラスター管理プラットフォームを構築しました。

クラスター管理を標準化して視覚化し、白黒画面の操作とメンテナンスを回避します。

アラームの自己修復と自動検査により問題が収束します。そのため、数十のクラスターがあるにもかかわらず、運用と保守の効率は依然として比較的高く、勤務中の学生が注意を払う必要はほとんどありません。

すべての運用・保守業務が合理化され、運用・保守効率が向上するだけでなく、人的操作による障害の発生確率も低減します。

運用データの分析により、リソースのスケジューリングや障害予測の精度向上、リスクの事前発見などをさらに進め、運用品質の向上を実現しました。

3.3 リスク管理と信頼性の保証

大規模で幅広いビジネス範囲をカバーするため、クラスターの障害はサービスの安定性、さらにはユーザー エクスペリエンスに直接影響を及ぼします。複数の運用および保守の失敗とセキュリティ上のプレッシャーを経験した後、私たちは再現可能な一連のリスク管理および信頼性保証戦略を策定しました。

リスク管理チェーン全体を、指標、アラーム、ツール、メカニズムと対策、人員の 5 つのレベルに分けます。

• インジケーター データの収集: ノード、クラスター、コンポーネント、およびリソース レベルからコア インジケーターをデータ ソースとして収集します。
• リスクプッシュは、コア指標をカバーする多レベルかつ多次元の警告メカニズムです。
• ツールのサポートに関しては、アクティブ、パッシブ、プロセスベースのアプローチを通じて誤操作のリスクが軽減されます。
• メカニズム保証の面では、テスト、グレースケール検証、リリース確認、訓練を統合し、不注意を減らします。
• リスクの根源は人であり、私たちは問題に確実に対応できるよう、この分野でチームの構築とローテーションに尽力してきました。

信頼性の検証と運用に関しては、クラスター検査を通じてクラスターの健全性を評価し、レポートをプッシュすることに力を入れる必要があると強く信じています。定期的なダウンタイム訓練により、実際の障害を迅速に回復し、フルリンク テストで毎日の問題を解決して閉ループを形成できるようになります。

IV.まとめと今後の展望

4.1 経験

Kubernetes の実装はコミュニティの Kubernetes API と完全に互換性があります。プラグイン拡張のみが行われ、コントロール層の本来の動作は可能な限り変更されません。

私たちは、いくつかのコミュニティ機能の長所を学び、その短所を補い、期待どおりのアップグレードを行います。私たちは盲目的にアップグレードしたりコミュニティのバージョンに従ったりせず、毎年コアの安定したバージョンを維持するよう努めています。

実装では、ユーザーの問題点を突破口として捉えます。ビジネスはより実用的になります。移行はなぜ必要なのでしょうか?企業はトラブルを恐れて協力しなくなるでしょう。したがって、それを推進するには、ビジネスの問題点を見つける必要があります。ビジネスを助けるという観点から見ると、効果は異なります。

内部のクラスター管理と運用の価値を実証することも非常に重要な部分です。ユーザーに価値を、企業に潜在的なメリットを認識させれば、積極的にアプローチしてくれるようになります。

コンテナ時代では、Ku1.bernetes そのものだけを見ることはできません。企業内のインフラストラクチャでは、「上位」と「下位」の統合と互換性も重要です。 「上向き」とは、ビジネス シナリオ用のドッキングをユーザーに提供することを意味します。コンテナはビジネスに直接役立つことはできないため、アプリケーションのデプロイ方法、サービス ガバナンス、スケジュール設定など、多くの側面も関係します。 「下向き」とは、コンテナとインフラストラクチャを組み合わせる問題を指します。ここでのより重要な問題としては、互換性のあるリソース タイプ、より強力な分離、およびより高いリソース利用効率が挙げられます。

4.2 今後の展望

• 統合スケジューリング：VMは少量でも長期間存在し続けることになりますが、2セットのインフラ製品を同時に維持するコストは非常に高いため、VMとコンテナの管理を統合するKubernetesも実装しています。
• VPA: VPA を通じて全体的なリソース利用効率をさらに向上させる方法を検討します。
• クラウドネイティブアプリケーション管理: 現在、本番環境にクラウドネイティブアプリケーション管理を実装しています。今後はクラウドネイティブアプリケーションの対象範囲をさらに拡大し、研究開発の効率を継続的に向上させていきます。
• クラウドネイティブアーキテクチャの実現：各種ミドルウェア、ストレージシステム、ビッグデータ、検索事業との連携により、様々な分野でのクラウドネイティブシステムの実現を推進します。

著者について

Meituan-Dianping の技術専門家である Guo Liang 氏は現在、Meituan-Dianping の Kubernetes クラスターの全体的な運用と保守、およびクラウドネイティブ テクノロジーの実装サポートを担当しています。