Bagikan melalui

Migrasi dari Amazon EKS ke Azure Kubernetes Service (AKS)

  • Artikel

Artikel ini menyediakan strategi untuk memigrasikan beban kerja stateless dan stateful khas dari Amazon EKS ke Azure Kubernetes Service (AKS).

Pertimbangan

Proses penyebaran aktual dari beban kerja produksi dunia nyata dapat bervariasi tergantung pada faktor-faktor berikut:

  • Strategi penyebaran: Pilihan antara GitOps dan metode DevOps Continuous Integration/Continuous Deployment (CI/CD) secara signifikan memengaruhi pendekatan penyebaran. GitOps memprioritaskan infrastruktur deklaratif yang dikelola melalui repositori yang dikontrol versi, sementara DevOps CI/CD berfokus pada alur kerja otomatis untuk pengiriman aplikasi.

  • Artefak penyebaran: Pemilihan artefak penyebaran memainkan peran penting dalam menentukan struktur penyebaran. File YAML, file manifes, bagan Helm, dan konfigurasi Kustomisasi mewakili berbagai pendekatan untuk menentukan dan menyesuaikan pengaturan penyebaran, masing-masing dengan kekuatan dan kasus penggunaannya.

  • Autentikasi dan otorisasi beban kerja: Tergantung pada metode penyiapan, autentikasi, dan otorisasi dapat berbeda. Anda dapat menggunakan peran Amazon Web Services (AWS) Identity and Access Management (IAM), mekanisme identitas beban kerja, atau string koneksi untuk kontrol akses.

  • Pemantauan: Implementasi solusi pemantauan adalah aspek penting yang dapat melibatkan berbagai alat dan metodologi untuk memastikan performa dan kesehatan beban kerja yang disebarkan. Untuk informasi selengkapnya tentang bagaimana pemantauan AKS dibandingkan dengan EKS, lihat Pemantauan dan pengelogan Kubernetes.

Sebelum memulai migrasi Anda, tinjau dan pertimbangkan panduan umum dan sumber daya praktik terbaik berikut:

  • Tinjau operator kluster dan praktik terbaik pengembang.
  • Tentukan strategi pemantauan dan pemberitahuan untuk memastikan aplikasi berkinerja seperti yang diharapkan.
  • Tentukan persyaratan keamanan dan kepatuhan untuk aplikasi dan lingkungan AKS.
  • Tentukan kebijakan kontrol akses dan bagaimana kebijakan tersebut diberlakukan. Identifikasi standar kepatuhan apa pun yang harus dipatuhi.
  • Tentukan pemulihan bencana dan rencana kelangsungan bisnis untuk lingkungan AKS dan aplikasi.
  • Tentukan kebijakan dan prosedur pencadangan dan pemulihan. Identifikasi tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO).
  • Identifikasi risiko atau tantangan apa pun yang mungkin dihadapi selama penyebaran.
  • Uji fungsionalitas untuk memastikan aplikasi berfungsi seperti yang diharapkan sebelum mengalihkan lalu lintas langsung ke kluster AKS baru.

Pertimbangan migrasi beban kerja

Bagian ini meninjau beberapa hal yang harus Anda pertimbangkan sebelum memigrasikan beban kerja Anda dari Amazon EKS ke AKS.

Memahami lingkungan Amazon EKS yang ada

Analisis lingkungan EKS yang ada untuk memahami arsitektur, sumber daya, dan konfigurasi saat ini.

  • Tinjau konfigurasi EKS: Menilai konfigurasi kluster EKS, seperti jenis node, jumlah simpul, versi Kubernetes dan kebijakan dukungan, dan konfigurasi penskalaan.

    Catatan

    EKS memungkinkan pembuatan gambar AMI kustom untuk simpul EKS. AKS tidak mengizinkan penggunaan gambar simpul kustom. Jika penyebaran Anda memerlukan kustomisasi node, Anda dapat menerapkan kustomisasi kubelet dan/atau DaemonSets untuk menyesuaikan simpul Anda.

  • Tinjau beban kerja aplikasi: Identifikasi semua beban kerja Kubernetes yang berjalan pada kluster EKS termasuk penyebaran, layanan, set stateful, konfigurasi ingress, dan klaim volume persisten. Pastikan Anda memiliki daftar lengkap aplikasi dan sumber daya terkaitnya.

  • Periksa dependensi: Identifikasi dependensi apa pun pada layanan AWS khusus untuk EKS.

    Layanan AWS Dependensi
    AWS Secret Manager Azure Key Vault
    AWS Guard Duty Agent Pertahanan Microsoft untuk Kontainer
    AGEN Identitas Pod EKS Identitas Beban Kerja ID Microsoft Entra
    Driver Antarmuka Penyimpanan Kontainer (CSI) Amazon Elastic File System (EFS) atau Elastic Block Store (EBS) Driver CSI AKS

  • Kluster EKS Cadangan: Anda dapat menggunakan alat non-Microsoft seperti Velero untuk mencadangkan dan memigrasikan sumber daya Kubernetes dan volume persisten.

Menyiapkan lingkungan Azure AKS

Antarmuka Jaringan Kontainer (CNI) cloud privat virtual Amazon (VPC) adalah plugin jaringan default yang didukung oleh EKS. Kluster AKS mendukung beberapa plugin dan metode jaringan untuk menyebarkan kluster di jaringan virtual, termasuk:

Untuk menyiapkan kluster AKS Anda, ikuti langkah-langkah berikut:

  1. Buat kluster AKS baru di Azure, mengonfigurasi pengaturan jaringan yang diinginkan agar sesuai dengan kebutuhan Anda.
  2. Tinjau manifes Kubernetes dan file YAML yang digunakan di EKS. Periksa potensi ketidaksesuaian versi API Kubernetes atau konfigurasi EKS tertentu yang tidak didukung AKS.
  3. Pastikan bahwa gambar Docker dan lokasi registri gambar kontainer Anda dapat diakses dari kluster AKS. Verifikasi konektivitas jaringan dan pengaturan autentikasi dan otorisasi yang diperlukan untuk mengakses gambar.

Dengan mengikuti langkah-langkah ini, Anda dapat berhasil membuat kluster AKS dan memastikan kompatibilitas untuk manifes Kubernetes dan gambar Docker, memastikan proses migrasi yang lancar dari EKS ke AKS.

Gambaran umum migrasi

Migrasi dari Amazon EKS ke AKS melibatkan beberapa langkah, seperti:

  • Migrasi gambar kontainer: Memigrasikan gambar kontainer adalah langkah penting saat berpindah dari EKS ke AKS. Anda dapat menggunakan alat seperti kubectl, Docker, atau registri kontainer untuk mengekspor dan mengimpor gambar.

    1. Ekspor Gambar dari EKS.
    2. Siapkan Azure Container Registry dan lampirkan ke AKS jika Anda belum melakukannya.
    3. Dorong gambar ke Container Registry.

    Gambar kontainer juga dapat diimpor ke Container Registry langsung dari repositori publik atau privat non-Azure. Untuk informasi selengkapnya, lihat Mengimpor gambar kontainer.

  • Migrasi manifes Kubernetes: AKS menggunakan manifes file YAML Kubernetes untuk menentukan objek Kubernetes. Penyebaran biasanya dibuat dan dikelola dengan kubectl create atau kubectl apply. Buat penyebaran dengan mendefinisikan file manifes dalam format YAML. Untuk informasi selengkapnya, lihat contoh manifes AKS ini. Anda dapat mempelajari lebih lanjut tentang cara kerja file YAML di Kubernetes dengan meninjau manifes Deployments dan YAML.

  • Migrasi data: Rencanakan migrasi aplikasi stateful Anda dengan cermat untuk menghindari kehilangan data atau waktu henti yang tidak terduga. Untuk informasi selengkapnya, lihat bagian Pertimbangan migrasi beban kerja stateful.

Pertimbangan migrasi beban kerja tanpa status

Migrasi manifes Kubernetes melibatkan adaptasi konfigurasi untuk bekerja di lingkungan Azure, termasuk langkah-langkah berikut:

  1. Memperbarui manifes: Perbarui manifes Kubernetes Anda untuk menggunakan lokasi gambar baru di Container Registry. Ganti referensi gambar dalam file YAML Anda dengan jalur Container Registry.

    1. Tinjau file manifes Kubernetes yang ada untuk konfigurasi khusus AWS, seperti peran VPC dan IAM.
    2. Tinjau peran EKS IAM yang terkait dengan simpul, akun layanan, dan sumber daya lainnya. Petakan dengan peran kontrol akses berbasis peran (RBAC) Azure AKS yang setara. Untuk informasi selengkapnya, lihat Identitas dan akses beban kerja Kubernetes.
    3. Ubah file manifes untuk mengganti pengaturan khusus AWS dengan pengaturan khusus Azure, seperti anotasi.

  2. Terapkan manifes ke AKS:

    1. Sambungkan ke Kluster AKS.
    2. Terapkan file manifes Kubernetes yang dimodifikasi menggunakan kubectl apply -f.

Pertimbangan migrasi beban kerja stateful

Jika aplikasi Anda menggunakan Volume Persisten (PV) atau Klaim Volume Persisten (PVC) untuk penyimpanan data, pastikan Anda mencadangkan data ini. Anda dapat menggunakan alat seperti Velero untuk melakukan pencadangan kluster, termasuk untuk PV dan data PVC. Untuk informasi selengkapnya, lihat Mencadangkan dan memulihkan sumber daya kluster Amazon EKS Anda menggunakan Velero.

Aplikasi stateful biasanya memiliki persyaratan penyimpanan data persisten, yang menambahkan kompleksitas ke proses migrasi. Untuk perbandingan kemampuan penyimpanan Amazon EKS dan AKS, lihat Opsi penyimpanan untuk kluster Kubernetes.

Ikuti langkah-langkah ini untuk mencadangkan data persisten:

  1. Siapkan Velero di kluster AKS dan EKS .
  2. Lakukan pencadangan kluster EKS Anda.
  3. Salin cadangan Velero dari wadah S3 ke penyimpanan blob Azure, dengan menggunakan perintah az copy.
  4. Karena AKS dan EKS mungkin menggunakan yang berbeda storageClassNames untuk klaim volume persisten, buat configMap yang menerjemahkan sumber storageClassNames ke nama kelas yang kompatibel dengan AKS. Anda dapat mengabaikan langkah ini jika menggunakan solusi penyimpanan yang sama pada EKS dan kluster AKS Kubernetes.
  5. Pulihkan cadangan ke AKS (menggunakan perintah pemulihan Velero).
  6. Terapkan perubahan yang diperlukan pada objek yang dipulihkan, seperti referensi ke gambar kontainer di Amazon Elastic Container Registry (ECR), atau akses ke rahasia.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

  • Dixit Arora | Insinyur Pelanggan Senior, ISV DN Coe
  • Ketan Chawda | Insinyur Pelanggan Senior, ISV DN Coe

Kontributor lain:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya