Memigrasikan ke Azure Kubernetes Service (AKS)

Untuk membantu Anda merencanakan dan menjalankan migrasi yang berhasil ke Azure Kubernetes Service (AKS), panduan ini memberikan detail untuk konfigurasi AKS yang direkomendasikan saat ini. Meskipun artikel ini tidak mencakup setiap skenario, artikel ini berisi tautan ke informasi yang lebih rinci untuk merencanakan migrasi yang berhasil.

Dalam artikel ini, kami meringkas detail migrasi untuk:

• Memasukkan aplikasi ke dalam kontainer melalui Azure Migrate
• AKS dengan load balancer standar dan Virtual Machine Scale Sets
• Layanan Azure terlampir yang sudah ada
• Memastikan kuota yang valid
• Ketersediaan tinggi dan kelangsungan bisnis
• Pertimbangan untuk aplikasi tanpa status
• Pertimbangan untuk aplikasi berstatus
• Penyebaran konfigurasi kluster Anda

Catatan

Bergantung pada skenario Anda, alat sumber terbuka berikut mungkin membantu migrasi Anda:

• Velero (Membutuhkan Kube 1.7+)
• Ekstensi Azure Kube CLI

Sebelum Anda mulai

• Pastikan versi Kubernetes target Anda berada dalam jendela yang didukung untuk AKS. Versi lama mungkin tidak berada dalam rentang yang didukung dan memerlukan peningkatan versi untuk dukungan AKS. Untuk informasi selengkapnya, lihat versi Kube yang didukung AKS.
• Jika Anda bermigrasi ke versi Kubernetes yang lebih baru, tinjau kebijakan dukungan penyimpangan versi dan versi Kubernetes.

Praktik penting yang harus Anda sertakan sebagai bagian dari proses migrasi Anda adalah mengingat untuk mengikuti pola penyebaran dan pengujian yang umum digunakan. Menguji aplikasi Anda sebelum penyebaran adalah langkah penting untuk memastikan kualitas, fungsionalitas, dan kompatibilitasnya dengan lingkungan target. Ini dapat membantu Anda mengidentifikasi dan memperbaiki kesalahan, bug, atau masalah apa pun yang dapat memengaruhi performa, keamanan, atau kegunaan aplikasi atau infrastruktur yang mendasar.

Menggunakan Azure Migrate untuk memigrasikan aplikasi Anda ke AKS

Azure Migrate menawarkan platform terpadu untuk menilai dan memigrasikan ke server, infrastruktur, aplikasi, dan data lokal Azure. Untuk AKS, Anda bisa menggunakan Azure Migrate untuk tugas berikut:

• Kontainerisasi aplikasi ASP.NET dan migrasi ke AKS.
• Kontainerisasi aplikasi web Java dan migrasi ke AKS.

AKS dengan load balancer standar dan Virtual Machine Scale Sets

AKS adalah layanan terkelola yang menawarkan kemampuan unik dengan overhead manajemen yang lebih rendah. Karena AKS adalah layanan terkelola, Anda harus memilih dari sekumpulan wilayah yang didukung AKS. Anda mungkin perlu memodifikasi aplikasi yang ada agar tetap sehat di sarana kontrol yang dikelola AKS selama transisi dari kluster yang ada ke AKS.

Sebaiknya gunakan kluster AKS yang didukung oleh Virtual Machine Scale Sets dan Azure Standard Load Balancer untuk memastikan Anda mendapatkan fitur berikut:

• Beberapa kumpulan simpul,
• Zona ketersediaan,
• Rentang IP yang Diotorisasi,
• Penskala otomatis kluster,
• Azure Policy untuk AKS, dan
• Fitur baru lainnya saat dirilis.

Kluster AKS yang didukung oleh set ketersediaan komputer virtual tidak memiliki dukungan untuk banyak fitur ini.

Membuat kluster AKS dengan Load Balancer Standar dan Virtual Machine Scale Sets

Contoh berikut membuat kluster AKS dengan satu kumpulan simpul yang didukung oleh set skala komputer virtual (VM). Ini memungkinkan autoscaler kluster pada kumpulan simpul untuk kluster dan menetapkan minimal satu dan maksimum tiga simpul.

1. Buat grup sumber daya menggunakan az group create perintah .

   az group create --name myResourceGroup --location eastus
   

2. Buat kluster AKS menggunakan az aks create perintah .

   az aks create \
     --resource-group myResourceGroup \
     --name myAKSCluster \
     --node-count 1 \
     --vm-set-type VirtualMachineScaleSets \
     --load-balancer-sku standard \
     --enable-cluster-autoscaler \
     --min-count 1 \
     --max-count 3
   

Layanan Azure terlampir yang sudah ada

Saat memigrasikan kluster, Anda mungkin telah melampirkan layanan Azure eksternal. Meskipun layanan berikut tidak memerlukan rekreasi sumber daya, layanan ini memerlukan pembaruan koneksi dari kluster sebelumnya ke baru untuk mempertahankan fungsionalitas.

• Azure Container Registry
• Analitik Log
• Application Insights
• Traffic Manager
• Akun Penyimpanan
• Database Eksternal

Memastikan kuota yang valid

Karena VM lain disebarkan ke langganan Anda selama migrasi, Anda harus memverifikasi kuota dan batas anda cukup untuk sumber daya ini. Jika perlu, minta peningkatan kuota vCPU.

Anda mungkin perlu meminta peningkatan kuota jaringan untuk memastikan Anda tidak menghabiskan IP. Untuk informasi selengkapnya, lihat jaringan dan rentang IP untuk AKS.

Untuk informasi selengkapnya, lihat langganan Azure dan batas layanan. Untuk memeriksa kuota Anda saat ini, di portal Microsoft Azure, buka bilah langganan, pilih langganan Anda, lalu pilih Penggunaan + kuota.

Ketersediaan tinggi dan kelangsungan bisnis

Jika aplikasi Anda tidak dapat menangani waktu henti, Anda perlu mengikuti praktik terbaik untuk skenario migrasi ketersediaan tinggi. Baca selengkapnya tentang Praktik terbaik untuk perencanaan kelangsungan bisnis yang kompleks, pemulihan bencana, dan memaksimalkan waktu aktif di Azure Kubernetes Service (AKS).

Untuk aplikasi yang kompleks, Anda biasanya bermigrasi dari waktu ke waktu daripada sekaligus, yang berarti lingkungan lama dan baru mungkin perlu berkomunikasi melalui jaringan. Aplikasi yang sebelumnya menggunakan ClusterIP layanan untuk berkomunikasi mungkin perlu diekspos sebagai jenis LoadBalancer dan diamankan dengan tepat.

Untuk menyelesaikan migrasi, Anda ingin mengarahkan klien ke layanan baru yang berjalan di AKS. Sebaiknya alihkan lalu lintas dengan memperbarui DNS untuk mengarahkan ke load balancer yang duduk di depan kluster AKS Anda.

Azure Traffic Manager dapat mengarahkan pelanggan ke kluster Kube dan instans aplikasi yang diinginkan. Traffic Manager adalah load balancer lalu lintas berbasis DNS yang dapat mendistribusikan lalu lintas jaringan di seluruh wilayah. Untuk performa dan redundansi terbaik, arahkan semua lalu lintas aplikasi melalui Traffic Manager sebelum masuk ke kluster AKS Anda.

Dalam penyebaran multi-kluster, pelanggan harus menyambungkan ke nama DNS Traffic Manager yang menunjuk ke layanan pada setiap kluster AKS. Tentukan layanan ini dengan menggunakan titik akhir Traffic Manager. Setiap titik akhir adalah IP load balancer layanan. Gunakan konfigurasi ini untuk mengarahkan lalu lintas jaringan dari titik akhir Traffic Manager di satu wilayah ke titik akhir di wilayah yang berbeda.

Azure Front Door Service adalah opsi lain untuk merutekan lalu lintas untuk kluster AKS. Dengan Azure Front Door Service, Anda dapat menentukan, mengelola, dan memantau perutean global untuk lalu lintas web Anda dengan mengoptimalkan untuk mencapai performa terbaik dan kegagalan global instan untuk ketersediaan tinggi.

Pertimbangan untuk aplikasi tanpa status

Migrasi aplikasi stateless melibatkan langkah-langkah berikut:

1. Terapkan definisi sumber daya Anda (YAML atau Helm) ke kluster baru.
2. Pastikan semuanya berfungsi seperti yang diharapkan.
3. Alihkan lalu lintas untuk mengaktifkan kluster baru Anda.

Pertimbangan untuk aplikasi berstatus

Rencanakan migrasi aplikasi berstatus Anda dengan hati-hati untuk menghindari kehilangan data atau waktu henti yang tidak terduga.

• Jika Anda menggunakan Azure Files, Anda dapat memasang berbagi sebagai volume ke dalam kluster baru. Lihat Mount Static Azure Files sebagai Volume.
• Jika Anda menggunakan Azure Managed Disks, Anda hanya dapat memasang disk jika tidak terikat ke komputer virtual apa pun. Lihat Mount Static Azure Disk sebagai Volume.
• Jika tidak ada pendekatan yang berfungsi, Anda dapat menggunakan opsi pencadangan dan pemulihan. Lihat Velero di Azure.

Azure Files

Tidak seperti disk, Azure Files dapat dipasang ke beberapa host secara bersamaan. Di kluster AKS Anda, Azure dan Kube tidak mencegah Anda membuat pod yang masih digunakan kluster AKS Anda. Untuk mencegah kehilangan data dan perilaku tak terduga, pastikan kluster tidak menulis secara bersamaan ke file yang sama.

Jika aplikasi Anda dapat meng-host beberapa replika yang menunjuk ke berbagi yang sama, ikuti langkah-langkah migrasi tanpa status dan sebarkan definisi YAML Anda ke kluster baru Anda.

Jika tidak, pendekatan migrasi yang mungkin melibatkan langkah-langkah berikut:

1. Validasi aplikasi Anda berfungsi dengan benar.
2. Arahkan lalu lintas langsung Anda ke kluster AKS baru.
3. Putuskan sambungan dengan kluster lama.

Jika Anda ingin memulai dengan berbagi kosong dan membuat salinan data sumber, Anda dapat menggunakan az storage file copy perintah untuk memigrasikan data Anda.

Memigrasikan volume persisten

Jika Anda memigrasikan volume persisten yang ada ke AKS, Anda umumnya mengikuti langkah-langkah berikut:

1. Menghentikan penulisan ke aplikasi.
   • Langkah ini bersifat opsional dan memerlukan waktu henti.
2. Ambil rekam jepret dari disk.
3. Buat disk terkelola baru dari rekam jepret.
4. Buat volume persisten di AKS.
5. Perbarui spesifikasi pod untuk menggunakan volume yang ada daripada PersistentVolumeClaims (provisi statik).
6. Sebarkan aplikasi Anda ke AKS.
7. Validasi aplikasi Anda berfungsi dengan benar.
8. Arahkan lalu lintas langsung Anda ke kluster AKS baru.

Penting

Jika Anda memilih untuk tidak menghentikan penulisan, Anda perlu mereplikasi data ke penyebaran baru. Jika tidak, Anda melewatkan data yang ditulis setelah Anda mengambil rekam jepret disk.

Alat sumber terbuka berikut dapat membantu Anda membuat disk terkelola dan memigrasikan volume antar kluster Kubernetes:

• Ekstensi Azure CLI Disk Copy menyalin dan mengonversi disk di seluruh grup sumber daya dan wilayah Azure.
• Ekstensi Azure Kube CLI menghitung volume Kube ACS dan memigrasikannya ke kluster AKS.

Penyebaran konfigurasi kluster Anda

Sebaiknya gunakan alur Integrasi Berkelanjutan (CI) dan Pengiriman Berkelanjutan (CD) yang ada untuk menyebarkan konfigurasi yang diketahui baik ke AKS. Anda dapat menggunakan Azure Pipelines untuk membangun dan menyebarkan aplikasi Anda ke AKS. Kloning tugas penyebaran yang ada dan pastikan kubeconfig poin ke kluster AKS baru.

Jika tidak memungkinkan, ekspor definisi sumber daya dari kluster Kube yang ada lalu terapkan ke AKS. Anda dapat menggunakan kubectl untuk mengekspor objek. Contohnya:

kubectl get deployment -o yaml > deployments.yaml

Pastikan untuk memeriksa output dan menghapus bidang data langsung yang tidak perlu.

Memindahkan sumber daya yang sudah ada ke wilayah lain

Anda mungkin ingin memindahkan kluster AKS Anda ke wilayah lain yang didukung oleh AKS. Sebaiknya buat kluster baru di wilayah lain lalu sebarkan sumber daya dan aplikasi Anda ke kluster baru Anda.

Jika Anda memiliki layanan yang berjalan di kluster AKS, Anda perlu menginstal dan mengonfigurasi layanan tersebut pada kluster Anda di wilayah baru.

Dalam artikel ini kami akan meringkas detail migrasi untuk:

• Memasukkan aplikasi ke dalam kontainer melalui Azure Migrate
• AKS dengan load balancer standar dan Virtual Machine Scale Sets
• Layanan Azure terlampir yang sudah ada
• Memastikan kuota yang valid
• Ketersediaan tinggi dan kelangsungan bisnis
• Pertimbangan untuk aplikasi tanpa status
• Pertimbangan untuk aplikasi berstatus
• Penyebaran konfigurasi kluster Anda