Merencanakan praktik terbaik

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

CLI klien discovery Pusat Migrasi atau CLI mcdc adalah alat yang Anda gunakan untuk menentukan kecocokan workload VM untuk migrasi ke container.

Workload yang direkomendasikan

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

Cocok

Linux

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

• Server Aplikasi/Web
• 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 yang selalu aktif dan beban rendah

Secara umum, sebagian besar beban kerja Linux kompatibel dengan migrasi, kecuali untuk workload tersebut yang secara eksplisit tercantum di bawah di bagian Tidak sesuai.

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 ini.

Tidak cocok

Linux

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

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

Windows

Untuk Windows, beban kerja tanpa IIS 7 atau versi yang lebih tinggi 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 jaringan dan DNS

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

Merencanakan nama layanan Kubernetes Anda

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

Spesifikasi deployment yang dihasilkan oleh proses migrasi berisi objek Service headless yang disarankan untuk jenis "ClusterIP". "ClusterIP" berarti tidak ada load balancing, dan satu IP internal cluster hanya dapat dijangkau dari dalam cluster tersebut. 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 container

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

Mengidentifikasi dan mengonfigurasi nama dan IP yang dimigrasikan

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

Menempatkan layanan dependen dalam namespace yang sama

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

Mengontrol permukaan 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. Langkah ini memberikan kesempatan untuk mengontrol dan membatasi platform akses lebih lanjut ke beban kerja tanpa kerumitan tambahan dalam mengelola VLAN, filter, atau aturan perutean.

Misalnya, aplikasi tiga tingkat standar memiliki tingkat frontend, aplikasi, dan database. Saat dimigrasikan ke Google Cloud, layanan frontend akan dikonfigurasi dengan LoadBalancer di jaringan VPC. Tingkatan 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 Persisten

Saat Anda membuat paket migrasi, klien NFS yang dipasang pada VM sumber akan otomatis ditemukan dan ditambahkan ke paket yang dihasilkan.

Meskipun dudukan ditambahkan ke rencana, 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 beban kerja container 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. Lihat Mengakses instance Filestore dengan driver CSI Filestore untuk informasi selengkapnya.

Catatan: Menggunakan NFS melalui link VPN mungkin mengalami penurunan 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 berbasis cloud.

Memigrasikan data dari berbagi NFS sumber

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

Untuk opsi penyalinan data, lihat referensi berikut:

1. Storage Transfer Service atau Transfer Appliance.

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

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

4. aplikasi utilitas OSS seperti Rsync.

Memastikan database dapat diakses

Jika aplikasi Anda mengandalkan database, baik yang berjalan secara lokal di VM maupun di mesin eksternal, Anda harus memastikan bahwa database tersebut masih dapat diakses dari pod yang baru 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 mengetahui 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 akan menawarkan ConfigMaps dan Secret.

Mengonfigurasi layanan yang diperlukan agar dimulai di runlevel 3

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

Nonaktifkan layanan yang tidak diperlukan

Migrate to Containers secara otomatis menonaktifkan layanan khusus hardware atau lingkungan, dan kumpulan layanan tambahan standar yang berjalan di VM. Layanan ini tidak diperlukan setelah Anda memigrasikan beban kerja ke container.

Misalnya, Migrate to Containers secara 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 khusus yang akan dinonaktifkan dalam penampung yang dimigrasikan dengan menyesuaikan rencana migrasi untuk menentukan daftar yang tidak diizinkan. Dengan daftar yang tidak diizinkan, Anda menentukan satu atau beberapa layanan yang akan dinonaktifkan dalam penampung yang dimigrasikan.

Mengelola dan mengupdate VM yang dimigrasikan

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

Untuk informasi selengkapnya, lihat Pembaruan gambar pascamigrasi.

Langkah selanjutnya

• Pelajari penilaian offline lebih lanjut.