こんにちは、みんな！ 私の名前はパベル・アガレツキーです。 私は Lamoda 配信システムを開発するチームのチームリーダーとして働いています。 2018 年に私は HighLoad++ カンファレンスで講演しましたが、今日はそのレポートの書き起こしを紹介したいと思います。

私のトピックは、さまざまな環境へのシステムとサービスの導入における当社の経験に特化しています。 すべてのシステムを通常の仮想サーバーにデプロイした先史時代から始まり、Nomad から Kubernetes でのデプロイへの段階的な移行で終わりました。 なぜそれを行ったのか、そしてその過程でどのような問題があったのかを説明します。

アプリケーションを VM にデプロイする

3 年前、会社のすべてのシステムとサービスが通常の仮想サーバーに展開されていたという事実から始めましょう。 技術的には、システムのすべてのコードが保管され、Jenkins を使用した自動アセンブリ ツールを使用して組み立てられるように編成されていました。 Ansible を使用して、バージョン管理システムから仮想サーバーに展開されました。 さらに、当社が所有していた各システムは少なくとも 2 台のサーバーにデプロイされており、そのうちの XNUMX 台は先頭に、もう XNUMX 台は末尾にありました。 これら XNUMX つのシステムは、すべての設定、電源、構成などにおいてまったく同一でした。 両者の唯一の違いは、head はユーザー トラフィックを受信するのに対し、tail はユーザー トラフィックをまったく受信しないことです。

なぜこれが行われたのですか？

アプリケーションの新しいリリースをデプロイするときは、シームレスなロールアウト、つまりユーザーに目立った影響を与えることなくロールアウトできるようにしたいと考えていました。 これは、Ansible を使用してコンパイルされた次のリリースが末尾にロールアウトされたという事実によって達成されました。 そこで、展開に関わった人々は、すべてが正常であることを確認し、すべてのメトリクス、セクション、アプリケーションが機能していることを確認できました。 必要なスクリプトが起動されます。 すべてが正常であると確信した後でのみ、トラフィックが切り替えられました。 以前は末尾だったサーバーにアクセスし始めました。 そして、以前にヘッドだったものは、アプリケーションの以前のバージョンが残ったまま、ユーザー トラフィックなしのままでした。

そのため、ユーザーにとってはシームレスでした。 バランサーを切り替えるだけなので切り替えは瞬時です。 バランサーを元に戻すだけで、非常に簡単に以前のバージョンにロールバックできます。 また、ユーザー トラフィックを受信する前でもアプリケーションが運用可能であることを確認できたので、非常に便利でした。

これらすべてにどのような利点があることがわかりましたか?

1. まずはそれで十分です それはちょうどうまくいきます。 ほとんどの人は通常の仮想サーバーに展開したことがあるため、このような展開スキームがどのように機能するかを誰もが理解しています。
2. これで十分です 確実に、導入テクノロジーがシンプルであり、何千もの企業によってテストされているためです。 数百万台のサーバーがこの方法で導入されています。 何かを壊すのは難しいです。
3. そしてついに手に入れることができました アトミック展開。 古いバージョンと新しいバージョンの間で目立った切り替えを行わずに、ユーザーに対して同時に行われる展開。

しかし、これらすべてにはいくつかの欠点もありました。

1. 本番環境、開発環境に加えて、その他の環境もあります。 たとえば、QA やプリプロダクションなどです。 当時、多くのサーバーと約 60 のサービスがありました。 このために必要だった 各サービスの最新バージョンを維持する 仮想マシン。 さらに、ライブラリを更新したり、新しい依存関係をインストールしたりする場合は、すべての環境でこれを行う必要があります。 また、アプリケーションの次の新しいバージョンをデプロイする時刻と、devops が必要な環境設定を実行する時刻を同期する必要もありました。 この場合、すべての環境で一度に環境が多少異なるという状況に陥りやすくなります。 たとえば、QA 環境にはいくつかのバージョンのライブラリがあり、運用環境には異なるバージョンが存在するため、問題が発生します。
2. 依存関係の更新が難しい あなたの申請。 それはあなた次第ではなく、他のチーム次第です。 つまり、サーバーを保守する Devops チームからのものです。 彼らに適切なタスクと、あなたがやりたいことの説明を与える必要があります。
3. 当時、私たちは、今後さらに多くのサービスが存在することを理解していたため、所有していた大きなモノリスを個別の小さなサービスに分割したいと考えていました。 当時、すでに 100 を超える仮想マシンが存在しており、新しいサービスごとに個別の新しい仮想マシンを作成する必要があり、その仮想マシンの保守と展開も必要でした。 さらに、車はXNUMX台ではなく、少なくともXNUMX台必要です。 これらすべてに QA 環境が追加されます。 これにより問題が発生し、新しいシステムを構築して実行することがより困難になります。 複雑で高価で時間のかかるプロセス。

したがって、通常の仮想マシンのデプロイから、Docker コンテナーでのアプリケーションのデプロイに移行する方が便利であると判断しました。 docker を使用している場合は、コンテナーを起動するだけではできないため、クラスター内でアプリケーションを実行できるシステムが必要です。 通常、コンテナが自動的に持ち上げられるように、持ち上げられたコンテナの数を追跡する必要があります。 このため、制御方式の選定が必要でした。

私たちはどれを採用できるか長い間考えました。 実際のところ、当時、通常の仮想サーバー上のこのデプロイメント スタックは、最新バージョンのオペレーティング システムを搭載していなかったために、やや時代遅れでした。 ある時点では、サポートするのがあまり便利ではなかった FreeBSD さえありました。 できるだけ早く Docker に移行する必要があることを理解しました。 私たちの開発担当者は、さまざまなソリューションの既存の経験を検討し、Nomad のようなシステムを選択しました。

ノマドに切り替える

Nomad は HashiCorp の製品です。 彼らは他のソリューションでも知られています。

"領事" サービス発見のためのツールです。

「テラフォーム」 - 構成を通じてサーバーを構成できるサーバー管理システム、いわゆるコードとしてのインフラストラクチャ。

「浮浪者」 特定の構成ファイルを使用して、仮想マシンをローカルまたはクラウドにデプロイできます。

当時の Nomad は、インフラストラクチャ全体を変更せずにすぐに切り替えられる、かなりシンプルなソリューションのように見えました。 さらに、学習は非常に簡単です。 それが、コンテナの濾過システムとしてこれを選択した理由です。

システムを Nomad にデプロイするには何が必要ですか?

1. まず最初に必要なのは Dockerイメージ あなたの申請。 これをビルドして、Docker イメージ リポジトリに配置する必要があります。 私たちの場合、これはアーティファクト、つまりさまざまなタイプのさまざまなアーティファクトをプッシュできるシステムです。 アーカイブ、Docker イメージ、Composer PHP パッケージ、NPM パッケージなどを保存できます。
2. こちらも必要 設定ファイルこれにより、Nomad に何を、どこに、どのくらいの量で展開するかを指示します。

Nomad について話すとき、Nomad は情報ファイル形式として HCL 言語を使用します。 HashiCorp 構成言語。 これは、Nomad の用語でサービスを説明できるようにする Yaml のスーパーセットです。

これにより、デプロイするコンテナーの数、デプロイメント中にどのイメージからさまざまなパラメーターを渡すかを指定できます。 したがって、このファイルを Nomad にフィードすると、そのファイルに従ってコンテナが実稼働環境に起動されます。

私たちの場合、サービスが多数あり、場合によってはそれらを更新する必要があるため、サービスごとに完全に同一の HCL ファイルを単純に記述するだけではあまり便利ではないことがわかりました。 100 つのサービスが XNUMX つのインスタンスではなく、さまざまなインスタンスにデプロイされることがあります。 たとえば、運用環境にあるシステムの XNUMX つは、運用環境に XNUMX を超えるインスタンスがあります。 これらは同じイメージから実行されますが、構成設定と構成ファイルが異なります。

したがって、デプロイメント用のすべての構成ファイルを XNUMX つの共通リポジトリに保存すると便利であると判断しました。 こうすることで、それらが見えるようになり、メンテナンスが簡単になり、どのようなシステムがあるのか​​を確認することができました。 必要に応じて、何かを更新したり変更したりすることも簡単です。 新しいシステムの追加も難しくありません。新しいディレクトリ内に構成ファイルを作成するだけです。 その中には、サービスの説明が含まれる service.hcl と、運用環境にデプロイされるこのサービスを構成できるようにするいくつかの env ファイルがあります。

ただし、一部のシステムは実稼働環境に XNUMX つのコピーではなく、一度に複数のコピーで展開されます。 したがって、構成を純粋な形式ではなく、テンプレート化された形式で保存すると便利であると判断しました。 そして私たちが選んだのは 神社2。 この形式では、サービス自体の構成とサービスに必要な環境ファイルの両方が保存されます。

さらに、すべてのプロジェクトに共通のデプロイメント スクリプトをリポジトリに配置しました。これにより、サービスを実稼働環境、目的の環境、目的のターゲットに起動してデプロイできるようになります。 HCL 構成をテンプレートに変えると、以前は通常の Nomad 構成だった HCL ファイルが少し違って見えるようになりました。

つまり、一部の構成場所変数を、env ファイルまたは他のソースから取得した挿入変数に置き換えました。 さらに、HCL ファイルを動的に収集する機会も得られました。つまり、通常の変数挿入だけでなく、使用することもできます。 jinja はループと条件をサポートしているため、そこに構成ファイルを作成することもできます。構成ファイルは、アプリケーションを正確にデプロイする場所に応じて変更されます。

たとえば、サービスを実稼働前と実稼働にデプロイしたいとします。 実稼働前では、cron スクリプトを実行したくないが、サービスが機能していることを確認するために別のドメインでサービスを確認したいだけだとします。 サービスをデプロイする人にとって、プロセスは非常にシンプルかつ透明に見えます。 必要なのは、deploy.sh ファイルを実行し、デプロイするサービスとターゲットを指定することだけです。 たとえば、特定のシステムをロシア、ベラルーシ、またはカザフスタンに導入するとします。 これを行うには、パラメーターの XNUMX つを変更するだけで、正しい構成ファイルが作成されます。

Nomad サービスがすでにクラスターにデプロイされている場合は、次のようになります。

まず、すべてのユーザー トラフィックを受信する、何らかのバランサーが外部に必要です。 Consul と連携して、特定のドメイン名に対応する特定のサービスが、どのノードのどの IP アドレスにあるのかを調べます。 Consul のサービスは Nomad 自体から来ています。 これらは同じ会社の製品なので、相互に関連性があります。 Nomad はそのままの状態で、そこで起動されたすべてのサービスを Consul 内に登録できると言えます。

フロントエンド ロード バランサーは、トラフィックの送信先サービスを認識すると、アプリケーションに一致する適切なコンテナーまたは複数のコンテナーにトラフィックを転送します。 当然、安全性への配慮も必要です。 すべてのサービスがコンテナ内の同じ仮想マシン上で実行されているとしても、これには通常、どのサービスから他のサービスへも自由にアクセスできないようにする必要があります。 私たちはセグメンテーションによってこれを実現しました。 各サービスは独自の仮想ネットワーク内で起動され、その仮想ネットワーク上でルーティング ルールや、他のシステムやサービスへのアクセスを許可/拒否するルールが規定されています。 それらは、このクラスターの内部と外部の両方に存在する可能性があります。 たとえば、サービスが特定のデータベースに接続できないようにしたい場合は、ネットワーク レベルのセグメンテーションを通じてこれを行うことができます。 つまり、たとえ間違っても、テスト環境から運用データベースに誤って接続することはできません。

この移行により人的資源の面でどれくらいのコストがかかりましたか?

会社全体の Nomad への移行には約 5 ～ 6 か月かかりました。 私たちはサービスごとに移行しましたが、かなり速いペースで進みました。 各チームはサービス用に独自のコンテナを作成する必要がありました。

各チームが独自にシステムの Docker イメージを担当するアプローチを採用しました。 DevOps は、展開に必要な一般的なインフラストラクチャ、つまりクラスター自体のサポート、CI システムのサポートなどを提供します。 当時、60 を超えるシステムが Nomad に移行され、その数は約 2 コンテナに達しました。

Devops は、展開とサーバーに関連するすべてのインフラストラクチャ全般を担当します。 そして、各開発チームは、特定のコンテナに一般的に何が必要かを知っているため、その特定のシステムにコンテナを実装する責任を負います。

ノマドをやめた理由

Nomad や docker などを使用したデプロイメントに切り替えることで、どのようなメリットが得られましたか?

1. 我々 同等の条件を提供した あらゆる環境に。 開発、QA 環境、実稼働前、実稼働では、同じ依存関係を持つ同じコンテナー イメージが使用されます。 したがって、本番環境で最終的に作成されるものが、以前にローカルまたはテスト環境でテストしたものと異なる可能性は事実上ありません。
2. それで十分であることもわかりました 新しいサービスを簡単に追加できる。 導入の観点から見ると、新しいシステムは非常に簡単に起動できます。 構成を保存するリポジトリに移動し、そこにシステムの別の構成を追加するだけで準備は完了です。 Devops による追加の労力を必要とせずに、システムを実稼働環境にデプロイできます。
3. すべて 設定ファイル XNUMX つの共通リポジトリ内で 検討中であることが判明した。 仮想サーバーを使用してシステムをデプロイしたときは、構成が同じリポジトリにあった Ansible を使用していました。 ただし、ほとんどの開発者にとって、これは少し作業が困難でした。 ここでは、サービスをデプロイするために追加する必要がある構成とコードの量が大幅に減りました。 さらに、DevOps がそれを修正または変更するのは非常に簡単です。 たとえば、Nomad の新しいバージョンに移行する場合、同じ場所にあるすべてのオペレーティング ファイルを取得して一括更新できます。

しかし、いくつかの欠点にも遭遇しました。

判明したのは、 シームレスな導入を実現できなかった ノマドの場合。 さまざまな条件でコンテナをロールアウトすると、コンテナが実行中であることが判明する可能性があり、Nomad はそれをトラフィックを受信する準備ができているコンテナとして認識しました。 これは、内部のアプリケーションが起動する前に発生しました。 このため、まだトラフィックを受け入れる準備ができていないコンテナにトラフィックが送信され始めたため、システムは短期間で 500 エラーを生成し始めました。

私たちはいくつかに遭遇しました 沼によって。 最も重大なバグは、多数のシステムとコンテナがある場合、Nomad が大規模なクラスターをうまく処理できないことです。 Nomad クラスターに含まれるサーバーの XNUMX つをメンテナンスのために取り外したい場合、かなりの確率でクラスターの調子が悪く、崩壊してしまいます。 たとえば、一部のコンテナは落下して上昇しない可能性があります。すべての運用システムが Nomad によって管理されるクラスタ内に配置されている場合、これにより後々大きなコストがかかります。

そこで、次にどこに行くべきかを考えることにしました。 その時点で、私たちは自分たちが何を達成したいのかをよりよく認識するようになりました。 つまり、信頼性、Nomad が提供する機能よりももう少し多くの機能、そしてより成熟した、より安定したシステムが必要です。

この点で、私たちはクラスターを起動するための最も人気のあるプラットフォームとして Kubernetes を選択しました。 特に、コンテナのサイズと数が十分に大きかったことを考慮すると。 このような目的には、Kubernetes が検討できる最も適したシステムであると考えられました。

Kubernetes への移行

Kubernetes の基本概念と Nomad との違いについて少し説明します。

まず、Kubernetes の最も基本的な概念はポッドの概念です。 ポッド 常に一緒に実行される 127.0.0.1 つ以上のコンテナのグループです。 そして、それらは常に XNUMX つの仮想マシン上で厳密に動作するかのように動作します。 これらは、異なるポート上の IP XNUMX を介して相互にアクセスできます。

nginx と php-fpm (古典的なスキーム) で構成される PHP アプリケーションがあると仮定しましょう。 おそらく、nginx コンテナと php-fpm コンテナの両方を常に一緒に保持しておきたいと思うでしょう。 Kubernetes では、これらを XNUMX つの共通のポッドとして記述することでこれを実現できます。 これはまさに Nomad では実現できなかったことです。

二つ目のコンセプトは、 展開。 実際のところ、ポッド自体は一時的なものであり、始まっては消えます。 最初に以前のコンテナをすべて強制終了してから、新しいバージョンを一度に起動しますか? それとも、段階的にロールアウトしますか? これは、デプロイメントの概念が担当するプロセスです。 ポッドをデプロイする方法、数量、更新方法について説明します。

XNUMXつ目のコンセプトは、 サービス。 サービスは実際にはシステムであり、トラフィックを受信し、それをサービスに対応する XNUMX つ以上のポッドに転送します。 つまり、これこれの名前を持つこれこれのサービスへのすべての受信トラフィックをこれらの特定のポッドに送信する必要があると指定できます。 同時にトラフィックのバランシングも実現します。 つまり、アプリケーションの XNUMX つのポッドを起動でき、すべての受信トラフィックはこのサービスに関連するポッド間で均等に分散されます。

そしてXNUMXつ目の基本コンセプトは、 進入。 これは、Kubernetes クラスター上で実行されるサービスです。 すべてのリクエストを引き継ぐ外部ロード バランサーとして機能します。 Kubernetes API を使用して、Ingress はこれらのリクエストの送信先を決定できます。 しかも、彼はこれを非常に柔軟にやってくれます。 このホストおよびこれこれの URL へのすべてのリクエストがこのサービスに送信されると言えます。 そして、このホストおよび別の URL に送信されるこれらのリクエストは、別のサービスに送信されます。

アプリケーションを開発する人の観点から見て、最も素晴らしいことは、アプリケーションをすべて自分で管理できることです。 Ingress 構成を設定すると、これこれの API に来るすべてのトラフィックを、たとえば Go で作成された別のコンテナーに送信できます。 しかし、同じドメインに来るが別の URL に来るこのトラフィックは、PHP で書かれたコンテナに送信される必要があります。PHP には多くのロジックがありますが、それほど高速ではありません。

これらすべての概念を Nomad と比較すると、最初の XNUMX つの概念はすべてサービスであると言えます。 そして最後の概念は Nomad 自体には存在しません。 外部バランサーを使用しました。これには、haproxy、nginx、nginx+ などが使用できます。 キューブの場合、この追加の概念を個別に導入する必要はありません。 ただし、Ingress を内部的に見ると、それは nginx、haproxy、または traefik のいずれかですが、一種の Kubernetes に組み込まれています。

私が説明したすべての概念は、実際には、Kubernetes クラスター内に存在するリソースです。 キューブ内でそれらを記述するには、Nomad の場合、HCL ファイルよりも読みやすく親しみやすい yaml 形式が使用されます。 しかし、構造的には、たとえばポッドの場合でも同じことを説明します。 彼らはこう言います - 私は、これこれのポッドを、これこれのイメージとともに、これこれの量でデプロイしたいと考えています。

さらに、デプロイメント、サービス、Ingress などの個々のリソースを手動で作成したくないことに気付きました。 代わりに、必要なリソースの依存関係をすべて正しい順序で手動で再作成する必要がないように、展開中に各システムを Kubernetes の観点から説明したいと考えました。 これを可能にするシステムとして Helm が選ばれました。

Helm の基本概念

ヘルムは パッケージマネージャー Kubernetesの場合。 これは、プログラミング言語のパッケージ マネージャーの仕組みとよく似ています。 これらにより、たとえば、nginx のデプロイメント、php-fpm のデプロイメント、Ingress の構成、configmaps (システムの環境やその他のパラメーターを設定できるエンティティ) で構成されるサービスを、次の形式で保存できます。チャートと呼ばれます。 同時にヘルム Kubernetes 上で動作する。 つまり、これは脇に置かれたある種のシステムではなく、キューブ内で起動される別のサービスにすぎません。 コンソール コマンドを介して API を介して操作します。 その利便性と利点は、たとえヘルムが壊れたりクラスターから削除したとしても、ヘルムは本質的にシステムを起動するだけの役割を果たすため、サービスが消えないことです。 Kubernetes 自体がサービスのパフォーマンスと状態に責任を負います。

私たちもそれを実感しました テンプレート化これは、以前は構成に jinja を導入することで自分で行う必要がありましたが、これは helm の主な機能の XNUMX つです。 システム用に作成したすべての構成は、テンプレートの形式で Helm に保存されます。これは jinja に少し似ていますが、実際には、Kubernetes などの Helm が記述される Go 言語のテンプレートを使用します。

Helm はさらにいくつかの概念を追加します。

チャート - これはサービスの説明です。 他のパッケージ マネージャーでは、パッケージ、バンドル、または同様のものと呼ばれます。 ここではそれをチャートと呼びます。

価値観 は、テンプレートから構成を構築するために使用する変数です。

リリース。 Helm を使用してデプロイされたサービスがリリースの増分バージョンを受け取るたびに。 Helm は、前のリリースやその前のリリースなどのサービス構成を覚えています。 したがって、ロールバックする必要がある場合は、helm コールバック コマンドを実行して、以前のリリース バージョンを指定するだけです。 ロールバック時にリポジトリ内の対応する構成が利用できない場合でも、helm はその構成を記憶しており、システムを以前のリリースの状態にロールバックします。

Helm を使用する場合、Kubernetes の通常の構成も、変数、関数を使用し、条件ステートメントを適用できるテンプレートに変わります。 この方法で、環境に応じてサービス構成を収集できます。

実際には、Nomad の場合とは少し異なる方法で物事を行うことにしました。 Nomad では、サービスのデプロイに必要なデプロイメント構成と n 変数の両方が XNUMX つのリポジトリに保存されていた場合、ここではそれらを XNUMX つの別個のリポジトリに分割することにしました。 「deploy」リポジトリにはデプロイメントに必要な n 変数のみが保存され、「helm」リポジトリには構成またはチャートが保存されます。

これは私たちに何をもたらしたのでしょうか？

にもかかわらず、構成ファイル自体には本当に機密データは保存されません。 たとえば、データベースのパスワードなどです。 これらは Kubernetes にシークレットとして保存されますが、それでも、誰にでもアクセスできるようにしたくないものもあります。 したがって、「deploy」リポジトリへのアクセスはより制限されており、「helm」リポジトリにはサービスの説明が含まれるだけです。 そのため、より幅広い方に安心してご利用いただけます。

運用環境だけでなく他の環境も存在するため、この分離のおかげで、ヘルム チャートを再利用して、運用環境だけでなく、たとえば QA 環境にもサービスをデプロイできます。 を使用してローカルにデプロイすることもできます Minikube - これは Kubernetes をローカルで実行するためのものです。

各リポジトリ内では、サービスごとに個別のディレクトリに分割を残しました。 つまり、各ディレクトリ内には、対応するチャートに関連し、システムを起動するためにデプロイする必要があるリソースを説明するテンプレートがあります。 「deploy」リポジトリには env のみを残しました。 この場合、jinja を使用したテンプレートは使用しませんでした。これは、helm 自体がすぐに使えるテンプレートを提供するためです。これは、helm の主な機能の XNUMX つです。

デプロイメント スクリプト、deploy.sh を残しました。これは、helm を使用したデプロイメントの起動を簡素化し、標準化します。 そのため、デプロイを希望する人にとって、デプロイ インターフェイスは Nomad 経由でデプロイしたときとまったく同じに見えます。 同じdeploy.sh、サービスの名前、およびそれをデプロイする場所。 これにより、helm が内部で起動します。 次に、テンプレートから構成を収集し、必要な値ファイルをそれらに挿入してからデプロイして、Kubernetes に起動します。

所見

Kubernetes サービスは Nomad よりも複雑であるようです。

ここで、送信トラフィックが Ingress に送信されます。 これは単なるフロント コントローラーであり、すべてのリクエストを引き継ぎ、その後リクエスト データに対応するサービスにリクエストを送信します。 これらは、helm 内のアプリケーションの説明の一部であり、開発者が独自に設定した構成に基づいて決定されます。 サービスはリクエストをそのポッド、つまり特定のコンテナーに送信し、このサービスに属するすべてのコンテナー間で受信トラフィックのバランスをとります。 そしてもちろん、ネットワーク レベルのセキュリティから離れるべきではないことを忘れてはなりません。 したがって、セグメンテーションはタグ付けに基づいた Kubernetes クラスターで機能します。 すべてのサービスには特定のタグがあり、クラスタ内外の特定の外部/内部リソースに対するサービスのアクセス権が関連付けられています。

移行を進めていくと、Kubernetes には以前使用していた Nomad のすべての機能があり、さらに多くの新しい機能も追加されていることがわかりました。 これはプラグインを通じて拡張でき、実際にはカスタム リソース タイプを通じて拡張できます。 つまり、Kubernetes に付属しているものをそのまま使用するだけでなく、独自のリソースやリソースを読み取るサービスを作成する機会もあります。 これにより、Kubernetes を再インストールしたり、変更を加えたりすることなく、システムを拡張するための追加のオプションが提供されます。

そのような使用例としては、Kubernetes クラスター内で実行される Prometheus があります。 特定のサービスからメトリクスの収集を開始するには、追加のタイプのリソース、いわゆるサービス モニターをサービスの説明に追加する必要があります。 Prometheus は、Kubernetes での起動時にカスタム リソース タイプを読み取ることができるため、新しいシステムから自動的にメトリクスの収集を開始します。 とても便利です。

Kubernetes への最初のデプロイは 2018 年 3000 月でした。 この間、私たちはそれに関して何の問題も経験しませんでした。 重大なバグもなく非常に安定して動作します。 さらに、それをさらに拡張することもできます。 現在、私たちは Kubernetes の機能を十分に備えており、Kubernetes の開発のペースを非常に気に入っています。 現在、XNUMX を超えるコンテナが Kubernetes に存在します。 クラスターは複数のノードを占有します。 同時に、保守性が高く、安定しており、非常に制御可能です。

出所： habr.com