Mengupgrade penyaluran Knative di VMware ke fleet

Pelajari cara memigrasikan penyaluran Knative di VMware untuk menggunakan fleet sehingga Anda dapat upgrade ke Anthos Versi 1.8.

Penting: Anthos Versi 1.8 mengharuskan semua penginstalan sebelumnya Penyajian Knative di VMware dimigrasikan untuk digunakan fleet. Anda harus memigrasikan inferensi Knative sebelum mengupgrade cluster GKE Versi 1.8.

Jika Anda memilih untuk tetap menggunakan Anthos Versi 1.7 atau yang lebih lama, Anda tidak diperlukan untuk segera memigrasikan instalasi Anda. Namun, dimulai dengan Anthos 1.8, penginstalan baru, dan upgrade ke layanan Knative hanya tersedia melalui fleet.

Penyajian Knative sekarang merupakan pengalaman terpisah dari layanan Cloud Run dan kini disediakan sebagai komponen fleet di ke cluster Anda. Menginstal penyaluran Knative pada fitur VMware sebagai memungkinkan Anda mengelola dan meningkatkan instalasi terpisah dari komponen armada lainnya.

Pada tingkat tinggi, memigrasikan penyaluran Knative Anda pada instalasi VMware untuk menggunakan perangkat, Anda harus:

• Konfigurasikan penyaluran Knative Anda pada instalasi VMware untuk memenuhi persyaratan perangkat mereka.
• Mengaktifkan komponen fitur penayangan Knative di perangkat seluler.

Perlu diperhatikan bahwa server Kubernetes API tidak terpengaruh selama migrasi ini.

Untuk mengetahui detail tentang cara melakukan instalasi baru dari inferensi Knative pada VMware, lihat Menginstal penyaluran Knative di VMware.

Sebelum memulai

Anda harus memenuhi persyaratan berikut:

• Langkah-langkah ini mengharuskan inferensi Knative Anda di cluster VMware terdaftar ke fleet dan terlihat di Konsol Google Cloud:

  Buka cluster GKE

• Penginstalan Knative Anda di VMware berlangsung cluster yang menjalankan Anthos Versi 1.7 atau yang lebih lama.

• Istio tidak lagi didukung di Anthos 1.8. Versi Cloud Service Mesh 1.18 harus diinstal di fleet Anda dan instalasi Anda Penyajian Knative harus dikonfigurasi sebelum Anda mengupgrade cluster tersebut ke Versi 1.8.

  Lihat petunjuk Cloud Service Mesh untuk mengetahui detail di Google Distributed Cloud.

  Perlu diperhatikan bahwa Cloud Service Mesh mengharuskan cluster Anda menggunakan jenis mesin yang memiliki setidaknya empat vCPU, seperti e2-standard-4. Jika Anda ingin mengubah jenis mesin cluster Anda, lihat Memigrasikan workload ke berbagai jenis mesin.

• Ada dua opsi untuk memigrasikan penyaluran Knative ke Cloud Service Mesh, Anda dapat:

  • Mendapatkan alamat IP eksternal baru tempat Anda mengonfigurasi load balancer.

  • Gunakan kembali alamat IP load balancer yang ada.

    Peringatan: Proses penggunaan kembali alamat IP yang ada untuk mengonfigurasi Cloud Service Mesh menyebabkan koneksi sekitar 2 menit periode nonaktif. Anda harus merencanakan untuk mengakomodasi periode ini, Layanan penayangan Knative tidak dapat terhubung.

• Pastikan lingkungan command line Anda sudah dikonfigurasi dan sudah diupdate.

Bermigrasi ke fleet

Untuk mengupgrade Anthos ke Versi 1.8, Anda harus terlebih dahulu melakukan Untuk memastikan bahwa inferensi Knative yang ada di VMware, instalasi dimigrasikan untuk menggunakan komponen fleet.

Penting: Sebagian besar langkah dalam proses ini mengharuskan Anda mengonfigurasi setiap klaster pengguna Anda, dan oleh karena itu, harus mengulangi beberapa langkah untuk masing-masing cluster.

Mengakses cluster admin

Dapatkan jalur dan nama file dari file kubeconfig cluster admin Anda, lalu buat variabel lingkungan ADMIN_KUBECONFIG:

export ADMIN_KUBECONFIG=[ADMIN_CLUSTER_KUBECONFIG]

Ganti [ADMIN_CLUSTER_KUBECONFIG] dengan jalur dan nama file ke file kubeconfig cluster admin Anda.

Mengonfigurasi setiap cluster pengguna

Penting: Jika memiliki beberapa cluster pengguna, Anda harus mengulangi langkah-langkah dalam untuk setiap cluster pengguna.

1. Buat variabel lingkungan lokal berikut untuk cluster pengguna:

   1. Buat variabel lingkungan USER_KUBECONFIG dengan jalur file kubeconfig cluster pengguna:

      export USER_KUBECONFIG=[USER_CLUSTER_KUBECONFIG]
      

      Ganti [USER_CLUSTER_KUBECONFIG] dengan jalur dan nama file ke file kubeconfig cluster pengguna Anda.

   2. Buat variabel lingkungan untuk konfigurasi berikut:

      • ID project Google Cloud Anda.
      • Lokasi resource Google Cloud Anda.
      • Nama cluster pengguna.

      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. Hapus konfigurasi cloudrun dari kustom OnPremUserCluster untuk resource cluster pengguna Anda:

   1. Pastikan cloudRun ditetapkan di OnPremUserCluster:

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

      Hasil:

      {"enabled":true}
      

   2. Hapus cloudRun dari OnPremUserCluster:

      kubectl patch onpremusercluster \
        "${CLUSTER_NAME}" \
        --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --type="merge" \
        --patch '{"spec": {"cloudRun": null}}'
      

   3. Validasi bahwa cloudRun berhasil dihapus dari OnPremUserCluster dengan menjalankan perintah get yang sama dan memverifikasi bahwa tidak ada konfigurasi yang ditampilkan:

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

      Seharusnya tidak ada output ke terminal Anda.

3. Perbarui rahasia create-config cluster pengguna Anda:

   1. Buat salinan YAML lokal dari file create-config:

      kubectl get secret create-config \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --namespace "${CLUSTER_NAME}" \
        --output=jsonpath={.data.cfg} \
        | base64 -d > "${CLUSTER_NAME}_create_secret.yaml"
      

   2. Buka file ${CLUSTER_NAME}_create_secret.yaml yang baru saja Anda buat di editor, lalu hapus kolom cloudrun dari bawah spec.

   3. Base64 mengenkode file ${CLUSTER_NAME}_cluster_create_secret.yaml menjadi file .b64:

      cat "${CLUSTER_NAME}_create_secret.yaml" | base64 -w0 > "${CLUSTER_NAME}_create_secret.b64"
      

   4. Di editor, buka file .b64 lokal yang baru saja Anda buat, lalu salin string dari atribut data.cfg untuk digunakan pada langkah berikutnya langkah waktu ini.

      Anda harus memastikan bahwa Anda hanya menyalin konten dari atribut cfg. Misalnya, jangan sertakan baris baru (\n).

   5. Jalankan perintah berikut untuk edit rahasia di cluster pengguna Anda:

      kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \
        --namespace "${CLUSTER_NAME}"
      

   6. Di editor yang terbuka, ganti kolom data[cfg] dengan string yang Anda salin dari file .b64 lokal, lalu simpan perubahan.

   7. Verifikasi bahwa perubahan Anda telah di-deploy ke cluster pengguna dan atribut cloudrun berhasil dihapus dari create-config rahasia:

      kubectl get secret create-config \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --namespace ${CLUSTER_NAME} \
        --output=jsonpath={.data.cfg} \
        | base64 -d
      

4. Konfigurasikan namespace knative-serving di cluster pengguna Anda:

   1. Hapus operator cloudrun-operator dari knative-serving ruang nama:

      kubectl delete deployments.apps --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving cloudrun-operator
      

   2. Tambahkan patch peta konfigurasi config-network di namespace knative-serving:

      kubectl patch configmap --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving config-network --patch '{"metadata": {"annotations":{"knative.dev/example-checksum": null}}}'
      

5. Hapus konfigurasi cloudrun.enabled dari cluster pengguna file konfigurasi user-config.yaml penginstalan Google Distributed Cloud Anda.

   Atribut berikut harus dihapus dari dalam user-config.yaml Anda file:

   cloudRun:
     enabled: true
   

   Saat mengupgrade cluster ke Anthos Versi 1.8, tindakan ini perubahan konfigurasi akan di-deploy.

6. Jika memiliki beberapa klaster pengguna, Anda harus mengulangi semua langkah dalam "Mengonfigurasi setiap cluster pengguna" untuk setiap pengguna .

Mengonfigurasi komponen fleet

1. Aktifkan komponen penayangan Knative di perangkat Anda:

   gcloud container fleet cloudrun enable --project=$PROJECT_ID
   

   Untuk mengetahui detail dan opsi tambahan, lihat gcloud container fleet cloudrun enable alamat IP internal.

2. Opsional: Pastikan bahwa komponen fitur penayangan Knative diaktifkan:

   Konsol

   Lihat apakah komponen penayangan Knative Diaktifkan di bagian Konsol Google Cloud:

   Buka Feature Manager

   Command line

   Lihat apakah status appdevexperience adalah ENABLED:

   gcloud container fleet features list --project=$PROJECT_ID
   

   Untuk mengetahui detail dan opsi tambahan, lihat daftar fitur fleet container gcloud alamat IP internal.

   Hasil:

   NAME               STATE
   appdevexperience   ENABLED
   

3. Deploy resource kustom CloudRun untuk menginstal Penyaluran Knative di VMware pada setiap cluster pengguna Anda. Secara default, Penayangan Knative versi latest telah di-deploy.

   Penting: Jika memiliki beberapa cluster pengguna, Anda harus mengulangi langkah ini untuk setiap cluster pengguna.

   Jalankan perintah kubectl apply berikut untuk men-deploy default untuk konfigurasi resource kustom 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
   

Mengonfigurasi Cloud Service Mesh

Konfigurasikan load balancer Cloud Service Mesh untuk setiap cluster pengguna Anda.

Penting: Jika memiliki beberapa cluster pengguna, Anda harus mengulangi langkah-langkah dalam untuk setiap cluster pengguna.

Anda dapat mengonfigurasi gateway masuk Cloud Service Mesh dengan mengonfigurasi alamat IP eksternal baru atau menggunakan kembali alamat IP yang ada:

• Dengan alamat IP eksternal baru yang Anda peroleh, Anda mengonfigurasi beban dengan mengikuti langkah-langkah dalam Dokumentasi Cloud Service Mesh.

  Perhatikan bahwa opsi ini memastikan bahwa layanan penyaluran Knative Anda memulai ulang tanpa gangguan.

• Alternatif: Gunakan langkah-langkah berikut untuk mengonfigurasi Cloud Service Mesh load balancer ke alamat IP yang ada.

  Peringatan: Bermigrasi ke Cloud Service Mesh menggunakan alamat IP Anda yang sudah ada menyebabkan periode nonaktif koneksi sekitar 2 menit. Anda harus merencanakan untuk mengakomodasi periode ini, selama layanan penayangan Knative Anda tidak dapat terhubung.

  1. Konfigurasi gateway layanan Anda ke Cloud Service Mesh dengan menjalankan perintah berikut:

     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. Hapus setelan konfigurasi Istio saat ini:

     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}}'
     

Verifikasi migrasi

Anda dapat memeriksa apakah appdevexperience-operator sudah aktif untuk memverifikasi bahwa inferensi Knative Anda di VMware telah berhasil dimigrasikan ke armada Anda.

Untuk setiap cluster pengguna, jalankan perintah berikut:

 kubectl get deployment -n appdevexperience appdevexperience-operator

appdevexperience-operator operator akan menampilkan 1/1 sebagai siap, misalnya:

 NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
 appdevexperience-operator   1/1     1            1           1h

Jika operator gagal mencapai status siap, Anda dapat melihat konfigurasi status halaman workload di Konsol Google Cloud untuk mengidentifikasi masalah resource:

Buka workload Google Kubernetes Engine

Upgrade cluster Anda

Sekarang setelah Anda memigrasikan penyaluran Knative Anda pada instalasi VMware untuk menggunakan perangkat Anda, Anda dapat mengupgrade cluster ke Anthos Versi 1.8. Ikuti petunjuk terperinci di Mengupgrade GKE On-Prem.

Pemecahan masalah

Proses upgrade cluster pengguna gagal diselesaikan

Pod cluster-local-gateway dalam namespace gke-system mungkin mencegah cluster pengguna Anda karena menyelesaikan upgrade ke Anthos Versi 1.8. Pod cluster-local-gateway tidak lagi diperlukan dan dapat dihapus dengan aman.

Untuk membantu proses upgrade secara manual, Anda dapat menghapus Pod cluster-local-gateway dengan memperkecil skala replika deployment Anda menjadi 0. Contoh:

1. Perkecil cluster-local-gateway:

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

   Pod cluster-local-gateway di namespace gke-system dan semua beban kerja di namespace knative-serving akan dihapus.

2. Tunggu hingga proses upgrade selesai.

Pelajari deployment penskalaan lebih lanjut.