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 tinggi, sebaiknya Anda mengikuti 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. Bidang kontrol semacam ini disebut sebagai kubeception. Di 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 meliputi:

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 node pool dapat memiliki versi minor yang satu atau dua tingkat lebih rendah daripada 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 alamat IP yang cukup untuk node bidang kontrol cluster pengguna. Node bidang kontrol memerlukan alamat IP statis, dan Anda akan memerlukan alamat IP tambahan untuk IP virtual (VIP) bidang kontrol baru.

Mempersiapkan migrasi

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

Sebelum memulai migrasi, jalankan perintah berikut untuk melihat apakah enkripsi secret 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, berarti enkripsi rahasia selalu aktif belum pernah diaktifkan. Anda dapat memulai migrasi.

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

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:

Dalam 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

Perbarui file konfigurasi cluster pengguna

Buat perubahan berikut pada file konfigurasi cluster pengguna yang ada:

Tetapkan enableControlplaneV2 ke benar (true).
Secara opsional, buat bidang kontrol untuk cluster pengguna Controlplane V2 memiliki ketersediaan tinggi (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 bidang kontrol cluster pengguna ke bagian network.controlPlaneIPBlock.ips. Alamat IP (atau alamat) untuk node bidang kontrol harus berada di VLAN yang sama dengan node pekerja. Nama host wajib diisi.
Isi netmask dan gateway di bagian network.controlPlaneIPBlock.
Jika bagian network.hostConfig kosong, isi bagian tersebut.
Jika cluster pengguna menggunakan load balancing manual, konfigurasikan load balancer Anda 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 alamat IP ini 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 oleh perintah tersebut.
```
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.

Mirip dengan mengonfigurasi load balancer untuk cluster pengguna CPv2, untuk setiap tiga alamat IP node bidang kontrol 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)

Memperbarui 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 diaktifkan.
Hentikan bidang kontrol Kubernetes dari cluster kubeception.
Ambil snapshot etcd cluster kubeception.
Nonaktifkan node bidang kontrol cluster pengguna dari cluster kubeception. Perhatikan bahwa demi pemulihan kegagalan, yaitu melakukan failover 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.
Sesuaikan cluster pengguna yang dipulihkan agar sesuai dengan status akhir cluster dengan ControlPlane V2 diaktifkan.

Catatan

Selama migrasi, tidak ada periode nonaktif untuk workload cluster pengguna.
Selama migrasi, bidang kontrol cluster pengguna akan mengalami periode nonaktif. Lebih khusus lagi, bidang kontrol tidak tersedia antara langkah 2 dan penyelesaian langkah 6. (Periode nonaktif kurang dari 7 menit berdasarkan pengujian kami, tetapi durasi sebenarnya bergantung pada infrastruktur Anda).
Di akhir migrasi, node bidang kontrol cluster pengguna dari cluster kubeception akan dihapus. Jika network.ipMode.type di cluster admin 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 sedang digunakan.

Setelah migrasi

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

Dalam file konfigurasi cluster pengguna, setel secretsEncryption.generatedKey.disabled ke false. Contoh:

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

Perbarui cluster pengguna:

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