このストーリーは、実稼働環境、特に Kubernetes でコンテナーを使用する方法についてです。 この記事では、コンテナからのメトリクスとログの収集、およびイメージの構築について説明します。

私たちは、B2B および B2C 向けのオンライン取引およびフィンテック製品のサービスを開発するフィンテック企業 Exness の出身です。 当社の研究開発にはさまざまなチームがあり、開発部門には 100 人以上の従業員がいます。

私たちは、開発者がコードを収集して実行するためのプラットフォームを担当するチームを代表します。 特に、アプリケーションからのメトリクス、ログ、イベントの収集、保存、レポートを担当します。 当社は現在、運用環境で約 50 の Docker コンテナを運用し、XNUMX TB のビッグ データ ストレージを維持し、Kubernetes、Rancher、さまざまなパブリック クラウド プロバイダーなどのインフラストラクチャを中心に構築されたアーキテクチャ ソリューションを提供しています。 

私たちのモチベーション

何が燃えているのですか？ 誰も答えることができません。 囲炉裏はどこにありますか？ 理解するのは難しいです。 いつ発火したのですか？ 調べることはできますが、すぐにはわかりません。 

一部のコンテナは立っているのに、他のコンテナはなぜ倒れているのでしょうか? どのコンテナが原因だったのでしょうか? 結局のところ、コンテナの外側は同じですが、内側にはそれぞれの Neo が存在します。

私たちの開発者は有能な人材です。 彼らは会社に利益をもたらす優れたサービスを提供します。 しかし、アプリケーションが入ったコンテナが誤って動作すると、障害が発生します。 XNUMX つのコンテナーは CPU を過剰に消費し、別のコンテナーはネットワークを消費し、XNUMX 番目のコンテナーは I/O 操作を消費します。XNUMX 番目のコンテナーはソケットで何を行うのかまったく不明です。 すべてが崩れ落ち、船は沈没します。 

エージェント

内部で何が起こっているかを理解するために、エージェントをコンテナ内に直接配置することにしました。

これらのエージェントは、コンテナが互いに壊れないような状態に保つプログラムを抑制します。 エージェントは標準化されているため、コンテナをサービスするための標準化されたアプローチが可能になります。 

この場合、エージェントは、タグ付けされ調整された標準形式のログを提供する必要があります。 また、ビジネス アプリケーションの観点から拡張可能な標準化されたメトリクスも提供する必要があります。

エージェントは、さまざまなイメージ (Debian、Alpine、Centos など) をサポートするさまざまなオーケストレーション システムで動作できる、運用とメンテナンスのためのユーティリティも意味します。

最後に、エージェントは Docker ファイルを含む単純な CI/CD をサポートする必要があります。 そうしないと、コンテナが「曲がった」レールに沿って配送され始めるため、船は崩壊してしまいます。

ビルドプロセスとターゲットイメージデバイス

すべてを標準化して管理しやすくするには、ある種の標準的なビルド プロセスに従う必要があります。 したがって、コンテナごとにコンテナを収集することにしました。これが再帰です。

ここでは、コンテナは実線で表されています。 同時に、彼らは「人生がラズベリーのように見えないように」配布キットを入れることに決めました。 なぜこのようなことが行われたのかについては、以下で説明します。
 
その結果、特定のディストリビューション バージョンと特定のスクリプト バージョンを参照するバージョン固有のコンテナーであるビルド ツールが作成されます。

どのように使用しますか? コンテナを含む Docker Hub があります。 それをシステム内にミラーリングして、外部の依存関係を排除します。 結果は、黄色でマークされたコンテナーです。 必要なすべてのディストリビューションとスクリプトをコンテナーにインストールするためのテンプレートを作成します。 その後、すぐに使用できるイメージを組み立てます。開発者は、コードと独自の特別な依存関係をそのイメージに追加します。 

このアプローチの何が良いのでしょうか? 

• まず、ビルド ツールの完全なバージョン管理 (ビルド コンテナー、スクリプト、および配布バージョン)。 
• 次に、標準化を達成しました。テンプレート、中間イメージ、すぐに使用できるイメージを同じ方法で作成します。 
• 第三に、コンテナは移植性をもたらします。 今日は Gitlab を使用していますが、明日は TeamCity または Jenkins に切り替えて、同じ方法でコンテナを実行できるようになります。 
• XNUMX 番目に、依存関係を最小限に抑えます。 配布キットをコンテナに入れたのは偶然ではありません。これにより、配布キットを毎回インターネットからダウンロードする必要がなくなりました。 
• 第 XNUMX に、ビルド速度が向上しました。ローカル イメージがあるため、イメージのローカル コピーが存在するため、ダウンロードにかかる時間を無駄にすることがなくなります。 

言い換えれば、制御された柔軟な組み立てプロセスを実現しました。 完全にバージョン管理されたコンテナーの構築には同じツールを使用します。 

ビルド手順の仕組み

アセンブリは XNUMX つのコマンドで起動され、イメージ内でプロセスが実行されます (赤で強調表示されています)。 開発者は Docker ファイル (黄色で強調表示) を持っているので、それをレンダリングして、変数を値に置き換えます。 そして、その過程でヘッダーとフッターを追加します - これらは私たちのエージェントです。 

ヘッダーは、対応する画像からのディストリビューションを追加します。 そしてフッターは内部にサービスをインストールし、ワークロード、ロギング、その他のエージェントの起動を構成し、エントリポイントを置き換えます。 

私たちはスーパーバイザーを設置するかどうか長い間考えました。 結局、私たちは彼が必要だと判断しました。 私たちはS6を選びました。 スーパーバイザはコンテナ管理を提供します。メイン プロセスがクラッシュした場合に接続できるようになり、コンテナを再作成せずに手動で管理できます。 ログとメトリクスは、コンテナ内で実行されるプロセスです。 また、何らかの方法で制御する必要がありますが、これはスーパーバイザーの助けを借りて行われます。 最後に、S6 はハウスキーピング、信号処理、その他のタスクを処理します。

さまざまなオーケストレーション システムを使用するため、構築して実行した後、コンテナーは自分がどのような環境にあるかを理解し、状況に応じて動作する必要があります。 例えば：
これにより、XNUMX つのイメージを構築して、それをさまざまなオーケストレーション システムで実行できるようになり、このオーケストレーション システムの詳細を考慮して起動されます。

 

同じコンテナに対して、Docker と Kubernetes では異なるプロセス ツリーが得られます。

ペイロードは S6 の監視下で実行されます。 コレクターとイベントに注意してください。これらはログとメトリックを担当するエージェントです。 Kubernetes にはそれらがありませんが、Docker にはあります。 なぜ？ 

「ポッド」（以下、Kubernetes ポッド）の仕様を見ると、イベント コンテナがポッド内で実行され、ポッドにはメトリクスとログを収集する機能を実行する別個のコレクタ コンテナがあることがわかります。 Kubernetes の機能を使用して、XNUMX つのポッド、単一プロセス、および/またはネットワーク空間でコンテナーを実行できます。 実際にエージェントを紹介し、いくつかの機能を実行します。 また、同じコンテナが Docker で起動される場合、エージェントは内部で起動されるため、すべて同じ機能を出力として受け取ります。つまり、ログとメトリクスを配信できます。 

メトリクスとログ

メトリクスとログの配信は複雑なタスクです。 彼女の決断にはいくつかの側面があります。
インフラストラクチャはペイロードの実行のために作成されており、ログの大量配信のために作成されません。 つまり、このプロセスは最小限のコンテナー リソース要件で実行する必要があります。 私たちは開発者を支援するよう努めています。「Docker Hub コンテナを取得して実行すれば、ログを配信できます。」 

XNUMX 番目の側面は、ログの量を制限することです。 複数のコンテナでログ量の急増が発生した場合（アプリケーションがスタック トレースをループで出力する場合）、CPU、通信チャネル、ログ処理システムの負荷が増加し、ホストの動作に影響を与えます。ホスト上のコンテナ全体と他のコンテナが破損した場合、これがホストの「フォール」につながる場合があります。 

XNUMX 番目の側面は、すぐに使用できるメトリクス収集方法をできるだけ多くサポートする必要があるということです。 ファイルの読み取りと Prometheus エンドポイントのポーリングから、アプリケーション固有のプロトコルの使用まで。

そして最後の側面は、リソースの消費を最小限に抑えることです。

私たちは、Telegraf と呼ばれるオープンソースの Go ソリューションを選択しました。 140種類以上のインプットチャンネル（インプットプラグイン）と30種類以上の出力チャンネル（アウトプットプラグイン）に対応したユニバーサルコネクターです。 これが完成したので、Kubernetes を例として使用する方法を説明します。 

開発者がワークロードをデプロイし、Kubernetes がポッドを作成するリクエストを受信したとします。 この時点で、Collector と呼ばれるコンテナーがポッドごとに自動的に作成されます (ミューテーション Webhook を使用します)。 コレクターは当社の代理店です。 最初に、このコンテナは Prometheus およびログ収集システムと連携するように自体を構成します。

• これを行うために、Pod アノテーションを使用し、その内容に応じて、たとえば Prometheus エンドポイントを作成します。 
• ポッドの仕様と特定のコンテナー設定に基づいて、ログの配信方法を決定します。

Docker API を介してログを収集します。開発者はログを stdout または stderr に置くだけで、Collector がログを分類します。 ホストの過負荷を防ぐために、ログはある程度の遅延を伴ってチャンクとして収集されます。 

メトリクスは、コンテナ内のワークロード インスタンス (プロセス) 全体で収集されます。 すべてに名前空間、下などのタグが付けられ、Prometheus 形式に変換され、収集できるようになります (ログを除く)。 また、ログ、メトリクス、イベントを Kafka に送信し、さらに次のことも行います。

• ログは Graylog で利用できます (視覚的分析用)。
• ログ、メトリクス、イベントは長期保存のために Clickhouse に送信されます。

AWS ではすべてがまったく同じように機能します。ただし、Graylog を Kafka と Cloudwatch に置き換えるだけです。 そこにログを送信すると、すべてが非常に便利であることがわかりました。ログがどのクラスターとコンテナーに属しているかがすぐにわかります。 Google Stackdriver についても同様です。 つまり、私たちのスキームは、Kafka を使用したオンプレミスとクラウドの両方で機能します。 

ポッドを備えた Kubernetes がない場合、スキームは少し複雑になりますが、同じ原理で機能します。

同じプロセスがコンテナ内で実行され、S6 を使用して調整されます。 すべて同じプロセスが同じコンテナ内で実行されます。

結果として、

私たちは、ログとメトリクスを収集および配信するためのオプションを備えた、イメージの構築と起動のための完全なソリューションを作成しました。

• 私たちは画像を組み立てるための標準化されたアプローチを開発し、それに基づいて CI テンプレートを開発しました。
• データ収集エージェントは、Telegraf 拡張機能です。 私たちは実稼働環境でそれらを十分にテストしました。
• ミューテーション Webhook を使用して、ポッド内のエージェントを含むコンテナーを実装します。 
• Kubernetes/Rancher エコシステムに統合されています。
• 同じコンテナを異なるオーケストレーション システムで実行すると、期待どおりの結果が得られます。
• 完全に動的なコンテナ管理構成を作成しました。 

共著者: イリヤ・プルドニコフ

出所： habr.com