このガイドでは、Google Cloud 上の Knative serving の既存のインストールを移行してフリートと Cloud Service Mesh を使用できるようにします。
Knative serving の以前の無料トライアル バージョン（GKE アドオンとも呼ばれます）には、Istio 1.4 の簡易バージョンが組み込まれていますが、これは Anthos 1.8 以降ではサポートされません。
フリートと Cloud Service Mesh を使用するように Knative serving のインストールをアップグレードすると、プロダクトのアップグレードと管理の独立性が向上し、GKE Enterprise 機能全体の統合も改善されます。詳しくは、新機能と変更点をご覧ください。
インストールを移行するには、次の 2 つの方法があります。
推奨のプロセスは、以前のバージョンの Knative serving がインストールされているクラスタ（以下、GKE アドオン）から、Knative serving の新しいフリート インストールをインストールして構成した新しいクラスタにワークロードを移行することです。このプロセスは比較的単純であり、また理想的ですが、ワークロードがトラフィックを処理する場合、新しく作成されたクラスタに移行するとダウンタイムが発生します。この移行パスを実行するには、新しいクラスタで次のことを行います。
- フリート コンポーネントとして Knative serving をインストールします。
新しいインストールにサービスをデプロイします。
たとえば、既存のサービスのリビジョンをデプロイするの手順に沿って、各サービスの YAML 構成ファイルを個別にダウンロードし、YAML ファイルを Knative serving のフリート インストールにある新しいクラスタにデプロイします。
古いインストールでは、次のコマンドを実行して YAML 構成ファイル（
service.yamlなど）をダウンロードできます。gcloud run services describe SERVICE --format export > service.yamlSERVICE は、Knative serving サービスの名前に置き換えます。
新しいフリート コンポーネントをインストールすると、次のコマンドを実行して同じ
service.yamlをデプロイできます。gcloud run deploy service.yaml --cluster CLUSTER_NAME --cluster-location CLUSTER_LOCATION --project PROJECT_ID次のように置き換えます。
CLUSTER_NAME: Knative serving の新しいフリート コンポーネント インストールに含まれるクラスタの名前。
CLUSTER_LOCATION: Knative serving の新しいフリート コンポーネント インストールに含まれるクラスタのゾーンまたはリージョン。
PROJECT_ID: Knative serving の新しいフリート コンポーネント インストールが存在する Google Cloud プロジェクトの ID。
別の方法: 新しいクラスタを作成できず、Knative serving のアクティブなインストールを移行する必要がある場合は、このガイドの手順に沿って操作します。
- 以前の GKE アドオンと Istio リソースを削除します。
- 新しいフリート リソースをインストールします。
- Cloud Service Mesh に移行してからトラフィックを移行します。
- 古いリソースや未使用のリソースをすべてクリーンアップします。
以下では、GKE Enterprise 1.8 以降の要件を満たすために、Knative serving の既存のアクティブなインストール（とすべてのワークロード）をアップグレードする別の手順について説明します。
始める前に
このアップグレード プロセスは、以前に GKE アドオンとして Knative serving をインストールした Google Kubernetes Engine クラスタでのみ実施してください。
GKE アドオンがインストールされているかどうかを確認します。
Knative serving のインストールが GKE アドオンであるかどうかを確認するには、次のコマンドを実行します。
gcloud container clusters describe \ CLUSTER_NAME \ --region CLUSTER_LOCATION \ --project PROJECT_ID --format='get(addonsConfig.cloudRunConfig)'
次のように置き換えます。
- CLUSTER_NAME: 使用するクラスタの名前。
- CLUSTER_LOCATION: クラスタが配置されているロケーション。
- PROJECT_ID: 実際の Google Cloud プロジェクトの ID。
結果:
- GKE アドオンはインストールされていない:
- アドオンがインストールされていない場合、ターミナルにはなにも返されません。
- アドオンがすでにアンインストールされている場合は、
disabled=trueが返されます。
- GKE アドオンがインストールされている: アドオンがクラスタにインストールされている場合は、アドオンの構成の詳細が返されます。例:
loadBalancerType=LOAD_BALANCER_TYPE_EXTERNAL
- 例:
-
次の例では、Knative serving が GKE アドオンによって
my-addon-clusterクラスタにインストールされ、外部トラフィックを処理するように構成されていることを示します。gcloud container clusters describe my-addon-cluster \ --region us-central1-c --project my-gcp-project \ --format='get(addonsConfig.cloudRunConfig)'
レスポンス:
loadBalancerType=LOAD_BALANCER_TYPE_EXTERNAL
クラスタ、フリート、Cloud Service Mesh の要件を満たすには、Google Cloud プロジェクトに十分な権限が必要です。
Google Cloud プロジェクトのオーナーロールが付与されている場合は、クラスタの作成、Knative serving のインストールと構成に必要な権限よりも多くの権限が付与されています。
Cloud Service Mesh の権限要件でも、Knative serving のインストールと構成に関するすべての権限要件を満たしている必要があります。
他のロールの使用と最小要件:
組織によっては、次の事前定義ロールを組み合わせて権限要件を満たすこともできます。
Google Cloud プロジェクトの権限: 基本編集者のロール
フリートの権限: GKE Hub 管理者、または次の権限を含むロール。
gkehub.features.creategkehub.features.update
クラスタの権限: Kubernetes Engine 管理者のロール。
- Kubernetes Engine 管理者
- Kubernetes Engine クラスタ管理者
Cloud Service Mesh バージョン 1.18 のみがサポートされています。
Cloud Service Mesh では、クラスタで少なくとも 4 つの vCPU を備えたマシンタイプを使用する必要があります（
e2-standard-4など）。要件の詳細については、Cloud Service Mesh のインストール ガイドをご覧ください。既存のクラスタのマシンタイプを変更する必要がある場合は、異なるマシンタイプへのワークロードの移行をご覧ください。このプロセスでコマンドと移行スクリプトを実行する環境として、Cloud Shell を使用することをおすすめします。Cloud Service Mesh のインストール スクリプトは、Linux または Cloud Shell のみをサポートしています。
Knative serving の既存のインストールで Istio on GKE アドオンを使用している場合は、Cloud Service Mesh マネージド コントロール プレーンに移行する必要があります。現在、Istio on GKE アドオンから Cloud Service Mesh クラスタ内コントロール プレーンへの移行はサポートされていません。
Knative serving のアップグレードとワークロードの移行
Knative serving のアップグレードとワークロードの移行を簡単に行うため、スクリプトを使用します。このスクリプトでは、プロセスを通じて求められた入力を行うだけで、ほとんどのステップが自動的に実行されます。