アプリケーション要件

約5分

Istioは、アプリケーションコードへの影響を最小限に抑えながら、アプリケーションに多くの機能を提供します。多くのKubernetesアプリケーションは、一切変更を加えることなく、Istio対応クラスタにデプロイできます。しかし、Istioのサイドカーモデルには、Istio対応アプリケーションをデプロイする際に特別な考慮が必要となる場合があります。このドキュメントでは、これらのアプリケーションに関する考慮事項と、Istio対応の具体的な要件について説明します。

Podの要件

メッシュの一部となるには、Kubernetes Podは次の要件を満たしている必要があります。

アプリケーションUID: Podで、ユーザーID（UID）値が1337のユーザーとしてアプリケーションを実行しないようにしてください。1337はサイドカープロキシ用に予約されています。
NET_ADMINおよびNET_RAW機能: クラスタでPodセキュリティポリシーが有効になっている場合、およびIstio CNIプラグインを使用しない限り、PodはNET_ADMINおよびNET_RAW機能を許可する必要があります。Envoyプロキシの初期化コンテナは、これらの機能を必要とします。
PodでNET_ADMINおよびNET_RAW機能が許可されているかどうかを確認するには、そのサービスアカウントが、NET_ADMINおよびNET_RAW機能を許可するPodセキュリティポリシーを使用できるかどうかを確認する必要があります。Podのデプロイメントでサービスアカウントを指定していない場合、Podはデプロイメントのネームスペースにあるdefaultサービスアカウントを使用して実行されます。
サービスアカウントの機能を一覧表示するには、次のコマンドで<あなたのネームスペース>および<あなたのサービスアカウント>をあなたの値に置き換えてください。
```
$ for psp in $(kubectl get psp -o jsonpath="{range .items[*]}{@.metadata.name}{'\n'}{end}"); do if [ $(kubectl auth can-i use psp/$psp --as=system:serviceaccount:<your namespace>:<your service account>) = yes ]; then kubectl get psp/$psp --no-headers -o=custom-columns=NAME:.metadata.name,CAPS:.spec.allowedCapabilities; fi; done
```
たとえば、defaultネームスペースのdefaultサービスアカウントを確認するには、次のコマンドを実行します。
```
$ for psp in $(kubectl get psp -o jsonpath="{range .items[*]}{@.metadata.name}{'\n'}{end}"); do if [ $(kubectl auth can-i use psp/$psp --as=system:serviceaccount:default:default) = yes ]; then kubectl get psp/$psp --no-headers -o=custom-columns=NAME:.metadata.name,CAPS:.spec.allowedCapabilities; fi; done
```
サービスアカウントの許可されたポリシーのいずれかの機能リストにNET_ADMINおよびNET_RAWまたは*が表示された場合、PodはIstio初期化コンテナを実行する権限を持っています。そうでない場合は、権限を付与する必要があります。
Podラベル: アプリケーション識別子とバージョンをPodラベルを使用して明示的に宣言することをお勧めします。これらのラベルは、Istioが収集するメトリクスとテレメトリにコンテキスト情報を追加します。これらの値は、優先順位の高い順に複数のラベルから読み取られます。
- アプリケーション名: service.istio.io/canonical-name、app.kubernetes.io/name、またはapp。
- アプリケーションバージョン: service.istio.io/canonical-revision、app.kubernetes.io/version、またはversion。
名前付きサービスポート: プロトコルを明示的に指定するために、サービスポートに名前を付けることができます。詳細については、プロトコル選択を参照してください。Podが複数のKubernetesサービスに属している場合、サービスはHTTPとTCPなど、異なるプロトコルに対して同じポート番号を使用できません。

Istioが使用するポート

Istioサイドカープロキシ（Envoy）は、次のポートとプロトコルを使用します。

ポート	プロトコル	説明	Pod内のみ
15000	TCP	Envoy管理ポート（コマンド/診断）	はい
15001	TCP	Envoyアウトバウンド	いいえ
15004	HTTP	デバッグポート	はい
15006	TCP	Envoyインバウンド	いいえ
15008	HTTP2	HBONE mTLSトンネルポート	いいえ
15020	HTTP	Istioエージェント、Envoy、およびアプリケーションからの統合Prometheusテレメトリ	いいえ
15021	HTTP	ヘルスチェック	いいえ
15053	DNS	キャプチャが有効になっている場合のDNSポート	はい
15090	HTTP	Envoy Prometheusテレメトリ	いいえ

Istioコントロールプレーン（istiod）は、次のポートとプロトコルを使用します。

ポート	プロトコル	説明	ローカルホストのみ
443	HTTPS	Webhookサービスポート	いいえ
8080	HTTP	デバッグインターフェース（非推奨、コンテナポートのみ）	いいえ
15010	GRPC	XDSおよびCAサービス（プレーンテキスト、セキュアネットワークのみ）	いいえ
15012	GRPC	XDSおよびCAサービス（TLSおよびmTLS、本番環境での使用に推奨）	いいえ
15014	HTTP	コントロールプレーンの監視	いいえ
15017	HTTPS	Webhookコンテナポート（443から転送）	いいえ

サーバーファーストプロトコル

一部のプロトコルは「サーバーファースト」プロトコルであり、サーバーが最初のバイトを送信することを意味します。これにより、PERMISSIVE mTLSと自動プロトコル選択に影響を与える可能性があります。

これらの機能はどちらも、接続の最初のバイトを検査してプロトコルを決定することで機能するため、サーバーファーストプロトコルとは互換性がありません。

これらのケースをサポートするには、明示的なプロトコル選択の手順に従って、アプリケーションのプロトコルをTCPとして宣言します。

次のポートは、一般的にサーバーファーストプロトコルを伝送することが知られており、自動的にTCPと見なされます。

プロトコル	ポート
SMTP	25
DNS	53
MySQL	3306
MongoDB	27017

TLS通信はサーバーファーストではないため、TLSで暗号化されたサーバーファーストトラフィックは、TLSスニッフィングの対象となるすべてのトラフィックが暗号化されていることを確認する限り、自動プロトコル検出で機能します。

サーバーに対してmTLSモードSTRICTを設定します。これにより、すべての要求に対してTLS暗号化が強制されます。
サーバーに対してmTLSモードDISABLEを設定します。これにより、TLSスニッフィングが無効になり、サーバーファーストプロトコルを使用できるようになります。
すべてのクライアントがTLSトラフィックを送信するように設定します。一般的にはDestinationRuleを使用するか、自動mTLSに依存します。
アプリケーションが直接TLSトラフィックを送信するように設定します。

アウトバウンドトラフィック

Istioのトラフィックルーティング機能をサポートするために、Podから送信されるトラフィックは、サイドカーがデプロイされていない場合とは異なる方法でルーティングされる場合があります。

HTTPベースのトラフィックの場合、トラフィックはHostヘッダーに基づいてルーティングされます。宛先IPとHostヘッダーが一致しない場合、予期しない動作が発生する可能性があります。たとえば、curl 1.2.3.4 -H "Host: httpbin.default"のようなリクエストは、1.2.3.4ではなくhttpbinサービスにルーティングされます。

HTTPベースではないトラフィック（HTTPSを含む）の場合、IstioはHostヘッダーにアクセスできないため、ルーティングの決定はサービスIPアドレスに基づいて行われます。

この1つの意味は、サービスではなくPodへの直接呼び出し（たとえば、curl <POD_IP>）は一致しないことです。トラフィックは通過する可能性がありますが、mTLS暗号化、トラフィックルーティング、およびテレメトリを含むIstioの完全な機能は得られません。

詳細については、トラフィックルーティングページを参照してください。