Bermigrasi dari AWS ke Google Cloud: Bermigrasi dari Amazon EKS ke GKE

Last reviewed 2024-08-02 UTC

Google Cloud menyediakan alat, produk, panduan, dan layanan profesional untuk bermigrasi dari Amazon Elastic Kubernetes Service (Amazon EKS) ke Google Kubernetes Engine (GKE). Dokumen ini membantu Anda untuk mendesain,menerapkan, dan memvalidasi sebuah rencana bermigrasi dari Amazon EKS ke GKE. Dokumen ini juga menyediakan panduan jika Anda mengevaluasi peluang untuk bermigrasi dan ingin mempelajari tampilan migrasi tersebut. Selain berjalan di Amazon Elastic Compute Cloud (Amazon EC2), Amazon EKS memiliki beberapa opsi deployment lainnya, seperti Amazon EKS pada output AWS dan Amazon EKS di mana saja. Dokumen ini berfokus pada Amazon EKS di EC2.

Dokumen ini adalah bagian dari rangkaian multi-bagian tentang migrasi dari AWS ke Google Cloud yang mencakup dokumen berikut:

GKE adalah layanan Kubernetes yang dikelola Google yang dapat Anda gunakan untuk men-deploy dan mengoperasikan aplikasi dalam container dalam skala besar menggunakan infrastruktur Google, serta menyediakan fitur yang membantu Anda mengelola lingkungan Kubernetes, seperti:

  • Dua edisi: GKE Standard dan GKE Enterprise. Dengan GKE Standard, Anda mendapatkan akses ke tingkat standar fitur inti. Dengan GKE Enterprise, Anda mendapatkan akses ke semua kemampuan GKE. Untuk informasi selengkapnya, lihat edisi GKE.
  • Dua mode operasi: Standar dan Autopilot. Dengan Standard, Anda mengelola infrastruktur pokok dan konfigurasi setiap node di cluster GKE. Dengan Autopilot, GKE mengelola infrastruktur dasar seperti konfigurasi node, penskalaan otomatis, upgrade otomatis, keamanan dasar pengukuran, dan konfigurasi jaringan. Untuk mengetahui informasi selengkapnya tentang mode operasi GKE, lihat Memilih mode operasi GKE.
  • Perjanjian tingkat layanan unik industri untuk Pod saat menggunakan Autopilot di beberapa zona.
  • Pembuatan dan penghapusan node pool otomatis dengan penyediaan otomatis node.
  • Jaringan multi-cluster yang dikelola Google untuk membantu Anda mendesain dan menerapkan arsitektur terdistribusi yang selalu tersedia untuk workload Anda.

Untuk mengetahui informasi selengkapnya tentang GKE, lihat Ringkasan GKE.

Untuk migrasi ke Google Cloud ini, sebaiknya ikuti framework migrasi yang dijelaskan dalam Migrasi ke Google Cloud: Memulai.

Diagram berikut menggambarkan jalur perjalanan migrasi Anda.

Jalur migrasi dengan empat fase.

Anda dapat bermigrasi dari lingkungan sumber ke Google Cloud dalam serangkaian iterasi—misalnya, Anda dapat memigrasikan beberapa workload terlebih dahulu dan yang lainnya nanti. Untuk setiap iterasi migrasi terpisah, Anda harus mengikuti fase framework migrasi umum:

  1. Lakukan penilaian dan temukan workload dan data Anda.
  2. Rencanakan dan bangun fondasi di Google Cloud.
  3. Memigrasikan workload dan data Anda ke Google Cloud.
  4. Mengoptimalkan lingkungan Google Cloud Anda.

Untuk mengetahui informasi selengkapnya tentang fase framework ini, lihat Bermigrasi ke Google Cloud: Memulai.

Untuk mendesain rencana migrasi yang efektif, sebaiknya validasi setiap langkah rencana, dan pastikan Anda memiliki strategi rollback. Untuk membantu Anda memvalidasi rencana migrasi, lihat Bermigrasi ke Google Cloud: Praktik terbaik untuk memvalidasi rencana migrasi.

Menilai lingkungan sumber

Pada fase penilaian, Anda akan menentukan persyaratan dan dependensi untuk memigrasikan lingkungan sumber ke Google Cloud.

Fase penilaian sangat penting untuk keberhasilan migrasi Anda. Anda perlu mendapatkan pengetahuan mendalam tentang workload yang ingin dimigrasikan, persyaratannya, dependensinya, dan tentang lingkungan Anda saat ini. Anda perlu memahami titik awal agar berhasil merencanakan dan menjalankan migrasi Google Cloud.

Fase penilaian terdiri dari tugas-tugas berikut:

  1. Mem-build inventaris workload yang komprehensif.
  2. Membuat katalog workload Anda sesuai dengan properti dan dependensinya.
  3. Latih dan ajari tim Anda di Google Cloud.
  4. Buat eksperimen dan bukti konsep di Google Cloud.
  5. Hitung total biaya kepemilikan (TCO) lingkungan target.
  6. Pilih strategi migrasi untuk workload Anda.
  7. Pilih alat migrasi Anda.
  8. Tentukan rencana dan linimasa migrasi.
  9. Validasi rencana migrasi Anda.

Untuk mengetahui informasi selengkapnya tentang fase penilaian dan tugas ini, lihat Bermigrasi ke Google Cloud: Menilai dan menemukan workload Anda. Bagian berikut didasarkan pada informasi dalam dokumen tersebut.

Membangun inventaris Anda

Untuk menentukan cakupan migrasi, buat dua inventaris:

  1. Inventaris cluster Anda.
  2. Inventaris workload Anda yang di-deploy di cluster tersebut.

Setelah membuat inventaris ini, Anda:

  1. Menilai proses deployment dan operasional untuk lingkungan sumber Anda.
  2. Evaluasi layanan pendukung dan dependensi eksternal.

Membuat inventaris cluster

Untuk mem-build inventaris cluster Anda, pertimbangkan hal berikut untuk setiap cluster:

  • Jumlah dan jenis node. Setelah mengetahui jumlah node dan karakteristik setiap node yang Anda miliki di lingkungan saat ini, Anda dapat menyesuaikan ukuran cluster saat berpindah ke GKE. Node di lingkungan baru Anda mungkin berjalan pada generasi atau arsitektur hardware yang berbeda dengan yang Anda gunakan di lingkungan. Performa setiap arsitektur dan generasi akan berbeda, sehingga jumlah node yang Anda perlukan di lingkungan baru mungkin berbeda dari lingkungan Anda. Evaluasi semua jenis hardware yang Anda gunakan di node, seperti perangkat penyimpanan, GPU, dan TPU berperforma tinggi. Nilai image sistem operasi yang Anda gunakan di node.
  • Cluster internal atau eksternal. Evaluasi aktor mana, baik dari internal ke lingkungan Anda atau eksternal, yang terpapar oleh setiap klaster. Untuk mendukung kasus penggunaan Anda, evaluasi ini mencakup workload yang berjalan di cluster, dan antarmuka yang berinteraksi dengan cluster Anda.
  • Multi-tenancy. Jika Anda mengelola cluster multi-tenant di lingkungan Anda, nilai apakah cluster tersebut berfungsi di lingkungan Google Cloud yang baru. Sekarang adalah saat yang tepat untuk mengevaluasi cara meningkatkan cluster multi-tenant Anda karena strategi multi-tenancy Anda memengaruhi cara Anda membangun fondasi di Google Cloud.
  • Versi Kubernetes. Kumpulkan informasi tentang versi Kubernetes dari cluster Anda untuk menilai apakah ada ketidakcocokan antara versi tersebut dan yang tersedia di GKE. Jika menjalankan versi Kubernetes yang lebih lama atau yang baru dirilis, Anda mungkin menggunakan fitur yang tidak tersedia di GKE. Fitur tersebut mungkin tidak digunakan lagi, atau versi Kubernetes yang mengirimkannya belum tersedia di GKE.
  • Siklus upgrade Kubernetes. Untuk mempertahankan lingkungan yang andal, pahami cara Anda menangani upgrade Kubernetes dan hubungan siklus upgrade Anda dengan upgrade GKE.
  • Kumpulan Node. Jika menggunakan bentuk pengelompokan node apa pun, Anda mungkin perlu mempertimbangkan cara pengelompokan ini dipetakan ke konsep kumpulan node di GKE karena kriteria pengelompokan Anda mungkin tidak sesuai untuk GKE.
  • Inisialisasi node. Lakukan penilaian terhadap cara Anda menginisialisasi setiap node sebelum menandainya sebagai tersedia untuk menjalankan workload, sehingga Anda dapat mentransfer prosedur inisialisasi tersebut ke GKE.
  • Konfigurasi jaringan. Nilai konfigurasi jaringan cluster Anda, alokasi alamat IP-nya, cara Anda mengonfigurasi plugin jaringannya, cara Anda mengonfigurasi server DNS dan penyedia layanan DNS-nya, apakah Anda mengonfigurasi bentuk NAT atau SNAT apa pun untuk cluster ini, dan apakah cluster tersebut merupakan bagian dari lingkungan multi-cluster.
  • Kepatuhan: Tinjau setiap persyaratan kepatuhan dan peraturan yang harus dipenuhi oleh cluster Anda, dan apakah Anda memenuhi persyaratan ini.
  • Kuota dan batas. Evaluasi cara Anda mengonfigurasi kuota dan batas untuk cluster. Misalnya, berapa banyak Pod yang dapat dijalankan setiap node? Berapa jumlah node yang dapat dimiliki cluster?
  • Label dan tag. Nilai metadata apa pun yang Anda terapkan ke cluster, node pool, dan node, serta cara Anda menggunakannya. Misalnya, Anda mungkin membuat laporan dengan atribusi biaya berbasis label yang mendetail.

Item berikut yang Anda nilai dalam inventaris berfokus pada keamanan infrastruktur dan cluster Kubernetes Anda:

  • Namespaces. Jika Anda menggunakan Namespaces Kubernetes di cluster Anda untuk memisahkan resource secara logis, nilai resource mana yang ada di setiap Namespace, dan pahami alasan Anda membuat pemisahan ini. Misalnya, Anda mungkin menggunakan Namespace sebagai bagian dari strategi multi-tenancy. Anda mungkin memiliki beban kerja yang di-deploy di Namespace yang dicadangkan untuk komponen sistem Kubernetes, dan Anda mungkin tidak memiliki banyak kontrol di GKE.
  • Kontrol akses berbasis peran (RBAC). Jika Anda menggunakan otorisasi RBAC di cluster, cantumkan deskripsi semua ClusterRoles dan ClusterRoleBindings yang Anda konfigurasi di cluster Anda.
  • Kebijakan jaringan. Catat semua kebijakan jaringan yang Anda konfigurasi di cluster, dan pahami cara kerja kebijakan jaringan di GKE.
  • Konteks keamanan pod. Catat informasi tentang konteks keamanan Pod yang Anda konfigurasi di cluster dan pelajari cara kerjanya di GKE.
  • Akun layanan. Jika ada proses di cluster Anda yang berinteraksi dengan server Kubernetes API, ambil informasi tentang akun layanan yang mereka gunakan.

Saat mem-build inventaris cluster Kubernetes, Anda mungkin mendapati bahwa beberapa cluster perlu dinonaktifkan sebagai bagian dari migrasi Anda. Pastikan bahwa rencana migrasi Anda mencakup penghentian resource ini.

Mem-build inventaris workload Kubernetes Anda

Setelah menyelesaikan inventaris cluster Kubernetes dan menilai keamanan lingkungan Anda, bangun inventaris workload yang di-deploy di cluster tersebut. Saat mengevaluasi beban kerja, kumpulkan informasi tentang aspek-aspek berikut:

  • Pod dan pengontrol. Untuk mengukur cluster di lingkungan baru Anda, nilai jumlah instance dari setiap beban kerja yang telah di-deploy, dan apakah Anda menggunakan Kuota resource dan menghitung batas konsumsi resource. Kumpulkan informasi tentang beban kerja yang berjalan di node bidang kontrol setiap cluster dan pengontrol yang digunakan oleh setiap beban kerja. Misalnya, berapa banyak Deployments yang Anda gunakan? Berapa banyak DaemonSets yang Anda gunakan?
  • Tugas dan CronJobs. Cluster dan beban kerja Anda mungkin perlu menjalankan Tugas atau CronJobs sebagai bagian dari prosedur inisialisasi atau operasinya. Menilai jumlah instance Lowongan dan CronJobs yang telah Anda deploy, serta kriteria penyelesaian dan tanggung jawab untuk setiap instance.
  • Autoscaler Kubernetes. Untuk memigrasikan kebijakan penskalaan otomatis di lingkungan baru, pelajari cara Autoscaler Pod Horizontal dan Autoscaler Pod Vertikal, di GKE.
  • Workload stateful dan stateless. Workload stateless tidak menyimpan data atau status dalam cluster atau ke penyimpanan persisten. Aplikasi stateful menyimpan data untuk digunakan nanti. Untuk setiap beban kerja, nilai komponen mana yang stateless dan stateful, karena memigrasikan stateful workloads biasanya lebih sulit daripada memigrasikan workload stateless.
  • Fitur Kubernetes. Dari inventaris cluster, Anda tahu versi Kubernetes mana yang dijalankan oleh setiap cluster. Tinjau catatan rilis setiap versi Kubernetes untuk mengetahui fitur mana yang dikirimkan dan fitur mana yang tidak digunakan lagi. Kemudian nilai workload Anda berdasarkan fitur Kubernetes yang Anda perlukan. Tujuan tugas ini adalah untuk mengetahui apakah Anda menggunakan fitur yang tidak digunakan lagi atau fitur yang belum tersedia di GKE. Jika Anda menemukan fitur yang tidak tersedia, beralihlah dari fitur yang tidak digunakan lagi dan gunakan fitur baru saat tersedia di GKE.
  • Penyimpanan. Untuk workload stateful, nilai apakah workload tersebut menggunakan PersistenceVolumeClaims. Mencantumkan semua persyaratan penyimpanan, seperti ukuran dan mode akses, serta cara PersistenceVolumeClaims ini dipetakan ke PersistenceVolumes. Untuk memperhitungkan pertumbuhan di masa mendatang, nilai apakah Anda perlu memperluas PersistenceVolumeClaim.
  • Konfigurasi dan injeksi secret. Untuk menghindari mem-build ulang artefak yang dapat di-deploy setiap kali ada perubahan dalam konfigurasi lingkungan Anda, masukkan konfigurasi dan secret ke dalam Pod menggunakan ConfigMaps dan Secrets. Untuk setiap beban kerja, nilai ConfigMaps dan Rahasia mana yang digunakan workload, dan cara Anda mengisi objek tersebut.
  • dependensi berurutan. Workload Anda mungkin tidak bekerja secara isolasi. Komponen tersebut mungkin memiliki dependensi, baik dari internal ke cluster, maupun dari sistem eksternal. Untuk setiap beban kerja, catat dependensinya, dan apakah beban kerja Anda memiliki toleransi saat dependensi tidak tersedia. Misalnya, dependensi umum meliputi sistem file terdistribusi, database, platform distribusi rahasia, sistem pengelolaan akses dan identitas, mekanisme penemuan layanan, dan sistem eksternal lainnya.
  • Kubernetes Services. Untuk mengekspos workload Anda ke klien internal dan eksternal, gunakan Layanan. Untuk setiap Layanan, Anda perlu mengetahui jenisnya. Untuk layanan yang diekspos secara eksternal, nilai cara layanan tersebut berinteraksi dengan seluruh infrastruktur Anda. Misalnya, bagaimana infrastruktur Anda mendukung layanan LoadBalancer, Objek gateway, dan Objek Ingress? Ingress controller mana yang Anda deploy di cluster?
  • Mesh Layanan. Jika menggunakan mesh layanan di lingkungan Anda, Anda akan menilai cara layanan tersebut dikonfigurasi. Anda juga perlu mengetahui jumlah cluster yang dicakupnya, layanan mana yang merupakan bagian dari mesh, dan cara Anda memodifikasi topologi mesh.
  • Taint dan toleransi serta afinitas dan anti-afinitas. Untuk setiap Pod dan Node, nilai apakah Anda mengonfigurasi taint Node, toleransi Pod, atau afinitas untuk menyesuaikan penjadwalan Pod di cluster Kubernetes. Properti ini juga dapat memberi Anda insight tentang kemungkinan konfigurasi Node atau Pod non-homogen, dan dapat berarti bahwa Pod, Node, atau keduanya perlu dinilai dengan fokus dan perhatian khusus. Misalnya, jika Anda mengonfigurasi kumpulan Pod tertentu untuk dijadwalkan hanya pada Node tertentu di cluster Kubernetes, itu mungkin berarti bahwa Pod memerlukan resource khusus yang hanya tersedia di Node tersebut.
  • Autentikasi: Menilai cara workload Anda melakukan autentikasi terhadap resource di cluster, dan terhadap resource eksternal.

Menilai layanan pendukung dan dependensi eksternal

Setelah menilai cluster dan workload-nya, evaluasi layanan dan aspek pendukung lainnya dalam infrastruktur Anda, seperti berikut:

  • StorageClass dan PersistentVolumes. Nilai cara infrastruktur Anda mendukung PersistentVolumeClaims dengan mencantumkan StorageClasses untuk dynamic provisioning, dan statically provisioned PersistentVolumes. Untuk setiap PersistentVolume, pertimbangkan hal berikut: kapasitas, mode volume mode akses, class, kebijakan klaim kembali, opsi pemasangan, dan afinitas node.
  • VolumeSnapshots dan VolumeSnapshotContents. Untuk setiap PersistentVolume, nilai apakah Anda mengonfigurasi VolumeSnapshot, dan apakah Anda perlu memigrasikan VolumeSnapshotContents yang ada.
  • Driver Container Storage Interface (CSI). Jika di-deploy di cluster Anda, periksa apakah driver ini kompatibel dengan GKE, dan apakah Anda perlu menyesuaikan konfigurasi volume agar dapat digunakan dengan driver CSI yang kompatibel dengan GKE.
  • Penyimpanan Data. Jika Anda mengandalkan sistem eksternal untuk menyediakan PersistentVolume, berikan cara bagi workload di lingkungan GKE Anda untuk menggunakan sistem tersebut. Lokalitas data berdampak pada performa workload stateful, karena latensi antara sistem eksternal dan lingkungan GKE Anda sebanding dengan jarak antar-sistem. Untuk setiap sistem penyimpanan data eksternal, pertimbangkan jenisnya, seperti volume blok, penyimpanan file, atau penyimpanan objek, serta persyaratan performa dan ketersediaan yang perlu dipenuhi.
  • Resource kustom dan add-on Kubernetes. Kumpulkan informasi tentang resource Kubernetes kustom dan add-on Kubernetes yang mungkin telah Anda deploy di cluster, karena resource tersebut mungkin tidak berfungsi di GKE, atau Anda mungkin perlu memodifikasinya. Misalnya, jika resource kustom berinteraksi dengan sistem eksternal, Anda akan menilai apakah resource tersebut berlaku untuk lingkungan Google Cloud Anda.
  • Pencadangan. Evaluasi cara Anda mencadangkan konfigurasi cluster dan data beban kerja stateful di lingkungan sumber.

Menilai proses deployment dan operasional Anda

Sangat penting untuk memiliki pemahaman yang jelas tentang cara kerja proses deployment dan operasional Anda. Proses ini adalah bagian mendasar dari praktik yang menyiapkan dan memelihara lingkungan produksi Anda serta beban kerja yang berjalan di sana.

Proses deployment dan operasional Anda dapat mem-build artefak yang diperlukan oleh beban kerja Anda agar berfungsi. Oleh karena itu, Anda harus mengumpulkan informasi tentang setiap jenis artefak. Misalnya, artefak dapat berupa paket sistem operasi, paket deployment aplikasi, image sistem operasi container, atau lainnya.

Selain jenis artefak, pertimbangkan cara Anda menyelesaikan tugas-tugas berikut:

  • Kembangkan workload Anda. Nilai proses yang dimiliki tim pengembangan untuk mem-build workload Anda. Misalnya, bagaimana tim pengembangan Anda mendesain, melakukan coding, dan menguji workload?
  • Buat artefak yang Anda deploy di lingkungan sumber. Untuk men-deploy beban kerja di lingkungan sumber, Anda mungkin membuat artefak yang dapat di-deploy, seperti image container atau image sistem operasi, atau Anda mungkin menyesuaikan artefak yang ada, seperti image sistem operasi pihak ketiga dengan menginstal dan mengonfigurasi software. Mengumpulkan informasi tentang cara Anda membuat artefak ini membantu Anda memastikan bahwa artefak yang dihasilkan sesuai untuk deployment di Google Cloud.

  • Simpan artefak. Jika Anda membuat artefak yang disimpan di registry artefak di lingkungan sumber, Anda harus menyediakan artefak tersebut di lingkungan Google Cloud. Anda dapat melakukannya dengan menggunakan strategi seperti berikut:

    • Membuat saluran komunikasi antarlingkungan: Buat artefak di lingkungan sumber Anda dapat dijangkau dari lingkungan Google Cloud target.
    • Faktorkan ulang proses build artefak: Selesaikan pemfaktoran ulang kecil pada lingkungan sumber agar Anda dapat menyimpan artefak di lingkungan sumber dan lingkungan target. Pendekatan ini mendukung migrasi Anda dengan mem-build infrastruktur seperti repositori artefak sebelum Anda harus menerapkan proses build artefak di lingkungan Google Cloud target. Anda dapat menerapkan pendekatan ini secara langsung, atau Anda dapat mengembangkan pendekatan sebelumnya dengan membuat saluran komunikasi terlebih dahulu.

    Dengan memiliki artefak yang tersedia di lingkungan sumber dan target, Anda dapat berfokus pada migrasi tanpa harus menerapkan proses build artefak di lingkungan Google Cloud target sebagai bagian dari migrasi.

  • Pindai dan tanda tangani kode. Sebagai bagian dari proses build artefak, Anda mungkin menggunakan pemindaian kode untuk membantu Anda melindungi dari kerentanan umum dan ekspos jaringan yang tidak diinginkan, serta penandatanganan kode untuk membantu Anda memastikan bahwa hanya kode tepercaya yang berjalan di lingkungan Anda.

  • Deploy artefak di lingkungan sumber. Setelah membuat artefak yang dapat di-deploy, Anda mungkin akan men-deploy-nya di lingkungan sumber. Sebaiknya Anda menilai setiap proses deployment. Penilaian ini membantu memastikan bahwa proses deployment Anda kompatibel dengan Google Cloud. Hal ini juga membantu Anda memahami upaya yang pada akhirnya akan diperlukan untuk memfaktorkan ulang proses. Misalnya, jika proses deployment Anda hanya berfungsi dengan lingkungan sumber, Anda mungkin perlu memfaktorkan ulang proses tersebut untuk menargetkan lingkungan Google Cloud Anda.

  • Memasukkan konfigurasi runtime. Anda mungkin memasukkan konfigurasi runtime untuk cluster, lingkungan runtime, atau deployment beban kerja tertentu. Konfigurasi dapat menginisialisasi variabel lingkungan dan nilai konfigurasi lainnya seperti secret, kredensial, dan kunci. Untuk membantu memastikan proses injeksi konfigurasi runtime Anda berfungsi di Google Cloud, sebaiknya Anda menilai cara Anda mengonfigurasi workload yang berjalan di lingkungan sumber Anda.

  • Logging, pemantauan, dan pembuatan profil. Nilai proses logging, pemantauan, dan pembuatan profil yang Anda terapkan untuk memantau kondisi lingkungan sumber, metrik yang diinginkan, dan cara Anda menggunakan data yang disediakan oleh proses ini.

  • Autentikasi. Nilai cara Anda mengautentikasi terhadap lingkungan sumber.

  • Menyediakan dan mengonfigurasi resource Anda. Untuk menyiapkan lingkungan sumber, Anda mungkin telah mendesain dan menerapkan proses yang menyediakan dan mengonfigurasi resource. Misalnya, Anda mungkin menggunakan Terraform bersama dengan alat pengelolaan konfigurasi untuk menyediakan dan mengonfigurasi resource di lingkungan sumber Anda.

Alat untuk membuat inventaris lingkungan sumber Anda

Untuk mem-build inventaris cluster Amazon EKS, sebaiknya gunakan Migration Center, platform terpadu Google Cloud yang membantu Anda mempercepat perjalanan cloud menyeluruh dari lingkungan Anda saat ini ke Google Cloud. Migration Center memungkinkan Anda mengimpor data dari Amazon EKS dan resource AWS lainnya. Migration Center kemudian merekomendasikan layanan Google Cloud yang relevan yang dapat Anda jadikan tujuan migrasi.

Meningkatkan kualitas inventaris cluster dan beban kerja Amazon EKS Anda

Data yang disediakan oleh Pusat Migrasi mungkin tidak sepenuhnya mengambil dimensi yang Anda minati. Dalam hal ini, Anda dapat mengintegrasikan data tersebut dengan hasil dari mekanisme pengumpulan data lain yang Anda buat berdasarkan AWS API, alat developer AWS, dan antarmuka command line AWS.

Selain data yang Anda dapatkan dari Migration Center, pertimbangkan titik data berikut untuk setiap cluster Amazon EKS yang ingin Anda migrasikan:

  • Pertimbangkan aspek dan fitur khusus Amazon EKS untuk setiap cluster Amazon EKS, termasuk yang berikut ini:
    • Cluster pribadi
    • Kontrol akses endpoint cluster
    • Enkripsi rahasia
    • Grup node terkelola dan node yang dikelola sendiri
    • Tag pada resource Amazon EKS
    • AMI Kustom Amazon dalam EKS
    • Penggunaan Amazon EKS Fargate
    • Penggunaan Prometheus Terkelola Amazon EKS
    • Konfigurasi autentikasi OpenID Connect
  • Nilai cara Anda melakukan autentikasi terhadap cluster Amazon EKS dan cara Anda mengonfigurasi AWS Identity and Access Management (IAM) untuk Amazon EKS.
  • Nilai konfigurasi jaringan cluster Amazon EKS Anda.

Merencanakan dan membangun fondasi Anda

Pada fase perencanaan dan build, Anda akan menyediakan dan mengonfigurasi infrastruktur untuk melakukan hal berikut:

  • Dukung workload Anda di lingkungan Google Cloud.
  • Hubungkan lingkungan sumber dan lingkungan Google Cloud Anda untuk menyelesaikan migrasi.

Fase perencanaan dan build terdiri dari tugas-tugas berikut:

  1. Buat hierarki resource.
  2. Mengonfigurasi Identity and Access Management (IAM) Google Cloud.
  3. Menyiapkan penagihan.
  4. Menyiapkan konektivitas jaringan.
  5. Perketat keamanan Anda.
  6. Siapkan logging, pemantauan, dan pemberitahuan.

Untuk mengetahui informasi selengkapnya tentang setiap tugas ini, lihat Bermigrasi ke Google Cloud: Merencanakan dan membangun fondasi Anda.

Bagian berikut mengintegrasikan pertimbangan dalam Memigrasikan ke Google Cloud: Merencanakan dan membangun fondasi Anda.

Membuat rencana untuk multi-tenancy

Untuk mendesain hierarki resource yang efisien, pertimbangkan cara struktur bisnis dan organisasi Anda dipetakan ke Google Cloud. Misalnya, jika memerlukan lingkungan multi-tenant di GKE, Anda dapat memilih di antara opsi berikut:

  • Membuat satu project Google Cloud untuk setiap tenant.
  • Membagikan satu project di antara tenant yang berbeda, dan menyediakan beberapa cluster GKE.
  • Menggunakan namespace Kubernetes.

Pilihan Anda bergantung pada kebutuhan isolasi, kompleksitas, dan skalabilitas Anda. Untuk Misalnya, memiliki satu project per tenant akan mengisolasi tenant dari satu sama lain, etapi hierarki resource menjadi lebih kompleks untuk dikelola karena banyaknya jumlah project. Namun, meskipun mengelola Namespace Kubernetes relatif lebih mudah daripada hierarki resource yang kompleks, opsi ini tidak menjamin banyak isolasi. Misalnya, bidang kontrol mungkin dibagikan kepada tenant. Untuk mengetahui informasi selengkapnya, lihat Multi-tenancy cluster.

Konfigurasikan pengelolaan akses dan identitas

GKE mendukung berbagai opsi untuk mengelola akses ke resource dalam project Google Cloud Anda dan cluster-nya menggunakan RBAC. Untuk informasi selengkapnya, lihat Kontrol akses.

Mengonfigurasi jaringan GKE

Konfigurasi jaringan adalah aspek mendasar dari lingkungan Anda. Sebelum menyediakan dan mengonfigurasi cluster, sebaiknya Anda menilai model jaringan GKE, praktik terbaik untuk jaringan GKE, dan cara merencanakan alamat IP saat bermigrasi ke GKE.

Menyiapkan pemantauan dan pemberitahuan

Memiliki gambaran yang jelas tentang performa infrastruktur dan workload Anda adalah kunci untuk menemukan area peningkatan. GKE memiliki integrasi mendalam dengan Google Cloud Observability, sehingga Anda mendapatkan informasi logging, pemantauan, dan pembuatan profil tentang cluster dan workload GKE di dalam cluster tersebut.

Memigrasikan data Anda dan men-deploy workload

Pada fase deployment, Anda melakukan hal berikut:

  1. Menyediakan dan mengonfigurasi lingkungan GKE Anda.
  2. Konfigurasikan cluster GKE Anda.
  3. Faktorkan ulang beban kerja Anda.
  4. Memfaktorkan ulang proses deployment dan operasional.
  5. Migrasikan data dari lingkungan sumber Anda ke Google Cloud.
  6. Deploy workload Anda di lingkungan GKE.
  7. Validasi workload dan lingkungan GKE Anda.
  8. Mengekspos workload yang berjalan di GKE.
  9. Mengalihkan traffic dari lingkungan sumber ke lingkungan GKE.
  10. Penghentian lingkungan sumber.

Menyediakan dan mengonfigurasi lingkungan Google Cloud

Sebelum memindahkan beban kerja apa pun ke lingkungan Google Cloud yang baru, Anda harus menyediakan cluster GKE.

GKE mendukung pengaktifan fitur tertentu di cluster yang ada, tetapi mungkin ada fitur yang hanya dapat Anda aktifkan pada saat pembuatan cluster. Untuk membantu Anda menghindari gangguan dan menyederhanakan migrasi, sebaiknya Anda mengaktifkan fitur cluster yang diperlukan pada saat pembuatan cluster. Jika tidak, Anda mungkin perlu menghancurkan dan membuat ulang cluster jika fitur cluster yang Anda perlukan tidak dapat diaktifkan setelah membuat cluster.

Setelah fase penilaian, sekarang Anda tahu cara menyediakan cluster GKE di lingkungan Google Cloud baru untuk memenuhi kebutuhan Anda. Untuk menyediakan cluster, pertimbangkan hal berikut:

Untuk informasi selengkapnya tentang penyediaan cluster GKE, lihat:

Manajemen Fleet

Saat menyediakan cluster GKE, Anda mungkin menyadari bahwa Anda memerlukan cluster dalam jumlah besar untuk mendukung semua kasus penggunaan lingkungan Anda. Misalnya, Anda mungkin perlu memisahkan produksi dari lingkungan non-produksi, atau memisahkan layanan di seluruh tim atau geografi. Untuk mengetahui informasi selengkapnya, lihat kasus penggunaan multi-cluster.

Seiring bertambahnya jumlah cluster, lingkungan GKE Anda mungkin menjadi lebih sulit dikelola karena mengelola cluster dalam jumlah besar menimbulkan tantangan operasional dan skalabilitas yang signifikan. GKE menyediakan alat dan fitur untuk membantu Anda mengelola fleet, pengelompokan cluster Kubernetes secara logis. Untuk mengetahui informasi selengkapnya, lihat Pengelolaan armada.

Networking multi-cluster

Untuk membantu meningkatkan keandalan lingkungan GKE, dan untuk mendistribusikan beban kerja di beberapa cluster GKE, Anda dapat menggunakan:

  • Penemuan Layanan Multi-Cluster, mekanisme pemanggilan dan penemuan layanan lintas cluster. Layanan dapat ditemukan dan diakses di seluruh cluster GKE. Untuk mengetahui informasi selengkapnya, lihat Multi-Cluster Service Discovery.
  • Gateway multi-cluster, mekanisme load balancing traffic masuk lintas cluster. Untuk mengetahui informasi selengkapnya, lihat Men-deploy Gateway multi-cluster.
  • Mesh multi-cluster di Cloud Service Mesh terkelola. Untuk mengetahui informasi selengkapnya, lihat Menyiapkan mesh multi-cluster.

Untuk informasi selengkapnya tentang cara bermigrasi dari lingkungan GKE cluster tunggal ke lingkungan GKE multi-cluster, lihat Bermigrasi ke jaringan multi-cluster.

Mengonfigurasi cluster GKE

Setelah menyediakan cluster GKE dan sebelum men-deploy berbagai workload atau memigrasikan data, Anda harus mengonfigurasi namespace, RBAC, kebijakan jaringan, akun layanan, dan objek Kubernetes dan GKE lainnya untuk setiap cluster GKE.

Untuk mengonfigurasi objek Kubernetes dan GKE di cluster GKE, sebaiknya Anda:

  1. Pastikan Anda memiliki kredensial dan izin yang diperlukan untuk mengakses kedua cluster di lingkungan sumber, dan di lingkungan GKE Anda.
  2. Lakukan penilaian apakah objek di cluster Kubernetes atau lingkungan sumber Anda kompatibel dengan GKE, dan bagaimana implementasi yang mendukung objek ini berbeda dengan lingkungan sumber dan GKE.
  3. Faktorkan ulang objek yang tidak kompatibel agar kompatibel dengan GKE, atau hentikan.
  4. Buat objek ini ke cluster GKE Anda.
  5. Konfigurasikan objek tambahan apa pun yang dibutuhkan di cluster GKE Anda.

Config Sync

Untuk membantu Anda menerapkan praktik terbaik GitOps guna mengelola konfigurasi cluster GKE saat GKE diskalakan, sebaiknya gunakan Config Sync, layanan GitOps untuk men-deploy konfigurasi dari sumber tepercaya. Misalnya, Anda dapat menyimpan konfigurasi cluster GKE di repositori Git, dan menggunakan Config Sync untuk menerapkan konfigurasi tersebut.

Untuk mengetahui informasi selengkapnya, lihat Arsitektur Config Sync.

Pengontrol Kebijakan

Pengontrol Kebijakan membantu Anda menerapkan dan menerapkan kebijakan yang dapat diprogram untuk membantu memastikan bahwa cluster dan workload GKE Anda berjalan dengan cara yang aman dan mematuhi kebijakan. Saat lingkungan GKE diskalakan, Anda dapat menggunakan Pengontrol Kebijakan untuk menerapkan kebijakan, paket kebijakan, dan batasan secara otomatis ke semua cluster GKE. Misalnya, Anda dapat membatasi repositori tempat image container dapat diambil, atau Anda dapat mewajibkan setiap namespace memiliki minimal satu label untuk membantu Anda memastikan pelacakan penggunaan resource yang akurat.

Untuk informasi selengkapnya, lihat Pengontrol Kebijakan.

Memfaktorkan ulang workload

Praktik terbaik untuk mendesain workload dalam container adalah menghindari dependensi pada platform orkestrasi container. Hal ini mungkin tidak selalu dapat dilakukan dalam prakteknya karena persyaratan dan desain beban kerja Anda. Misalnya, beban kerja Anda mungkin bergantung pada fitur khusus lingkungan yang tersedia hanya di lingkungan sumber, seperti add-on, ekstensi, dan integrasi.

Meskipun Anda mungkin dapat memigrasikan sebagian besar workload apa adanya ke GKE, Anda mungkin perlu melakukan upaya tambahan untuk memfaktorkan ulang workload yang bergantung pada fitur khusus lingkungan, untuk meminimalkan dependensi ini, dan pada akhirnya beralih ke alternatif yang tersedia di GKE.

Untuk memfaktorkan ulang workload sebelum memigrasikannya ke GKE, Anda harus melakukan hal berikut:

  1. Tinjau fitur khusus lingkungan sumber, seperti add-on, ekstensi, dan integrasi.
  2. Gunakan solusi GKE alternatif yang sesuai.
  3. Faktorkan ulang beban kerja Anda.

Meninjau fitur khusus lingkungan sumber

Jika menggunakan fitur khusus lingkungan sumber, dan workload Anda bergantung pada fitur ini, Anda harus:

  1. Temukan solusi GKE alternatif yang sesuai.
  2. Faktorkan ulang workload Anda untuk memanfaatkan solusi GKE alternatif.

Sebagai bagian dari peninjauan ini, sebaiknya Anda melakukan hal berikut:

  • Pertimbangkan apakah Anda dapat menghentikan penggunaan salah satu fitur khusus lingkungan sumber ini.
  • Evaluasi seberapa penting fitur khusus lingkungan sumber untuk keberhasilan migrasi.

Mengadopsi solusi GKE alternatif yang sesuai

Setelah meninjau fitur khusus lingkungan sumber, dan memetakan solusi alternatif GKE yang sesuai, Anda akan mengadopsi solusi ini di lingkungan GKE. Untuk mengurangi kompleksitas migrasi, sebaiknya lakukan hal berikut:

  • Hindari mengadopsi solusi GKE alternatif untuk fitur khusus lingkungan sumber yang ingin Anda hentikan.
  • Berfokuslah untuk mengadopsi solusi GKE alternatif untuk fitur khusus lingkungan sumber yang paling kritis, dan rencanakan project migrasi khusus untuk fitur lainnya.

Memfaktorkan ulang workload

Meskipun sebagian besar beban kerja Anda mungkin berfungsi seperti di GKE, Anda mungkin perlu memfaktorkan ulang beberapa di antaranya, terutama jika beban kerja tersebut bergantung pada fitur khusus lingkungan sumber yang Anda gunakan untuk solusi GKE alternatif.

Pemfaktoran ulang ini mungkin melibatkan:

  • Deskripsi objek Kubernetes, seperti Deployment, dan Layanan yang dinyatakan dalam format YAML.
  • Deskripsi image container, seperti Dockerfile dan Containerfile.
  • Kode sumber workload.

Untuk menyederhanakan upaya pemfaktoran ulang, sebaiknya Anda berfokus untuk menerapkan jumlah perubahan minimum yang diperlukan agar workload Anda sesuai untuk GKE, dan perbaikan bug penting. Anda dapat merencanakan peningkatan dan perubahan lainnya sebagai bagian dari project mendatang.

Memfaktorkan ulang proses deployment dan operasional

Setelah memfaktorkan ulang workload, Anda akan memfaktorkan ulang proses deployment dan operasional untuk melakukan hal berikut:

  • Menyediakan dan mengonfigurasi resource di lingkungan Google Cloud Anda, bukan menyediakan resource di lingkungan sumber.
  • Build dan konfigurasikan workload, lalu deploy di Google Cloud, bukan men-deploynya di lingkungan sumber.

Sebelumnya, Anda telah mengumpulkan informasi tentang proses ini selama fase penilaian dalam proses ini.

Jenis pemfaktoran ulang yang perlu Anda pertimbangkan untuk proses ini bergantung pada cara Anda mendesain dan menerapkannya. Pemfaktoran ulang juga bergantung pada status akhir yang Anda inginkan untuk setiap prosesnya. Misalnya, pertimbangkan hal berikut:

  • Anda mungkin telah menerapkan proses ini di lingkungan sumber dan Anda bermaksud untuk merancang dan menerapkan proses serupa di Google Cloud. Misalnya, Anda dapat memfaktorkan ulang proses ini untuk menggunakan Cloud Build, Cloud Deploy, dan Infrastructure Manager.
  • Anda mungkin telah menerapkan proses ini di lingkungan pihak ketiga lain di luar lingkungan sumber Anda. Dalam hal ini, Anda perlu memfaktorkan ulang proses ini untuk menarget lingkungan Google Cloud, bukan lingkungan sumber Anda.
  • Gabungan dari pendekatan sebelumnya.

Pemfaktoran ulang proses deployment dan operasional dapat bersifat kompleks dan dapat membutuhkan upaya yang signifikan. Jika Anda mencoba melakukan tugas ini sebagai bagian dari migrasi workload, migrasi workload dapat menjadi lebih kompleks, dan dapat menimbulkan risiko bagi Anda. Setelah menilai proses deployment dan operasional, Anda mungkin telah memahami desain dan kompleksitasnya. Jika Anda memperkirakan bahwa Anda memerlukan upaya signifikan untuk memfaktorkan ulang proses deployment dan operasional, sebaiknya pertimbangkan untuk memfaktorkan ulang proses ini sebagai bagian dari project khusus yang terpisah.

Untuk mengetahui informasi selengkapnya tentang cara mendesain dan menerapkan proses deployment di Google Cloud, lihat:

Dokumen ini berfokus pada proses deployment yang menghasilkan artefak untuk di-deploy, dan men-deploynya di lingkungan runtime target. Strategi pemfaktoran ulang sangat bergantung pada kompleksitas proses ini. Daftar berikut menguraikan kemungkinan strategi pemfaktoran ulang umum:

  1. Menyediakan repositori artefak di Google Cloud. Misalnya, Anda dapat menggunakan Artifact Registry untuk menyimpan artefak dan mem-build dependensi.
  2. Faktorkan ulang proses build untuk menyimpan artefak di lingkungan sumber dan di Artifact Registry.
  3. Faktorkan ulang proses deployment Anda untuk men-deploy workload di lingkungan Google Cloud target. Misalnya, Anda dapat memulai dengan men-deploy sebagian kecil workload di Google Cloud, menggunakan artefak yang disimpan di Artifact Registry. Kemudian, Anda secara bertahap meningkatkan jumlah workload yang di-deploy di Google Cloud, hingga semua workload yang akan dimigrasikan berjalan di Google Cloud.
  4. Faktorkan ulang proses build Anda untuk menyimpan artefak hanya di Artifact Registry.
  5. Jika perlu, migrasikan artefak versi sebelumnya untuk di-deploy dari repositori di lingkungan sumber Anda ke Artifact Registry. Misalnya, Anda dapat menyalin image container ke Artifact Registry.
  6. Hentikan repositori di lingkungan sumber saat Anda tidak lagi memerlukannya.

Untuk memfasilitasi rollback pada akhirnya karena masalah yang tidak terduga selama migrasi, Anda dapat menyimpan image container di repositori artefak saat ini di Google Cloud saat migrasi ke Google Cloud sedang berlangsung. Terakhir, sebagai bagian dari penghentian lingkungan sumber, Anda dapat memfaktorkan ulang proses build image container untuk menyimpan artefak di Google Cloud saja.

Meskipun mungkin tidak penting untuk keberhasilan migrasi, Anda mungkin perlu memigrasikan artefak versi sebelumnya dari lingkungan sumber ke repositori artefak di Google Cloud. Misalnya, untuk mendukung rollback workload ke titik waktu arbitrer, Anda mungkin perlu memigrasikan artefak versi sebelumnya ke Artifact Registry. Untuk informasi selengkapnya, lihat Memigrasikan image dari registry pihak ketiga.

Jika Anda menggunakan Artifact Registry untuk menyimpan artefak, sebaiknya konfigurasi kontrol untuk membantu Anda mengamankan repositori artefak, seperti kontrol akses, pencegahan eksfiltrasi data, pemindaian kerentanan, dan Otorisasi Biner. Untuk mengetahui informasi selengkapnya, lihat Mengontrol akses dan melindungi artefak.

Migrasikan data

GKE mendukung beberapa layanan penyimpanan data, seperti penyimpanan blok, penyimpanan blok mentah, penyimpanan file, dan penyimpanan objek. Untuk mengetahui informasi selengkapnya, lihat Ringkasan penyimpanan untuk cluster GKE.

Untuk memigrasikan data ke lingkungan GKE, Anda melakukan hal berikut:

  1. Sediakan dan konfigurasikan semua infrastruktur penyimpanan yang diperlukan.
  2. Konfigurasikan penyedia StorageClass, di cluster GKE Anda. Tidak semua penyedia StorageClass kompatibel dengan semua lingkungan. Sebelum men-deploy penyedia StorageClass, sebaiknya evaluasi kompatibilitasnya dengan GKE, dan dependensinya.
  3. Konfigurasikan StorageClasses.
  4. Konfigurasikan PersistentVolumes dan PersistentVolumeClaims untuk menyimpan data yang akan dimigrasikan.
  5. Migrasikan data dari lingkungan sumber Anda ke PersistentVolume ini. Detail migrasi data ini bergantung pada karakteristik lingkungan sumber.

Untuk memigrasikan data dari lingkungan sumber ke lingkungan Google Cloud, sebaiknya rancang paket migrasi data dengan mengikuti panduan dalam artikel Bermigrasi ke Google Cloud: Mentransfer set data besar.

Memigrasikan data dari EKS ke GKE

AWS menyediakan beberapa opsi penyimpanan data untuk Amazon EKS. Dokumen ini berfokus pada skenario migrasi data berikut:

  • Memigrasikan data dari volume Amazon EBS ke resource PersistentVolume GKE.
  • Salin data dari volume Amazon EBS ke Amazon S3 atau ke Cloud Storage, lalu migrasikan data ke resource PersistentVolume GKE.
Memigrasikan data dari volume Amazon EBS ke GKE PersistentVolumes

Anda dapat memigrasikan data dari volume Amazon EBS ke resource PersistentVolume GKE menggunakan salah satu pendekatan berikut:

  • Salin data langsung dari volume Amazon EBS ke persistent disk Compute Engine:
    1. Sediakan instance Amazon EC2 dan lampirkan volume Amazon EBS yang berisi data yang akan dimigrasikan.
    2. Sediakan instance Compute Engine dengan persistent disk kosong yang memiliki kapasitas cukup untuk menyimpan data yang akan dimigrasikan.
    3. Jalankan alat sinkronisasi data, seperti rsync, untuk menyalin data dari volume Amazon EBS ke persistent disk Compute Engine.
    4. Lepaskan persistent disk dari instance Compute Engine.
    5. Penonaktifan instance Compute Engine.
    6. Konfigurasikan persistent disk sebagai resource PersistentVolume GKE.
  • Memigrasikan instance Amazon EC2 dan volume Amazon EBS ke Compute Engine:
    1. Sediakan instance Amazon EC2 dan lampirkan volume Amazon EBS yang berisi data yang akan dimigrasikan.
    2. Migrasikan instance Amazon EC2 dan volume Amazon EBS ke Compute Engine dengan Migrate for Virtual Machines.
    3. Lepaskan persistent disk dari instance Compute Engine.
    4. Penonaktifan instance Compute Engine.
    5. Konfigurasikan persistent disk sebagai resource PersistentVolume GKE.

Untuk mengetahui informasi selengkapnya tentang cara memigrasikan instance Amazon EC2 ke Compute Engine, lihat Melakukan migrasi dari AWS ke Google Cloud: Bermigrasi dari Amazon EC2 ke Compute Engine.

Untuk informasi selengkapnya tentang cara menggunakan persistent disk Compute Engine sebagai resource PersistentVolume GKE, lihat Menggunakan persistent disk yang sudah ada sebagai PersistentVolumes.

Menyalin data dari volume Amazon EBS ke media sementara, dan bermigrasi ke GKE PersistentVolumes

Daripada bermigrasi dari volume Amazon EBS ke resource PersistentVolume GKE secara langsung, Anda dapat menggunakan media sementara seperti object store:

  1. Mengupload data dari volume Amazon EBS ke media sementara seperti Amazon S3 bucket or a Cloud Storage bucket.
  2. Download data dari media sementara ke resource PersistentVolume GKE Anda.

Dalam skenario tertentu, menggunakan beberapa media dapat menyederhanakan transfer data berdasarkan konfigurasi keamanan dan jaringan Anda. Misalnya, pada awalnya Anda dapat mengupload data ke bucket S3, lalu menyalinnya dari bucket S3 ke bucket Cloud Storage, dan akhirnya mendownload data ke volume persisten. Apa pun pendekatan yang Anda pilih, untuk memastikan transisi yang lancar sambil memperhatikan pertimbangan penting, sebaiknya tinjau Bermigrasi dari AWS ke Google Cloud: Migrasi dari Amazon S3 ke Cloud Storage.

Memilih opsi migrasi

Opsi migrasi terbaik untuk Anda bergantung pada kebutuhan dan persyaratan khusus Anda, seperti pertimbangan berikut:

  • Jumlah data yang perlu dimigrasikan.
    • Jika Anda memiliki sedikit data untuk dimigrasikan, misalnya beberapa file data, pertimbangkan alat seperti rsync untuk menyalin data langsung ke persistent disk Compute Engine. Opsi ini relatif cepat, tetapi mungkin tidak cocok untuk data dalam jumlah besar.
    • Jika Anda memiliki data dalam jumlah besar yang akan dimigrasikan, pertimbangkan untuk menggunakan Migrate to Virtual Machines untuk memigrasikan data ke Compute Engine. Opsi ini lebih kompleks daripada langsung menyalin data, tetapi lebih andal dan skalabel.
  • Jenis data yang perlu dimigrasikan.
  • Konektivitas jaringan Anda antara lingkungan sumber dan target.
    • Jika Anda tidak dapat membangun konektivitas jaringan langsung antara instance AWS EC2 dan Compute Engine, sebaiknya gunakan Amazon S3 atau Cloud Storage untuk menyimpan data sementara saat memigrasikannya ke Compute Engine singkat ini. Opsi ini mungkin lebih murah karena Anda tidak perlu menjaga instance EC2 dan Compute Engine tetap berjalan secara bersamaan.
  • Linimasa migrasi Anda.
    • Jika Anda memiliki bandwidth jaringan yang terbatas atau data dalam jumlah besar, dan linimasa tidak ketat, Anda juga dapat mempertimbangkan untuk menggunakan Transfer Appliance untuk memindahkan data dari AWS ke Google Cloud.

Apa pun opsi yang Anda pilih, penting bagi Anda untuk menguji migrasi sebelum mengaktifkannya. Pengujian akan membantu Anda mengidentifikasi potensi masalah dan membantu memastikan bahwa migrasi berhasil.

Men-deploy workload Anda

Jika proses deployment sudah siap, Anda dapat men-deploy workload ke GKE. Untuk informasi selengkapnya, lihat Ringkasan men-deploy workload.

Untuk menyiapkan workload yang akan di-deploy untuk GKE, sebaiknya Anda menganalisis deskriptor Kubernetes karena beberapa resource Google Cloud yang disediakan GKE secara otomatis untuk Anda dapat dikonfigurasi menggunakan Kubernetes label dan annotations, bukan harus menyediakan resource ini secara manual. Misalnya, Anda dapat menyediakan load balancer internal, bukan eksternal dengan menambahkan anotasi ke Layanan LoadBalancer.

Memvalidasi workload Anda

Setelah men-deploy workload di lingkungan GKE, tetapi sebelum Anda mengekspos beban kerja ini kepada pengguna, sebaiknya lakukan validasi dan pengujian yang ekstensif. Pengujian ini dapat membantu Anda memverifikasi bahwa workload Anda berperilaku seperti yang diharapkan. Sebagai contoh, Anda dapat:

  • Lakukan pengujian integrasi, pengujian beban, pengujian kepatuhan, pengujian keandalan, dan prosedur verifikasi lainnya yang membantu Anda memastikan bahwa workload Anda beroperasi dalam parameter yang diharapkan, dan sesuai dengan spesifikasinya.
  • Periksa log, metrik, dan laporan error di Google Cloud Observability untuk mengidentifikasi potensi masalah, dan menemukan tren untuk mengantisipasi masalah sebelum terjadi.

Untuk mengetahui informasi selengkapnya tentang validasi workload, lihat Menguji keandalan.

Mengekspos workload Anda

Setelah menyelesaikan pengujian validasi beban kerja yang berjalan di lingkungan GKE Anda, ekspos workload agar dapat dijangkau.

Untuk mengekspos workload yang berjalan di lingkungan GKE, Anda dapat menggunakan Layanan Kubernetes dan mesh layanan.

Untuk mengetahui informasi selengkapnya tentang mengekspos workload yang berjalan di GKE, lihat:

Mengalihkan traffic ke lingkungan Google Cloud

Setelah memastikan bahwa workload berjalan di lingkungan GKE, Anda, dan setelah mengeksposnya kepada klien, Anda akan mengalihkan traffic dari lingkungan sumber ke lingkungan GKE. Untuk membantu Anda menghindari migrasi berskala besar dan semua risiko terkait, sebaiknya alihkan traffic secara bertahap dari lingkungan sumber ke GKE Anda.

Bergantung pada cara Anda mendesain lingkungan GKE, Anda memiliki beberapa opsi untuk menerapkan mekanisme load balancing yang secara bertahap mengalihkan traffic dari lingkungan sumber ke lingkungan target Anda. Misalnya, Anda dapat menerapkan kebijakan resolusi DNS yang menyelesaikan data DNS sesuai dengan kebijakan tertentu untuk menyelesaikan persentase permintaan tertentu ke alamat IP milik lingkungan GKE Anda. Atau, Anda dapat menerapkan mekanisme load balancing menggunakan alamat IP virtual dan load balancing jaringan.

Setelah mulai mengalihkan traffic ke lingkungan GKE secara bertahap, sebaiknya pantau perilaku workload Anda seiring dengan bertambahnya beban kerja.

Terakhir, Anda akan melakukan cutover, yang terjadi saat Anda mengalihkan semua traffic dari lingkungan sumber ke lingkungan GKE.

Untuk mengetahui informasi selengkapnya tentang load balancing, lihat Load balancing di frontend.

Penghapusan lingkungan sumber

Setelah beban kerja di lingkungan GKE Anda melayani permintaan dengan benar, lingkungan sumber Anda akan dinonaktifkan.

Sebelum mulai menghentikan resource di lingkungan sumber, sebaiknya lakukan hal berikut:

  • Cadangkan data apa pun untuk membantu Anda memulihkan resource di lingkungan sumber.
  • Beri tahu pengguna Anda sebelum menonaktifkan lingkungan.

Untuk menonaktifkan lingkungan sumber, lakukan hal berikut:

  1. Hentikan workload yang berjalan di cluster di lingkungan sumber Anda.
  2. Hapus cluster di lingkungan sumber.
  3. Hapus resource yang terkait dengan cluster ini, seperti grup keamanan, load balancer, dan jaringan virtual.

Agar tidak meninggalkan resource usang, urutan penonaktifan resource di lingkungan sumber harus dilakukan. Misalnya, Penyedia tertentu mengharuskan Anda menonaktifkan Layanan Kubernetes yang menyebabkan pembuatan load balancer sebelum dapat menonaktifkan jaringan virtual yang berisi load balancer tersebut.

Mengoptimalkan lingkungan Google Cloud Anda

Pengoptimalan adalah fase terakhir dari migrasi Anda. Pada fase ini, Anda melakukan iterasi tugas pengoptimalan sampai lingkungan target memenuhi persyaratan pengoptimalan. Langkah-langkah setiap iterasi adalah sebagai berikut:

  1. Menilai lingkungan, tim, dan loop pengoptimalan Anda saat ini.
  2. Tetapkan persyaratan dan sasaran pengoptimalan Anda.
  3. Optimalkan lingkungan dan tim Anda.
  4. Sesuaikan loop pengoptimalan.

Anda mengulangi urutan ini sampai Anda mencapai sasaran pengoptimalan.

Untuk mengetahui informasi selengkapnya tentang cara mengoptimalkan lingkungan Google Cloud Anda, lihat Bermigrasi ke Google Cloud: Mengoptimalkan lingkungan Anda dan Proses pengoptimalan performa.

Bagian berikut mengintegrasikan pertimbangan dalam Bermigrasi ke Google Cloud: Mengoptimalkan lingkungan Anda.

Menetapkan persyaratan pengoptimalan

Persyaratan pengoptimalan membantu Anda mempersempit cakupan iterasi pengoptimalan saat ini. Untuk mengetahui informasi selengkapnya tentang persyaratan dan sasaran pengoptimalan, lihat Menetapkan persyaratan dan sasaran pengoptimalan.

Untuk menetapkan persyaratan pengoptimalan untuk lingkungan GKE, mulailah dengan mempertimbangkan aspek berikut:

  • Keamanan, privasi, dan kepatuhan: membantu Anda meningkatkan postur keamanan lingkungan GKE.
  • Keandalan: membantu Anda meningkatkan ketersediaan, skalabilitas, dan ketahanan lingkungan GKE.
  • Pengoptimalan biaya: membantu Anda mengoptimalkan konsumsi resource dan pengeluaran yang dihasilkan dari lingkungan GKE Anda.
  • Efisiensi operasional: membantu Anda mengelola dan mengoperasikan lingkungan GKE secara efisien.
  • Pengoptimalan performa: membantu Anda mengoptimalkan performa workload yang di-deploy di lingkungan GKE.

Keamanan, privasi, dan kepatuhan:

  • Pantau postur keamanan cluster GKE Anda. Anda dapat menggunakan dasbor postur keamanan untuk mendapatkan rekomendasi opini yang dapat ditindaklanjuti untuk membantu Anda meningkatkan postur keamanan lingkungan GKE.
  • Melakukan hardening pada lingkungan GKE Anda. Pahami model keamanan GKE, dan cara memperkuat memperkuat cluster GKE Anda.
  • Lindungi supply chain software Anda. Untuk workload yang sangat penting bagi keamanan, Google Cloud menyediakan serangkaian produk modular yang menerapkan praktik terbaik keamanan supply chain software di seluruh siklus proses software.

Keandalan

  • Meningkatkan keandalan cluster Anda. Untuk membantu Anda mendesain GKE yang lebih tahan terhadap pemadaman layanan zona yang tidak mungkin terjadi, pilih cluster regional daripada cluster zona atau multi-zona.
  • Pencadangan dan pemulihan workload. Konfigurasikan alur kerja pencadangan dan pemulihan workload dengan Pencadangan untuk GKE.

Pengoptimalan biaya

Untuk mengetahui informasi selengkapnya tentang cara mengoptimalkan biaya lingkungan GKE, lihat:

Efisiensi operasional

Untuk membantu Anda menghindari masalah yang memengaruhi lingkungan produksi, sebaiknya:

  • Rancang cluster GKE Anda agar mudah digunakan. Dengan mempertimbangkan cluster sebagai fungible dan dengan mengotomatiskan penyediaan dan konfigurasinya, Anda dapat menyederhanakan dan menggeneralisasi proses operasional untuk mempertahankannya dan juga menyederhanakan migrasi dan upgrade cluster GKE mendatang. Misalnya, jika perlu mengupgrade cluster GKE yang dapat dialihkan ke versi GKE baru, Anda dapat secara otomatis menyediakan dan mengonfigurasi cluster baru yang telah diupgrade, men-deploy workload di cluster baru secara otomatis, dan menonaktifkan cluster GKE yang sudah usang.
  • Pantau metrik yang diinginkan. Pastikan semua metrik yang diinginkan tentang beban kerja dan cluster Anda dikumpulkan dengan benar. Selain itu, pastikan semua pemberitahuan yang relevan yang menggunakan metrik ini sebagai input sudah diterapkan dan berfungsi.

Untuk informasi selengkapnya tentang cara mengonfigurasi pemantauan, logging, dan pembuatan profil di lingkungan GKE, lihat:

Pengoptimalan performa

Untuk mengetahui informasi selengkapnya, lihat Tentang skalabilitas GKE.

Langkah selanjutnya

Kontributor

Penulis: