バージョン 1.6 以降の Istio on Google Kubernetes Engine アドオンでは、インストールと構成に Istio Operator が使用されます。Istio Operator は Kubernetes のOperator パターンに従います。Operator を使用すると、Istio のインストールに Kubernetes カスタム リソース定義（CRD）を定義することで Istio を構成できます。そうすると Operator はコントローラを使用して、カスタム リソースに一致するようインストールを変更します。
クラスタを 1.17.17-gke.3100+、1.18.16-gke.1600+、1.19.8-gke.1600+ にアップグレードすると、Istio 1.6 Operator とコントロール プレーンが既存の 1.4.x Istio コントロール プレーンとともにインストールされます。アップグレードではユーザーの操作が必要で、リビジョンを使用してワークロードを新しいコントロール プレーンに移行します。リビジョンベースのアップグレードでは、ワークロード上のラベルを新しいコントロール プレーンを指すように設定し、ローリング再起動を実行することで、1.6 バージョンに移行します。
Google Kubernetes Engine アドオンの 1.5 バージョンをリリースしません。バージョン 1.6 は、1.4.10 の後にリリースされるバージョンです。
Istio Operator のメリット
Operator によってインストールの構成の柔軟性が向上しています。1.6 より前のバージョンのアドオンでは、GKE アドオン マネージャーによって Istio マニフェストに変更が調整され、ほとんどの構成変更ができなくなります。Istio Operator にこの制限はありません。Operator は、インストール時に指定した IstioOperator カスタム リソース（CR）に基づいて Istio コントロール プレーンのインストール マニフェストを生成します。この CR はユーザーが完全に管理しているため、調整されることはありません。
Operator を使用して Istio 1.6 にアップグレードした後、Istio on GKE アドオンから Istio のオープンソース バージョンまたは Anthos Service Mesh に移行できます。
Operator による Istio 1.6 へのアップグレード
Operator に移行するには、これらの手順を一度だけ行います。その後のアップグレードは、デュアル コントロール プレーンのアップグレード プロセスに従います。
Istio 1.6（1.17.17-gke.3100+、1.18.16-gke.1600+、1.19.8-gke.1600+）を含む 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.3100 を選択すると、アップグレードの一環として Istio コントロール プレーンが 1.4.10-gke.0（またはそれ以降）にアップグレードされます。
クラスタ バージョンが最新であることを確認するには、次のコマンドを実行します。
kubectl get ns istio-system --show-labels | if [[ $(grep EnsureExists) ]]; then echo "Version is recent enough"; else echo "Need more recent version"; fi
コンソールの出力に、クラスタのバージョンは最新のバージョンかどうかが示されます。
upgrade-14-16スクリプトをダウンロードするcurl -LO https://storage.googleapis.com/csm-artifacts/asm/upgrade-14-16
このスクリプトは GitHub で表示できます。
スクリプトを実行可能にします。
chmod +x upgrade-14-16
アップグレードするクラスタに
kubectlが構成されていることを確認します。gcloud container clusters get-credentials cluster-name
ここで、cluster-name はクラスタ名です。
スクリプトを実行します。
./upgrade-14-16
このスクリプトでは、単一クラスタの移行手順を説明しています。
別のクラスタを移行するには、
--resetフラグを指定してツールを実行します。./upgrade-14-16 --reset
ステップ 4 と 5 を繰り返します。
Anthos Service Mesh への移行
Anthos Service Mesh に移行する前に、下で説明するように Operator を無効にする必要があります。移行後も、Operator と同じ IstioOperator CR 形式を使用してサービス メッシュを構成します。ただし、Operator コントローラが継続してクラスタ内の IstioOperator CR を監視するのではなくインストール状態を変更する場合は、istioctl
install コマンドを使用してそのようにします。
Anthos Service Mesh に移行するには、Google 提供のスクリプト（install_asm）を使用して Anthos Service Mesh 1.7 に移行します。install_asm スクリプトは、Cloud プロジェクトとクラスタの準備のすべての詳細を処理し、Anthos Service Mesh バージョンの istioctl install を使用して Anthos Service Mesh をインストールします。
要件
クラスタが次の要件を満たしていることを確認します。
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 1.7 に移行する方法について説明します。
-
次の例は、選択した認証局（CA）を使用して Anthos Service Mesh に移行する方法を示しています。Mesh CA を使用して Anthos Service Mesh に移行します。
Citadel
Anthos Service Mesh に移行した後も Citadel を CA を引き続き使用するには:
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME\ --cluster_location CLUSTER_LOCATION \ --mode migrate \ --output_dir DIR_PATH \ --ca citadel \ --enable_apisMesh CA
Anthos Service Mesh に移行するときに、メッシュ CA に移行するには:
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME\ --cluster_location CLUSTER_LOCATION \ --mode migrate \ --output_dir DIR_PATH \ --ca mesh_ca \ --enable_apisAnthos Service Mesh 1.7 には、下りゲートウェイで有効にするなど、よく使用される機能のために、GitHub で利用できるオーバーレイ ファイルも用意されています。詳細については、オプション機能の有効化をご覧ください。
Anthos Service Mesh の設定を完了するには、自動サイドカー インジェクションを有効にして、ワークロードをデプロイまたは再デプロイする必要があります。
移行後
次のコマンドを実行します。VERSION は、以前に Operator を無効にするために使用した Operator のバージョンに置き換えます。
kubectl patch -n istio-system istiooperator VERSION -p '{"spec":{"profile":"empty"}}'
このコマンドによって、empty プロファイルを持つ Operator が再び有効にされます。これにより、Operator は以前にクラスタからインストールしたリソースを削除します。これには、install_asm スクリプトによってインストールされたゲートウェイまたはコントロール プレーンの要素は含まれません。