FAQ

Istioとサービスメッシュテクノロジーに関する情報をお探しですか？このFAQがお役に立てれば幸いです！

一般

Istioとは何ですか？

Istioは、トラフィック管理、ポリシー適用、テレメトリ収集を提供するオープンでプラットフォームに依存しないサービスメッシュです。

オープンソース: Istioはオープンソースソフトウェアとして開発および保守されています。コミュニティからの貢献とフィードバックを歓迎します。

プラットフォーム非依存: Istioは特定のデプロイ環境をターゲットとしていません。開発初期段階では、IstioはKubernetesベースのデプロイをサポートします。しかし、Istioは他の環境への迅速かつ容易な適応を可能にするために構築されています。

サービスメッシュ: Istioは、マイクロサービスとアプリケーション間の通信を管理するように設計されています。基盤となるサービスに変更を加えることなく、Istioは、すべてのサービス間の通信に対して、自動化された基本的なトラフィック耐性、サービスメトリクス収集、分散トレーシング、トラフィック暗号化、プロトコルアップグレード、高度なルーティング機能を提供します。

詳細については、Istioサービスメッシュをご覧ください。

なぜIstioを使用するのですか？

従来、Istioによって処理されるロジックの多くは、アプリケーションに直接組み込まれていました。多数のサービスにわたって、この通信ロジックの更新を管理することは、大きな負担となる可能性があります。Istioは、サービス通信の管理に対するインフラストラクチャレベルのソリューションを提供します。

アプリケーション開発者: Istioがサービス間のトラフィックフローを管理することにより、開発者はビジネスロジックに専念し、新機能を迅速に反復できます。

サービスオペレーター: Istioは、アプリケーションの進化とは無関係に、単一の集中管理ポイントからポリシー適用とメッシュ監視を可能にします。その結果、オペレーターは簡素化された管理プレーンを通じて、継続的なポリシーコンプライアンスを保証できます。

Istioの使い方は？

入門ページの手順に従うことをお勧めします。これにより、Istioの主要なサンプルアプリケーションであるBookinfoと共に、デモ構成がインストールされます。その後、この設定を使用して、インテリジェントルーティング、ポリシー適用、セキュリティ、テレメトリなどをチュートリアル形式で紹介するさまざまなIstioガイドを順を追って実行できます。

本番KubernetesデプロイメントでIstioを使用するには、デプロイメントモデルドキュメントとどのIstioインストール方法を使用する必要がありますか？FAQページを参照してください。

ライセンスは何ですか？

IstioはApache License 2.0を使用しています。

Istioはどのように開始されましたか？

Istioプロジェクトは、GoogleとIBMのチームがLyftのEnvoyチームと連携して開始されました。GitHubで完全にオープンに開発されています。

サポートされているデプロイ環境は？

Istioはプラットフォームに依存しないように設計されており、最初はKubernetesに重点を置いています。1.24リリースでは、IstioはKubernetes（1.28、1.29、1.30、1.31）を実行している環境をサポートしています。

どのように貢献できますか？

貢献は大歓迎です。コミュニティからのフィードバック、追加、バグレポートを期待しています。

コードリポジトリはGitHubでホストされています。貢献方法については、貢献ガイドラインを参照してください。

コードに加えて、Istioコミュニティに貢献する他の方法があり、ディスカッションフォーラム、Slack、Stack Overflowなどがあります。

ドキュメントはどこにありますか？

istio.ioのドキュメントをご覧ください。ドキュメントには、概念の概要、タスクガイド、例、および完全なリファレンスドキュメントが含まれています。

詳細な開発者レベルのドキュメントは、当社のWikiで管理されています。

Istioが機能しません - どうすればよいですか？

ソリューションを見つけるには運用ガイド、バグを報告するにはバグ報告ページを確認してください。

Istioのロードマップは何ですか？

機能ステージページとニュースで最新の出来事をご覧ください。

「Istio」という言葉の意味は何ですか？

ギリシャ語で「帆」を意味します。

Istio Slackワークスペースに参加するにはどうすればよいですか？

コミュニティメンバーとライブで交流したい場合は、IstioのSlackワークスペースに参加できます。

設定

どのIstioインストール方法を使用する必要がありますか？

簡単な入門評価インストールに加えて、Istioをインストールするために使用できるいくつかの異なる方法があります。どの方法を使用するかは、本番環境の要件によって異なります。以下は、利用可能な各方法の長所と短所のいくつかを示しています。

istioctl install
シンプルで高セキュリティなインストールと管理パス。これは、ほとんどのユースケースでコミュニティが推奨する方法です。
長所
- 徹底的な構成検証とヘルス検証。
- 広範な構成/カスタマイズオプションを提供するIstioOperator APIを使用します。
短所
- Istioマイナーバージョンごとに1つずつ、複数のバイナリを管理する必要があります。
- istioctlコマンドは、実行中の環境に基づいて値を自動的に設定できるため、異なるKubernetes環境で異なるインストールが生成されます。
istioctl manifest generate
Kubernetesマニフェストを生成し、kubectl apply --pruneで適用します。この方法は、厳格な監査または出力マニフェストの拡張が必要な場合に適しています。
長所
- リソースは、istioctl installで使用されているものと同じIstioOperator APIから生成されます。
- 広範な構成/カスタマイズオプションを提供するIstioOperator APIを使用します。
短所
- istioctl installで実行される一部のチェックは実行されません。
- istioctl installと比較してUXが簡素化されていません。
- 適用ステップのエラーレポートは、istioctl installほど堅牢ではありません。
Helmを使用したインストール
Helmチャートを使用すると、Helmベースのワークフローとアップグレード中の自動リソースプルーニングを容易に統合できます。
長所
- 業界標準ツールを使用した使い慣れたアプローチ。
- Helmネイティブのリリースとアップグレード管理。
短所
- istioctl installと比較して、チェックと検証が少なくなっています。
- 一部の管理タスクには、より多くの手順と高い複雑さが伴います。

これらのすべての方法のインストール手順は、Istioインストールページにあります。

Kubernetes - 自動サイドカーインジェクションの問題をデバッグするにはどうすればよいですか？

クラスタが自動サイドカーインジェクションの前提条件を満たしていることを確認してください。マイクロサービスがkube-system、kube-public、またはistio-system名前空間にデプロイされている場合、自動サイドカーインジェクションから除外されます。代わりに別の名前空間を使用してください。

アンビエントモード

ztunnelは単一障害点ですか？

Istioのztunnelは、Kubernetesクラスタに単一障害点（SPOF）を導入しません。ztunnelの障害は単一ノードに限定されており、Linuxカーネル、コンテナランタイムなど、すべてのクラスタで実行されている他のノードクリティカルなインフラストラクチャと同じように扱われます。適切に設計されたシステムでは、ノードの停止はクラスタの停止につながりません。詳細はこちら。

セキュリティ

Istioのインストール後に相互TLSを有効/無効にするにはどうすればよいですか？

認証ポリシーとデスティネーションルールを使用して、いつでもサービスの相互TLS設定を変更できます。タスクで詳細をご覧ください。

同じクラスタ内の他のサービスを無効のままにして、一部のサービスに対して相互TLSを有効にできますか？

認証ポリシーは、メッシュ全体（メッシュ内のすべてのサービスに影響を与える）、名前空間全体（同じ名前空間内のすべてのサービス）、またはサービス固有にすることができます。クラスタ内のサービスに対して相互TLSを設定するためのポリシーまたはポリシーを、必要に応じて自由に設定できます。

トラフィックが相互TLS暗号化を使用していることを確認するにはどうすればよいですか？

values.global.proxy.privileged=trueでIstioをインストールした場合、tcpdumpを使用して暗号化状態を確認できます。また、Kubernetes 1.23以降では、Istioを特権としてインストールする代わりに、一時コンテナでtcpdumpを実行するためにkubectl debugを使用できます。Istio相互TLS移行の手順を参照してください。

相互TLSがグローバルに有効になっている場合、非IstioサービスはIstioサービスにアクセスできますか？

STRICT相互TLSが有効になっている場合、非Istioワークロードは有効なIstioクライアント証明書を持たないため、Istioサービスと通信できません。

これらのクライアントを許可する必要がある場合、相互TLSモードをPERMISSIVEに設定して、プレーンテキストと相互TLSの両方を許可できます。これは、個々のワークロードまたはメッシュ全体に対して行うことができます。

認証ポリシーで詳細をご覧ください。

相互TLSが有効になっている場合、ポッドのヘルスチェックにKubernetesのライブネスとレディネスを使用するにはどうすればよいですか？

相互TLSが有効になっている場合、kubeletからのHTTPおよびTCPヘルスチェックは、kubeletにIstio発行の証明書がないため、変更せずに機能しません。

いくつかのオプションがあります。

プローブの書き換えを使用して、ライブネスとレディネスのリクエストをワークロードに直接リダイレクトします。プローブの書き換えの詳細を参照してください。これはデフォルトで有効になっており、推奨されます。
ヘルスチェックに別のポートを使用し、通常のサービスポートでのみ相互TLSを有効にします。Istioサービスのヘルスチェックの詳細を参照してください。
ワークロードに対してPERMISSIVEモードを使用し、プレーンテキストトラフィックと相互TLSトラフィックの両方を許可します。このオプションでは、相互TLSは適用されないことに注意してください。

Istio証明書の有効期間を設定するにはどうすればよいですか？

Kubernetesで実行されているワークロードの場合、Istio証明書の有効期間はデフォルトで24時間です。

プロキシ構成のproxyMetadataフィールドをカスタマイズすることで、この構成をオーバーライドできます。例えば

proxyMetadata:
  SECRET_TTL: 48h

"excludeInboundPorts"アノテーションを使用して設定されたポートは、自動相互TLSから除外されますか？

いいえ。「traffic.sidecar.istio.io/excludeInboundPorts」をサーバーワークロードで使用する場合でも、IstioはデフォルトでクライアントEnvoyが相互TLSを送信するように構成します。それを変更するには、相互TLSモードがDISABLEに設定されたデスティネーションルールを構成して、クライアントがそれらのポートにプレーンテキストを送信する必要があります。

MySQL接続のトラブルシューティング

Istioインストール後にMySQLに接続できない場合があります。これは、MySQLがサーバーファーストプロトコルを使用しており、Istioのプロトコル検出と干渉するためです。特に、PERMISSIVE mTLSモードを使用すると問題が発生する可能性があります。「ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0」のようなエラーメッセージが表示される場合があります。

これを修正するには、STRICTモードまたはDISABLEモードを使用するか、すべてのクライアントがmTLSを送信するように構成します。サーバーファーストプロトコルに関する詳細情報をご覧ください。

Istioは認可をサポートしていますか？

はい。Istioは、メッシュ内のHTTPサービスとプレーンTCPサービスの両方に対して認可機能を提供します。詳細はこちら。

Istio IngressをTLSトラフィックのみを受け入れるように構成する方法を教えてください。

セキュアなイングレストラフィックタスクの手順に従うことで、Istio IngressをTLSトラフィックのみを受け入れるようにセキュリティ保護できます。

HTTPSサービスにIstioサイドカーをインストールできますか？

はい、できます。相互TLSが有効な場合と無効な場合の両方で動作します。

メトリクスとログ

IstioメトリクスにREST経由でアクセスできますか？

Prometheusを使用してIstioに関するテレメトリデータを取得できます。その後、PrometheusのHTTP APIを使用してそのデータにクエリを実行できます。

プロキシ内テレメトリ（v2）とMixerベースのテレメトリ（v1）で報告されるテレメトリの違いは何ですか？

プロキシ内テレメトリ（v2）は、Mixerベースのテレメトリ（v1）アプローチと比較して、リソースコストを削減し、プロキシのパフォーマンスを向上させます。これは、Istioでテレメトリを提示するための推奨メカニズムです。ただし、v1とv2の間で報告されるテレメトリにはいくつかの違いがあります。

メッシュ外のトラフィックのラベルの欠如 プロキシ内テレメトリは、Envoyプロキシ間のメタデータ交換に依存して、ピアワークロード名、名前空間、ラベルなどの情報を収集します。Mixerベースのテレメトリでは、この機能は、リクエスト属性とプラットフォームデータを組み合わせる処理の一部としてMixerによって実行されていました。このメタデータ交換は、HTTPプロトコルの場合は特定のHTTPヘッダーを追加することで、TCPプロトコルの場合はALPNプロトコルを拡張することでEnvoyプロキシによって実行されます（こちらを参照）。これには、クライアントとサーバーの両方のワークロードにEnvoyプロキシを注入する必要があるため、一方のピアがメッシュ内にない場合、ワークロード名、名前空間、ラベルなどのピア属性が欠落したテレメトリが報告されます。ただし、両方のピアにプロキシが注入されている場合、ここに記載されているすべてのラベルが生成されたメトリクスで使用できます。サーバーワークロードがメッシュ外にある場合でも、サーバーワークロードのメタデータはクライアントサイドカーに配信されるため、クライアント側のメトリクスにはサーバーワークロードのメタデータラベルが埋め込まれます。
TCPメタデータ交換にはmTLSが必要 TCPメタデータ交換は、Istio ALPNプロトコルに依存しており、Envoyプロキシがメタデータを正常に交換するには相互TLS（mTLS）を有効にする必要があります。これは、クラスタでmTLSを有効にしていない場合、TCPプロトコルのテレメトリには、ワークロード名、名前空間、ラベルなどのピア情報が含まれないことを意味します。
ヒストグラムメトリクスのカスタムバケットを設定するメカニズムがない Mixerベースのテレメトリは、リクエストの期間やTCPバイトサイズなどのヒストグラムタイプのメトリクスのバケットのカスタマイズをサポートしていました。プロキシ内テレメトリにはそのようなメカニズムはありません。さらに、プロキシ内テレメトリのレイテンシメトリクスで使用可能なバケットはミリ秒単位であるのに対し、Mixerベースのテレメトリでは秒単位です。ただし、プロキシ内テレメトリでは、デフォルトでより多くのバケットが低レイテンシレベルのレイテンシメトリクスで使用できます。
短期的なメトリクスのメトリクス期限切れがない Mixerベースのテレメトリは、設定可能な時間生成されなかったメトリクスをPrometheusによる収集のために登録解除するメトリクス期限切れをサポートしていました。これは、一括処理など、短期的なメトリクスを生成するシナリオに役立ちます。メトリクスを登録解除すると、将来変更されなくなるメトリクスのレポートが防止され、Prometheusのネットワークトラフィックとストレージが削減されます。この期限切れメカニズムは、プロキシ内テレメトリでは使用できません。これに対する回避策はこちらにあります。

短期的なメトリクスを管理するにはどうすればよいですか？

短期的なメトリクスは、多くの場合、ラベルのカーディナリティの大きな原因となるため、Prometheusのパフォーマンスを阻害する可能性があります。カーディナリティとは、ラベルの一意の値の数を測定する尺度です。短期的なメトリクスがPrometheusに与える影響を管理するには、まずカーディナリティの高いメトリクスとラベルを特定する必要があります。Prometheusは、その/statusページでカーディナリティ情報を提供します。追加情報はPromQL経由で取得できます。Istioメトリクスのカーディナリティを削減するにはいくつかの方法があります。

ホストヘッダーのフォールバックを無効にする。destination_serviceラベルは、カーディナリティが高い可能性のあるソースの1つです。destination_serviceの値は、Istioプロキシが他のリクエストメタデータから宛先サービスを判断できない場合、ホストヘッダーにデフォルト設定されます。クライアントがさまざまなホストヘッダーを使用している場合、これによりdestination_serviceの値が多数になる可能性があります。この場合、メトリクスのカスタマイズガイドに従って、メッシュ全体でホストヘッダーのフォールバックを無効にします。特定のワークロードまたは名前空間でホストヘッダーのフォールバックを無効にするには、stats EnvoyFilter構成をコピーし、ホストヘッダーのフォールバックが無効になるように更新し、より具体的なセレクターを使用して適用する必要があります。この問題には、これを実現する方法の詳細が記載されています。
収集から不要なラベルを削除する。カーディナリティの高いラベルが必要ない場合は、tags_to_removeを使用してメトリクスのカスタマイズを介してメトリクスの収集から削除できます。
フェデレーションまたは分類によってラベル値を正規化する。ラベルによって提供される情報が必要な場合は、Prometheusフェデレーションまたはリクエストの分類を使用してラベルを正規化できます。

既存のMixer機能を移行するにはどうすればよいですか？

MixerはIstio 1.8リリースで削除されました。Mixerの組み込みアダプターまたはメッシュ拡張のためのプロセス外アダプターにまだ依存している場合は、移行が必要です。

組み込みアダプターについては、いくつかの代替手段が提供されています。

PrometheusとStackdriverの統合は、プロキシ拡張機能として実装されています。これらの2つの拡張機能によって生成されるテレメトリのカスタマイズは、リクエストの分類とPrometheusメトリクスのカスタマイズを介して実現できます。
グローバルおよびローカルレート制限（memquotaおよびredisquotaアダプター）機能は、Envoyベースのレート制限ソリューションを介して提供されます。
OPAアダプターは、Envoy ext-authzベースのソリューションに置き換えられ、OPAポリシーエージェントとの統合をサポートします。

カスタムプロセス外アダプターについては、Wasmベースの拡張機能への移行を強くお勧めします。Wasmモジュールの開発と拡張機能の配布に関するガイドを参照してください。一時的な解決策として、MixerでEnvoy ext-authzとgRPCアクセスログAPIのサポートを有効にすることができます。これにより、プロセス外アダプターを使用してIstioを1.7以降のバージョンにアップグレードできます。これにより、Wasmベースの拡張機能に移行するための時間をより多く確保できます。この一時的な解決策は実戦テストされておらず、パッチ修正は行われない可能性が高いことに注意してください。これは、2021年2月以降サポート期間外となっているIstio 1.7ブランチでのみ使用可能であるためです。

PrometheusアダプターをKubernetes以外の環境で使用できますか？

docker-composeを使用してPrometheusをインストールできます。

Istioのリクエストで何が起こったのかを調べるにはどうすればよいですか？

Istioのリクエストの流れを判断するためにトレーシングを有効にできます。

さらに、次のコマンドを使用してメッシュの状態について詳細を確認できます。

istioctl proxy-config：Kubernetesで実行している場合のプロキシ構成に関する情報を取得します。

# Retrieve information about bootstrap configuration for the Envoy instance in the specified pod. $ istioctl proxy-config bootstrap productpage-v1-bb8d5cbc7-k7qbm Retrieve information about cluster configuration for the Envoy instance in the specified pod. $ istioctl proxy-config cluster productpage-v1-bb8d5cbc7-k7qbm Retrieve information about listener configuration for the Envoy instance in the specified pod. $ istioctl proxy-config listener productpage-v1-bb8d5cbc7-k7qbm Retrieve information about route configuration for the Envoy instance in the specified pod. $ istioctl proxy-config route productpage-v1-bb8d5cbc7-k7qbm Retrieve information about endpoint configuration for the Envoy instance in the specified pod. $ istioctl proxy-config endpoints productpage-v1-bb8d5cbc7-k7qbm Try the following to discover more proxy-config commands

$ istioctl proxy-config –help

kubectl get：ルーティング構成とともに、メッシュ内のさまざまなリソースに関する情報を取得します。
```
# List all virtual services
$ kubectl get virtualservices
```

Prometheusを使用してIstioでアプリケーションメトリクスをスクレイピングできますか？

はい。Prometheusはオープンソースの監視システムおよび時系列データベースです。PrometheusをIstioで使用して、Istioとサービスメッシュ内のアプリケーションの健全性を追跡するメトリクスを記録できます。GrafanaやKialiなどのツールを使用してメトリクスを視覚化できます。Prometheusの構成を参照して、メトリクスの収集を有効にする方法を理解してください。

いくつかの注意点

Prometheusポッドがistiodポッドが必要な証明書を生成してPrometheusに配布する前に開始された場合、相互TLSで保護されたターゲットから収集するには、Prometheusポッドを再起動する必要があります。
アプリケーションが専用のポートでPrometheusメトリクスを公開している場合、そのポートをサービスとデプロイメントの仕様に追加する必要があります。

分散トレーシング

Istioでの分散トレーシングの動作方法を教えてください。

Istioは、Envoyベースのトレーシングを使用して分散トレーシングシステムと統合されます。Envoyベースのトレーシング統合では、アプリケーションは後続の送信リクエストのトレーシングヘッダーを転送する役割を担います。

Istio分散トレーシング（Jaeger、Lightstep、Zipkin）タスクとEnvoyトレーシングドキュメントで追加情報を確認できます。

Istioでの分散トレーシングには何が求められますか？

Istio は、メッシュ内のワークロード間の通信に関するトレーススパンのレポートを有効にします。しかし、トラフィックフローの完全なビューを得るために様々なトレーススパンを繋ぎ合わせるためには、アプリケーションが着信リクエストと発信リクエスト間でトレースコンテキストを伝播する必要があります。

特に、Istio はアプリケーションがB3 トレースヘッダーと、Envoy が生成したリクエストID を伝播することに依存しています。これらのヘッダーには以下が含まれます。

x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
b3

Lightstep を使用している場合は、次のヘッダーも転送する必要があります。

x-ot-span-context

OpenTelemetry または Stackdriver を使用している場合は、次のヘッダーも転送する必要があります。

traceparent
tracestate

ヘッダーの伝播は、Zipkin や Jaeger などのクライアントライブラリを通じて行うことができます。また、分散トレーシングタスクに記載されているように、手動で行うこともできます。

Envoy ベースのトレーシングはどのように動作しますか？

Envoy ベースのトレーシング統合では、Envoy（サイドカープロキシ）が、プロキシされているアプリケーションに代わって、トレーシング情報を直接トレーシングバックエンドに送信します。

Envoy は

プロキシを通過するリクエストに対して、リクエストID とトレースヘッダー（つまり、X-B3-TraceId）を生成します。
リクエストとレスポンスのメタデータ（つまり、レスポンスタイム）に基づいて、各リクエストのトレーススパンを生成します。
生成されたトレーススパンをトレーシングバックエンドに送信します。
プロキシされたアプリケーションにトレースヘッダーを転送します。

Istio は、Lightstep と Zipkin の Envoy ベースの統合、および Jaeger を含むすべての Zipkin API 互換バックエンドをサポートしています。

分散トレーシングに必要な最小限の Istio 設定は何ですか？

トレーシングが有効になっているIstio 最小プロファイルは、Istio が Zipkin 互換バックエンドと統合するために必要なすべてです。

初期の Zipkin (B3) HTTP ヘッダーを生成するのは何ですか？

Istio サイドカープロキシ (Envoy) は、リクエストによって提供されない場合、初期のヘッダーを生成します。

Istio は、アプリケーションではなくヘッダーを伝播できないのはなぜですか？

Istio サイドカーは関連付けられたアプリケーションインスタンスの着信リクエストと発信リクエストの両方を処理しますが、発信リクエストを着信リクエストに関連付ける暗黙的な方法はありません。この相関関係を実現できる唯一の方法は、アプリケーションが関連情報（つまり、ヘッダー）を着信リクエストから発信リクエストに伝播することです。ヘッダーの伝播は、クライアントライブラリまたは手動で行うことができます。詳細は Istio を使用した分散トレーシングに必要なものを参照してください。

リクエストがトレースされないのはなぜですか？

Istio 1.0.3 以降、トレーシングのサンプリングレートはdefault 設定プロファイルで 1% に削減されました。これは、Istio によってキャプチャされたトレースインスタンスの 100 個のうち 1 個だけがトレーシングバックエンドにレポートされることを意味します。demo プロファイルのサンプリングレートは、引き続き 100% に設定されています。サンプリングレートの設定方法の詳細についてはこのセクションを参照してください。

それでもトレースデータが表示されない場合は、ポートが Istio のポート命名規則に準拠していること、および適切なコンテナポートが（たとえば、pod spec を介して）公開されて、サイドカープロキシ (Envoy) によるトラフィックキャプチャを有効にしていることを確認してください。

発信プロキシに関連付けられたトレースデータのみが表示され、着信プロキシには表示されない場合は、Istio のポート命名規則に関連している可能性があります。Istio 1.3 以降、発信トラフィックのプロトコルは自動的に検出されます。

トレースのボリュームを制御するにはどうすればよいですか？

Istio は、Envoy を介して、現在、トレース生成に対してパーセンテージベースのサンプリング戦略をサポートしています。このサンプリングレートの設定方法の詳細についてはこのセクションを参照してください。

トレーシングを無効にするにはどうすればよいですか？

トレーシングが有効になっている Istio を既にインストールしている場合は、次のように無効にすることができます。

# Fill <istio namespace> with the namespace of your istio mesh.Ex: istio-system
TRACING_POD=`kubectl get po -n <istio namespace> | grep istio-tracing | awk '{print $1}'`
$ kubectl delete pod $TRACING_POD -n <istio namespace>
$ kubectl delete services tracing zipkin   -n <istio namespace>
# Now, manually remove instances of trace_zipkin_url from the file and save it.

次に、分散トレーシングタスクのクリーンアップセクションの手順に従います。

トレーシング機能をまったく必要としない場合は、Istio のインストール時にトレーシングを無効にします。

Istio はトレーシング情報を外部の Zipkin 互換バックエンドに送信できますか？

そうするには、Zipkin 互換インスタンスの完全修飾ドメイン名を使用する必要があります。たとえば：zipkin.mynamespace.svc.cluster.local。

Istio は vert.x イベントバスメッセージのリクエストトレーシングをサポートしていますか？

Istio は現在、pub/sub およびイベントバスプロトコルをサポートしていません。これらのテクノロジーの使用はベストエフォートであり、破損する可能性があります。

トラフィック管理

Istio で設定した現在のルートルールを表示するにはどうすればよいですか？

ルールはkubectl get virtualservice -o yaml を使用して表示できます。

サイドカープロキシは、どのポートで着信トラフィックをキャプチャしますか？

Istio はデフォルトですべてのポートで着信トラフィックをキャプチャします。traffic.sidecar.istio.io/includeInboundPorts pod アノテーションを使用してキャプチャするポートの明示的なリストを指定するか、traffic.sidecar.istio.io/excludeOutboundPorts を使用してバイパスするポートのリストを指定することにより、この動作をオーバーライドできます。

MUTUAL と ISTIO_MUTUAL TLS モードの違いは何ですか？

これらのDestinationRule設定の両方とも、相互TLSトラフィックを送信します。ISTIO_MUTUALでは、Istio証明書が自動的に使用されます。MUTUALの場合、キー、証明書、および信頼できるCAを設定する必要があります。これにより、非Istioアプリケーションとの相互TLSの開始が可能になります。

Istio は StatefulSet とヘッドレスサービスで使用できますか？

はい、Istio はIstio 1.10以降、これらのワークロードを完全にサポートしています。

ルートルールなしで標準の Ingress 仕様を使用できますか？

ホスト、TLS、および正確なパスベースのマッチングを使用した単純な Ingress 仕様は、ルートルールを必要とせずにすぐに機能します。ただし、Ingress リソースで使用されるパスに.文字を含めないでください。

たとえば、次の Ingress リソースは、example.com ホストのリクエストと、/helloworld を URL として一致させます。

$ kubectl create -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: simple-ingress
  annotations:
    kubernetes.io/ingress.class: istio
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /helloworld
        pathType: Prefix
        backend:
          service:
            name: myservice
            port:
              number: 8000
EOF

ただし、次のルールは、パスに正規表現とingress.kubernetes.ioアノテーションを使用しているため機能しません。

$ kubectl create -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: this-will-not-work
  annotations:
    kubernetes.io/ingress.class: istio
    # Ingress annotations other than ingress class will not be honored
    ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /hello(.*?)world/
        pathType: Prefix
        backend:
          service:
            name: myservice
            port:
              number: 8000
EOF

CORS 設定が機能しないのはなぜですか？

CORS 設定を適用した後、何も起こらなかったように見え、何が間違っていたのか疑問に思うかもしれません。CORS は一般的に誤解されている HTTP の概念であり、設定する際に混乱を招くことがよくあります。

これを理解するには、一歩下がってCORS とは何であるかと、いつ使用するべきかを検討することが役立ちます。デフォルトでは、ブラウザはスクリプトによって開始された「クロスオリジン」リクエストに制限があります。これにより、たとえば、ウェブサイトattack.example.comがbank.example.comに JavaScript リクエストを行い、ユーザーの機密情報を盗むことが防止されます。

このリクエストを許可するには、bank.example.comがattack.example.comにクロスオリジンリクエストを実行することを許可する必要があります。ここで CORS が役立ちます。Istio が有効なクラスタでbank.example.comを提供している場合、これを許可するcorsPolicyを設定できます。

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: bank
spec:
  hosts:
  - bank.example.com
  http:
  - corsPolicy:
      allowOrigins:
      - exact: https://attack.example.com
...

この場合、1 つのオリジンを明示的に許可しています。ワイルドカードは、機密性の低いページによく使用されます。

これを行った後、よくある間違いはcurl bank.example.com -H "Origin: https://attack.example.com"のようなリクエストを送信し、リクエストが拒否されることを期待することです。しかし、curl や他の多くのクライアントは、拒否されたリクエストを見ることができません。なぜなら、CORS はブラウザの制約だからです。CORS 設定は、レスポンスにAccess-Control-*ヘッダーを追加するだけです。レスポンスが適切でない場合にリクエストを拒否するのはクライアント（ブラウザ）の役割です。ブラウザでは、これはプリフライトリクエストによって行われます。

Istio はどのプロトコルをサポートしていますか？

現在、Istio は TCP ベースのプロトコルをサポートしています。さらに、Istio はhttpやmysqlなどの他のプロトコルについても、ルーティングやメトリクスなどの機能を提供しています。

すべてのプロトコルのリストと、プロトコルの設定方法については、プロトコルの選択ドキュメントを参照してください。