この記事は、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 クラウド プラットフォーム期間中に私たちが直面した主な問題には、次のような側面がありました。
2.1 コンテナ化のプロセスと障害 仮想マシンに存在する問題を解決するために、Meituan はより軽量なコンテナ テクノロジ、つまり Hulk1.0 プロジェクトの実装を検討し始めました。しかし、当時のリソース環境とアーキテクチャに基づいて、Hulk 1.0 は、オリジナルの OpenStack を基本的なリソース管理レイヤーとして実装したコンテナ プラットフォームでした。 OpenStack は、基盤となるホスト マシンのリソース管理機能を提供し、ビジネスの弾力性のあるリソースに対する要求を解決し、リソース配信サイクル全体を数分から数秒に短縮しました。 しかし、Hulk 1.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 といういくつかの再起動戦略があることは誰もが知っています。ホストを再起動するとコンテナが再作成されます。 この問題を解決するために、コンテナ再起動戦略タイプに再利用戦略を追加しました。プロセスは次のとおりです。
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%のコンテナ化を完了し、リソース管理の効率と業務の安定性が大幅に向上しました。
3. 大規模Kubernetesクラスタ運用の課題と戦略 インフラ移行プロセス全体において、これまでの課題の解決やシステム構築に加え、Kubernetes クラスターの規模と数が急速に拡大するにつれて、大規模な Kubernetes クラスターをいかに安定的かつ効率的に運用するかという新たな課題に直面しています。過去数年間の Kubernetes 運用において、私たちは実証済みの運用経験を徐々に探求してきました。 3.1 コアコンポーネントの最適化とアップグレード 当初は Kubernetes バージョン 1.6 を使用していましたが、パフォーマンスと安定性が比較的低かったです。 1K ノードに達したときに徐々に問題が発生し、5K ノードに達したときに基本クラスターが使用できなくなりました。たとえば、スケジューリングのパフォーマンスが非常に悪く、クラスターのスループットが比較的低く、時々「雪崩」が発生し、リンクの拡張と縮小に必要な時間も増加しています。 コア コンポーネントの分析と最適化は、kube-apiserver、kube-scheduler、etcd、コンテナーの 4 つの側面からまとめられています。
さらに、コミュニティ バージョンの反復は非常に高速で、上位バージョンでは安定性と機能サポートが向上します。バージョンのアップグレードは避けられませんが、特にリソースを転送するための十分な Buffer リソースがない場合、アップグレードの成功を確実にする方法は大きな課題です。 業界におけるクラスターのアップグレードの一般的なソリューションは、元のクラスターを直接アップグレードすることです。このソリューションには次の問題があります。
そこで、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 今後の展望
著者について Meituan-Dianping の技術専門家である Guo Liang 氏は現在、Meituan-Dianping の Kubernetes クラスターの全体的な運用と保守、およびクラウドネイティブ テクノロジーの実装サポートを担当しています。 |
<<: 彼女がアオ・ビンに尋ねました: 分散トランザクションとは何ですか?
>>: 適切なクラウド データベース サービスを選択するための 4 つのヒント
tmhhostは現在、春のプロモーションを実施しています。(1)香港安昌データセンターのVPSを20...
ハイブリッドクラウドの使用がますます増えています。過去 10 年間でハイブリッド クラウド、市場構造...
中国の現在の医療状況では、医師の診察を受けることがますます困難かつ高額になっており、またインターネッ...
Swiftvm の VPS は openvz に基づいており、移植性は現時点では非常に良好です。特に...
[[382198]] 10 年で人々の生活は大きく変わるかもしれませんが、10 年で起こるテクノロジ...
私はこれまでオンラインプロモーションの経験を共有する記事を書いてきましたが、SEOに関する記事は一度...
新年を迎え、主要プラットフォームが相次いで今年の年間総括と展望を発表しています。DAMO Acade...
ファンを集めて広告を掲載するWeiboマーケティングが増加中現在、数百万人のフォロワーを持つWeib...
あなたのビジネスでクラウドを利用すべきかどうかお悩みですか?クラウド コンピューティングの最大のメリ...
UPホストは、常にビリビリのコンテンツエコロジーとプラットフォーム開発の基盤であり、無限のコンテンツ...
6月から、Baiduは段階的にサイトのK-upを開始しました。ほぼ一夜にして、数万のウェブサイトがK...
クラウド コンピューティングの出現は、当初は経済的な提案でした。サーバーは高価であり、必要なスペース...
8月18日、テンセントクラウドと昆山農村商業銀行は正式に戦略協力協定を締結した。両者は、銀行プライベ...
SEO 担当者なら誰でも、この文を知っています。「人々が情報を入手し、探しているものを見つけやすくす...
HUAWEI CONNECT 2018において、Sinopec Yingke Information...