Halaman ini diterjemahkan oleh Cloud Translation API.

Memigrasikan cluster pengguna ke Controlplane V2

Dokumen ini menunjukkan cara memigrasikan cluster pengguna versi 1.29 menggunakan kubeception ke Controlplane V2. Jika cluster Anda menggunakan versi 1.30 atau yang lebih baru, sebaiknya ikuti petunjuk di Merencanakan migrasi cluster ke fitur yang direkomendasikan.

1.29: Pratinjau
1.28: Tidak tersedia

Tentang bidang kontrol cluster pengguna

Sebelum Google Distributed Cloud versi 1.13, bidang kontrol untuk cluster pengguna berjalan di satu atau beberapa node dalam cluster admin. Jenis bidang kontrol ini disebut kubeception. Pada versi 1.13, Controlplane V2 diperkenalkan untuk cluster pengguna baru. Jika Controlplane V2 diaktifkan, bidang kontrol untuk cluster pengguna akan berjalan di cluster pengguna itu sendiri.

Manfaat Controlplane V2 mencakup hal berikut:

Isolasi kegagalan. Kegagalan cluster admin tidak memengaruhi cluster pengguna.
Pemisahan operasional. Upgrade cluster admin tidak menyebabkan periode nonaktif untuk cluster pengguna.
Pemisahan deployment. Anda dapat menempatkan cluster admin dan pengguna di domain kegagalan atau situs geografis yang berbeda. Misalnya, cluster pengguna di lokasi edge dapat berada di situs geografis yang berbeda dari cluster admin.

Persyaratan

Untuk memigrasikan cluster pengguna ke Controlplane V2, cluster pengguna harus memenuhi persyaratan berikut:

Cluster pengguna harus versi 1.29 atau yang lebih tinggi. Cluster admin dan kumpulan node dapat memiliki satu atau dua versi minor lebih rendah dari cluster pengguna. Jika diperlukan, upgrade cluster.
Cluster pengguna harus mengaktifkan Dataplane V2. Kolom ini tidak dapat diubah, jadi jika Dataplane V2 tidak diaktifkan di cluster, Anda tidak dapat memigrasikannya ke Controlplane V2.
Cluster pengguna harus dikonfigurasi untuk menggunakan MetalLB atau load balancer manual. Jika cluster pengguna menggunakan load balancer SeeSaw, Anda dapat memigrasikannya ke MetalLB.
Tinjau dokumen perencanaan alamat IP, dan pastikan Anda memiliki cukup alamat IP yang tersedia untuk node bidang kontrol cluster pengguna. Node bidang kontrol memerlukan alamat IP statis, dan Anda memerlukan alamat IP tambahan untuk IP virtual (VIP) bidang kontrol baru.

Mempersiapkan migrasi

Jika enkripsi secret yang selalu aktif pernah diaktifkan di cluster pengguna, Anda harus melakukan langkah-langkah di Menonaktifkan enkripsi secret yang selalu aktif dan mendekripsi secret sebelum memulai migrasi. Jika tidak, cluster Controlplane V2 baru tidak dapat mendekripsi secret.

Sebelum memulai migrasi, jalankan perintah berikut untuk melihat apakah enkripsi secret yang selalu aktif pernah diaktifkan pada suatu waktu:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  get onpremusercluster USER_CLUSTER_NAME \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  -o jsonpath={.spec.secretsEncryption}

Jika output perintah sebelumnya kosong, enkripsi secret yang selalu aktif belum pernah diaktifkan. Anda dapat memulai migrasi.

Jika output perintah sebelumnya tidak kosong, berarti enkripsi secret yang selalu aktif sebelumnya telah diaktifkan. Sebelum melakukan migrasi, Anda harus melakukan langkah-langkah di bagian berikutnya untuk memastikan bahwa cluster Controlplane V2 baru dapat mendekripsi secret.

Contoh berikut menunjukkan output yang tidak kosong:

{"generatedKeyVersions":{"keyVersions":[1]}}

Menonaktifkan enkripsi secret yang selalu aktif dan mendekripsi secret jika diperlukan

Untuk menonaktifkan enkripsi secret yang selalu aktif dan mendekripsi secret, lakukan langkah-langkah berikut:

Di file konfigurasi cluster pengguna, untuk menonaktifkan enkripsi secret yang selalu aktif, tambahkan kolom disabled: true ke bagian secretsEncryption:
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: true
```
Update cluster:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
Ganti kode berikut:
- ADMIN_CLUSTER_KUBECONFIG: jalur file kubeconfig cluster admin
- USER_CLUSTER_CONFIG: jalur file konfigurasi cluster pengguna

Lakukan update berkelanjutan pada DaemonSet tertentu, sebagai berikut:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  rollout restart statefulsets kube-apiserver \
  -n USER_CLUSTER_NAME

Dapatkan manifes semua secret di cluster pengguna, dalam format YAML:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  get secrets -A -o yaml > SECRETS_MANIFEST.yaml

Agar semua secret disimpan di etcd sebagai teks biasa, terapkan kembali semua secret di cluster pengguna:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
Sekarang Anda dapat memulai migrasi ke Controlplane V2. Setelah migrasi selesai, Anda dapat mengaktifkan kembali enkripsi secret yang selalu aktif di cluster.

Memperbaiki webhook workload yang salah dikonfigurasi

Jika Anda memiliki webhook yang menyertakan pod sistem di namespace kube-system, tambahkan namespaceSelector untuk memfilter namespace kube-system.

Misalnya,

  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system

Memperbarui file konfigurasi cluster pengguna

Buat perubahan berikut pada file konfigurasi cluster pengguna yang ada:

Tetapkan enableControlplaneV2 ke true.
Secara opsional, buat panel kontrol untuk cluster pengguna Controlplane V2 sangat tersedia (HA). Untuk mengubah dari cluster non-HA menjadi cluster HA, ubah masterNode.replicas dari 1 menjadi 3.
Tambahkan alamat IP statis (atau alamat) untuk node platform kontrol cluster pengguna ke bagian network.controlPlaneIPBlock.ips.
Isi netmask dan gateway di bagian network.controlPlaneIPBlock.
Jika bagian network.hostConfig kosong, isi.
Jika cluster pengguna menggunakan load balancing manual, konfigurasikan load balancer seperti yang dijelaskan di bagian berikutnya.
Jika cluster pengguna menggunakan load balancing manual, tetapkan loadBalancer.manualLB.controlPlaneNodePort dan loadBalancer.manualLB.konnectivityServerNodePort ke 0 karena tidak diperlukan saat Controlplane V2 diaktifkan.
Perbarui kolom loadBalancer.vips.controlPlaneVIP dengan alamat IP baru untuk VIP bidang kontrol. Perhatikan bahwa node tersebut harus berada di VLAN yang sama dengan IP node bidang kontrol.
Semua kolom sebelumnya tidak dapat diubah kecuali saat memperbarui cluster untuk migrasi. Pastikan untuk memeriksa ulang semua setelan.
Jalankan gkectl diagnose cluster, dan perbaiki masalah apa pun yang ditemukan perintah.
```
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --cluster-name=USER_CLUSTER_NAME
```
Ganti kode berikut:
- ADMIN_CLUSTER_KUBECONFIG: jalur file kubeconfig cluster admin.
- USER_CLUSTER_NAME: nama cluster pengguna.

Menyesuaikan konfigurasi load balancer manual

Jika cluster pengguna Anda menggunakan load balancing manual, lakukan langkah-langkah di bagian ini. Jika tidak, lewati bagian ini.

Serupa dengan mengonfigurasi load balancer untuk cluster pengguna CPv2, untuk setiap dari tiga alamat IP node kontrol-platform baru yang Anda tentukan di bagian network.controlPlaneIPBlock, konfigurasikan pemetaan di load balancer Anda:

(ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)

Mengupdate cluster

Jalankan perintah berikut untuk memigrasikan cluster ke Controlplane V2:

gkectl update cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Ganti kode berikut:

ADMIN_CLUSTER_KUBECONFIG: jalur file kubeconfig cluster admin.
USER_CLUSTER_CONFIG: jalur file konfigurasi cluster pengguna.

Perintah tersebut melakukan hal berikut:

Buat bidang kontrol cluster baru dengan ControlPlane V2 yang diaktifkan.
Hentikan panel kontrol Kubernetes dari cluster kubeception.
Ambil snapshot etcd dari cluster kubeception.
Matikan node bidang kontrol cluster pengguna dari cluster kubeception. Perhatikan bahwa demi pemulihan kegagalan, yaitu kembali ke cluster kubeception, node tidak akan dihapus hingga migrasi selesai.
Pulihkan data cluster di bidang kontrol baru dengan snapshot etcd yang disebutkan di atas.
Hubungkan node nodepool cluster kubeception ke bidang kontrol baru, yang dapat diakses dengan controlPlaneVIP baru.
Lakukan rekonsiliasi cluster pengguna yang dipulihkan untuk memenuhi status akhir cluster dengan mengaktifkan ControlPlane V2.

Catatan

Selama migrasi, tidak ada periode nonaktif untuk beban kerja cluster pengguna.
Selama migrasi, akan ada periode nonaktif untuk platform kontrol cluster pengguna. Lebih khusus lagi, panel kontrol tidak tersedia antara langkah 2 dan penyelesaian langkah 6. (Periode nonaktif kurang dari 7 menit berdasarkan pengujian kami, tetapi durasi yang sebenarnya bergantung pada infrastruktur Anda).
Pada akhir migrasi, node bidang kontrol cluster pengguna dari cluster kubeception akan dihapus. Jika cluster admin memiliki network.ipMode.type yang ditetapkan ke "static", Anda dapat mendaur ulang beberapa IP statis yang tidak digunakan dengan menghapusnya dari file konfigurasi cluster admin dan menjalankan gkectl update admin. Anda dapat membuat daftar objek node cluster admin dengan kubectl get nodes -o wide untuk melihat IP yang digunakan.

Setelah migrasi

Jika Anda menonaktifkan enkripsi secret yang selalu aktif sebelum migrasi, lakukan langkah-langkah berikut untuk mengaktifkan kembali fitur tersebut:

Dalam file konfigurasi cluster pengguna, tetapkan secretsEncryption.generatedKey.disabled ke salah (false). Contoh:

secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: false

Update cluster pengguna:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG