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.

Dokumen ini membantu mendukung skenario berikut:

Saat melakukan migrasi, pastikan versi Kube target berada dalam jendela yang didukung untuk AKS. Versi lama mungkin tidak berada dalam rentang yang didukung dan akan memerlukan peningkatan versi agar didukung oleh AKS. Untuk informasi selengkapnya, lihat versi Kube yang didukung AKS.

Jika Anda bermigrasi ke versi Kube yang lebih baru, tinjau kebijakan dukungan versi Kube dan versi kecondongan.

Beberapa alat sumber terbuka dapat membantu migrasi Anda, bergantung pada skenario Anda:

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

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:

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 set 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 Load Balancer Standar Azure untuk memastikan Anda mendapatkan fitur seperti:

Kluster AKS yang didukung oleh Virtual Machine Availability Sets tidak memiliki dukungan untuk banyak fitur ini.

Contoh berikut membuat kluster AKS dengan satu kumpulan simpul yang didukung oleh set skala komputer virtual (VM). Kluster:

  • Menggunakan load balancer standar.
  • Mengaktifkan autoscaler kluster pada kumpulan simpul untuk kluster.
  • Menetapkan minimum 1 dan maksimum 3 simpul.
# First create a resource group
az group create --name myResourceGroup --location eastus

# Now create the AKS cluster and enable the cluster autoscaler
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 pembuatan ulang sumber daya, layanan tersebut memerlukan pembaruan koneksi dari kluster sebelumnya ke kluster baru untuk mempertahankan fungsionalitas.

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

Memastikan kuota yang valid

Karena komputer virtual lain akan disebarkan ke langganan Anda selama migrasi, Anda harus memverifikasi bahwa 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 harus 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 akan melakukan migrasi dari waktu ke waktu daripada memigrasi sekaligus, yang berarti lingkungan lama dan baru mungkin perlu berkomunikasi melalui jaringan. Aplikasi yang sebelumnya menggunakan layanan ClusterIP untuk berkomunikasi mungkin perlu diekspos sebagai LoadBalancer jenis dan diamankan dengan tepat.

Untuk menyelesaikan migrasi, Anda mungkin ingin mengarahkan klien ke layanan baru yang berjalan di AKS. Sebaiknya Anda mengalihkan lalu lintas dengan memperbarui DNS agar mengarah ke Load Balancer yang ada 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.

AKS dengan Traffic Manager

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 tanpa status adalah kasus yang paling mudah:

  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.

File Azure

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 bahwa kluster tidak menulis ke file yang sama secara bersamaan.

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, satu 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 bisa menggunakan perintah az storage file copy untuk melakukan migrasi data Anda.

Memigrasikan volume persisten

Jika Anda memigrasikan volume persisten yang ada ke AKS, Anda biasanya akan 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 harus mereplikasi data ke penyebaran baru. Jika tidak, Anda akan melewatkan data yang ditulis setelah Anda mengambil rekam jepret disk.

Beberapa alat sumber terbuka dapat membantu Anda membuat disk terkelola dan memigrasikan volume antar kluster Kube:

Penyebaran konfigurasi kluster Anda

Sebaiknya Anda menggunakan alur Continuous Integration (CI) dan Continuous Deliver (CD) yang ada untuk menyebarkan konfigurasi yang dikenal baik ke AKS. Anda dapat menggunakan Azure Pipelines untuk membangun dan menyebarkan aplikasi Anda ke AKS. Kloning tugas penyebaran yang ada dan pastikan tugas kubeconfig tersebut mengarah 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 Anda membuat kluster baru di wilayah lain, lalu menyebarkan sumber daya dan aplikasi ke kluster baru Anda.

Selain itu, jika Anda memiliki layanan yang berjalan di kluster AKS, Anda harus menginstal dan mengonfigurasi layanan tersebut di kluster Anda di wilayah baru.

Dalam artikel ini kami akan meringkas detail migrasi untuk:

  • 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