Pinterest で Kubernetes プラットフォームを作成する

長年にわたり、Pinterest の 300 億人のユーザーは、200 億以上のボードに 4 億以上のピンを作成してきました。 この多数のユーザーと膨大なコンテンツ ベースにサービスを提供するために、ポータルは、少数の CPU で処理できるマイクロサービスから、仮想マシン全体で実行される巨大なモノリスに至るまで、何千ものサービスを開発してきました。 そして、企業の視線がk8sに注がれる瞬間がやって来ました。 Pinterest で「立方体」がよく映えたのはなぜですか? これについては、最近の記事の翻訳から学ぶことができます。 ブログ Pinterest エンジニアリング.

つまり、何億ものユーザーと何千億ものピンが存在します。 この大勢のユーザーと膨大なコンテンツ ベースにサービスを提供するために、私たちは数個の CPU で処理できるマイクロサービスから、仮想マシンのフリート全体で実行される巨大なモノリスに至るまで、何千ものサービスを開発してきました。 さらに、CPU、メモリ、または I/O アクセスを必要とするさまざまなフレームワークもあります。

このツールの動物園を維持する上で、開発チームは多くの課題に直面しています。

• エンジニアが実稼働環境を実行するための統一された方法はありません。 ステートレス サービス、ステートフル サービス、および現在開発中のプロジェクトは、まったく異なるテクノロジー スタックに基づいています。 これにより、エンジニア向けのトレーニング コース全体が作成されることになり、インフラストラクチャ チームの作業も大幅に複雑化しました。
• 独自の仮想マシン群を持つ開発者は、内部管理者に大きな負担を与えます。 その結果、OS や AMI の更新などの単純な操作には数週間から数か月かかります。 これにより、一見日常的な状況でも作業量が増加します。
• 既存のソリューションに加えてグローバル インフラストラクチャ管理ツールを作成することの難しさ。 仮想マシンの所有者を見つけるのが簡単ではないという事実により、状況はさらに複雑になります。 つまり、この容量をインフラストラクチャの他の部分で動作させるために安全に抽出できるかどうかはわかりません。

コンテナ オーケストレーション システムは、ワークロード管理を統合する方法です。 プロジェクトに関係するすべてのリソースが XNUMX つの集中システムで管理されるため、開発速度が向上し、インフラストラクチャ管理が簡素化されます。

図 1: インフラストラクチャの優先順位 (信頼性、開発者の生産性、効率性)。

Pinterest のクラウド管理プラットフォーム チームは、8 年に K2017 を発見しました。 2017 年前半までに、API やすべての Web サーバーを含む、ほとんどの運用機能を文書化しました。 その後、コンテナ ソリューションの調整、クラスタの構築、および連携のためのさまざまなシステムの徹底的な評価を実施しました。 2017 年の終わり頃、私たちは Kubernetes を使用することに決めました。 これは非常に柔軟で、開発者コミュニティで広くサポートされていました。

これまでに、Kops に基づいて独自のクラスター ブート ツールを構築し、ネットワーキング、セキュリティ、メトリクス、ロギング、アイデンティティ管理、トラフィックなどの既存のインフラストラクチャ コンポーネントを Kubernetes に移行してきました。 また、リソースのワークロード モデリング システムも実装しましたが、その複雑さは開発者には隠されています。 現在、私たちはクラスターの安定性を確保し、クラスターを拡張し、新しいクライアントを接続することに重点を置いています。

Kubernetes: Pinterest のやり方

当社のエンジニアが好むプラットフォームとして Pinterest の規模で Kubernetes を使い始めるには、多くの課題が伴いました。

大企業として、当社はインフラストラクチャ ツールに多額の投資を行ってきました。 例には、証明書の処理とキーの配布を処理するセキュリティ ツール、トラフィック制御コンポーネント、サービス検出システム、可視性コンポーネント、ログとメトリクスのディスパッチ コンポーネントが含まれます。 これらすべてには理由があって集められたのです。私たちは通常の試行錯誤の道を経てきたため、新しいプラットフォームで古い車輪を再発明するのではなく、これらすべての機器を Kubernetes 上の新しいインフラストラクチャに統合したいと考えました。 このアプローチでは、すべてのアプリケーション サポートがすでに存在し、最初から作成する必要がないため、移行が全体的に簡素化されました。

一方で、Kubernetes 自体の負荷予測モデル (デプロイメント、ジョブ、デーモン セットなど) は、私たちのプロジェクトには十分ではありません。 こうしたユーザビリティの問題は、Kubernetes への移行にとって大きな障壁となります。 たとえば、ログイン設定が欠落している、または正しくないというサービス開発者からの苦情を聞いたことがあります。 また、同じ仕様とタスクで何百ものコピーが作成された場合、テンプレート エンジンの誤った使用にも遭遇し、悪夢のようなデバッグ問題が発生しました。

同じクラスター内で異なるバージョンを維持することも非常に困難でした。 同じランタイム環境の複数のバージョンで、すべての問題、バグ、アップデートを同時に処理する必要がある場合のカスタマー サポートの複雑さを想像してみてください。

Pinterest ユーザーのプロパティとコントローラー

エンジニアによる Kubernetes の実装を容易にし、インフラストラクチャを簡素化して高速化するために、当社は独自のカスタム リソース定義 (CRD) を開発しました。

CRD は次の機能を提供します。

1. さまざまなネイティブ Kubernetes リソースを組み合わせて、単一のワークロードとして機能するようにします。 たとえば、PinterestService リソースには、デプロイメント、ログイン サービス、構成マップが含まれています。 これにより、開発者は DNS の設定について心配する必要がなくなります。
2. 必要なアプリケーションのサポートを実装します。 ユーザーはビジネス ロジックに従ってコンテナーの仕様のみに注目する必要がありますが、CRD コントローラーは必要な初期コンテナー、環境変数、およびポッドの仕様をすべて実装します。 これにより、開発者には根本的に異なるレベルの快適さが提供されます。
3. CRD コントローラーは、ネイティブ リソースのライフサイクルも管理し、デバッグの可用性を向上させます。 これには、望ましい仕様と実際の仕様の調整、CRD ステータスの更新、イベント ログの維持などが含まれます。 CRD がなければ、開発者は複数のリソースを管理する必要があり、エラーの可能性が高まるだけです。

以下は、PinterestService とコントローラーによって管理される内部リソースの例です。

上でわかるように、カスタム コンテナをサポートするには、セキュリティ、可視性、およびネットワーク トラフィックを提供するために、init コンテナといくつかのアドオンを統合する必要があります。 さらに、構成マップ テンプレートを作成し、バッチ ジョブ用の PVC テンプレートのサポートを実装したほか、ID、リソース消費、ガベージ コレクションを追跡するための複数の環境変数の追跡も実装しました。

開発者が CRD サポートなしでこれらの構成ファイルを手動で作成することを望むとは想像しにくいです。ましてや、構成をさらに保守したりデバッグしたりすることは言うまでもありません。

アプリケーション導入ワークフロー

上の画像は、Pinterest カスタム リソースを Kubernetes クラスターにデプロイする方法を示しています。

1. 開発者は、CLI とユーザー インターフェイスを通じて Kubernetes クラスターと対話します。
2. CLI/UI ツールは、ワークフロー構成 YAML ファイルとその他のビルド プロパティ (同じバージョン ID) を Artifactory から取得し、それらをジョブ送信サービスに送信します。 この手順により、運用バージョンのみがクラスターに配信されるようになります。
3. JSS は、Kubernetes を含むさまざまなプラットフォームのゲートウェイです。 ここでユーザーが認証され、クォータが発行され、CRD の構成が部分的にチェックされます。
4. JSS側でCRDを確認した後、k8sプラットフォームAPIに情報を送信します。
5. CRD コントローラーは、すべてのユーザー リソース上のイベントを監視します。 CR をネイティブ k8s リソースに変換し、必要なモジュールを追加し、適切な環境変数を設定し、その他のサポート作業を実行して、コンテナ化されたユーザー アプリケーションが十分なインフラストラクチャ サポートを確保できるようにします。
6. 次に、CRD コントローラーは受信したデータを Kubernetes API に渡し、スケジューラーによって処理されて実稼働環境に投入できるようにします。

注意: このプレリリース展開ワークフローは、新しい k8s プラットフォームの最初のユーザー向けに作成されました。 現在、新しい CI/CD と完全に統合するためにこのプロセスを改良中です。 つまり、Kubernetes に関連するすべてをお伝えすることはできません。 次回のブログ投稿「Pinterest 用の CI/CD プラットフォームの構築」で、この方向における私たちの経験とチームの進捗状況を共有できることを楽しみにしています。

特殊リソースの種類

Исходя из конкретных потребностей Pinterest, мы разработали следующие CRD, которые подходят для различных рабочих процессов:

• PinterestService は、長期間にわたって実行されているステートレスなサービスです。 当社のコア システムの多くは、このようなサービスのセットに基づいています。
• PinterestJobSet はフルサイクルのバッチ ジョブをモデル化します。 Pinterest での一般的なシナリオは、他の同様のプロセスに関係なく、複数のジョブが同じコンテナを並行して実行することです。
• PinterestCronJob は、小規模な定期的な負荷と組み合わせて広く使用されています。 これは、セキュリティ、トラフィック、ログ、メトリクスを担当する Pinterest サポート メカニズムを使用したネイティブ cron 作業のラッパーです。
• PinterestDaemon にはインフラストラクチャ デーモンが含まれています。 このファミリーは、クラスターにサポートを追加するにつれて成長し続けます。
• PinterestTrainingJob は Tensorflow および Pytorch プロセスに拡張され、他のすべての CRD と同じレベルのランタイム サポートを提供します。 Pinterest は Tensorflow やその他の機械学習システムを積極的に使用しているため、それらを中心に別の CRD を構築する理由がありました。

また、間もなくデータ ウェアハウスやその他のステートフル システムに適応される PinterestStatefulSet にも取り組んでいます。

ランタイムサポート

アプリケーション ポッドが Kubernetes 上で実行されると、それ自体を識別するための証明書を自動的に受け取ります。 この証明書は、シークレット ストレージにアクセスしたり、mTLS 経由で他のサービスと通信したりするために使用されます。 一方、Container Init Configurator と Daemon は、コンテナ化されたアプリケーションを実行する前に、必要な依存関係をすべてダウンロードします。 すべての準備が完了すると、トラフィック サイドカーとデーモンはモジュールの IP アドレスを Zookeeper に登録し、クライアントがモジュールを検出できるようにします。 アプリケーションが起動される前にネットワーク モジュールが設定されているため、これはすべて機能します。

上記は、ワークロードのランタイム サポートの典型的な例です。 他のタイプのワークロードでは若干異なるサポートが必要になる場合がありますが、それらはすべてポッド レベルのサイドカー、ノード レベルまたは仮想マシン レベルのデーモンの形式で提供されます。 これらすべてが管理インフラストラクチャ内に展開され、アプリケーション間で一貫していることを保証するため、最終的には技術的な作業と顧客サポートの面での負担が大幅に軽減されます。

テストとQA

既存の Kubernetes テスト インフラストラクチャ上にエンドツーエンドのテスト パイプラインを構築しました。 これらのテストはすべてのクラスターに適用されます。 私たちのパイプラインは、製品クラスターの一部となるまでに多くの改訂を経ました。

当社では、テスト システムに加えて、システム コンポーネントのステータス、リソース消費、その他の重要な指標を常に監視し、人間の介入が必要な場合にのみ通知する監視および警告システムを備えています。

代替案

私たちは、ミューテーション アクセス コントローラーやテンプレート システムなど、カスタム リソースの代替手段をいくつか検討しました。 ただし、それらはすべて運用上の重大な課題を伴うため、私たちは CRD ルートを選択しました。

ミューテーション アドミッション コントローラーを使用して、サイドカー、環境変数、その他のランタイム サポートが導入されました。 しかし、CRD では発生しないリソース バインディングやライフサイクル管理など、さまざまな問題に直面しました。

注意： Helm チャートなどのテンプレート システムも、同様の構成でアプリケーションを実行するために広く使用されています。 ただし、仕事のアプリケーションは多様すぎて、テンプレートを使用して管理することはできません。 また、継続的なデプロイ中に、テンプレートを使用するとエラーが多すぎます。

今後の仕事

現在、すべてのクラスターにわたる混合負荷に対処しています。 このようなさまざまな種類や規模のプロセスをサポートするために、私たちは次の分野に取り組んでいます。

• クラスターの集合により、スケーラビリティと安定性を確保するために、大規模なアプリケーションがさまざまなクラスターに分散されます。
• クラスターの安定性、拡張性、可視性を確保して、アプリケーションの接続性と SLA を作成します。
• アプリケーションが互いに競合しないようにリソースとクォータを管理し、クラスターの規模を制御します。
• Kubernetes 上でアプリケーションをサポートおよびデプロイするための新しい CI/CD プラットフォーム。

出所： habr.com