ついに1週間ほど前にIstio 1.1がリリースされました!
個人的にエンドユーザーの認証に関する機能を待ち望んでいたので、1ヶ月ほど前からIstioコミュニティの動きを注視していました。
注目のIstio 1.0.6からの変更点ですが、https://istio.io/about/notes/1.1/にまとめてくださっているので、今回は確認も兼ねてhttps://istio.io/about/notes/1.1/を日本語訳してみたいと思います。
Istio 1.1
Istio 1.1をリリースしました。 Google、IBM、VMware、Huawei、RedHat、Cisco、SAP、Salesforce、Pivotal、SUSE、Datadog、LightStepなどの協力により、修正と機能の開発を行い、ここ8か月間で製品全体を大幅に改善しました。 フィードバックと機能に関するご要望をいただいた、また、さまざまな規模でリリース候補のバージョンをテストしてくださったすべてのエンドユーザーに感謝します。
これらのリリースノートでは、Istio 1.0.6とIstio 1.1の違いについて説明しています。
Upgrades
私たち(Istio開発コミュニティ)は、コントロールプレーンとデータプレーンを手動で1.1にアップグレードすることをお勧めします。詳しくはUpgradesをご覧ください。
Installation
Istioインストールとは別にCRD(Custom Resource Definition)をインストール
IstioのCustom Resource Definitions(CRDs)をistio-initのHelm chartに設置します。 独自のHelmチャートにCRDsを配置することで、アップグレードプロセス中のカスタムリソースコンテンツのデータの継続性が維持され、IstioをHelmベースのインストールを超えてさらに進化させることができます。
インストール構成プロファイル
よく知られテストされたパターンを使用してインストールプロセスを簡素化するためにいくつかのインストール設定プロファイルを追加しました。installation profile featureより優れたユーザーエクスペリエンスについての詳細を学んでください。
改善されたマルチクラスタ統合
multicluster VPNおよびmulticluster split horizonリモートクラスターのインストールに使用されていた1.0 istio-remoteチャートをIstio Helmチャートに統合して、運用エクスペリエンスを簡素化しました。
Traffic management
Sidecar
リソースの追加
新しいSidecar
リソースにより、Namespace
内のワークロードに付随するサイドカープロキシの動作をよりきめ細かく制御できます。 特に、Service
のセットに対して、サイドカーが送信するトラフィックを制限するためのサポートを追加します。これにより、計算されてプロキシに送信される設定の量が減り、起動時間、リソース消費、およびコントロールプレーンのスケーラビリティが向上します。大規模な導入では、Namespace
ごとにSidecar
リソースを追加することをお勧めします。高度なユースケースのために、ポート、プロトコル、およびトラフィックキャプチャの制御も提供されています。
Service
の可視性の制限
exportTo
機能を追加し、サービスの所有者がどのNamespace
が自分のサービスを参照できるかを制御できるようになりました。 この機能はServiceEntry
, VirtualService
に追加され、networking.istio.io/exportTo
アノテーションを介してKubernetesサービスでもサポートされています。
Namespace Scoping
Gateway
でVirtualService
を参照するときは、Istioの構成モデルでは、DNSベースの名前マッチングを行っています。 同じホスト名に対して複数のネームスペースが仮想サービスを定義している場合、これはあいまいになる可能性があります。 あいまいさを解決するために、hosts
フィールドに[{namespace-name}] / {hostname-match}
の形式の構文を使用して、これらの参照を名前空間で明示的に範囲指定することが可能になりました。同等の機能は、egress用のSidecar
でも利用できます。
ServiceEntryリソースの更新
相互TLSで使用するサービスの局所性と関連するSANを指定するためのサポートが追加されました。 HTTPSポートを持つサービスエントリは、SNIベースのルーティングを有効にするために追加の仮想サービスを必要としなくなりました。
Locality-Aware Routing
他の地域のサービスを選択する前に、同じ地域のサービスへルーティングを行うための完全サポートを追加しました。Locality Load Balancer Settingsを参照してください。
洗練されたマルチクラスタルーティング
マルチクラスタ設定を簡略化し、追加の展開モードを有効にしました。 Pod
レベルのVPNを必要とせずに単純にそれらのIngress Gateway
を使用して複数のクラスタを接続し、高可用性のために各クラスタにコントロールプレーンを展開し、グローバルネームスペースを作成するために複数のクラスタにわたってネームスペースにまたがることができます。高可用性コントロールプレーンソリューションでは、ローカリティ対応ルーティングがデフォルトで有効になっています。
Istio Ingressは非推奨
以前に非推奨になったIstio Ingressを削除しました。 ゲートウェイでKubernetesのIngress
リソースを使用する方法の詳細については、Cert-Managerを使用したKubernetes Ingressの保護の例を参照してください。
パフォーマンスとスケーラビリティの向上
IstioとEnvoyのパフォーマンスとスケーラビリティを調整しました。パフォーマンスとスケーラビリティの強化に関する詳細をお読みください。
デフォルトでアクセスログを無効化
パフォーマンスを向上させるために、デフォルトですべてのEnvoyサイドカーのアクセスログを無効にしました。
Security
Readiness Probes
と Liveness Probes
相互TLSが有効になっている場合のKubernetesのHTTPのreadiness probes
とliveness probes
のサポートを追加しました。
クラスタRBACの設定
正しいクラスタスコープを実装するために、RbacConfig
リソースをClusterRbacConfig
リソースに置き換えました。 移行手順については、RbacConfig
からClusterRbacConfig
への移行を参照してください。
SDSによるアイデンティティプロビジョニング
Envoyを再起動せずに、ノード上でのキー生成と動的な証明書ローテーションで、より強力なセキュリティを提供するためのSDSサポートを追加しました。詳細については、SDSを介したIDのプロビジョニングを参照してください。
TCPサービスの承認
HTTPおよびgRPCサービスに加えて、TCPサービスに対する認証のサポートを追加しました。詳しくは、TCPサービスの認可を参照してください。
エンドユーザーグループの承認
groups
クレームまたはJWTのリストタイプクレームに基づく認可を追加しました。詳細については、groups
とリストクレームの認可を参照してください。
Ingress Gatewayコントローラでの外部証明書管理
外部証明書を動的にロードおよびローテーションするためのコントローラを追加しました。
カスタムPKI統合
Vaultで保護された署名鍵のサポートと既存のVault PKIとの統合機能を備えたVault PKI統合を追加しました。詳細については、Istio Vault CAの統合を参照してください。
カスタマイズされた(非cluster.local)信頼ドメイン
ID内の組織固有またはクラスタ固有の信頼ドメインのサポートを追加しました。
Policy and telemetry
ポリシーチェックはデフォルトで無効化
ほとんどの顧客シナリオでパフォーマンスを向上させるために、デフォルトでのポリシーチェックを無効にするように変更しました。 ポリシーチェックを有効にするには、必要に応じてIstioポリシーチェックをオンにする方法を参照してください。
Kiali
より豊富な視覚化体験を提供するために、Service Graph
アドオンをKialiに置き換えました。詳しくはKialiのタスクを見てください。
オーバーヘッドの削減
以下を含む、いくつかのパフォーマンスとスケールの向上を追加しました。
- Envoyが生成した統計のデフォルト収集の大幅な削減。
- ミキサーワークロードに負荷制限機能を追加。
- EnvoyとMixer間のプロトコルを改善。
ヘッダとルーティングの制御
受信するリクエストのヘッダとルーティングに影響を与えるアダプタを作成するオプションを追加しました。 詳細については、制御ヘッダーとルーティングタスクを参照してください。
プロセス外アダプタ
プロダクション用にプロセス外アダプタ機能を追加しました。その結果、このリリースではプロセス内アダプタモデルを非推奨にしました。すべての新しいアダプタ開発は、先行のプロセス外モデルを使用する必要があります。
トレーシングの改善
全体的なトレーシングストーリーで多くの改良を行いました:
- トレースIDは128ビット幅になりました
- LightStepへのトレースデータ送信のサポートを追加しました
- Mixer-Backedサービスのトレースを完全に無効にするオプションを追加しました
- ポリシー決定を意識したトレースを追加しました
デフォルトのTCPメトリクス
TCP接続を追跡するためのデフォルトのメトリクスを追加しました。
アドオンに対するロードバランサの要件の削減
別のロードバランサーを介してアドオンを公開するのを停止しました。 代わりに、アドオンはIstioゲートウェイ経由で公開されます。 HTTPまたはHTTPSプロトコルを使用してアドオンを外部に公開するには、アドオンゲートウェイのドキュメントを使用してください。
アドオンの認証情報の保護
アドオン資格情報の保存場所を変更しました。 Grafana
、Kiali
、Jaeger
のパスワードとユーザー名は、セキュリティとコンプライアンスを向上させるためにKubernetesのSecret
に格納されています。
statsd
コレクタによるさらなる柔軟性
組み込みのstatsd
コレクタを削除しました。 Istioは、既存のKubernetes deploymentsでの柔軟性を向上させるために、独自のstatsd
をサポートするようになりました。
Configuration management
Galley
Istio内の主要な設定取り込みおよび配布メカニズムとしてGalley
を追加しました。 それは、Kubernetesの詳細からIstioコンポーネントを絶縁して、Istioコンポーネントに構成状態を検証し、変換し、そして分配するための堅牢なモデルを提供します。 Galley
はMesh Configuration Protocol(MCP)を使用してコンポーネントと対話します。
モニタリングポート
Galley
のデフォルトのモニタリングポートを9093から15014に変更しました。
istioctl
and kubectl
コマンドを検証します
Istio Kubernetesリソースのオフライン検証用のistioctl validate
コマンドを追加しました。
インストール検証コマンド
指定されたインストールYAMLファイルを指定してIstioインストールのステータスを確認するためのistioctl experimental verify-install
コマンドを追加しました。
非推奨になるコマンド
istioctl create
、istioctl replace
、istioctl get
、およびistioctl delete
コマンドは非推奨です。 代わりに同等のkubectlを使用してください。istioctl gen-deploy
コマンドも非推奨になりました。 代わりにhelmテンプレートを使用してください。 リリース1.2ではこれらのコマンドが削除されます。
短いコマンド
Gateway
、VirtualService
、DestinationRule
、およびServiceEntry
用の短いコマンドをkubectl
に追加しました。