Merencanakan praktik terbaik

Topik ini menawarkan saran untuk migrasi aplikasi ke Google Kubernetes Engine (GKE) atau GKE Enterprise, berdasarkan migrasi aplikasi nyata yang telah dilakukan dengan Migrate to Containers.

Migration Center discovery client CLI atau CLI mcdc adalah alat yang Anda gunakan untuk menentukan kesesuaian workload VM untuk dimigrasikan ke container.

Beban kerja yang direkomendasikan

Migrate to Containers direkomendasikan untuk jenis workload Linux dan Windows tertentu, yang dijelaskan di bawah.

Cocok

Linux

Aplikasi Linux yang cocok untuk migrasi menggunakan Migrate to Containers mencakup arsitektur aplikasi berikut:

• Server Web/Aplikasi
• Middleware logika bisnis (misalnya, Tomcat)
• Stack multi-VM, multi-tingkat (misalnya, LAMP)
• Database berukuran Kecil/Sedang (misalnya, MySQL dan PostgreSQL)

Selain itu, aplikasi yang paling cocok untuk migrasi dengan Migrate to Containers memiliki karakteristik operasional berikut:

• Siklus tugas rendah & workload burst
• Lingkungan lab pengembangan, pengujian, dan pelatihan
• Layanan beban rendah yang selalu aktif

Secara umum, sebagian besar beban kerja Linux kompatibel dengan migrasi, kecuali beban kerja yang secara eksplisit tercantum di bawah ini di bagian Tidak cocok.

Windows

Aplikasi Windows yang cocok untuk migrasi menggunakan Migrate to Containers mencakup workload yang memenuhi semua karakteristik berikut:

• IIS 7 atau yang lebih baru, ASP.NET dengan .NET Framework 3.5 atau yang lebih baru
• Tingkat web dan logika
• WS2008 R2 atau yang lebih tinggi

Dukungan sistem operasi

Migrate to Containers kompatibel dengan sistem operasi VM berikut.

Tidak cocok

Linux

Untuk Linux, aplikasi dan server yang tidak cocok untuk migrasi dengan Migrate to Containers mencakup:

• Database dalam memori besar dan berperforma tinggi
• VM dengan driver kernel khusus (misalnya, NFS mode kernel)
• Dependensi pada hardware tertentu
• Software dengan lisensi yang terikat dengan pendaftaran ID hardware tertentu

Windows

Untuk Windows, workload tanpa IIS 7 atau yang lebih baru tidak cocok untuk migrasi. Jenis aplikasi lain yang tidak cocok untuk migrasi meliputi:

• Aplikasi dengan dependensi pada GPU atau TPU
• Aplikasi jaringan tingkat rendah
• Aplikasi desktop, RDP, dan VDI
• Aplikasi dengan BYOL

Aturan akses DNS dan jaringan

Sebelum bermigrasi ke GKE, pastikan Anda memahami resource jaringan, dan layanan yang digunakan oleh workload yang dimigrasikan, serta pastikan bahwa resource dan layanan tersebut dapat diakses dan dialamatkan dari Virtual Private Cloud Anda.

Merencanakan nama layanan Kubernetes

Jika workload Anda bergantung pada DNS untuk mengakses layanan, Anda perlu merencanakan skema namespace, kebijakan jaringan, dan nama layanan Kubernetes.

Spesifikasi deployment yang dihasilkan oleh proses migrasi berisi objek Service headless yang disarankan dari jenis "ClusterIP". "ClusterIP" berarti tidak ada load balancing, dan satu IP internal cluster yang hanya dapat dijangkau dari dalam cluster. Pengontrol endpoint Kubernetes mengubah konfigurasi DNS untuk menampilkan data (alamat) yang mengarah ke Pod, yang diberi label dengan "app": "app-name" di deployment_spec.yaml.

Catatan: Nama layanan Kubernetes lebih terbatas daripada yang diizinkan DNS.

Membuat dan menerapkan layanan untuk koneksi ke pod dan penampung

Setelah memigrasikan beban kerja, nama host tidak lagi berlaku. Untuk mengizinkan koneksi ke beban kerja Anda, buat dan terapkan layanan.

Mengidentifikasi dan mengonfigurasi nama dan IP yang dimigrasikan

GKE mengelola file /etc/hosts. Di Migrate to Containers, penyesuaian file host dari VM sumber ke GKE belum otomatis. Nama dan IP dalam file host di VM yang dimigrasikan harus diidentifikasi dan dikonfigurasi sebagai hostAliases.

Menempatkan layanan dependen di namespace yang sama

Layanan yang saling bergantung harus ditempatkan bersama di namespace Kubernetes yang sama dan menggunakan nama DNS singkat (misalnya app dan db) untuk berkomunikasi. Konfigurasi ini juga membantu mereplikasi beberapa lingkungan aplikasi, seperti produksi, staging, dan pengujian.

Mengontrol platform akses dengan jaringan GKE

GKE memiliki kontrol jaringan yang canggih. Pod dapat diakses dari berbagai jaringan, seperti internet publik, jaringan VPC, atau jaringan cluster internal. Hal ini memberikan peluang untuk mengontrol dan membatasi lebih lanjut platform akses ke beban kerja tanpa kompleksitas tambahan dalam mengelola VLAN, filter, atau aturan rute.

Misalnya, aplikasi tiga tingkat standar memiliki tingkat frontend, aplikasi, dan database. Saat dimigrasikan ke Google Cloud, layanan frontend dikonfigurasi dengan LoadBalancer di jaringan VPC. Tingkat lainnya tidak dapat diakses secara langsung dari luar cluster GKE. Kebijakan akses jaringan memastikan layanan aplikasi hanya dapat diakses oleh pod frontend dari dalam jaringan cluster internal. Kebijakan lain memastikan pod database hanya dapat diakses oleh pod aplikasi.

NFS

Menentukan pemasangan NFS sebagai Volume Permanen

Saat Anda membuat rencana migrasi, pemasangan klien NFS di VM sumber akan otomatis ditemukan dan ditambahkan ke rencana yang dihasilkan.

Meskipun ditambahkan ke paket, pemasangan akan dinonaktifkan secara default. Artinya, definisi PersistentVolume dan PersistentVolumeClaim tidak disertakan dalam file deployment_spec.yaml saat Anda membuat artefak migrasi. Jika ingin Migrate to Containers membuat definisi PersistentVolume dan PersistentVolumeClaim, Anda harus mengedit rencana migrasi terlebih dahulu untuk mengaktifkan pemasangan klien NFS.

Lihat Menyesuaikan pemasangan NFS untuk mengetahui informasi selengkapnya.

Catatan: Migrate to Containers mengharuskan pemasangan NFS dapat diakses dari cluster deployment yang menghosting workload penampung yang dimigrasikan. Namun, Migrate to Containers tidak memvalidasi konektivitas tersebut. Penampung yang dimigrasikan dengan masalah konektivitas tidak dapat dimulai dan Anda mungkin harus mengedit file deployment_spec.yaml untuk memperbaiki masalah tersebut. Lihat Mengakses instance Filestore dengan driver CSI Filestore untuk mengetahui informasi selengkapnya.

Catatan: Menggunakan NFS melalui link VPN mungkin akan mengurangi performa karena peningkatan latensi dan penurunan bandwidth.

Server NFS mode kernel

VM dengan server NFS yang berjalan dalam mode kernel tidak dapat dimigrasikan ke GKE dengan Migrate to Containers. VM ini harus dimigrasikan ke VM di Compute Engine. Atau, Anda dapat menggunakan Filestore untuk solusi NFS native cloud.

Memigrasikan data dari berbagi NFS sumber

Jika VM sumber Anda menggunakan pemasangan berbagi NFS, data ini tidak dapat dimigrasikan secara otomatis. Pasang share di penampung workload yang dimigrasikan menggunakan volume persisten NFS, atau—jika share NFS sumber bersifat jarak jauh—salin data ke share file lain yang memberikan akses latensi lebih rendah ke cluster.

Untuk opsi penyalinan data, lihat hal berikut:

1. Storage Transfer Service atau Transfer Appliance.

2. Menyalin data dengan gcloud storage rsync (dari berbagi file sumber ke bucket, lalu dari bucket ke berbagi file di cloud).

3. Solusi pihak ketiga, seperti NetApp SnapMirror ke NetApp Cloud Volumes.

4. Utilitas OSS seperti Rsync.

Memastikan database dapat diakses

Jika aplikasi Anda mengandalkan database, baik yang berjalan secara lokal di VM, atau di mesin eksternal, Anda harus memastikan bahwa database masih dapat diakses dari pod baru yang dimigrasikan. Anda perlu memvalidasi bahwa kebijakan firewall jaringan Anda mengizinkan akses dari cluster ke database.

Untuk memigrasikan database ke Google Cloud, sebaiknya gunakan Database Migration Service

Atau, Anda dapat menjalankan database di dalam cluster. Untuk informasi selengkapnya, lihat Merencanakan deployment database di GKE.

Memastikan metadata yang dimasukkan tersedia

Jika aplikasi Anda mengandalkan metadata yang dimasukkan (misalnya, variabel lingkungan), Anda harus memastikan bahwa metadata ini tersedia di GKE. Jika metode injeksi metadata yang sama tidak tersedia, GKE menawarkan ConfigMaps dan Secrets.

Mengonfigurasi layanan yang diperlukan untuk dimulai pada runlevel 3

Workload Migrate to Containers hanya mencapai runlevel 3. VM yang dimigrasikan ke GKE dengan Migrate to Containers akan di-booting di penampung pada runlevel 3 Linux. Layanan tertentu (misalnya X11 atau XDM, untuk akses GUI jarak jauh menggunakan VNC) dikonfigurasi secara default untuk hanya dimulai pada runlevel 5. Setiap layanan yang diperlukan harus dikonfigurasi untuk dimulai pada runlevel 3.

Menonaktifkan layanan yang tidak diperlukan

Migrate to Containers akan otomatis menonaktifkan layanan khusus hardware atau lingkungan, dan kumpulan layanan tambahan yang telah ditetapkan sebelumnya yang berjalan di VM. Layanan ini tidak diperlukan setelah Anda memigrasikan beban kerja ke penampung.

Misalnya, Migrate to Containers akan otomatis menonaktifkan iptables, ip6tables, dan firewalld. Untuk mengetahui daftar lengkap layanan yang dinonaktifkan oleh Migrate to Containers, download file blocklist.yaml.

Menyesuaikan layanan yang dinonaktifkan

Secara default, Migrate to Containers menonaktifkan layanan yang tidak diperlukan yang tercantum di atas. Anda juga dapat menentukan daftar layanan kustom Anda sendiri untuk dinonaktifkan dalam penampung yang dimigrasikan dengan menyesuaikan rencana migrasi untuk menentukan daftar yang tidak diizinkan. Dengan daftar blokir, Anda menentukan satu atau beberapa layanan untuk dinonaktifkan dalam penampung yang dimigrasikan.

Memelihara dan mengupdate VM yang dimigrasikan

Dengan menggunakan artefak yang Anda buat selama migrasi, Anda dapat menerapkan update software OS mode aplikasi dan pengguna, patch keamanan, mengedit konfigurasi tersemat, menambahkan atau mengganti file, dan untuk mengupdate software runtime Migrate to Containers.

Untuk mengetahui informasi selengkapnya, lihat Update gambar pascamigrasi.

Langkah selanjutnya

• Pelajari penilaian offline lebih lanjut.