K8s の使用に問題がありますか? Istio がお手伝いします!

コンテナ、特に Kubernetes を扱っている場合は、おそらく Istio について聞いたことがあるでしょう。初心者のために説明すると、Istio は Kubernetes 用のサービス メッシュです。いわゆるサービス メッシュは、サービス トラフィックを動的に管理し、安全に管理できるネットワーク層です。

Istio を最大限に活用する方法は、1 つのブログ投稿の範囲を超えています。したがって、この記事ではその機能のいくつかを紹介し、さらに重要なことに、この記事を通じていくつかの実用的な問題の解決を自動化する方法をいくつか学ぶことができます。

Istio を使用すると、一連のカスタム Kubernetes リソースを使用してネットワーク トラフィックを管理でき、サービス間およびクラスター内外のネットワーク トラフィックを保護および暗号化できます。 Kubernetes API と完全に統合されているため、Istio 設定は他の Kubernetes 構成とまったく同じ方法で定義および管理できます。

長所と短所を比較検討して選択してください

Istio を使い始める場合は、まずその理由を自問する必要があります。 Istio は、カナリア リリースなどの非常に価値のある機能を提供しますが、複雑さを増さずに使用することはできません。それを学ぶには、ある程度の時間を投資する必要もあります。とはいえ、状況に応じて、Istio の機能を独自のクラスターに慎重かつ段階的に導入することができます (また、そうすべきです)。

新しい環境をゼロから構築し、長所と短所を比較検討した上で Istio の導入を決定した場合は、必ず最初から厳密な相互 TLS を設定して、その強力な機能を活用してください。具体的な操作については、

これらすべてを価値あるものにし、コスト効率を高めるには、実際のアプリケーションのコンテキストで Istio について考える必要がありますが、簡単な免責事項なしにそれを行わない方がよいでしょう。少数のサービスのみを管理する必要があり、それらが単一のクラスター内に配置されている場合、Istio を導入するコスト効率は比較的低くなります。

この記事のコード例は、問題を完全に解決するのに役立つとは限りませんが、すべてのコードと使用方法の詳細な手順が必要な場合は、GitLabで見つけることができます。

以下では、クラウド ネイティブの導入時に遭遇する可能性のある 2 つの一般的な問題と、Istio を使用してそれらの問題を解決する方法について説明します。

問題1: テストを信頼できない

テスト範囲がアプリケーションに加えた変更を完全にカバーしていない場合、すぐに新しいテスト ラウンドに移行できますが、アプリケーションが正しく機能しない可能性があります。

理想的には、すべてのコードが徹底的にテストされていることを確認する必要があります。そうしないと、アプリケーションに機能が追加されません。しかし現実は常に厳しいものです。 DDLに追われることが多いです。テストを作成または更新する前に、関数をプロジェクトにアップロードする必要がある場合があります。

解決策: 速度を落とす

では、コードに潜むバグによって大多数のユーザーが影響を受けないようにしながら、変更を加えて新しい機能を展開するにはどうすればよいでしょうか?答えは、まず最小限のユーザーに新しいバージョンを展開することで、これらの小さな問題の影響を最小限に抑えることです。

変更が期待どおりに機能した場合は、新しいバージョンを使用するユーザーの割合を徐々に増やすことができます。メトリックに問題が発生した場合、変更を簡単にロールバックして再試行できます。

Istio なしで Kubernetes 上でカナリアデプロイメントを実行することは可能ですか?もちろんですが、プロセスを自動化したい場合は、Web サーバー コードとカスタム自動化スクリプトに完全に集中する必要があります。この動作モードは費用対効果が高くありません。

Istio には非常に優れたトラフィック分散ソリューションが備わっており、これを使用して適切なクライアントに適切なバージョンを適切なタイミングで提供することができ、調整する必要があるのは 1 つまたは 2 つのパラメータだけです。

これを実現するには、Ingress ゲートウェイ、仮想サービス、および宛先ルールを設定する必要があります。これは通常のデプロイメントとサービスの上に配置され、トラフィックを分散します。

 APIバージョン: networking.istio.io/v1alpha3
種類: ゲートウェイ
メタデータ:
名前: http-gateway
仕様:
セレクタ：
 istio: イングレスゲートウェイ
サーバー:
 - ポート:
  番号: 80
名前: http
  プロトコル: HTTP
ホス
ts:
    - 「*」  
 APIバージョン: networking.istio.io/v1alpha3
種類: 仮想サービス
メタデータ:
名前: my-app
仕様:
ホスト:
 - 「*」  
ゲートウェイ:
 -http ゲートウェイ
http:
 - マッチ：
 - ウリ:
    プレフィックス: "/my-app"  
リライト：
  uri: "/"  
ルート：
  - 行き先：
      ホスト: my-app
      サブセット: v1
      ポート：
        番号: 80
    重量: 90
  - 行き先：
      ホスト: my-app
      サブセット: v2
      ポート：
        番号: 80
        重量: 10
 APIバージョン: networking.istio.io/v1alpha3
種類: 宛先ルール
メタデータ:
名前: my-app
仕様:
ホスト: my-app
サブセット:
 -名前: v1
ラベル:
  バージョン: v1.0.0
 -名前: v2
ラベル:
  バージョン: v2.0.0

仮想サービスの Weight フィールドからわかるように、Istio は指定された値に基づいてアプリケーションの 2 つのバージョン間でトラフィックを分散します。これらの値の合計は 100% である必要があります。そうでない場合、API は定義の適用を拒否します。

その後、あなた (または理想的には、継続的インテグレーション/継続的デリバリー パイプラインの 1 つ以上の手動ステップ) は、すべてのリクエストが新しいバージョンで満たされ、以前のバージョンをメンテナンスから削除できるようになるまで、重みを調整して新しいバージョンをより多くのユーザーに宣伝します。

また、Istio の障害注入機能を使用して実際のトラフィックのネットワーク停止やパフォーマンス低下をシミュレートすることで、Istio を統合テスト戦略に統合することもできます。

本番環境でテストを行うことに不安を感じるなら、それは間違ったやり方です。たとえば、仮想サービス仕様に次のスニペットを追加して混乱を招き、Istio を使用してそのような混乱を解決する方法に関する記事を探してみてください。

仕様:
ホスト:
 - 私のアプリ
http:
 - 故障：
  遅れ：
    固定遅延: 7秒
    パーセント: 100
ルート：
 - 行き先：
    ホスト: 評価
    サブセット: v2

問題2: マーケティング戦略ではリリースバージョンを決定できない

多くの場合、企業では実際のユーザーに対してアプリケーションの複数のバージョンをテストする必要があります。しかし、どのマーケティング戦略が最高のコンバージョン率につながるのか、またはどのデザイン選択が最高の顧客維持率につながるのかを判断するのは不可能な場合があります。

Kubernetes を使用すると、トラフィックを 2 つのバージョンに分割できますが、この演習から貴重な洞察を得るには、関連する情報を取得し、技術に詳しくない同僚が理解できる方法で処理するための一連のカスタム コードが再度必要になります。

ソリューション: Istio を使用した A/B テスト

Istio のトラフィック分散ルールはこの問題を再び解決でき、Prometheus および Grafana との緊密な統合により直感的な A/B テスト結果を得ることができます。一般に、受信パケットの内容の一部に基づいて、どのユーザーがアプリケーションのバージョンを取得するかを決定する方法はほぼ無限にあります。

この例では、User-Agent フィールドを使用して、異なるブラウザに異なるバージョンを提供します。

 APIバージョン: networking.istio.io/v1alpha3
種類: 仮想サービス
メタデータ:
名前: my-app
仕様:
ホスト:
 - 「*」  
ゲートウェイ:
 -http ゲートウェイ
http:
 - マッチ：
 - ヘッダー:
ユーザーエージェント:
      正規表現: 「.*Chrome.*」  
  ウリ:
    プレフィックス: "/my-app"  
リライト：
  uri: "/"  
ルート：
  - 行き先：
      ホスト: my-app
      サブセット: v1
      ポート：
        番号: 80
 - マッチ：
 - ヘッダー:
ユーザーエージェント:
      正規表現: 「.*Mozilla.*」  
  ウリ:
    プレフィックス: "/my-app"  
リライト：
  uri: "/"  
ルート：
  - 行き先：
      ホスト: my-app
      サブセット: v2
      ポート：
        番号: 80

上記のコードからわかるように、Firefox を使用するユーザーはアプリケーションのバージョン 1 を取得し、Chrome ユーザーはバージョン 2 を取得します。ブラウザの「User-Agent」フィールドに「mozilla」または「chrome」が含まれていない場合、どちらのバージョンも取得されません。

他のクライアントにサービスを提供するには、デフォルト ルートを追加する必要がありますが、これは演習として残しておきます。 （ヘイヘイ）

別のブラウザをインストールせずに試してみたいだけの場合は、ヘッダー フラグを指定した curl を使用して、任意のブラウザを装うことができます。次に例を示します。

 curl /my-app -H "ユーザーエージェント: Chrome"  

user-agent の値を変更することで、コマンドラインからさまざまなルートをすべてテストできます。

要約する

上記の 2 つの状況から、Istio の強力な機能を垣間見ることができるでしょう。前述のように、Istio がなくてもカナリア デプロイメントと A/B テストを実行することはできますが、トラフィック分散を自分で実装する必要があります。ただし、これにより開発と展開の複雑さが大幅に増し、コスト効率の悪いオプションになります。

この投稿で Istio の実際の動作について十分に理解していただけたと思います。ぜひご自身で試してみるのが待ちきれません。 Istio について詳しく知りたい場合は、役立つ情報が多数掲載されている公式 Web サイトをご覧ください。

Rancher 2.3 Preview2 バージョンが Istio のサポートを開始したことは注目に値します。ユーザーは UI インターフェースで直接 Istio を起動し、各名前空間に自動サイドカーを挿入できます。さらに、Rancher は Istio のインストールと構成を簡素化し、トラフィックとテレメトリの視覚化のための Kiali サポートを備えた組み込みダッシュボードを備え、トレースには Jaeger を使用し、独自の Prometheus と Grafana (高度な監視用のインスタンスとは別) も備えています。これらすべてにより、Istio の導入と管理が簡単かつ迅速になります。

リリースノートとインストール手順は GitHub で入手できます。