Anthos バージョン 1.8 にアップグレードできるように、フリートを使用するように Knative serving on VMware を移行する方法について説明します。
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 クラスタが GKE Enterprise に登録されている必要があります。
クラスタの登録方法を確認してください。
Knative serving on VMware は、Anthos バージョン 1.7 以前を実行しているクラスタにインストールされています。
Anthos 1.8 では、Istio がサポートされなくなりました。クラスタをバージョン 1.8 にアップグレードする前に、Anthos Service Mesh バージョン 1.18 をフリートにインストールして、Knative serving のインストールを構成する必要があります。
GKE on VMware へのインストールについて詳しくは、Anthos Service Mesh の手順をご覧ください。
Anthos Service Mesh では、クラスタで少なくとも 4 つの vCPU（
e2-standard-4など）を備えたマシンタイプを使用する必要があります。クラスタのマシンタイプを変更する必要がある場合は、異なるマシンタイプへのワークロードの移行をご覧ください。Knative serving を Anthos 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}OnPremUserClusterからcloudRunを削除します。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 Secret を更新します。
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-serving名前空間のconfig-networkconfigmap にパッチを適用します。kubectl patch configmap --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving config-network --patch '{"metadata": {"annotations":{"knative.dev/example-checksum": null}}}'
GKE on VMware インストールのユーザー クラスタ構成ファイル
user-config.yamlからcloudrun.enabled構成を削除します。次の属性を
user-config.yamlファイル内から削除する必要があります。cloudRun: enabled: trueAnthos バージョン 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
Anthos Service Mesh を構成する
各ユーザー クラスタに Anthos Service Mesh ロードバランサを構成します。
Anthos Service Mesh の上り（内向き）ゲートウェイは、新しい外部 IP アドレスを構成するか、既存の IP アドレスを再利用することで構成できます。
取得した新しい外部 IP アドレスを使用して、Anthos Service Mesh のドキュメントの手順に沿ってロードバランサを構成します。
この方法を使用すると、Knative serving サービスを中断することなく再起動できます。
別の方法: 次の手順を使用して、Anthos Service Mesh ロードバランサを既存の IP アドレスで構成します。
次のコマンドを実行して、Anthos 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-system名前空間のcluster-local-gatewayPod とknative-serving名前空間 のすべてのワークロードが削除されます。アップグレード プロセスが完了するまで待ちます。