フリートを使用するように Knative serving on VMware を移行する方法について説明します。これにより、Anthos バージョン 1.8 へのアップグレードが可能になります。
Knative serving は、マネージド Cloud Run プロダクトとは切り離され、クラスタのフリート コンポーネントとして提供されるようになりました。フリートのコンポーネントとして Knative serving on VMware の機能をインストールすると、他のフリート コンポーネントとは関係なく、管理およびアップグレードできます。
フリートを使用することを目的として Knative serving on VMware を移行する場合は、次の操作を行う必要があります。
- フリートの要件を満たすように Knative serving on VMware を構成します。
- フリートで Knative serving の機能コンポーネントを有効にします。
この移行中、Kubernetes API サーバーは影響を受けません。
Knative serving on VMware を新しくインストールする方法の詳細については、Knative serving on VMware のインストールをご覧ください。
始める前に
次の要件を満たす必要があります。
以下の手順では、Knative serving on VMware クラスタがフリートに登録され、Google Cloud コンソールに表示されている必要があります。
Knative serving on VMware が、Anthos バージョン 1.7 以前を実行しているクラスタにインストールされています。
Anthos 1.8 では、Istio がサポートされなくなりました。クラスタをバージョン 1.8 にアップグレードする前に、Cloud Service Mesh バージョン 1.18 をフリートにインストールして、Knative serving のインストールを構成する必要があります。
Google Distributed Cloud へのインストールについて詳しくは、Cloud Service Mesh の手順をご覧ください。
Cloud Service Mesh では、クラスタで少なくとも 4 つの vCPU（
e2-standard-4など）を備えたマシンタイプを使用する必要があります。クラスタのマシンタイプを変更する必要がある場合は、異なるマシンタイプへのワークロードの移行をご覧ください。Knative serving を Cloud Service Mesh に移行する方法には、次の 2 つがあります。
ロードバランサを構成する新しい外部 IP アドレスを取得する。
既存のロードバランサの IP アドレスを再利用する。
フリートに移行する
Anthos をバージョン 1.8 にアップグレードするには、まず次の操作を行い、フリート コンポーネントを使用するように既存の Knative serving on VMware のインストールを移行する必要があります。
管理クラスタにアクセスする
管理クラスタの kubeconfig ファイルのパスとファイル名を取得し、ADMIN_KUBECONFIG 環境変数を作成します。
export ADMIN_KUBECONFIG=[ADMIN_CLUSTER_KUBECONFIG]
[ADMIN_CLUSTER_KUBECONFIG] は、管理クラスタの kubeconfig ファイルのパスとファイル名に置き換えます。
各ユーザー クラスタを構成する
ユーザー クラスタ用に次のローカル環境変数を作成します。
ユーザー クラスタの kubeconfig ファイルのパスを指定して
USER_KUBECONFIG環境変数を作成します。export USER_KUBECONFIG=[USER_CLUSTER_KUBECONFIG][USER_CLUSTER_KUBECONFIG] は、ユーザー クラスタの kubeconfig ファイルのパスとファイル名に置き換えます。
次の構成用に環境変数を作成します。
- Google Cloud プロジェクトの ID。
- Google Cloud リソースのロケーション。
- ユーザー クラスタの名前。
export PROJECT_ID=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-project-id']}") export CLUSTER_LOCATION=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-gcp-location']}") export CLUSTER_NAME=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-cluster-name']}")
ユーザー クラスタの
OnPremUserClusterカスタム リソースから、cloudrun構成を削除します。OnPremUserClusterにcloudRunが設定されていることを確認します。$ kubectl get onpremusercluster \ "${CLUSTER_NAME}" \ --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --output=jsonpath="{.spec.cloudRun}"結果:
{"enabled":true}cloudRunをOnPremUserClusterから削除します。kubectl patch onpremusercluster \ "${CLUSTER_NAME}" \ --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --type="merge" \ --patch '{"spec": {"cloudRun": null}}'同じ
getコマンドを実行して、構成が返されないことを確認することで、OnPremUserClusterからcloudRunが正常に削除されたことを確認します。kubectl get onpremusercluster \ "${CLUSTER_NAME}" \ --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --output=jsonpath="{.spec.cloudRun}"ターミナルには何も出力されていないはずです。
ユーザー クラスタの create-config シークレットを更新します。
create-config ファイルのローカル YAML コピーを作成します。
kubectl get secret create-config \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --namespace "${CLUSTER_NAME}" \ --output=jsonpath={.data.cfg} \ | base64 -d > "${CLUSTER_NAME}_create_secret.yaml"作成した
${CLUSTER_NAME}_create_secret.yamlファイルをエディタで開き、specの下にあるcloudrunフィールドを削除します。${CLUSTER_NAME}_cluster_create_secret.yamlファイルを.b64ファイルに Base64 でエンコードします。cat "${CLUSTER_NAME}_create_secret.yaml" | base64 -w0 > "${CLUSTER_NAME}_create_secret.b64"先ほど作成したローカルの
.b64ファイルをエディタで開き、次の手順で使用するためにdata.cfg属性の下にある文字列をコピーします。cfg属性からコピーするのは、その属性の内容のみにする必要があります。たとえば、改行コード（\n）を含めないでください。次のコマンドを実行して、ユーザー クラスタの Secret を編集します。
kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \ --namespace "${CLUSTER_NAME}"エディタでそれを開き、
data[cfg]フィールドをローカルの.b64ファイルからコピーした文字列に置き換えてから、変更を保存します。変更がユーザー クラスタにデプロイされ、
cloudrun属性がcreate-configSecret から正常に削除されたことを確認します。kubectl get secret create-config \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --namespace ${CLUSTER_NAME} \ --output=jsonpath={.data.cfg} \ | base64 -d
ユーザー クラスタで
knative-servingNamespace を構成します。cloudrun-operatorオペレーターをknative-servingNamespace から削除します。kubectl delete deployments.apps --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving cloudrun-operatorknative-servingNamespace のconfig-networkconfigmap にパッチを適用します。kubectl patch configmap --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving config-network --patch '{"metadata": {"annotations":{"knative.dev/example-checksum": null}}}'
Google Distributed Cloud インストールのユーザー クラスタ構成ファイル
user-config.yamlからcloudrun.enabled構成を削除します。次の属性を
user-config.yamlファイル内から削除する必要があります。cloudRun: enabled: trueクラスタを Anthos バージョン 1.8 にアップグレードすると、この構成変更がデプロイされます。
複数のユーザー クラスタがある場合は、ユーザー クラスタごとに各ユーザー クラスタを構成するセクションの手順をすべて繰り返す必要があります。
フリート コンポーネントを構成する
フリートで Knative serving のコンポーネントを有効にします。
gcloud container fleet cloudrun enable --project=$PROJECT_ID詳細とその他のオプションについては、gcloud container fleet cloudrun enable のリファレンスをご覧ください。
省略可: Knative serving 機能コンポーネントが有効になっていることを確認します。
コンソール
Google Cloud コンソールで Knative serving コンポーネントが有効になっているかどうかを確認します。
コマンドライン
appdevexperienceの状態がENABLEDであるかどうかを確認します。gcloud container fleet features list --project=$PROJECT_ID詳細と他のオプションについては、gcloud container fleet features list をご覧ください。
結果:
NAME STATE appdevexperience ENABLEDCloudRunカスタム リソースをデプロイして、各ユーザー クラスタに Knative serving on VMware をインストールします。デフォルトでは、latestバージョンの Knative serving がデプロイされます。次の
kubectl applyコマンドを実行して、CloudRunカスタム リソースのデフォルト構成をデプロイします。cat <<EOF | kubectl apply -f - apiVersion: operator.run.cloud.google.com/v1alpha1 kind: CloudRun metadata: name: cloud-run spec: metricscollector: stackdriver: projectid: $PROJECT_ID gcpzone: $CLUSTER_LOCATION clustername: $CLUSTER_NAME secretname: "stackdriver-service-account-key" secretkey: "key.json" EOF
Cloud Service Mesh を構成する
各ユーザー クラスタに Cloud Service Mesh ロードバランサを構成します。
Cloud Service Mesh の Ingress ゲートウェイは、新しい外部 IP アドレスを構成するか、既存の IP アドレスを再利用することで構成できます。
取得した新しい外部 IP アドレスを使用して、Cloud Service Mesh のドキュメントの手順に沿ってロードバランサを構成します。
この方法を使用すると、Knative serving サービスを中断することなく再起動できます。
別の方法: 次の手順で Cloud Service Mesh ロードバランサを既存の IP アドレスに構成します。
次のコマンドを実行して、Cloud Service Mesh へのサービスのゲートウェイを構成します。
export CURRENT_INGRESS_IP=$(kubectl get service --namespace gke-system istio-ingress --output jsonpath='{.spec.loadBalancerIP}') kubectl patch service --namespace istio-system istio-ingressgateway --patch "{\"spec\":{\"loadBalancerIP\": \"$CURRENT_INGRESS_IP\"}}" kubectl patch service --namespace gke-system istio-ingress --patch "{\"spec\":{\"loadBalancerIP\": null}}"現在の Istio 構成設定を削除します。
kubectl patch configmap --namespace knative-serving config-istio --patch '{"data":{"local-gateway.cluster-local-gateway": null}}' kubectl patch configmap --namespace knative-serving config-istio --patch '{"data":{"gateway.gke-system-gateway": null}}'
移行を検証する
Knative serving on VMware がフリートに正常に移行されたかどうかを検証するために、appdevexperience-operator が稼働中かどうかを確認します。
各ユーザー クラスタに、次のコマンドを実行します。
kubectl get deployment -n appdevexperience appdevexperience-operator
appdevexperience-operator オペレーターで 1/1 が準備完了として表示されます。次に例を示します。
NAME READY UP-TO-DATE AVAILABLE AGE
appdevexperience-operator 1/1 1 1 1h
オペレーターが準備完了状態にならずに失敗した場合は、Google Cloud コンソールでクラスタのワークロードのページを表示して、リソースの問題を特定できます。
Google Kubernetes Engine のワークロードに移動
クラスタをアップグレードする
フリート コンポーネントを使用するように Knative serving on VMware を移行する作業が完了したので、クラスタを Anthos バージョン 1.8 にアップグレードできます。GKE On-Prem のアップグレードにある手順を実施します。
トラブルシューティング
- ユーザー クラスタのアップグレード プロセスが完了しない
gke-systemNamespace のcluster-local-gatewayPod により、ユーザー クラスタの Anthos バージョン 1.8 へのアップグレードが完了できない場合があります。cluster-local-gatewayPod は不要になったため、安全に削除できます。アップグレード プロセスを手動で行うには、デプロイ レプリカを
0にスケールダウンすることで、cluster-local-gatewayPod を手動で削除できます。例:cluster-local-gatewayをスケールダウンします。kubectl scale deployment cluster-local-gateway --replicas 0 --namespace gke-systemgke-systemNamespace のcluster-local-gatewayPod とknative-servingNamespace のすべてのワークロードが削除されます。アップグレード プロセスが完了するまで待ちます。