Migrasi langsung dari ACK klaster khusus ke ACK klaster Pro managed - Container Service for Kubernetes

Anda dapat melakukan migrasi langsung untuk memindahkan ACK Klaster Khusus ke ACK Klaster Pro Managed. Migrasi ini tidak mengganggu layanan dan tidak memengaruhi operasi normal klaster.

Pembuatan ACK Klaster Khusus dihentikan di Container Service for Kubernetes sejak 21 Agustus 2024. Kami menyarankan Anda menggunakan ACK Klaster Pro Managed di lingkungan produksi untuk reliabilitas, keamanan, dan efisiensi penjadwalan yang lebih tinggi. Ini memungkinkan Anda memanfaatkan fitur dan kemampuan ACK Klaster Pro Managed, seperti bidang kontrol terkelola dan ketersediaan tinggi.

Prasyarat

Sebuah ACK Klaster Khusus (yang akan dimigrasikan) yang menjalankan Kubernetes 1.18 atau lebih baru telah dibuat. Untuk informasi lebih lanjut tentang cara meningkatkan klaster, lihat Tingkatkan Klaster ACK Secara Manual.
Versi Kubernetes klaster tetap tidak berubah setelah migrasi. Untuk migrasi dengan peningkatan, migrasikan klaster sebelum Anda meningkatkannya.
Sebelum migrasi, Anda harus mengonfigurasi zona waktu pada halaman Basic Information klaster. Hal ini memastikan bahwa zona waktu bidang kontrol ACK Klaster Pro Managed tetap konsisten setelah migrasi, sehingga menghindari pengecualian seperti perubahan waktu eksekusi CronJob yang disebabkan oleh perbedaan zona waktu.
Sebuah Object Storage Service (OSS) bucket dibuat di wilayah klaster ACK yang akan dimigrasikan dan perlindungan hotlink dinonaktifkan untuk bucket tersebut karena perlindungan hotlink dapat menyebabkan kegagalan migrasi. Untuk informasi lebih lanjut, lihat Buat Bucket dan Perlindungan Hotlink.

Catatan penggunaan

Item	Deskripsi
Penagihan	Setelah Anda memigrasikan klaster, penagihan klaster berubah. Anda tidak lagi dikenakan biaya untuk node master yang dihapus. Anda dikenakan biaya untuk biaya manajemen klaster. Penagihan sumber daya cloud lainnya tetap tidak berubah. Anda tidak dikenakan biaya untuk membuat bucket. Anda hanya dikenakan biaya untuk penyimpanan objek di bucket dan lalu lintas yang dihasilkan saat objek diakses. Untuk informasi lebih lanjut, lihat Ikhtisar penagihan.
Akses Internet	Untuk klaster yang mengekspos server API dengan menggunakan elastic IP addresses (EIPs) untuk akses publik, alamat akses klaster tidak berubah setelah klaster dimigrasikan. Beberapa ACK klaster khusus mengakses server API dengan menggunakan instance Server Load Balancer (SLB) berbasis Internet. Saat Anda memigrasikan ACK klaster khusus ke ACK klaster Pro managed, Anda harus beralih secara manual ke mode EIP, yang berarti mengikat EIP ke instance Classic Load Balancer (CLB) internal dari server API. Untuk informasi lebih lanjut tentang operasi detail, lihat Ekspos server API ke Internet.
Konfigurasi pod kustom	Jika ACK klaster khusus Anda memiliki konfigurasi pod kustom yang diaktifkan, Anda tidak dapat memigrasikan klaster ke ACK klaster Pro managed. Anda harus menghentikan terway-controlplane sebelum migrasi dimulai dan kemudian mengaktifkan terway-controlplane setelah migrasi selesai. Untuk informasi lebih lanjut, lihat Hentikan terway-controlplane sebelum migrasi klaster. Untuk informasi lebih lanjut tentang cara menyesuaikan konfigurasi pod, lihat Konfigurasikan alamat IP statis, vSwitch terpisah, dan grup keamanan terpisah untuk setiap pod.
Node master	Cloud Assistant Agent tidak diinstal pada beberapa node master lama. Anda harus menginstalnya secara manual. Untuk informasi lebih lanjut, lihat Instal Cloud Assistant Agent. Setelah migrasi klaster selesai, status node master berubah menjadi Tidak Siap.
Pelepasan Instance ECS	Saat Anda menghapus node master, ACK melepaskan semua instance ECS bayar sesuai pemakaian dan disk data mereka. Anda harus melepaskan instance langganan secara manual. Anda harus melepaskan instance ECS langganan secara manual. Untuk informasi lebih lanjut, lihat Lepas atau batalkan langganan instance ApsaraDB RDS for MySQL.

Langkah 1: Lakukan migrasi langsung untuk memindahkan ACK klaster khusus ke ACK klaster Pro managed

Sebelum Anda mulai, pastikan semua prasyarat terpenuhi dan Anda telah membaca serta memahami pertimbangan-pertimbangan. Setelah Anda bermigrasi ke ACK Klaster Pro Managed, Anda tidak dapat kembali ke ACK Klaster Khusus.

Masuk ke Konsol ACK. Di panel navigasi kiri, klik Clusters.
Di halaman Clusters, pilih More>Migrate to Pro di kolom Actions dari klaster ACK yang akan dimigrasikan.
Di kotak dialog Migrate to Pro, selesaikan pra-pemeriksaan dan otorisasi Manajemen Akses Sumber Daya (RAM), pilih bucket OSS yang Anda buat untuk migrasi langsung, dan kemudian klik OK.
Lihat Cara Menyelesaikan Pra-Pemeriksaan
Klik precheck untuk masuk ke Konsol Layanan Intelijen Kontainer. Klik Mulai di halaman Pemeriksaan Migrasi. Kemudian, konfirmasikan item pemeriksaan di panel yang muncul, pilih I know and agree, dan kemudian klik Start.
Jika klaster gagal melewati pra-pemeriksaan, ikuti petunjuk di halaman untuk memperbaiki masalah.
Lihat Cara Menyelesaikan Otorisasi RAM
1. Klik RAM console dan selesaikan otorisasi RAM. Dapatkan nama bucket OSS, yang akan digunakan dalam langkah-langkah berikutnya.
2. Klik kebijakan yang namanya dimulai dengan k8sMasterRolePolicy. Di tab Policy Document halaman detail kebijakan, klik Modify Policy Document. Kemudian, tambahkan konten berikut ke bidang Statement di editor JSON dan klik OK.
  Ganti <YOUR_BUCKET_NAME> dengan nama bucket OSS yang ditentukan di kotak dialog Migrate to Pro. Anda perlu menghapus tanda kurung sudut (<>).
```
,
        {
            "Action": [
                "oss:PutObject",
                "oss:GetObject"
            ],
            "Effect": "Allow",
            "Resource": [
                "acs:oss:*:*:<YOUR_BUCKET_NAME>/*"  
            ]
        }
```
Setelah migrasi selesai, kotak dialog Migrate to Pro menampilkan pesan. Anda dapat memeriksa jenis klaster ACK dan status node masternya.
- Tipe Klaster: Kembali ke halaman Clusters. Jenis klaster di kolom Type berubah dari ACK Dedicated Cluster menjadi ACK Managed. Professional ditampilkan di kolom Cluster Specification.
- Status Node Master: Di halaman Clusters, klik Details di kolom Actions klaster. Di panel navigasi kiri, pilih Nodes > Nodes. Jika kolom Role/Status dari node master menampilkan Unknown, node master terputus dari klaster. Anda dapat merujuk ke Langkah 2: Hapus Node Master dari ACK Klaster Khusus Setelah Migrasi Langsung Selesai untuk menghapus node master setelah migrasi langsung selesai.

Langkah 2: Hapus node master dari ACK klaster khusus setelah migrasi langsung selesai

Setelah migrasi langsung selesai, Anda dapat menggunakan konsol atau menjalankan perintah kubectl untuk menghapus node master dari ACK Klaster Khusus.

Gunakan Konsol ACK

Masuk ke Konsol ACK. Di panel navigasi kiri, klik Clusters.
Di halaman Clusters, klik nama klaster yang ingin Anda ubah. Di panel navigasi kiri, pilih Nodes > Nodes.
Di halaman Nodes, pilih More > Remove di kolom Actions dari node master atau pilih satu atau lebih node master dan klik Batch Remove di bagian bawah. Di kotak dialog yang muncul, konfigurasikan parameter dan klik OK.

Gunakan kubectl

Sebelum Anda menjalankan perintah, pastikan Anda telah terhubung ke klaster menggunakan kubectl. Untuk informasi lebih lanjut, lihat Dapatkan File kubeconfig Klaster dan Gunakan kubectl untuk Terhubung ke Klaster.

Kueri dan catat nama node master yang ingin Anda hapus.
```
kubectl get node | grep control-plane
```
Hapus node master. Ganti <MASTER_NAME> dengan nama node master.
```
kubectl delete node <MASTER_NAME>
```
Untuk menghapus beberapa node master sekaligus, ganti <MASTER_NAME> dengan nama node master. Misalnya, untuk menghapus node master cn-hangzhou.192.xx.xx.65 dan cn-hangzhou.192.xx.xx.66 secara bersamaan, jalankan perintah berikut:
```
kubectl delete node cn-hangzhou.192.xx.xx.65 cn-hangzhou.192.xx.xx.66
```

(Opsional) Langkah 3: Tangani komponen

Periksa apakah pengontrol Ingress Application Load Balancer (ALB) atau ack-virtual-node diinstal di ACK Klaster Khusus. Jika ya, Anda harus menginstal ulang atau memigrasikan komponen tersebut.

Di halaman Clusters, temukan klaster yang ingin Anda kelola dan klik namanya. Di panel kiri, pilih Operations > Add-ons.
Di halaman Add-ons, periksa apakah pengontrol Ingress ALB atau ack-virtual-node diinstal di ACK Klaster Khusus.
Instal ulang pengontrol Ingress ALB
Jika ACK Klaster Khusus Anda memiliki pengontrol Ingress ALB yang diinstal, Anda harus menginstal ulangnya setelah migrasi selesai. Untuk informasi lebih lanjut tentang cara menginstal pengontrol Ingress ALB, lihat Kelola Komponen.
Setelah instalasi selesai, jalankan perintah berikut untuk menghapus aplikasi asli dan pastikan aplikasi terhubung ke klaster menggunakan kubectl. Untuk informasi lebih lanjut, lihat Dapatkan File kubeconfig Klaster dan Gunakan kubectl untuk Terhubung ke Klaster.
```
kubectl delete deployment alb-ingress-controller -n kube-system
```
Instal ulang komponen ACK Virtual Node
Jika klaster ACK khusus Anda memiliki komponen ACK Virtual Node yang diinstal, untuk migrasi tanpa gangguan bisnis, Anda harus menginstal ulang komponen ACK Virtual Node secara manual di klaster ACK Pro managed setelah migrasi selesai.
1. Masuk ke Konsol ACK. Di panel navigasi kiri, klik Clusters.
2. Di halaman Clusters, temukan klaster yang ingin Anda kelola dan klik namanya. Di panel navigasi kiri, klik Add-ons.
3. Di halaman Add-ons, temukan dan instal komponen ACK Virtual Node.
4. Setelah komponen ACK Virtual Node diinstal, jalankan perintah berikut secara berurutan untuk menghapus komponen dan konfigurasi asli.
```
# Hapus Service vk-webhook asli, Deployment ack-virtual-node-controller, ClusterRoleBindings terkait dengan node virtual, dan ServiceAccounts node virtual secara berurutan.
kubectl -n kube-system delete service vk-webhook
kubectl -n kube-system delete deployment ack-virtual-node-controller
kubectl -n kube-system delete clusterrolebinding virtual-kubelet
kubectl -n kube-system delete serviceaccount virtual-kubelet
```
5. Setelah migrasi selesai, buat pod untuk memeriksa apakah klaster berjalan dengan normal.

Apa yang harus dilakukan selanjutnya

Setelah Anda bermigrasi ke ACK Klaster Pro Managed, Anda harus membatasi izin peran RAM pekerja yang diasumsikan oleh node dalam klaster secara manual untuk meningkatkan keamanan node. Untuk informasi lebih lanjut, lihat Batasi Izin Peran RAM Pekerja Klaster ACK Managed Secara Manual.
Jika ACK Klaster Khusus Anda memiliki cGPU Edisi Dasar yang diinstal, setelah Anda bermigrasi ke ACK Klaster Pro Managed, Anda harus meningkatkan cGPU Edisi Dasar ke cGPU Edisi Profesional. Untuk informasi lebih lanjut, lihat Tingkatkan cGPU Edisi Dasar ke cGPU Edisi Profesional di Klaster ACK Pro.

Tanya Jawab Umum

Apakah layanan di ACK klaster Basic managed terpengaruh selama migrasi?

Selama migrasi, komponen bidang kontrol ACK Klaster Khusus tidak aktif. Layanan yang sedang berjalan tidak terpengaruh.

Berapa lama proses migrasi berlangsung?

Migrasi klaster mencakup tiga tahap: bidang kontrol memasuki mode tidur, data etcd dicadangkan, dan komponen terkelola dimulai. Proses keseluruhan diperkirakan memakan waktu 10 hingga 15 menit. Selama waktu ini, server API diperkirakan tidak tersedia selama 5 hingga 10 menit.

Apakah tautan akses berubah setelah migrasi klaster?

Setelah migrasi, alamat IP instance SLB dari server API tidak berubah. Saat Anda menggunakan file kubeconfig untuk mengakses klaster, alamat IP klaster tidak berubah.

Bagaimana cara menangani kegagalan dalam konfigurasi variabel lingkungan untuk ACK Virtual Node selama pra-pemeriksaan?

Jika komponen ACK Virtual Node diinstal di ACK Klaster Khusus, Anda harus mengonfigurasi titik akhir internal untuk kube-apiserver sebelum migrasi dimulai. Untuk melakukannya, ikuti langkah-langkah berikut:

Di halaman Cluster Information, dapatkan titik akhir internal dari kube-apiserver.
Di halaman Deployments, pilih namespace kube-system, temukan Deployment bernama ack-virtual-node-controller, dan tambahkan variabel lingkungan berikut ke bidang spec.template.spec.containers[0].env dari Deployment:
- KUBERNETES_APISERVER_HOST: Alamat IP privat dari kube-apiserver.
- KUBERNETES_APISERVER_PORT: Port privat dari kube-apiserver, yang biasanya diatur ke 6443.