このガイドでは、Knative serving on Google Cloud の既存のインストールを移行してフリートと 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.yaml
SERVICE は、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
- 例:
- 次の例では、「GKE アドオン」によって
my-addon-cluster
クラスタに Knative serving がインストールされ、外部トラフィックを処理するように構成されていることを示します。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.create
gkehub.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 の既存のインストールのアップグレードとワークロードの移行をサポートするため、ほとんどの手順を自動化し、プロセス全体で入力を求めるスクリプトを実行します。