Istio v1 API のご紹介
Istio の機能の安定性を反映して、ネットワーキング、セキュリティ、テレメトリー API が 1.22 で v1 に昇格しました。
Istio は、サービスメッシュ内のサービスの堅牢なセキュリティ、シームレスな接続性、効果的な可観測性を確保するために重要な、ネットワーキング、セキュリティ、テレメトリー API を提供します。これらの API は、世界中の何千ものクラスターで使用されており、重要なインフラストラクチャを保護および強化しています。
これらの API によって提供される機能のほとんどは、しばらくの間安定しているとみなされてきましたが、API バージョンは v1beta1 のままでした。これらのリソースの安定性、採用、価値を反映して、Istio コミュニティは Istio 1.22 でこれらの API を v1 に昇格させることを決定しました。
Istio 1.22 では、以下の API を v1 に昇格させるために集中的な取り組みが行われたことを発表できて嬉しく思います。
- Destination Rule (宛先ルール)
- Gateway (ゲートウェイ)
- Service Entry (サービスエントリ)
- Sidecar (サイドカー)
- Virtual Service (仮想サービス)
- Workload Entry (ワークロードエントリ)
- Workload Group (ワークロードグループ)
- Telemetry API (テレメトリー API)*
- Peer Authentication (ピア認証)
機能の安定性と API バージョン
Kubernetes や Istio で使用されているような宣言型 API は、リソースの記述を、それに基づいて動作する実装から切り離します。
Istio の機能段階の定義では、安定した機能（あらゆる規模の本番環境での使用準備が整っており、正式な非推奨ポリシーが付属している機能）は v1 API と一致させる必要があると説明しています。現在、API バージョンは機能の安定性と一致しており、以前から安定している機能と、このリリースで新たに安定したと指定された機能の両方に対して、この約束を実現しています。
現在のところ、以前の v1beta1 および v1alpha1 API バージョンのサポートを中止する計画はありませんが、ユーザーは既存の YAML ファイルを更新して、v1 API の利用に手動で移行することをお勧めします。
Telemetry API (テレメトリー API)
v1 テレメトリー API は、以前の API バージョンから変更があった唯一の昇格された API です。次の v1alpha1 機能は v1 に昇格しませんでした。
metrics.reportingIntervalレポート間隔では、メトリクスレポートのための呼び出し間の時間を構成できます。現在は TCP メトリクスのみをサポートしていますが、将来的には長時間の HTTP ストリームにも使用する可能性があります。
現時点では、Istio にはこの機能の必要性を裏付ける使用状況データがありません。
accessLogging.filter指定した場合、このフィルターはログ記録のために特定の要求/接続を選択するために使用されます。
この機能は Envoy の比較的新しい機能に基づいており、Istio は
v1に昇格する前にユースケースと実装をさらに開発する必要があります。
tracing.useRequestIdForTraceSamplingこの値はデフォルトで true です。このリクエスト ID の形式は Envoy に固有であり、ユーザー トラフィックを最初に受信するプロキシによって生成されたリクエスト ID が Envoy に固有でない場合、Envoy はリクエスト ID を解釈できないためトレースを中断します。この値を false に設定することで、Envoy がリクエスト ID に基づいてサンプリングするのを防ぐことができます。
テレメトリー API を介してこれを構成可能にする強力なユースケースはありません。
これらのフィールドに関するフィードバックは、GitHub で issue を作成して共有してください。
Istio CRD の概要
これは、サポートされている API バージョンの完全なリストです。
| カテゴリ | API | バージョン |
|---|---|---|
| ネットワーキング | Destination Rule (宛先ルール) | v1、v1beta1、v1alpha3 |
| Istio Gateway (ゲートウェイ) | v1、v1beta1、v1alpha3 | |
| Service Entry (サービスエントリ) | v1、v1beta1、v1alpha3 | |
| Sidecar (サイドカー) スコープ | v1、v1beta1、v1alpha3 | |
| Virtual Service (仮想サービス) | v1、v1beta1、v1alpha3 | |
| Workload Entry (ワークロードエントリ) | v1、v1beta1、v1alpha3 | |
| Workload Group (ワークロードグループ) | v1、v1beta1、v1alpha3 | |
| プロキシ構成 | v1beta1 | |
| Envoy フィルター | v1alpha3 | |
| セキュリティ | 承認ポリシー | v1、v1beta1 |
| Peer Authentication (ピア認証) | v1、v1beta1 | |
| リクエスト認証 | v1、v1beta1 | |
| テレメトリー | テレメトリー | v1、v1alpha1 |
| 拡張機能 | Wasm プラグイン | v1alpha1 |
Istio は、Kubernetes Gateway API を使用して構成することもできます。
v1 Istio API の使用
Istio には、現在開発中で、リリース間で変更される可能性のある API がいくつかあります。たとえば、Envoy フィルター、プロキシ構成、および Wasm プラグイン API です。
さらに、Istio は、CRD バージョン管理の制限により、API のすべてのバージョンで厳密に同一のスキーマを維持します。したがって、v1 テレメトリー API が存在する場合でも、上記で説明した 3 つの v1alpha1 フィールドは、v1 テレメトリー API リソースを宣言するときにも利用できます。
リスク回避型の環境のために、安定した検証ポリシー、検証アドミッションポリシーを追加しました。これにより、Istio API で v1 API およびフィールドのみが使用されることを保証できます。
新しい環境では、Istio のインストール時に安定した検証ポリシーを選択すると、今後作成または更新されるすべてのカスタムリソースが v1 であり、v1 機能のみが含まれることが保証されます。
このポリシーが、それに準拠していないカスタムリソースを持つ既存の Istio インストールにデプロイされた場合、許可される唯一のアクションは、リソースを削除するか、問題のあるフィールドの使用を削除することです。
安定した検証ポリシーを使用して Istio をインストールするには
$ helm install istio-base -n istio-system --set experimental.stableValidationPolicy=true
ポリシーを使用して Istio をインストールするときに特定のリビジョンを設定するには
$ helm install istio-base -n istio-system --set experimental.stableValidationPolicy=true -set revision=x
この機能は Kubernetes 1.30 以降と互換性があります。検証は CEL 式を使用して作成され、ユーザーは特定のニーズに合わせて検証を変更できます。
まとめ
Istio プロジェクトは、サービスメッシュの正常な運用に不可欠な安定した API と機能を提供することに尽力しています。機能に関する関連するユースケースと安定性の障害を洗練させ続ける際に、適切な意思決定を行うためのガイドとして、皆様からのフィードバックをお待ちしています。issue を作成したり、関連する Istio Slack チャンネルに投稿したり、毎週開催されるワーキンググループミーティングに参加して、フィードバックをお寄せください。
