Knative serving on VMware をフリートにアップグレードする

フリートを使用するように 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 コンソールに表示されている必要があります。

    GKE クラスタに移動

  • 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 ファイルのパスとファイル名に置き換えます。

各ユーザー クラスタを構成する

  1. ユーザー クラスタ用に次のローカル環境変数を作成します。

    1. ユーザー クラスタの kubeconfig ファイルのパスを指定して USER_KUBECONFIG 環境変数を作成します。

      export USER_KUBECONFIG=[USER_CLUSTER_KUBECONFIG]
      

      [USER_CLUSTER_KUBECONFIG] は、ユーザー クラスタの kubeconfig ファイルのパスとファイル名に置き換えます。

    2. 次の構成用に環境変数を作成します。

      • 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']}")
      
  2. ユーザー クラスタの OnPremUserCluster カスタム リソースから、cloudrun 構成を削除します。

    1. OnPremUserClustercloudRun が設定されていることを確認します。

      $ kubectl get onpremusercluster \
        "${CLUSTER_NAME}" \
        --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --output=jsonpath="{.spec.cloudRun}"
      

      結果:

      {"enabled":true}
      
    2. cloudRunOnPremUserCluster から削除します。

      kubectl patch onpremusercluster \
        "${CLUSTER_NAME}" \
        --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --type="merge" \
        --patch '{"spec": {"cloudRun": null}}'
      
    3. 同じ get コマンドを実行して、構成が返されないことを確認することで、OnPremUserCluster から cloudRun が正常に削除されたことを確認します。

      kubectl get onpremusercluster \
        "${CLUSTER_NAME}" \
        --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --output=jsonpath="{.spec.cloudRun}"
      

      ターミナルには何も出力されていないはずです。

  3. ユーザー クラスタの create-config シークレットを更新します。

    1. 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"
      
    2. 作成した ${CLUSTER_NAME}_create_secret.yaml ファイルをエディタで開き、spec の下にある cloudrun フィールドを削除します。

    3. ${CLUSTER_NAME}_cluster_create_secret.yaml ファイルを .b64 ファイルに Base64 でエンコードします。

      cat "${CLUSTER_NAME}_create_secret.yaml" | base64 -w0 > "${CLUSTER_NAME}_create_secret.b64"
      
    4. 先ほど作成したローカルの .b64 ファイルをエディタで開き、次の手順で使用するために data.cfg 属性の下にある文字列をコピーします。

      cfg 属性からコピーするのは、その属性の内容のみにする必要があります。たとえば、改行コード(\n)を含めないでください。

    5. 次のコマンドを実行して、ユーザー クラスタの Secret を編集します。

      kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \
        --namespace "${CLUSTER_NAME}"
      
    6. エディタでそれを開き、data[cfg] フィールドをローカルの .b64 ファイルからコピーした文字列に置き換えてから、変更を保存します。

    7. 変更がユーザー クラスタにデプロイされ、cloudrun 属性が create-config Secret から正常に削除されたことを確認します。

      kubectl get secret create-config \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --namespace ${CLUSTER_NAME} \
        --output=jsonpath={.data.cfg} \
        | base64 -d
      
  4. ユーザー クラスタで knative-serving Namespace を構成します。

    1. cloudrun-operator オペレーターを knative-serving Namespace から削除します。

      kubectl delete deployments.apps --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving cloudrun-operator
      
    2. knative-serving Namespace の config-network configmap にパッチを適用します。

      kubectl patch configmap --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving config-network --patch '{"metadata": {"annotations":{"knative.dev/example-checksum": null}}}'
      
  5. Google Distributed Cloud インストールのユーザー クラスタ構成ファイル user-config.yaml から cloudrun.enabled 構成を削除します。

    次の属性を user-config.yaml ファイル内から削除する必要があります。

    cloudRun:
      enabled: true
    

    クラスタを Anthos バージョン 1.8 にアップグレードすると、この構成変更がデプロイされます。

  6. 複数のユーザー クラスタがある場合は、ユーザー クラスタごとに各ユーザー クラスタを構成するセクションの手順をすべて繰り返す必要があります。

フリート コンポーネントを構成する

  1. フリートで Knative serving のコンポーネントを有効にします。

    gcloud container fleet cloudrun enable --project=$PROJECT_ID
    

    詳細とその他のオプションについては、gcloud container fleet cloudrun enable のリファレンスをご覧ください。

  2. 省略可: Knative serving 機能コンポーネントが有効になっていることを確認します。

    コンソール

    Google Cloud コンソールで Knative serving コンポーネントが有効になっているかどうかを確認します。

    機能マネージャーに移動

    コマンドライン

    appdevexperience の状態が ENABLED であるかどうかを確認します。

    gcloud container fleet features list --project=$PROJECT_ID
    

    詳細と他のオプションについては、gcloud container fleet features list をご覧ください。

    結果:

    NAME               STATE
    appdevexperience   ENABLED
    
  3. CloudRun カスタム リソースをデプロイして、各ユーザー クラスタに 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 アドレスに構成します。

    1. 次のコマンドを実行して、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}}"
      
    2. 現在の 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-system Namespace の cluster-local-gateway Pod により、ユーザー クラスタの Anthos バージョン 1.8 へのアップグレードが完了できない場合があります。cluster-local-gateway Pod は不要になったため、安全に削除できます。

アップグレード プロセスを手動で行うには、デプロイ レプリカを 0 にスケールダウンすることで、cluster-local-gateway Pod を手動で削除できます。例:

  1. cluster-local-gateway をスケールダウンします。

    kubectl scale deployment cluster-local-gateway --replicas 0 --namespace gke-system
    

    gke-system Namespace の cluster-local-gateway Pod と knative-serving Namespace のすべてのワークロードが削除されます。

  2. アップグレード プロセスが完了するまで待ちます。

Deployment のスケーリングの詳細を確認します