バージョン 1.6 以降の Istio on Google Kubernetes Engine アドオンでは、インストールと構成に Istio Operator が使用されます。Istio Operator は Kubernetes のOperator パターンに従います。Operator を使用すると、Istio のインストールに Kubernetes カスタム リソース定義（CRD）を定義することで Istio を構成できます。そうすると Operator はコントローラを使用して、カスタム リソースに一致するようインストールを変更します。
クラスタを 1.17.9-gke.6300 以降にアップグレードすると、Istio 1.6 Operator とコントロール プレーンが既存の 1.4.x Istio コントロール プレーンとともにインストールされます。アップグレードには、ユーザーの操作が必要です。また、デュアル コントロール プレーンのアップグレード（Istio ドキュメントでは、カナリア アップグレード）のプロセスに従う必要があります。デュアル コントロール プレーンのアップグレードでは、ワークロード上にラベルを付けて新しいコントロール プレーンをポイントし、ローリング再起動を実行することで、1.6 バージョンに移行できます。
Istio on GKE アドオンの 1.5 バージョンはリリースしません。バージョン 1.6 は、1.4.10 の後にリリースされるバージョンです。
- クラスタを GKE バージョン 1.17 以降にアップグレードすると、組み込み Ingress ゲートウェイはアップグレード プロセス中に約 5 分間使用できなくなります。これにより、Ingress Deployment に対してユーザーが行った変更は失われます。この問題を回避するには、ゲートウェイの追加での説明に従って、個別のユーザー定義ゲートウェイをインストールして管理することをおすすめします。
- R33 より前のバージョンの GKE 1.16 から 1.17 と 1.18 へのアップグレードには既知の問題があります。修正版は、バージョン 1.17.12-gke.1501 以降と 1.18.9-gke.1501 以降でご利用いただけます。この問題により、アップグレード中に istio システムの名前空間に作成したカスタム リソースが削除されます。これらのリソースは手動で再作成する必要があります。該当するバージョンのみにアップグレードするようにしてください。この問題はアップグレード中にのみ発生するため、新しいクラスタへの影響はありません。
Istio Operator のメリット
Operator によってインストールの構成の柔軟性が向上しています。1.6 より前のバージョンのアドオンでは、GKE アドオン マネージャーによって Istio マニフェストに変更が調整され、ほとんどの構成変更ができなくなります。Istio Operator にこの制限はありません。Operator は、インストール時に指定した IstioOperator カスタム リソース（CR）に基づいて Istio コントロール プレーンのインストール マニフェストを生成します。この CR はユーザーが完全に管理しているため、調整されることはありません。
Operator を使用して Istio 1.6 にアップグレードした後、Istio on GKE アドオンから Istio のオープンソース バージョンに移行できます。
Operator による Istio 1.6 へのアップグレード
Operator に移行するには、これらの手順を一度だけ行います。その後のアップグレードは、デュアル コントロール プレーンのアップグレード プロセスに従います。
Istio 1.6（1.17.7-gke.8+、1.17.8-gke.6+）を含む GKE バージョンを選択し、クラスタをアップグレードします。
Istio 1.6 の Istio on Google Kubernetes Engine アドオンは、次の 2 つのバージョンの Istio をインストールします。
アドオン マネージャーによって制御される静的マニフェスト バージョン（クラスタをアップグレードした後にアクティブになります）。
Operator によって制御される 1.6 のバージョン（有効化されるまで非アクティブ）。非アクティブな 1.6 バージョンはどのプロキシにも接続されず、無視できるクラスタ リソースを消費します。
インストールされた Istio のバージョンがインストール先の静的マニフェスト バージョンと異なる場合、クラスタをアップグレードすると、Istio のインプレース アップグレードも実行される可能性があります。たとえば、クラスタで現在 Istio 1.4.6-gke.0 が実行され、GKE クラスタ バージョン 1.17.7.gke-8 を選択すると、アップグレードの一環として Istio コントロール プレーンが 1.4.10-gke.0（またはそれ以降）にアップグレードされます。
1.6 バージョンの Istio がインストールされ、実行されていることを確認します。
kubectl get pods -n istio-systemistiodPod が 1.4 コントロール プレーン コンポーネントとともに実行されていることを確認します。次に例を示します。NAME READY STATUS RESTARTS AGE istio-citadel-78b9b5b589-52cqg 1/1 Running 0 4m16s istio-galley-79bd448645-zxfjm 1/1 Running 0 4m16s istio-ingressgateway-b4f8986c4-dbr6c 1/1 Running 0 4m27s istio-pilot-dc558d859-cnrqt 2/2 Running 1 4m16s istio-policy-8664dd6c4-m42xs 2/2 Running 1 4m15s istio-security-post-install-1.4.10-gke.4-255r6 0/1 Completed 0 4m15s istio-sidecar-injector-7f85d7f7c4-vt2x9 1/1 Running 0 4m15s istio-telemetry-69b6477c5f-4pr6v 2/2 Running 2 4m15s <b>istiod-istio-163-5fccfcf4dd-2p9c8 1/1 Running 0 3m31s</b> prometheus-7d9f49d945-4nps2 2/2 Running 0 3m17s promsd-696bcc5b96-ln2s8 2/2 Running 1 4m15sサポートされていない
v1alpha1セキュリティ ポリシー構成オブジェクトが移行されていることを確認してください。詳細については、Istio アップグレード ノートをご覧ください。1.4.x コントロール プレーンで構成の検証を無効にします。
galley
ClusterRoleリソースを編集します。kubectl edit clusterrole -n istio-system istio-galley-istio-system次のリストエントリ内の
'*'値をgetに変更します。- apiGroups: - admissionregistration.k8s.io resources: - validatingwebhookconfigurations verbs: - '*' # change this to get更新後、コードは次のようになります。
- apiGroups: - admissionregistration.k8s.io resources: - validatingwebhookconfigurations verbs: - getGallery
ValidatingWebhookConfigurationを削除します。kubectl delete ValidatingWebhookConfiguration istio-galley -n istio-system
名前空間を 1.6 に移行する
新しいリビジョンをインストールしても、既存のサイドカー プロキシには影響しません。これらをアップグレードするには、新しいコントロール プレーンを指すように構成する必要があります。これは、名前空間ラベル istio.io/rev に基づいたサイドカー インジェクションで制御されます。
正確な Istio 1.6 のバージョン番号を確認します。
kubectl -n istio-system get pods -lapp=istiod --show-labels
このコマンドの出力は、次のようになります。
NAME READY STATUS RESTARTS AGE LABELS istiod-istio-163-5fccfcf4dd-2p9c8 1/1 Running 0 22h app=istiod,istio.io/rev=istio-163,istio=istiod,pod-template-hash=5fccfcf4dd
この例のバージョンは
istio-163です。1.6 にロールオーバーするワークロードを含む名前空間のラベルを再変更します。バージョン ラベルは、コントロール プレーンのバージョンと一致している必要があります。次のコマンドで、
VERSIONを前のコマンド（istio-163など）と置き換えます。kubectl label namespace NAMESPACE istio-injection- istio.io/rev=VERSION --overwrite
選択したワークロードのローリング再起動を実行します。
kubectl rollout restart deployment DEPLOYMENT -n NAMESPACE
名前空間内の Pod を一覧表示します。
kubectl get pods -n NAMESPACE
いずれかの Pod を選択して、1.6 プロキシのサイドカー プロキシでワークロードが挿入されたことを確認します。
kubectl describe pod -n NAMESPACE YOUR_SELECTED_POD
出力には、次のような 1.6 バージョンのプロキシ コンテナが表示されます。
... istio-proxy: Container ID: docker://22f62020ddcc6f8e02d800b5614e02aae2d082ce991c9e3eab9846d9f2cf90f5 Image: gcr.io/gke-release/istio/proxyv2:1.6.3-gke.0 ...すべての名前空間を新しい Istio バージョンに移行します。すべてのワークロードの名前空間に対して手順 3 ～ 5 を繰り返します。
Anthos Service Mesh に移行する場合は、古いコントロール プレーンをオフにするに進んでください。
Istio アドオンを引き続き使用するには、次の手順に従って、Ingress ゲートウェイを新しい Istio バージョンに移行させます。
IstioOperatorCR を編集して、Ingress ゲートウェイを 1.6 バージョンに置き換えます。kubectl edit istiooperators -n istio-system istio-1-6-3-gke-0ゲートウェイの
enabled設定をtrueに変更します。... spec: components: ingressGateways: - enabled: false # change this to true name: istio-ingressgatewayゲートウェイ Pod が新しい 1.6 バージョンで再作成されていることを確認します。
kubectl get pods -n istio-system -l app=istio-ingressgateway -o yaml | grep image
古いコントロール プレーンを停止する
すべてのワークロード プロキシが 1.6 コントロール プレーンを使用するようになると、古いコンポーネントのレプリカを 0 にスケーリングすることで、古いコントロール プレーンを停止できます。
レプリカをスケールダウンするには、次のコマンドを実行します。
kubectl scale deploy -n istio-system --replicas=0 \
istio-citadel istio-galley istio-pilot istio-policy istio-sidecar-injector istio-telemetry prometheus promsd
残りの Istio リソースは問題なくクラスタに残すことができます。
Istio を引き続き使用している場合は、IstioOperator CR を編集して、独自のスケジュールで Operator をアップグレードできます。詳細については、Operator のドキュメントをご覧ください。
Anthos Service Mesh に移動する
Anthos Service Mesh に移行する前に、下で説明するように Operator を無効にする必要があります。移行後も、Operator と同じ IstioOperator CR 形式を使用してサービス メッシュを構成します。ただし、Operator コントローラが継続してクラスタ内の IstioOperator CR を監視するのではなくインストール状態を変更する場合は、istioctl
install コマンドを使用してそのようにします。
Anthos Service Mesh に移行するには、Cloud プロジェクトとクラスタの準備に関するすべての詳細を処理する Google 提供のスクリプトを使用し、続いて istioctl install の Anthos Service Mesh バージョン使用して Anthos Service Mesh をインストールします。Anthos Service Mesh 1.7 への移行をおすすめしますが、1.6 のサービス スクリプトを使用して Anthos Service Mesh 1.6 へも移行できます。
要件
クラスタが次の要件を満たしていることを確認します。
4 つ以上の vCPU を備えたマシンタイプ（
e2-standard-4など）。クラスタのマシンタイプに 4 つ以上の vCPU がない場合は、異なるマシンタイプへのワークロードの移行の説明に従ってマシンタイプを変更します。ノードの最小数は、マシンタイプによって異なります。Anthos Service Mesh には、8 つ以上の vCPU が必要です。4 つの vCPU を持つマシンタイプの場合、クラスタには少なくとも 2 つのノードが必要です。8 つの vCPU を持つマシンタイプの場合、クラスタに必要なノードは 1 つだけです。ノードを追加する必要がある場合は、クラスタのサイズ変更をご覧ください。
このスクリプトでは、クラスタで Workload Identity を有効にします。Workload Identity は、Google API を呼び出すためのおすすめの方法です。Workload Identity を有効にすると、Workload Identity の制限事項で説明されているように、ワークロードから Google API への呼び出し方法が変わります。
サービス メッシュに含めるには、サービスポートに名前を付ける必要があります。名前には、
name: protocol[-suffix]の構文でポートのプロトコルを含める必要があります。角かっこは、ダッシュで始まるオプションの接尾辞です。詳細については、サービスポートの命名をご覧ください。限定公開クラスタに Anthos Service Mesh をインストールする場合は、ファイアウォールでポート 15017 を開き、自動サイドカー インジェクションで使用される Webhook が適切に機能する必要があります。詳細については、限定公開クラスタのポートを開くをご覧ください。
組織にサービス境界を作成した場合は、Mesh CA サービスを境界に追加する必要があります。詳細については、サービス境界へのメッシュ CA の追加をご覧ください。
移行の計画を作成する
移行の計画立案にあたり、Istio からの移行の準備をご覧ください。
Operator の無効化
Operator が Anthos Service Mesh によってインストールされた istio-ingressgateway を調整しないようにするには、Operator を無効にする必要があります。
Operator を無効にするには、次のようにします。
Operator のバージョンを取得します。
kubectl get istiooperators -n istio-system出力は次のようになります。
NAME REVISION STATUS AGE istio-1-6-11-gke-0 istio-1611 HEALTHY 12h
サンプル出力の Operator のバージョンは
istio-1-6-11-gke-0です。Operator を無効にします。次のコマンドの VERSION は、前の手順で取得した Operator のバージョンに置き換えます。
kubectl patch -n istio-system istiooperator VERSION -p '{"spec":{"profile":"disabled"}}' --type=mergeこのコマンドにより、オペレーターはクラスタに変更を加えることができなくなります。
Anthos Service Mesh に移行する
このセクションでは、install_asm スクリプトを使用して Anthos Service Mesh に移行する方法について説明します。Anthos Service Mesh 1.7 に移行することをおすすめしますが、Anthos Service Mesh 1.6 への移行もサポートされています。
1.7 への移行
install_asmスクリプトをダウンロードします。スクリプトのオプションとフラグを確認します。
Istio のインストールをカスタマイズしておらず、認証局（CA）として Citadel を引き続き使用する場合は、スクリプトに次の引数を指定して Anthos Service Mesh に移行できます。
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME\ --cluster_location CLUSTER_LOCATION \ --mode migrate \ --ca citadel \ --enable_apisAnthos Service Mesh 1.7 では、外向きゲートウェイで有効にするなど、よく使用する機能のために、GitHub で利用できるオーバーレイ ファイルも用意されています。詳細については、オプション機能の有効化をご覧ください。
Anthos Service Mesh の設定を完了するには、自動サイドカー インジェクションを有効にして、ワークロードをデプロイまたは再デプロイする必要があります。
1.6 への移行
install_asmスクリプトをダウンロードします。スクリプトのオプションとフラグを確認します。
Istio のインストールをカスタマイズしておらず、認証局（CA）として Citadel を引き続き使用する場合は、スクリプトに次の引数を指定して Anthos Service Mesh に移行できます。
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME\ --cluster_location CLUSTER_LOCATION \ --mode migrate \ --ca citadel \ --enable_apisAnthos Service Mesh の設定を完了するには、自動サイドカー インジェクションを有効にして、ワークロードをデプロイまたは再デプロイする必要があります。
移行後
次のコマンドを実行します。VERSION は、以前に Operator を無効にするために使用した Operator のバージョンに置き換えます。
kubectl patch -n istio-system istiooperator VERSION -p '{"spec":{"profile":"empty"}}'
このコマンドによって、empty プロファイルを持つ Operator が再び有効にされます。これにより、Operator は以前にクラスタからインストールしたリソースを削除します。これには、install_asm スクリプトによってインストールされたゲートウェイまたはコントロール プレーンの要素は含まれません。