Docker Desktop を使用した Istio の使用を開始する

これはからのゲスト投稿です ドッカーキャプテン エルトン・ストーンマンは、Dockerの卒業生であり、現在はフリーランスのコンサルタント兼トレーナーであり、コンテナジャーニーのすべての段階で組織を支援しています。 エルトンは本の著者です 昼食の月にドッカーを学ぶ、および多数の 複数サイト ビデオトレーニングコース – 以下を含む Istio を使用した Kubernetes 上のアプリの管理 そして Docker を使用したコンテナー化されたアプリケーションの正常性の監視.

Istioはサービスメッシュであり、アプリケーションコンテナと一緒にコンテナで実行され、コンポーネント間のネットワークトラフィックを制御するソフトウェアコンポーネントです。 これは、コンポーネント自体とは無関係にコンポーネント間の通信を管理できる強力なアーキテクチャです。 これは、アプリのコードと構成を簡素化し、ルーティング、負荷分散、承認、監視など、すべてIstioで一元管理されるネットワークレベルのインフラストラクチャの問題をすべて排除するため、便利です。

Istioを掘り下げるための良い資料がたくさんあります。 私の仲間のDockerキャプテン Lee Calcote はIstioの共著者です :Up and Running、そして私はちょうど私自身のPluralsightコースを公開しました IstioでKubernetes上のアプリケーションを管理する。 しかし、行き過ぎる前にKubernetesの確かなバックグラウンドが本当に必要であるため、始めるのは難しいテクノロジーになる可能性があります。 この投稿では、シンプルにしようとします。 ここでは、Istio によって実現される 3 つのシナリオに焦点を当てますが、従う必要があるのは Docker Desktop だけです。

セットアップ

Docker Desktop は、ラップトップ上に完全な Kubernetes 環境を提供します。 Mac または Windows バージョンをインストールするだけで (Windows を使用している場合は必ず Linux コンテナーに切り替えてください)、Docker クジラ アイコンから設定を開き、[Kubernetes] セクションで [ Enable Kubernetes ] を選択します。 また、Istioとデモアプリはかなりの量を使用するため、Dockerが使用できるメモリの量を増やす必要があります– リソース セクションでメモリスライダーを少なくとも6GBに増やします。

次に、GitHubリポジトリにあるこのブログ投稿のサンプルコードを入手してください。

git clone https://github.com/sixeyed/istio-samples.git
cd istio-samples


リポジトリには、Istioとデモアプリ(シンプルな書店Webサイト)をデプロイする一連のKubernetesマニフェストがあります(これは Istioチームのデモアプリですが、さまざまな方法で使用するため、必ずリポジトリを使用してフォローしてください)。 Docker Desktop の一部としてインストールされている Kubernetes 制御ツール kubectl を使用して、すべてをデプロイします。

kubectl apply -f ./setup/

KubernetesがデモアプリとともにすべてのIstioコンポーネントを作成すると、数十行の出力が表示されますが、これらはすべてDockerコンテナで実行されます。 すべてのイメージが Docker Hub からダウンロードされるまでに数分かかり、kubectl を使用して状態を確認できます。

# Istio - will have “1/1” in the “READY” column when fully running:
kubectl get deploy -n istio-system

# demo app - will have “2/2” in the “READY” column when fully running:
kubectl get pods

すべてのビットの準備ができたら、http://localhost/productpage を参照すると 、 この非常にシンプルなデモアプリが表示されます。

そして、あなたは行ってもいいです。 Kubernetes YAML ファイルの操作に満足している場合は、 デモ アプリのデプロイ仕様を確認すると、すべての標準 Kubernetes リソース (サービス、サービス アカウント、デプロイ) であることがわかります。 Istioはアプリの通信を管理していますが、Istio構成をデプロイしていないため、まだ多くのことを行っていません。

デモ アプリケーションは分散アプリです。 ホームページは 1 つのコンテナーで実行され、他のコンテナーで実行されている REST API からのデータを消費します。 ページに表示される書籍の詳細と書籍レビューは、他のコンテナから取得されます。 Istioは、これらのコンポーネント間のネットワークトラフィックを管理しており、Kubernetesやホームページに着信する外部トラフィックも管理しています。

このデモアプリを使用して、Istioの主な機能であるトラフィック管理、セキュリティ、可観測性について説明します。

トラフィックの管理 – Istio を使用したカナリアデプロイ

ホームページはちょっとつまらないので、新しいリリースで盛り上げましょう。 更新プログラムがどのように受信されるかを確認できるように段階的なリリースを行いたいと考えており、Istio はブルーグリーンとカナリアの両方のデプロイをサポートしています。 カナリアのデプロイは一般的により便利であり、それを使用します。 ホームページの2つのバージョンが実行され、Istioはトラフィックの一部をバージョン1に送信し、残りをバージョン2に送信します。

ここでは、サービスの検出とルーティングにIstioを使用しています:すべての着信トラフィックはIstioに着信し、そのトラフィックを製品ページコンポーネントに転送する方法のルールを設定します。 これを行うには、カスタム Istio リソースである VirtualService をデプロイします。 これには、HTTP トラフィック用の次のルーティング規則が含まれます。

gateways:
    - bookinfo-gateway
  http:
    - route:
        - destination:
            host: productpage
            subset: v1
            port:
              number: 9080
          weight: 70
        - destination:
            host: productpage
            subset: v2
            port:
              number: 9080
          weight: 30

ここにはいくつかの可動部分があります。

• は gateway 、外部トラフィックを受信する Istio コンポーネントです。 bookinfo-gateway オブジェクトは、すべての HTTP トラフィックをリッスンするように構成されていますが、ゲートウェイは特定のポートとホスト名に制限できます。
• これは destination 、トラフィックがルーティングされる実際のターゲットです(要求されたドメイン名とは異なる場合があります)。 この場合、トラフィックの 70% を受信する v1 と 30% を受信する v2 の 2 つのサブセットがあります。
• これらは subsets 、Kubernetes ラベルを使用してサービス内のポッドを識別する宛先 ルール オブジェクトで定義されます。 この場合、v1 サブセットはラベル version=v1 のポッドを検索し、v2 サブセットはラベル version=v2 のポッドを検索します。

複雑に聞こえますが、実際に行っているのは、異なるポッド間でトラフィックをシフトするルールを定義することだけです。 これらの定義は Kubernetes マニフェスト YAML ファイルで提供され、アプリケーションと同じ方法でデプロイします。 そのため、1 つのコマンドでバージョン 2 のカナリア デプロイを実行でき、これにより、新しい v2 ポッドと Istio ルーティング ルールが作成されます。

# deploy:
kubectl apply -f ./canary-deployment

# check the deployment - it’s good when all pods show “2/2” in “READY”:
kubectl get pods

書店のデモアプリを数回更新すると、ほとんどの応答が同じ退屈なv1ページであることがわかりますが、幸運なことに、多くのユーザーエクスペリエンステストの結果であるv2ページが表示されます。

肯定的なフィードバックが寄せられたら、VirtualService 定義の重みを変更して再デプロイするだけで、トラフィックを v2 に増やすことができます。 どちらのバージョンのアプリもカナリアステージ全体で実行されているため、トラフィックをシフトすると、すでに稼働していてトラフィックを処理する準備ができているコンポーネントに送信されるため、新しいポッドの起動による追加のレイテンシーはありません。

カナリアのデプロイは、Istioがシンプルにするトラフィック管理の1つの側面にすぎません。 再試行やサーキットブレーカーを使用してフォールトトレランスを追加するなど、すべてIstioコンポーネントを使用して、アプリを変更することなく、さらに多くのことを行うことができます。

トラフィックの保護 – mTLS を使用した認証と承認

Istioは、コンポーネント間のすべてのネットワークトラフィックを透過的に処理し、コンポーネント自体が干渉していることを認識せずに処理します。 これは、Istioのルールを適用するネットワークプロキシを介してすべてのアプリケーションコンテナトラフィックを実行することによって行われます。 これをトラフィック管理に使用する方法を見てきましたが、セキュリティにも機能します。

アプリコンポーネント間の転送中に暗号化が必要で、特定のコンシューマーのみがサービスを呼び出すことができるようにアクセスルールを適用する場合は、Istioでもそれを行うことができます。 アプリケーションのコードと構成をシンプルに保ち、基本的な認証されていないHTTPを使用してから、ネットワークレベルでセキュリティを適用できます。

認証と承認はIstioのセキュリティ機能であり、説明するよりもはるかに使いやすいです。 ピースがどのように組み合わされるかを示す図を次に示します。

ここでは、左側の製品ページコンポーネントが右側のレビューコンポーネントからREST APIを使用しています。 これらのコンポーネントは Kubernetes ポッドで実行され、各ポッドにはアプリケーション用の 1 つの Docker コンテナーと、アプリのネットワーク トラフィックを処理する Istio プロキシを実行する 2 つ目の Docker コンテナーがあることがわかります。

この設定では、HTTP トラフィックの暗号化と発信者の認証と承認に相互 TLS を使用します。

• サービスに適用される 認証ポリシー オブジェクトには相互 TLS が必要です。つまり、サービス自体はポート 80 でのみ HTTP トラフィックをリッスンするように構成されていても、サービス プロキシはポート 443 で HTTPS トラフィックをリッスンします。
• サービスに適用される AuthorizationPolicy オブジェクトは、アクセスを許可する他のコンポーネントを指定します。 この場合、HTTP GETアクセスが許可されている製品ページコンポーネントを除いて、すべてがアクセスを拒否されます。
• DestinationRule オブジェクトは相互 TLS 用に構成されているため、製品ページコンポーネントのプロキシは HTTP 呼び出しを HTTPS にアップグレードするため、アプリがレビュー コンポーネントを呼び出すと相互 TLS 会話になります。

Mutual-TLS とは、クライアントが自身を識別するための証明書と、暗号化用の証明書を提示するサービスを提示することを意味します (サーバー証明書のみが標準の HTTPS 動作です)。 Istioはこれらすべての証明書を生成および管理できるため、通常のmTLS展開から大きな負担が軽減されます。 

そこには取り入れるべきことがたくさんありますが、そのすべての展開と管理は非常に簡単で、まったく同じ kubectl プロセスです。

kubectl apply -f ./service-authorization/

Istioは識別にKubernetesサービスアカウントを使用しており、アプリを試すと何も変更されていないことがわかりますが、すべて以前と同じように機能します。 違いは、クラスターで実行されている他のコンポーネントがレビューコンポーネントにアクセスできなくなり、APIがロックダウンされて製品ページのみがそれを消費できることです。

別のコンテナーに接続することで、詳細コンポーネントが同じクラスターで実行されていることを確認できます。 詳細コンテナーからレビュー API を使用してみてください。

docker container exec -it $(docker container ls --filter name=k8s_details --format '{{ .ID}}') sh

curl http://reviews:9080/1

エラーが表示されます – RBAC: アクセスが拒否されました。これは Istio が承認ポリシーを適用していることです。 これは強力なものであり、特にIstioに証明書を管理させます。 有効期間が短い証明書を生成するため、侵害された場合でも、長期間使用することはできません。 これはすべて、アプリコードを複雑にしたり、自己署名証明書を処理したりすることなく行われます。

可観測性 – Kiali を使用したサービスメッシュの視覚化

すべてのネットワークトラフィックはIstioを経由するため、すべての通信を監視および記録できます。 Istioは、テレメトリの保存にプラグ可能なアーキテクチャを使用しており、PrometheusやElasticsearchなどの標準システムをサポートしています。 

すべてのネットワーク呼び出しのテレメトリの収集と保存にはコストがかかる可能性があるため、これはすべて構成可能です。 使用している Istio のデプロイはデモ構成であり、テレメトリが構成されているため、試してみることができます。 テレメトリ データは、サービス プロキシから Mixer と呼ばれる Istio コンポーネントに送信され、さまざまなバックエンド ストア (この場合は Prometheus) に送信できます。

(この図は単純化したものです – Prometheus は実際に Istio からデータを取得し、単一の Prometheus インスタンスを使用して Istio とアプリケーションからメトリックを収集できます)。

Prometheusのデータには応答コードと期間が含まれており、Istioには、メトリックにドリルダウンするために使用できる多数のGrafanaダッシュボードが付属しています。 また、Kialiと呼ばれる優れたツールもサポートしており、すべてのサービスとそれらの間のネットワークトラフィックを非常に便利に視覚化できます。

Kiali はデモデプロイで既に実行されていますが、デフォルトでは公開されていません。 ゲートウェイと仮想サービスをデプロイすることでアクセスできます。

kubectl apply -f ./visualization-kiali/

次に、http://localhost/productpage 時にアプリを数回更新してから、http://localhost:15029 時に Kiali でサービス メッシュの視覚化を確認します。ユーザー名 admin とパスワード admin でログインし、グラフ ビューを参照すると、書店アプリのライブ トラフィックが表示されます。

ここでラベルの「リクエストの割合」をオンにしましたが、製品ページのバージョン間のトラフィックの分割は67%から34%であり、70〜30の重み付けにかなり近いことがわかります(トラフィックが多いほど、指定された重み付けに近づきます)。

Kiali は、Istio がサポートするオブザーバビリティ ツールの 1 つにすぎません。 デモ展開では、複数のダッシュボードを備えたGrafanaと、分散アプリケーションのレイテンシに関する問題を診断するための非常に強力なツールである分散トレース用のJaegerも実行します。 これらのビジュアライゼーションを強化するすべてのデータは、Istioによって自動的に収集されます。

ラップ

サービス メッシュは、アプリケーションの通信レイヤーを独立したエンティティにし、アプリ自体から一元的かつ独立して制御できます。 Istioは現在利用可能な最もフル機能のサービスメッシュですが、 Linkerd (ベースラインパフォーマンスが向上する傾向がある)や サービスメッシュインターフェイス プロジェクト(メッシュ機能の標準化を目的としています)もあります。

サービス メッシュの使用にはコストが伴います – プロキシの追加コンピューティングをホストするためのランタイム コストと、Istio のスキルを持つチームを取得するための組織コストがあります。 しかし、それによって可能になるシナリオは多くの人々のコストを上回り、Istioが自分に適しているかどうかを非常に迅速にテストして、Dockerデスクトップの独自のアプリで使用できます。