エンボイをフロントエッジプロキシとして使用し、着信トラフィックを複数のkubernetesクラスター（新しいサービス用）および歴史的遺産のレガシーアーキテクチャのバックエンドにリダイレクトします。それら。通常のバランサーとSSLターミネーションポイントの両方の機能とAPIゲートウェイを組み合わせたものです。
使節の前は、他の多くの人と同じように、そこにnginxがありました。かっこいいソフトウェア、私はそれが好きです。エンボイの全体像は、マイクロサービスが大量に開始された瞬間に始まり、ansibleテンプレートでさえ、nginx構成の管理に費やされる時間の増加からあなたを救うことはできませんでした。展開には長い時間がかかりました。さらに、管理者は「新しいサービスのドメインを取得してください」などの単調なリクエストを思いとどまらせていました。 Better™の自動化が明らかに必要でした。理想的には、何かを開始する必要がある人が自分で、できればサービスの他のパラメーターを構成したのと同じ場所でそれを実行できるようにします。さらに、フロントプロキシ内、およびフロントプロキシとアップストリームの間のセグメントで発生することの透明性を高め、ネイティブバランシング機能（さまざまなタイプの繰り返し要求、特定の条件下での異常なホストの除外、ヘルプチェック）を強化したいと考えました。そして魅力的なエッジテクノロジー、もちろん。
簡単に言えば、 Dropboxからエンボイへの移行に関する記事の翻訳です。nginxとの比較について多くの詳細があります。移行結果の個人的な印象について詳しく説明します。
スケーラブルなソフトウェアの使用に出くわした人にとって最も重要で明白な事実：それを支払う準備をしてください。セットアップの複雑さが増し（データプレーン+コントロールプレーン）、kubernetesだけでなくアップストリームがある場合は、独自のコントロールプレーンを作成することもできます。また、特にエンボイの場合、ソフトウェアの相対的な若さのため、したがっていくつかの一般的なnginx機能がないため+これらの機能が追加された場合、更新の頻度が高くなります。たとえば、標準オプションでは、パス、ホストヘッダーからのポートの削除、または正規表現による書き換えなど、スラッシュを組み合わせたnginxのデフォルトがないことが判明する場合があります。今日、このリストのすべてがすでに追加されていますが、きっと他のものが見つかるでしょう。
ポジティブなこと
ひどいドキュメント！良い面として、使節チームは昨年末にようやくテクニカルライターを雇い、物事はずっと友好的になりました。少なくとも、ソースコードを介してリクエストを処理する方法を研究し、問題の回答だけでいくつかのオプションの作業の説明を見つける必要はありません。そして、オプション自体を見つけるには、レベル80のグーグルマスターになります。現在、これの多くは過去のものですが、著者は、このまたはそのオプションがどのバージョンの使節に登場したか、またはリリースノートの問題へのリンクによってマークすることをまだ気にしませんが、少なくとも彼らはリストを強調し始めました専用のセクションでリリースの変更を壊すと、進歩があることがわかります。
拡張テレメトリ
ここですべての希望が正当化されました。現在、使節による私たちのgrafanaダッシュボードは、多数のグラフが用意されていないすべてのブラウザーを強制終了します。しかし、真剣に、今あなたはその通過のすべての段階で交通で何が起こっているかを便利に監視することができます、それは刺激的な探偵小説-事件後の調査で特によく役立ちます。そしてもちろん、異常の定義。
異常：「こんにちは」同じ使節グラファナダッシュボードからのフラグメント。
コントロールプレーン
さて、そして最も重要なことに、すべてが開始されたために、自動ルート制御の問題を解決しました。誰かが対象にいない場合のアプローチについての2つの言葉：コントロールプレーンはデータコントローラーとして機能し、ストレージを管理して構成を作成し、それがエンボイ（ステートレスデータプレーン）に送信されます。
バックエンドとしてkubernetesが1つしかない場合は、アンバサダータイプの既製のコントロールプレーンを使用できます。しかし、古いインフラストラクチャも管理する必要があり、さらにいくつかのクラスターがありました。そのため、エンボイプロジェクトによって提案されたデータプレーンAPI実装のいずれかを使用して、必要なすべての機能を台無しにし、インフラストラクチャのこの部分をkubernetesの自動化に接続する必要がありましたが、これは別の興味深い話のトピックです。
使節に切り替える過程からの印象-「何らかの理由で特別な問題はなく、非常に疑わしい」。
要するに、どこから始めて、何をすぐに準備するかです。使節のドキュメントについて瞑想し、存在の無益さを受け入れた後、古いフロントプロキシから2つの仮想ホスト（最も単純で最も典型的で最も広範囲）を取得し、使節で開始し、途中でオプションを分類します。
ここで覚えておくべき主なことは、nginxとenvoyの間で構成を作成するアプローチが非常に異なることです。フォームの急激な変化に備える必要があります。2つの単純な許可/拒否エントリの代わりに、26行のRBACルールツリーを記述します。一般に、ここで少し爆発する頭を受け入れるのは正常です。なぜなら、使節の構成は、人間の読みやすさではなく、自動化の利便性を優先して行われるからです。
オプションマッピング用のチートシートをまとめて、実際に自分が思っていることを実行していることを確認する必要がある場合があります。そのため、URLでスラッシュを組み合わせるメカニズムは（すでにエンボイに追加されている場合でも）異なる動作をするという結論に達しました。nginxでは変更されませんでした。アップストリームに送信されたパスと、エンボイでは完全なパスです。書き直しが行われ、すべてがうまくいくでしょうが、この書き直しで、変更されたバグが出てきました：ゲームへの完全なパス、まあ、一般的に、私たちの問題の後、それも修正されましたが、注意してください。
ちなみに、問題点については、もう一つ前向きな印象を述べざるを得ません。
フレンドリーなコミュニティと開発者
エンボイはCNCFがホストするオープンソースであるため、従来はプロジェクトのGitHubにアクセス して、改善を提案したり、質問したりできます。問題は非常に多く、開発者には明らかに十分な手がありませんが、同時に、あなたの質問に起こりうる最悪の事態は、それが無視されることです。ほとんどの場合、少なくとも何かがありますが、「申し訳ありませんが、これを行う予定はありません」という精神で短いものであっても、彼らは答えます。初心者からの質問でも毒性はなく、とてもフレンドリーな雰囲気。
雰囲気のあるトピック、特にコーギー。 github.comのエンボイパブリックリポジトリのスクリーンショット
さて、いつものように-プルリクエストは大歓迎です。 C ++が特に得意でない人にも役立ちます。初心者タグでマークされた問題もいくつかあります 、誰かが貢献したいと思っていて、どこから始めればよいかわからない場合に備えて。
GitHubに加えて、メールマガジンやスラックもありますが、後者はより多くの場合混乱します。:)
イベントの中で、EnvoyConが開催されていますが、現在はオンラインですが、それでもお勧めします。
結果
一般的に、トレンディで若々しく、「誰もが乗り越え」、創設者の髪型がおかしいという理由だけで、使節は必要ありません。それが圧迫されるまで、あなたがいた場所にとどまります。スタートアップや小さなプロジェクトがある場合は、シンプルでかわいいので、nginxを残すことをお勧めします。主なことはそこから始めることです。
多くのサービス、多くの開発者、kubernetesがあり、上記の記事のすべてのトレードオフは気になりません-考えて試すことができます。
頑張って、EnvoyConでお会いしましょう！