Istio でのダーク ローンチ: シークレット サービス

「危険は私のミドルネームだ」と国際的な謎の男、オースティン・パワーズはよく言っていた。 しかし、スーパーエージェントや諜報機関によって高く評価されているものは、危険よりも退屈のほうがはるかに優れているコンピューターサービスにはまったく適していません。

そして、Istio を OpenShift や Kubernetes と組み合わせると、マイクロサービスのデプロイが本当に退屈で予測可能になります。これは素晴らしいことです。 この点やその他のことについては、Istio シリーズの XNUMX 番目で最後の投稿で説明します。

退屈がちょうどいいとき

私たちの場合、退屈は最終段階でのみ発生します。この段階では、残っているのは座ってプロセスを眺めるだけです。 ただし、そのためには最初にすべてを設定する必要があり、ここでは多くの興味深いことがあなたを待っています。

ソフトウェアの新しいバージョンを導入するときは、リスクを最小限に抑えるためにあらゆるオプションを検討する価値があります。 並列実行は非常に強力で実証済みのテスト方法であり、Istio では「シークレット サービス」 (マイクロサービスの隠しバージョン) を使用して、運用システムに干渉することなくこれを実行できます。 これには「ダーク ローンチ」という特別な用語さえあります。これは、同様にスパイ名「トラフィック ミラーリング」を持つ機能によってアクティブ化されます。

前の段落の最初の文では、「リリース」ではなく「デプロイ」という用語が使用されていることに注意してください。 実際には、マイクロサービスを必要なだけデプロイでき、もちろん使用できる必要があります。 このサービスは、トラフィックを受信して​​処理し、結果を生成し、ログに書き込んで監視できる必要があります。 しかし同時に、このサービス自体は必ずしも運用環境にリリースする必要はありません。 ソフトウェアのデプロイとリリースは必ずしも同じではありません。 いつでもデプロイできますが、リリースは準備ができた場合に限ります。

退屈を整理するのは面白い

次の Istio ルーティング ルールを見てください。これは、すべての HTTP リクエストをマイクロサービス推奨 v1 にルーティングします (すべての例は、 Istio チュートリアル GitHub リポジトリ)、同時にそれらを推奨 v2 マイクロサービスにミラーリングします。

ラベルに注目してください mirror: 画面の下部にある - これがトラフィックミラーリングを設定します。 はい、とても簡単です!

このルールの結果、運用システム (v1) は受信リクエストの処理を続行しますが、リクエスト自体は非同期で v2 にミラーリングされ、完全な複製が v2 に送信されます。 このようにして、実稼働システムの動作をまったく妨げることなく、実際のデータとトラフィックを使用して、実際の条件で vXNUMX をテストできます。 これではテストの組織化が退屈になってしまいますか? はい、間違いなく。 しかし、それは興味深い方法で行われています。

ドラマを加えてみましょう

v2 コードでは、受信リクエストによってデータが変更される可能性がある状況に備える必要があることに注意してください。 リクエスト自体は簡単かつ透過的にミラーリングされますが、テストでの処理方法の選択はユーザー次第であり、これは少し心配です。

重要な点を繰り返しましょう

トラフィック ミラーリングを使用したシークレット起動 (ダーク起動/リクエスト ミラーリング) は、コードにまったく影響を与えることなく実行できます。

思考の糧

リクエストがミラーリングされる場所で、リクエストの一部が v1 ではなく v2 に送信される場合はどうなるでしょうか? たとえば、すべてのリクエストの 2 パーセント、または特定のユーザー グループからのリクエストのみなどです。 そして、v1 がどのように機能するかをすでに確認した上で、すべてのリクエストを徐々に新しいバージョンに転送します。 または逆に、v2 で問題が発生した場合は、すべてを vXNUMX に戻します。 カナリアデプロイメントと呼ばれるものだと思います。 鉱山に戻ります、そしてそれがロシア起源のものであれば、おそらくへの言及が含まれるでしょう。 猫）、次にこれをさらに詳しく見ていきます。

Istio での Canary デプロイメント: コミッショニングの簡素化

慎重に徐々に

Canary Deployment デプロイメント モデルの本質は非常にシンプルです。ソフトウェアの新しいバージョン (この場合はマイクロサービス) を起動するとき、まず、そのソフトウェアへのアクセスを少数のユーザー グループに許可します。 すべてがうまくいけば、新しいバージョンが機能し始めるまでこのグループを徐々に増やします。そうでない場合は、最終的にすべてのユーザーをそのグループに移行します。 新しいバージョンを慎重かつ段階的に導入し、制御された方法でユーザーをそのバージョンに切り替えることで、リスクを軽減し、フィードバックを最大化することができます。

もちろん、Istio は、インテリジェントなリクエスト ルーティングのための優れたオプションをいくつか提供することで、カナリア デプロイメントを簡素化します。 そして、はい、これらすべてはソースコードに一切触れずに実行できます。

ブラウザのフィルタリング

最も単純なルーティング基準の 2 つは、ブラウザベースのリダイレクトです。 Safari ブラウザからのリクエストのみを vXNUMX に送信したいとします。 その方法は次のとおりです。

このルーティング ルールを適用してから、次のコマンドを使用してみましょう。 curl ループ内のマイクロサービスへの実際のリクエストをシミュレートします。 スクリーンショットでわかるように、それらはすべて v1 に移行します。

v2 のトラフィックはどこにありますか? この例では、すべてのリクエストが独自のコマンド ラインからのみ送信されているため、単純に存在しません。 ただし、上の画面の一番下の行に注目してください。これは、Safari ブラウザからリクエストを実行したことに対する反応であり、結果として次のものが生成されます。

無制限のパワー

正規表現がリクエストをルーティングするための非常に強力な機能を提供することはすでに書きました。 次の例を見てください (これが何をするのか理解できると思います)。

ここまでで、正規表現で何ができるかについては理解できたのではないでしょうか。

賢く行動する

スマート ルーティング、特に正規表現を使用したパケット ヘッダーの処理により、トラフィックを希望どおりに誘導できます。 これにより、新しいコードの実装が大幅に簡素化されます。シンプルで、コード自体を変更する必要がなく、必要に応じてすべてを元の状態にすぐに戻すことができます。

興味がありますか？

コンピューター上で Istio、Kubernetes、OpenShift を試してみたいと思っていますか? チーム レッドハット開発者チーム 素晴らしいものを用意しました 教科書 このトピックについて議論し、すべての付随ファイルを公開しました。 ですから、自分自身を何も否定しないでください。
 

Istio Egress: 土産物店を通って出ます。

Istio を Red Hat OpenShift および Kubernetes と組み合わせて使用​​すると、マイクロサービスの使用がはるかに簡単になります。 Istio のサービス メッシュは Kubernetes ポッド内に隠されており、コードは (ほとんどの場合) 分離して実行されます。 パフォーマンス、変更の容易さ、トレースなど - サイドカー コンテナーを使用することで、これらすべてが簡単に使用できます。 しかし、マイクロサービスが OpenShift-Kubernetes システムの外部にある他のサービスと通信する必要がある場合はどうなるでしょうか?

ここで Istio Egress が役に立ちます。 一言で言えば、Kubernetes ポッドのシステムの一部ではないリソース (「サービス」と読みます) にアクセスできるようにするだけです。 追加の構成を実行しない場合、Istio Egress 環境では、トラフィックは内部 IP テーブルに基づいてポッドのクラスター内およびクラスター間でのみルーティングされます。 そして、そのような蛹化は、外部からサービスにアクセスする必要がない限り、うまく機能します。

Egress を使用すると、Egress ルールまたは IP アドレスの範囲に基づいて、上記の IP テーブルをバイパスできます。

httpbin.org/headers に GET リクエストを行う Java プログラムがあるとします。

(httpbin.org は、発信サービス要求をテストするための便利なリソースにすぎません。)

コマンドラインに入力すると curl http://httpbin.org/headers、次のことがわかります。

または、ブラウザで同じアドレスを開くこともできます。

ご覧のとおり、そこにあるサービスは、渡されたヘッダーを返すだけです。

私たちは輸入品を真っ向から置き換えています

次に、システムの外部にあるこのサービスの Java コードを取得し、Istio がインストールされている場所で独自に実行してみましょう。 （連絡すれば自分で行うこともできます） Istio チュートリアル.) 適切なイメージを構築して OpenShift プラットフォーム上で起動したら、次のコマンドでこのサービスを呼び出します。 curl egresshttpbin-istioegress.$(minishift ip).nip.ioその後、画面に次のように表示されます。

おっと、何が起こったのですか？ すべてがうまくいきました。 見つからない とはどういう意味ですか? 私たちは彼のためにやっただけです curl.

IP テーブルをインターネット全体に拡張する

これについては Istio が非難される (または感謝される) べきです。 結局のところ、Istio は、検出とルーティング (および先ほど説明した他の多くのこと) を担当するサイドカー コンテナーにすぎません。 このため、IP テーブルはクラスター システム内の内容のみを認識します。 また、httpbin.org は外部にあるためアクセスできません。 ここで Istio Egress が役に立ちます。ソース コードを少しも変更する必要はありません。

以下の Egress ルールにより、Istio は必要なサービス (この場合は httpbin.org) を (必要に応じてインターネット全体で) 検索します。 このファイル (egress_httpbin.yml) からわかるように、ここでの機能は非常に単純です。

残っているのは、このルールを適用することだけです。

istioctl create -f egress_httpbin.yml -n istioegress

コマンドを使用して Egress ルールを表示できます。 istioctl get egressrules:

そして最後に、コマンドを再度実行します curl – そして、すべてが機能していることがわかります。

私たちは率直に考えます

ご覧のとおり、Istio を使用すると、外部世界とのやり取りを整理できます。 言い換えれば、OpenShift サービスを作成し、Kubernetes を通じてそれらを管理し、必要に応じてスケールアップおよびスケールダウンできるポッドにすべてを保持することができます。 同時に、環境の外部のサービスに安全にアクセスできます。 はい、もう一度繰り返しますが、これらすべてはコードに一切触れずに実行できます。

これは Istio に関するシリーズの最後の投稿でした。 楽しみに待っていてください - これからもたくさんの興味深いことが待っています!

出所： habr.com