宿題ヘルパー Kubernetes サーバーレス実装と大規模タスクシナリオでの最適化

1. 背景

Zuoyebang のクラウドネイティブ コンテナ化変革のプロセスにおいて、さまざまなビジネス ラインの仮想マシンに元々展開されていたスケジュールされたタスクは、Kubernetes クラスターの cronjob に徐々に移行されました。当初、cronjobsの規模が小さく、その数が1,000未満のときは正常に動作していました。しかし、cronジョブの規模が数万に拡大するにつれて、徐々に問題が浮上してきました。

2. 問題

当時、私たちは主に 2 つの問題に直面していました。1 つはクラスター内のノードの安定性、もう 1 つはクラスターのリソース使用率の低さでした。

最初の質問: クラスター内のノードの安定性

ビジネスでは分単位で実行されるスケジュールされたタスクが多数あるため、ポッドは頻繁に作成および破棄されます。平均して、1 分間に 1 つのノードで数百のコンテナが作成および破棄され、マシンの安定性の問題が頻繁に発生します。
典型的な問題は、頻繁なポッド作成によりノード上の cgroup が多すぎることになり、特にメモリ cgroup が時間内にリサイクルできず、/sys/fs/cgroup/memory/memory.stat の読み取りが遅くなることです。 kubelet は定期的にこのファイルを読み取り、各 cgroup 名前空間のメモリ消費量をカウントするため、CPU カーネルの状態は徐々に増加します。これが一定のレベルまで増加すると、一部の CPU コアが長時間カーネル状態に閉じ込められ、ネットワーク パケットの送受信に明らかな遅延が発生します。

ノードでは、perf レコード cat /sys/fs/cgroup/memory/memory.stat と perf レポートにより、CPU が主に memcg_stat_show によって消費されていることが示されます。

cgroup-v1 の memcg_stat_show 関数は、各 CPU コアに対して memcg ツリーを複数回走査します。 memcg ツリー内のノード数が数十万に達すると、時間の消費は壊滅的になります。

コンテナが破棄されたときにメモリ cgroup がすぐに解放されないのはなぜですか?これは主に、メモリ cgroup が解放されると、すべてのキャッシュ ページをトラバースするため、非常に遅くなる可能性があるためです。カーネルは必要な場合にのみこれらのメモリを再利用します。すべてのメモリ ページがクリーンアップされると、対応するメモリ cgroup が解放されます。一般的に、この戦略は、リサイクルを遅らせることによって、直接的な全体的なリサイクルの時間消費を分散させることです。通常の状況では、マシン上に作成されるコンテナの数はそれほど多くなく、通常は数百から数千程度であれば基本的に問題ありません。ただし、大規模なスケジュールされたタスクのシナリオでは、マシン上で毎分数百のコンテナが作成および破棄され、ノードにメモリの負荷はかかりません。メモリ cgroup はリサイクルされません。しばらくすると、マシン上のメモリ cgroup の数は数十万に達します。メモリの読み取りには10秒以上かかります。 CPU カーネルの状態が大幅に増加し、明らかなネットワーク遅延が発生します。

さらに、dockerd が過負荷になったり、応答が遅くなったり、kubelet PLEG がタイムアウトしてノードが準備できなくなるなどの問題もあります。

2番目の質問: クラスターノードのリソース使用率

使用するスマート カードの CNI ネットワーク モードにより、単一ノード上のポッドの数に上限があります。ノード上のポッドのほぼ半分は、スケジュールされたタスクのポッド用に予約されています。ただし、スケジュールされたタスクのポッドの実行時間は一般的に非常に短く、リソース使用率は非常に低くなります。その結果、スケジュールされたタスク用にクラスターによって大量のアイドル リソースが予約され、マシンの全体的なリソース使用率の向上にはつながりません。

その他の問題: スケジュール速度、サービス間の分離

毎日 0:00 などの特定の時間帯には、何千ものジョブを同時に実行する必要があります。ネイティブ スケジューラは、クラスター リソースを割り当てる k8s スケジューリング ポッド自体です。スケジュール設定プロセスでは、事前選択段階とスコアリング段階が順番に、つまりシリアルに実行されます。何千ものジョブのスケジュールを完了するには数分かかりますが、ほとんどの企業では、ジョブが 00:00:00 に時間どおりに実行されること、または 3 秒以内のエラーが許容されることが求められます。

一部のサービス ポッドは、コンピューティングまたは IO を集中的に使用します。このようなサービスは大量のノード CPU または IO を占有しますが、cgroup の分離は徹底されていないため、他のオンライン サービスの正常な動作を妨げます。

3. k8s クラスターでサーバーレスを使用する

したがって、CRONJOB タイプのタスクでは、より徹底した分離方法、より細かい粒度のノード、およびより高速なスケジューリング モードが必要になります。

上記の問題を解決するために、スケジュールされたタスク ポッドを通常のオンライン サービス ポッドから分離することを検討しました。ただし、多くのスケジュールされたタスクはクラスター内のサービスと通信する必要があるため、最終的に、クラスター内のスケジュールされたタスク ポッドを分離するソリューション (k8s serverless) を決定しました。既存の k8s システムで k8s サーバーレスの使用を実装するために仮想ノードを導入しました。仮想ノードにデプロイされた POD は、クラスターの既存のノードにデプロイされた POD と同じセキュリティ分離とネットワーク接続を備えており、リソースを予約する必要がなく、従量課金制であるという特徴があります。図に示すように:

タスクスケジューラ

すべての cronjob ワークロードはタスク スケジューラを使用します。タスク スケジューラは、タスク ポッドをサーバーレス ノードにバッチ並列スケジュールします。スケジューリングは非シリアルであり、完全な並列性と ms のスケジューリング速度を実現します。また、サーバーレス ノードに障害が発生した場合やリソースが不足した場合に、通常のノードに戻すスケジュールもサポートします。

PODノードと通常のノードの違いを解決する

k8s サーバーレスを使用する前に、ビジネス開発への影響を避けるために、まずサーバーレス ポッドと通常のノードで実行される POD の違いを解決する必要があります。

1. 統合ログ収集

ログ収集に関しては、仮想ノードはクラウドベンダーによって管理されているため、DaemonSet を実行できず、ログ収集コンポーネントは DaemonSet の形式で実行されるため、仮想ノード上のログには別の収集プランが必要になります。クラウドベンダーは、コンテナの標準出力を独自のログ サービスに収集します。クラウド ベンダーによってログ サービスのインターフェイスは異なるため、当社では独自のログ消費サービスを開発しました。このサービスは、クラウド ベンダーのログ クライアントをプラグインの形で統合し、各クラウド ベンダーのログを消費し、クラスターの統合ログ コンポーネントによって収集されたログをフラット化して、統合された Kafka クラスターに配置し、その後消費します。

2. 統合監視と警報

監視に関しては、サーバーレス ポッド上で CPU/メモリ/ディスク/ネットワーク トラフィックのリアルタイム監視を実行し、通常のノード上のポッドと一貫性を保ち、ポッド サンボックスのエクスポート インターフェイスを公開します。私たちのプロメサスは、統一された収集を担当しています。サーバーレスへの移行により、ビジネスは完全に見えなくなりました。

起動パフォーマンスの向上

スケジュールされたタスクの起動速度要件を満たすには、サーバーレス ジョブの起動速度が数秒である必要があります。たとえば、業務では 00:00:00 に時間どおりに作業を行うことが求められたり、3 秒以内のエラーが許容されたりします。

時間のかかる主な手順は次のとおりです。
1. 基盤となるサンボックスの作成または動作環境の初期化
2. ビジネスイメージの向上

主な目的は、同じワークロードのサンボックスを再利用可能にすることです。このように、主な時間の消費はサービスの起動時間です。初回以外は起動に時間がかかりますが、その後の起動は基本的に数秒です。

IV.結論

ジョブスケジューラをカスタマイズし、通常ノード上の POD 間の差異を解決し、サーバーレス POD の起動性能を向上させることで、業務をシームレスにサーバーレスへ移行できます。無料の運用と保守、強力な分離、従量課金制というサーバーレスの特徴を効果的に活用してポッドを通常のビジネス ポッドから分離することで、クラスターはスケジュールされたタスク用にマシン リソースを予約する必要がなくなり、クラスター自身のノードに数万のポッドが解放され、全体の約 10% を占めるようになりました。同時に、ノード上でポッドが頻繁に作成されることによって発生する問題を回避し、ビジネスではスケジュールされたタスクの安定性をより良く体験できます。スケジュールされたタスクをサーバーレスに移行すると、クラスター全体のマシンの約 10% が解放され、スケジュールされたタスクのリソース コストが約 70% 削減されました。