Memigrasikan container ke Google Cloud: Bermigrasi dari OpenShift ke GKE Enterprise

Dokumen ini membantu Anda merencanakan, mendesain, dan mengimplementasikan migrasi dari OpenShift ke GKE Enterprise. Jika Anda salah melakukannya, memindahkan beban kerja dari satu lingkungan ke lingkungan lain dapat menjadi tugas yang menantang. Oleh karena itu, rencanakan dan menyetujui migrasi Anda dengan hati-hati.

Dokumen ini adalah bagian dari rangkaian multi-bagian tentang migrasi ke Google Cloud. Jika Anda tertarik dengan ringkasan dari rangkaian tersebut, lihat Migrasi ke Google Cloud: Memilih jalur migrasi.

Dokumen ini adalah bagian dari rangkaian yang membahas memigrasi containers ke Google Cloud:

Dokumen ini berguna jika Anda berencana untuk bermigrasi dari OpenShift yang berjalan di lingkungan hosting lokal atau pribadi, atau di penyedia cloud lainnya, ke GKE Enterprise. Dokumen ini juga berguna jika Anda sedang mengevaluasi peluang untuk bermigrasi dan ingin mempelajari kemungkinan gambarannya. Lingkungan target bisa berupa salah satu dari berikut ini:

  • Lingkungan yang dihosting sepenuhnya di Google Cloud.
  • Lingkungan hybrid tempat Anda mengelola sebagian beban kerja di lingkungan lokal atau di lingkungan hosting pribadi dan memigrasikan sisanya ke Google Cloud.

Untuk menentukan lingkungan yang sesuai dengan kebutuhan, Anda pertimbangkan persyaratannya. Misalnya, Anda dapat berfokus pada peningkatan nilai bisnis Anda daripada mengkhawatirkan infrastruktur, dengan bermigrasi ke lingkungan cloud publik dan mengalihkan sebagian tanggung jawab kepada Google. Anda akan mendapatkan manfaat dari model konsumsi yang elastis untuk mengoptimalkan pengeluaran dan penggunaan resource. Jika Anda memiliki persyaratan apa pun, sehingga Anda harus menyimpan beberapa beban kerja di luar Google Cloud, Anda dapat mempertimbangkan lingkungan hybrid. Misalnya, jika Anda diharuskan untuk mempertahankan bagian dari beban kerja Anda di lingkungan Anda saat ini untuk mematuhi kebijakan dan peraturan lokasi data. Atau, Anda dapat menerapkan strategi migrasi tingkatkan dan pindahkan, di mana Anda harus terlebih dahulu memodernisasi workload, lalu melakukan migrasi ke Google Cloud.

Terlepas dari jenis lingkungan target Anda, tujuan migrasi ini adalah untuk mengelola beban kerja yang berjalan di lingkungan tersebut menggunakan GKE Enterprise. Dengan menerapkan GKE Enterprise, Anda memiliki akses ke berbagai layanan, termasuk yang berikut:

  • Pengelolaan multi-cluster untuk membantu Anda dan organisasi Anda mengelola cluster, infrastruktur, dan beban kerja di seluruh lingkungan cloud dan lokal dari satu tempat.
  • Sinkronisasi Konfigurasi dan Pengontrol Kebijakan untuk membuat konfigurasi dan kebijakan umum di seluruh infrastruktur Anda, serta untuk menerapkannya di infrastruktur lokal dan cloud.
  • Anthos Service Mesh untuk mengadopsi mesh layanan terkelola sepenuhnya yang menyederhanakan layanan operasi, pengelolaan traffic, telemetri, dan mengamankan komunikasi antar-layanan.
  • Otorisasi Biner untuk membantu memastikan bahwa container yang Anda deploy di lingkungan dapat dipercaya.
  • Cloud Run for Anthos untuk mendukung workload serverless Anda di lingkungan GKE Enterprise.

Sebaiknya evaluasi layanan ini lebih awal dalam proses migrasi selagi Anda masih mendesain migrasi. Lebih mudah untuk mengadopsi layanan ini sekarang, daripada mengubah proses dan infrastruktur Anda nanti. Anda dapat mulai menggunakan layanan ini segera, atau jika Anda siap untuk memodernisasi workload Anda.

Dalam migrasi ini, Anda perlu mengikuti framework migrasi yang ditentukan dalam Migrasi ke Google Cloud: Memulai. Framework ini memiliki empat fase:

  1. Menilai dan menemukan workload Anda.
  2. Merencanakan dan membangun fondasi.
  3. Men-deploy workload Anda
  4. Mengoptimalkan lingkungan Anda.

Diagram berikut menggambarkan jalur perjalanan migrasi Anda.

Jalur migrasi dengan empat fase.

Dokumen ini bergantung pada konsep yang dibahas dalam artikel Memigrasikan container ke Google Cloud: Memigrasikan Kubernetes ke GKE, sehingga terdapat link ke dokumen tersebut jika sesuai.

Menilai dan menemukan workload Anda

Pada fase penilaian, Anda menentukan persyaratan dan dependensi untuk bermigrasi ke workload Anda dari OpenShift ke GKE Enterprise:

  1. Buat inventaris yang komprehensif untuk proses dan aplikasi Anda.
  2. Buat katalog proses dan aplikasi Anda sesuai dengan properti dan dependensinya.
  3. Latih dan ajari tim Anda di Google Cloud.
  4. Membangun eksperimen dan bukti konsep di Google Cloud.
  5. Menghitung total biaya kepemilikan (TCO) lingkungan target.
  6. Pilih beban kerja yang ingin Anda migrasikan terlebih dahulu.

Bagian berikut mengandalkan Migrasi ke Google Cloud: Menilai dan menemukan workload Anda, tetapi bagian ini memberikan informasi khusus untuk menilai workload yang ingin Anda migrasikan dari OpenShift ke GKE Enterprise.

Membangun inventaris Anda

Untuk mem-build inventaris komponen lingkungan Anda, pertimbangkan hal berikut:

  • Model pengelolaan platform dan pengiriman layanan
  • Project OpenShift
  • Proses build dan deployment
  • Beban kerja, persyaratan, dan dependensi
  • Konfigurasi cluster OpenShift

Model pengelolaan platform dan pengiriman layanan

Untuk memigrasikan workload dari OpenShift ke GKE Enterprise, Anda perlu menilai model pengelolaan platform dan pengiriman layanan saat ini dari lingkungan OpenShift Anda. Model ini mungkin mencerminkan struktur dan kebutuhan organisasi Anda saat ini. Jika Anda menyadari bahwa model saat ini tidak memenuhi kebutuhan organisasi, Anda dapat menggunakan migrasi ini sebagai peluang untuk meningkatkan model tersebut.

Pertama, Anda mengumpulkan informasi tentang tim yang bertanggung jawab atas aspek berikut:

  • Pengembangan dan deployment aplikasi, termasuk semua pengguna OpenShift, biasanya tim pengembangan, atau tim rilis beban kerja.
  • Pengelolaan platform OpenShift, termasuk membuat project OpenShift, menetapkan peran kepada pengguna, mengonfigurasi konteks keamanan, dan mengonfigurasi pipeline CI/CD singkat ini.
  • Penginstalan OpenShift dan pengelolaan cluster, termasuk penginstalan OpenShift, upgrade, penskalaan cluster, dan pengelolaan kapasitas.
  • Pengelolaan infrastruktur Tim ini mengelola server fisik, penyimpanan, jaringan, platform virtualisasi, dan sistem operasi.

Model pengiriman layanan dan pengelolaan platform dapat terdiri dari tim berikut:

  • Tim pengembangan. Tim ini mengembangkan beban kerja dan men-deploy-nya di OpenShift. Ketika berhadapan dengan lingkungan produksi yang kompleks, tim yang men-deploy beban kerja mungkin berbeda dari tim pengembangan. Untuk memudahkan dalam dokumen ini, kami menganggap tim ini sebagai bagian dari tim pengembangan. Dalam lingkungan layanan mandiri, tim pengembangan juga memiliki tanggung jawab untuk membuat project OpenShift.
  • Tim platform. Tim ini bertanggung jawab atas pengelolaan platform OpenShift, yang biasanya disebut sebagai administrator cluster OpenShift. Tim ini mengonfigurasi template project OpenShift untuk berbagai tim pengembangan dan, di lingkungan yang lebih terkelola, membuat project OpenShift. Tim ini juga menetapkan peran dan izin, mengonfigurasi konteks keamanan dan kontrol akses berbasis peran (RBAC), menentukan kuota untuk resource dan objek komputasi, serta menentukan build dan strategi deployment. Mereka terkadang disebut sebagai tim DevOps atau sebagai tim middleware, jika mereka mengelola konfigurasi server aplikasi dan middleware untuk developer. Tim platform dan tim infrastruktur mungkin juga terlibat dalam aktivitas pengelolaan cluster OpenShift tingkat rendah, seperti penginstalan dan upgrade software, penskalaan cluster, dan pengelolaan kapasitas.
  • Tim infrastruktur. Tim ini mengelola infrastruktur dasar yang mendukung lingkungan OpenShift. Misalnya, mereka bertanggung jawab atas server, penyimpanan, jaringan, platform virtualisasi, dan sistem operasi dasar. Tim ini terkadang disebut sebagai tim pusat data atau tim operasi. Jika OpenShift di-deploy di lingkungan cloud publik, tim ini bertanggung jawab atas layanan Infrastructure as a Service (IaaS) yang ditawarkan oleh penyedia cloud publik.

Penting juga untuk menilai apakah Anda memiliki cluster OpenShift khusus untuk lingkungan yang berbeda. Misalnya, Anda mungkin memiliki lingkungan yang berbeda untuk pengembangan, jaminan kualitas, dan produksi, atau untuk memisahkan berbagai zona jaringan dan keamanan, seperti zona internal dan zona demiliterisasi ini.

Project OpenShift

Project OpenShift adalah namespace Kubernetes dengan anotasi tambahan yang memungkinkan developer mengelola resource secara terpisah dari tim lain untuk memisahkan sumber daya secara logis. Untuk mem-build inventaris project OpenShift, pertimbangkan hal berikut ini untuk setiap project:

  • Peran cluster dan peran lokal. OpenShift mendukung kedua peran yang bersifat lokal untuk project OpenShift, atau peran seluruh cluster. Anda menilai apakah Anda membuat peran lokal dan cluster untuk merancang mekanisme kontrol akses yang efektif di lingkungan target.
  • Binding peran, baik untuk peran cluster dan peran lokal. Pengguna dan grup diberi izin untuk melakukan operasi pada project OpenShift dengan menetapkan binding peran kepada mereka. Peran dapat berada di tingkat cluster atau tingkat lokal. Sering kali, binding peran lokal terikat dengan peran cluster yang telah ditetapkan. Misalnya, binding peran admin project OpenShift default mungkin terikat dengan peran admin cluster default.
  • ResourceQuotas Untuk membatasi konsumsi resource gabungan, OpenShift memungkinkan Anda menentukan kuota level project OpenShift, dan kuota di beberapa project OpenShift. Anda menilai cara fitur dipetakan ke Kubernetes ResourceQuotas, dan mengisi daftar semua ResourceQuotas yang Anda sediakan dan dikonfigurasi di lingkungan OpenShift.

Menilai lingkungan Anda menjelaskan cara menilai resource Kubernetes, seperti ServiceAccounts, dan PersistentVolumes.

Proses build dan deployment

Setelah mengumpulkan informasi tentang model pengelolaan platform dan pengiriman layanan, serta tentang project OpenShift, Anda menilai cara mem-build beban kerja dan men-deploy-nya di lingkungan Anda.

Di lingkungan OpenShift yang sudah ada, Anda mungkin memiliki proses pembuatan dan deployment yang sama untuk semua workload Anda, atau mungkin ada proses berbeda yang perlu dinilai. Artefak proses build untuk beban kerja dalam container adalah image container. Dalam lingkungan OpenShift, Anda mungkin mem-build image container, menyimpannya, dan men-deploy-nya dengan cara yang berbeda:

Setelah mem-build setiap image container, Anda menyimpannya dalam registry container yang nantinya dapat di-deploy. Container registry Anda dapat dihosting pada OpenShift, atau di luar lingkungan OpenShift. Nilai aspek ini karena Anda mungkin memerlukan sistem yang serupa di lingkungan target.

Beban kerja, persyaratan, dan dependensi

Setiap aplikasi OpenShift berisi komponen berikut:

Bergantung pada tujuan aplikasi, Anda dapat menggunakan objek yang berbeda untuk menentukan aplikasi, bukan menggunakan objek Deployment atau DeploymentConfig:

  • Tentukan aplikasi batch menggunakan Job atau cron job.
  • Menentukan aplikasi stateful menggunakan StatefulSets.
  • Jika memiliki beban kerja terkait operasi yang harus dijalankan di setiap node, atau terikat dengan node tertentu, Anda dapat menentukannya menggunakan DaemonSets.

Tabel berikut mencantumkan spesifikasi dan parameter paling penting yang Anda kumpulkan dari resource OpenShift untuk memigrasikan aplikasi ke lingkungan GKE Enterprise target.

Manifes resource OpenShift sumber Spesifikasi dan parameter yang paling penting
Deployment, DeploymentConfig, StatefulSet, Job, cron job Image container dan repositori, port container, jumlah replika Pod, ConfigMaps, Secrets, PersistentVolumeClaims, permintaan dan batas resource, strategi pembaruan, Nama Layanan StatefulSet, jadwal cron job
ImageStream Image container, kebijakan pull image, repositori image container
Penskalaan Otomatis Pod Horizontal Kriteria penskalaan otomatis
Layanan Nama host yang digunakan untuk terhubung ke aplikasi dari dalam cluster, alamat IP, dan port tempat Layanan diekspos, endpoint yang dibuat untuk resource eksternal
Rute Nama host dan jalur resource yang digunakan untuk terhubung ke aplikasi dari luar cluster, aturan pemilihan rute, enkripsi, informasi rantai sertifikat

Menilai lingkungan Anda menjelaskan cara menilai resource Kubernetes seperti berikut:

OpenShift 4 memperkenalkan Framework Operator. Jika menggunakan versi OpenShift ini, Anda mungkin telah men-deploy beberapa aplikasi menggunakan Operator yang terinstal. Dalam hal ini, Anda akan mendapatkan daftar Operator yang terinstal dan mengumpulkan informasi untuk setiap Operator tentang instance Operator yang di-deploy. Instance ini adalah Resource Kustom yang ditentukan Operator, yang men-deploy beberapa Resource Kubernetes yang tercantum sebelumnya.

Selain menilai berbagai referensi tersebut, Anda juga menilai hal-hal berikut:

  • Persyaratan konektivitas jaringan aplikasi. Misalnya, apakah Layanan atau Pod Anda perlu diekspos ke jaringan tertentu? Apakah mereka perlu menjangkau sistem backend tertentu?
  • Batasan untuk menjalankan workload di lokasi tertentu. Misalnya, apakah workload atau set data harus tetap berada di infrastruktur lokal untuk mematuhi persyaratan seperti latensi dalam berkomunikasi dengan workload lain, kebijakan terkait lokasi data, dan kedekatan dengan pengguna?

Konfigurasi cluster OpenShift

Selanjutnya, Anda menilai cluster OpenShift. Untuk menyelesaikan tugas ini, Anda mengumpulkan informasi berikut:

  • Versi OpenShift. Versi utama OpenShift yang tercakup dalam dokumen ini adalah OpenShift 3 dan OpenShift 4. Versi OpenShift yang berbeda mungkin memiliki kemampuan yang berbeda. Anda menilai versi OpenShift mana yang Anda jalankan untuk mengetahui apakah Anda menggunakan fitur khusus versi OpenShift atau tidak.
  • Penyedia identitas yang digunakan untuk autentikasi. Untuk autentikasi, Anda mungkin menggunakan server OAuth bawaan, dan satu atau beberapa penyedia identitas.
  • Batasan Konteks Keamanan. Nilai Batasan Konteks Keamanan OpenShift yang Anda tentukan di cluster, konfigurasinya, serta pengguna, grup, dan akun layanan mana yang ditetapkan.
  • Kebijakan dan isolasi jaringan. Menilai NetworkPolicy, cara Anda mengonfigurasi isolasi jaringan Pod, dan mode OpenShift SDN yang telah dikonfigurasi di cluster Anda.
  • Pemantauan. Nilai persyaratan pemantauan Anda saat ini, serta cara Anda menyediakan dan mengonfigurasi sistem pemantauan saat ini untuk menentukan cara mendesain dan mengimplementasikan solusi pemantauan di lingkungan target. Penilaian ini dapat membantu Anda menentukan apakah akan menggunakan solusi pemantauan baru atau apakah Anda dapat terus menggunakan solusi yang ada. Banyak versi OpenShift menyertakan stack pemantauan berdasarkan Prometheus untuk memantau komponen sistem, yang juga dapat digunakan untuk pemantauan aplikasi. Saat mendesain solusi target, pertimbangkan hal berikut:

    • Solusi pemantauan yang saat ini Anda gunakan di lingkungan OpenShift, misalnya, Prometheus yang dihosting OpenShift, Prometheus- Grafana independen stack, Zabbix, InfluxData, atau Nagios.
    • Cara metrik dibuat dan dikumpulkan, misalnya, mekanisme pull atau push.
    • Dependensi pada komponen apa pun yang di-deploy di cluster OpenShift Anda.
    • Lokasi sistem pemantauan Anda, misalnya, yang di-deploy di lingkungan cloud atau lokal.
    • Metrik yang saat ini Anda kumpulkan untuk beban kerja Anda.
    • Pemberitahuan tentang metrik yang Anda konfigurasi di sistem pemantauan saat ini.
  • Logging. Nilai persyaratan logging Anda saat ini, serta cara Anda menyediakan dan mengonfigurasi sistem logging saat ini untuk menentukan cara mendesain dan menerapkan solusi logging di lingkungan target. Penilaian ini dapat membantu Anda menentukan apakah akan menggunakan solusi logging baru, atau apakah Anda dapat terus menggunakan solusi yang ada. Banyak versi OpenShift dilengkapi dengan solusi logging berdasarkan Elasticsearch .Fluent ,dan Kibana (EFK) yang digunakan untuk mengumpulkan log dari komponen sistem. Solusi ini juga dapat digunakan untuk logging aplikasi. Saat merancang solusi target, pertimbangkan hal-hal berikut:

    • Sistem logging yang saat ini Anda gunakan di lingkungan OpenShift, misalnya stack EFK yang dihosting OpenShift, stack EFK independen, atau Splunk.
    • Dependensi pada komponen apa pun yang di-deploy di cluster OpenShift Anda.
    • Arsitektur dan kapasitas komponen penyimpanan log.
    • Lokasi sistem logging Anda, misalnya, yang di-deploy di lingkungan cloud atau di infrastruktur lokal.
    • Konfigurasi dan kebijakan retensi log.

Menilai lingkungan Anda menjelaskan cara menilai hal berikut:

  • Jumlah cluster
  • Jumlah dan jenis node per cluster
  • Pertimbangan tambahan tentang logging, pemantauan, dan pelacakan
  • Resource Kubernetes kustom

Menyelesaikan penilaian

Setelah membangun inventaris yang terkait dengan proses dan beban kerja OpenShift, Anda akan menyelesaikan aktivitas fase penilaian lainnya dalam artikel Migrasi ke Google Cloud: Menilai dan menemukan workload Anda.

Merencanakan dan membangun fondasi Anda

Pada fase perencanaan dan pembuatan, Anda akan menyediakan dan mengonfigurasi infrastruktur dan layanan yang mendukung beban kerja Anda:

  1. Mem-build hierarki resource.
  2. Mengonfigurasi pengelolaan akses dan identitas.
  3. Menyiapkan penagihan.
  4. Menyiapkan konektivitas jaringan.
  5. Memperketat keamanan Anda.
  6. Menyiapkan pemantauan dan pemberitahuan.

Bagian ini memberikan informasi spesifik untuk membangun fondasi Anda di GKE Enterprise, yang disusun berdasarkan informasi dalam Migrasi ke Google Cloud: Membangun fondasi Anda.

Sebelum membangun fondasi di Google Cloud, baca ringkasan teknis GKE Enterprise untuk memahami cara kerja GKE Enterprise, dan komponen GKE Enterprise mana yang mungkin Anda perlukan. Bergantung pada persyaratan workload dan lokalitas data yang Anda kumpulkan dalam fase penilaian, Anda akan men-deploy beban kerja di GKE di VMware, cluster GKE di Google Cloud, atau di GKE di AWS. Cluster Anda mungkin didistribusikan di antara lingkungan yang berbeda. Untuk mengetahui informasi selengkapnya tentang cara membangun fondasi GKE di Google Cloud, lihat Merencanakan dan membangun fondasi Anda.

Untuk membangun fondasi GKE di VMware, baca konsep intinya, lalu pertimbangkan hal berikut saat menginstal GKE di VMware:

Untuk membangun fondasi bagi GKE di AWS, baca artikel tentang konsep inti, seperti arsitektur GKE pada AWS dan GKE pada penyimpanan AWS. Pertimbangkan hal berikut saat menginstal GKE di AWS:

Men-deploy beban kerja Anda

Pada fase deployment, Anda akan men-deploy workload di GKE Enterprise:

  1. Menyediakan dan mengonfigurasi platform dan lingkungan runtime.
  2. Migrasikan data dari lingkungan lama ke lingkungan baru.
  3. Men-deploy workload Anda.

Bagian berikut memberikan informasi spesifik untuk men-deploy workload ke GKE Enterprise, berdasarkan informasi dalam Migrasi ke Google Cloud: Mentransfer set data besar, Migrasi ke Google Cloud: Men-deploy workload, dan Migrasi ke Google Cloud: Bermigrasi dari deployment manual ke deployment otomatis dalam container.

Menyediakan dan mengonfigurasi platform dan lingkungan runtime

Sebelum dapat men-deploy beban kerja apa pun, Anda perlu menyediakan dan mengonfigurasi cluster GKE Enterprise yang diperlukan.

Anda dapat menyediakan cluster GKE di Google Cloud, GKE di cluster VMware, atau GKE di cluster AWS. Misalnya, jika Anda memiliki workload yang harus di-deploy secara lokal, Anda harus menyediakan satu atau beberapa GKE di cluster VMware. Jika beban kerja Anda tidak memiliki persyaratan lokalitas, Anda perlu menyediakan cluster GKE di Google Cloud. Dalam kedua kasus, Anda dapat mengelola dan memantau cluster dengan GKE Enterprise. Jika Anda memiliki persyaratan multi-cloud, Anda perlu menyediakan GKE di cluster AWS, beserta cluster GKE Enterprise lainnya.

Pertama, tentukan jumlah dan jenis cluster GKE Enterprise yang Anda perlukan. Persyaratan ini sangat bergantung pada informasi yang Anda kumpulkan dalam fase penilaian, seperti model layanan yang ingin Anda implementasikan dan cara Anda ingin mengisolasi lingkungan yang berbeda. Jika beberapa tim pengembangan saat ini membagikan cluster OpenShift, Anda harus menerapkan model multi-tenancy di GKE Enterprise:

  • Gunakan namespace Kubernetes yang berbeda. Tim platform membuat namespace Kubernetes untuk setiap project OpenShift, dan menerapkan model multi-tenancy cluster. Model ini sangat mirip dengan model yang mungkin Anda gunakan di lingkungan OpenShift, sehingga mungkin memerlukan sejumlah cluster GKE Enterprise yang jumlahnya sama dengan jumlah cluster OpenShift Anda. Jika perlu, Anda masih dapat memiliki cluster khusus untuk lingkungan yang berbeda.
  • Gunakan cluster GKE Enterprise yang berbeda. Tim infrastruktur menyediakan cluster GKE Enterprise untuk setiap tim pengembangan, dan tim platform mengelola setiap cluster ini. Model ini mungkin memerlukan sejumlah cluster GKE Enterprise lebih banyak daripada jumlah cluster OpenShift karena memberikan fleksibilitas dan isolasi yang lebih besar untuk pengembangan Anda.
  • Menggunakan project Google Cloud yang berbeda. Tim infrastruktur membuat project Google Cloud untuk setiap tim pengembangan, dan menyediakan cluster GKE Enterprise di dalam project Google Cloud tersebut. Tim platform kemudian mengelola klaster-klaster ini. Model ini mungkin memerlukan beberapa cluster GKE Enterprise lebih banyak daripada jumlah cluster OpenShift Anda karena memberikan fleksibilitas dan isolasi maksimum untuk tim pengembangan Anda.

Setelah menentukan jumlah cluster yang diperlukan dan di lingkungan mana akan disediakan, Anda dapat menentukan ukuran cluster, konfigurasi, dan jenis node. Kemudian, Anda menyediakan cluster dan kumpulan node, sesuai dengan persyaratan beban kerja yang dikumpulkan selama fase penilaian. Misalnya, workload Anda mungkin memerlukan jaminan performa dan skalabilitas tertentu, beserta persyaratan lainnya, seperti kebutuhan akan GPU dan TPU.

Untuk mengetahui informasi selengkapnya tentang cara menyediakan dan mengonfigurasi cluster, lihat hal berikut:

Setelah membuat cluster dan sebelum men-deploy workload, konfigurasikan komponen berikut untuk memenuhi persyaratan yang Anda kumpulkan di project OpenShift dan klaster penilaian:

Dengan Config Sync, Anda dapat secara terpusat menentukan konfigurasi resource berikut di repositori umum yang mematuhi Git, dan menerapkan konfigurasi tersebut ke semua cluster, baik di infrastruktur lokal maupun di cloud:

Untuk menginstal Config Sync, lihat Menginstal Config Sync. Untuk menginstal Pengontrol Kebijakan, lihat Menginstal Pengontrol Kebijakan.

Melakukan migrasi data dari lingkungan lama

Sekarang, Anda dapat memigrasikan data dari lingkungan sumber ke lingkungan target.

Jika aplikasi stateful OpenShift Anda menghosting data di volume persisten Kubernetes, ada berbagai strategi untuk memigrasikan data ke lingkungan target. Memilih strategi yang tepat bergantung pada berbagai faktor, seperti penyedia penyimpanan backend sumber dan target Anda serta lokasi deployment:

  • Andalkan kemampuan kloning, ekspor, dan impor volume penyedia penyimpanan Anda. Jika Anda menggunakan volume VMware vSphere di lingkungan lokal dan bermigrasi ke GKE di VMware, Anda harus meng-clone PersistentVolume yang menjadi dasar disk virtual VMDK, dan memasangnya sebagai volume di lingkungan target Anda. Saat bermigrasi ke GKE, Anda harus import disk virtual sebagai Persistent disk Compute Engine dan menggunakannya sebagai volume persisten.
  • Cadangkan data Anda dari lingkungan sumber menggunakan alat sistem operasi atau alat database. Hosting data tersebut di lokasi sementara yang dapat diakses dari kedua lingkungan, lalu pulihkan data di lingkungan target Anda.
  • Gunakan alat penyalin jarak jauh, seperti rsync, untuk menyalin data dari lingkungan sumber ke lingkungan target.
  • Gunakan solusi pencadangan yang tidak bergantung pada penyimpanan, seperti Velero dengan integrasi terbatas.

Untuk informasi selengkapnya, lihat Migrasi ke Google Cloud: Mentransfer set data besar.

Untuk mengetahui informasi selengkapnya tentang cara memigrasikan data dan strategi untuk mengelola penyimpanan di GKE, baca artikel Memigrasikan data dari lingkungan lama ke lingkungan baru Anda dan dokumen GKE tentang konfigurasi penyimpanan.

Dengan GKE on VMware, Anda dapat memilih antara berbagai opsi untuk berintegrasi dengan sistem penyimpanan eksternal, seperti melalui penyimpanan VMware vSphere, plugin volume dalam hierarki Kubernetes, dan driver Container Storage Interface (CSI). Pilihan Anda bergantung pada sistem penyimpanan eksternal yang perlu diintegrasikan, mode akses yang didukung, dan apakah Anda memerlukan penyediaan volume dinamis.

GKE di AWS secara otomatis men-deploy driver CSI untuk Amazon Elastic Block Store (EBS) dan StorageClass default yang mendukung PersistentVolumeClaims dengan volume EBS dan StorageClasses untuk jenis volume EBS lainnya. Anda juga dapat menginstal driver CSI tambahan dan StorageClasses kustom. Jika memiliki volume EBS yang ingin diimpor di GKE pada AWS, Anda dapat membuat PersistentVolume dari sana.

Men-deploy workload Anda

Setelah menyediakan cluster GKE Enterprise dan memigrasikan data, Anda kini akan membangun dan men-deploy workload. Anda memiliki berbagai opsi, mulai dari deployment manual hingga yang sepenuhnya otomatis.

Jika perlu menggunakan Operator untuk men-deploy beban kerja yang menggunakan metode deployment ini di lingkungan OpenShift, Anda harus menginstal Operator sebelum men-deploy beban kerja Anda. Anda dapat memverifikasi ketersediaan Operator yang Anda perlukan di sumber berikut:

Men-deploy secara manual

Jika men-deploy workload secara manual di lingkungan OpenShift, Anda dapat menyesuaikan proses deployment manual ini dengan lingkungan GKE Enterprise yang baru. Misalnya, Anda dapat menerjemahkan manifes resource OpenShift secara manual yang dinilai dalam beban kerja, persyaratan, dan dependensi ke manifes resource GKE Enterprise yang sesuai.

Tabel berikut memperluas tabel di bagian beban kerja, persyaratan, dan dependensi dalam dokumen ini serta menambahkan informasi tentang resource GKE Enterprise target tempat Anda dapat menggunakannya.

Manifes resource OpenShift sumber Spesifikasi dan parameter yang paling penting Manifes resource Target GKE Enterprise
Deployment, DeploymentConfig, StatefulSet, Job, cron job Image container dan repositori, port container, jumlah replika Pod, ConfigMaps, Secrets, PersistentVolumeClaims, permintaan dan batas resource, strategi pembaruan, Nama Layanan StatefulSet, jadwal cron job Deployment, StatefulSet, Tugas, cron job
ImageStream Image container, kebijakan pull image, repositori image container Deployment
Penskalaan Otomatis Pod Horizontal Kriteria penskalaan otomatis Penskalaan Otomatis Pod Horizontal
Layanan Nama host yang digunakan untuk terhubung ke aplikasi dari dalam cluster, alamat IP, dan port tempat Layanan diekspos, endpoint yang dibuat untuk resource eksternal Layanan
Rute Nama host dan jalur resource yang digunakan untuk terhubung ke aplikasi dari luar cluster, aturan perutean Masuk

Mendesain dan menerapkan proses deployment otomatis

Untuk mem-build dan men-deploy workload secara otomatis, Anda harus mendesain dan menerapkan proses build serta deployment, atau menyesuaikan proses yang sudah ada untuk mendukung lingkungan baru Anda. Jika Anda perlu men-deploy workload di lingkungan hybrid, proses deployment Anda harus mendukung GKE di Google Cloud dan GKE di VMware.

Untuk menerapkan proses build dan deployment, Anda dapat menggunakan Cloud Build. Jika ingin mengotomatiskan proses build dan deployment, Anda dapat mengonfigurasi pemicu build atau GitHub Pemicu aplikasi, atau siapkan deployment otomatis dari Konsol Google Cloud. Jika menggunakan batasan pengontrol kebijakan, Anda dapat memeriksa deskripsi Kubernetes dan GKE Enterprise dengan kebijakan dalam tugas Cloud Build untuk memberikan masukan kepada developer.

Jika perlu menjalankan tugas build atau menyimpan kode sumber secara lokal, Anda dapat menggunakan GitLab. GitLab menawarkan repositori kode sumber dan platform kolaborasi, kemampuan CI/CD, dan registry image container. Anda dapat men-deploy GitLab di cluster GKE Enterprise langsung dari Cloud Marketplace, atau menggunakan salah satu opsi penginstalan lain yang tersedia.

Jika saat ini Anda menggunakan salah satu fasilitas OpenShift untuk mem-build atau men-deploy workload secara otomatis, Anda dapat menggunakan salah satu strategi berikut berdasarkan proses Anda saat ini:

  • Pipeline Jenkins. Jika Anda menggunakan pipeline Jenkins untuk mengotomatiskan proses build dan deployment, Anda dapat mem-porting pipeline ke Cloud Build, menggunakan lingkungan Jenkins yang sudah ada, atau men-deploy Jenkins di Google Cloud.
  • Build dan deployment dari Dockerfile dan artefak yang diperlukan. Anda dapat menggunakan Cloud Build untuk membuat image container dengan Dockerfile atau file konfigurasi build singkat ini. Jika ingin menyetujui build di cluster lokal, Anda dapat menggunakan GitLab.
  • Build sumber ke gambar. Di Cloud Build, Anda harus mengimplementasikan langkah awal untuk mem-build artefak yang diperlukan oleh image container yang dihasilkan. Jika tugas sumber-ke-gambar mem-build aplikasi Python dan menghasilkan image container, Anda harus mengonfigurasi langkah build kustom untuk membangun aplikasi Python, lalu build image container. Pendekatan ini juga mengharuskan Anda menyediakan Dockerfile, atau jika tidak ingin menyediakannya, Anda dapat menggunakan buildpack Google Cloud atau Jib untuk aplikasi Java.
  • Build kustom. Anda dapat membuat builder Cloud Build kustom seperti yang Anda lakukan sekarang di OpenShift. Jika builder kustom Anda tidak menggunakan fitur khusus OpenShift, Anda mungkin dapat menggunakannya seperti di Cloud Build.

Apa pun pendekatan yang dipilih untuk mem-build image container, Anda harus menyimpannya dalam repositori image container. Berikut ini opsi yang tersedia untuk Anda:

Apa pun pilihan Anda untuk menyimpan image container, Anda perlu menyediakan dan mengonfigurasi kredensial untuk cluster Anda agar dapat mengakses repositori image container.

Jika perlu mengirim notifikasi tentang status build dan image container kepada pengguna atau layanan pihak ketiga, Anda dapat menggunakan Cloud Functions untuk merespons peristiwa yang dihasilkan oleh Cloud Build dan Container Registry.

Ringkasan pemetaan kapabilitas OpenShift ke GKE Enterprise

Tabel berikut adalah ringkasan cara memetakan kemampuan GKE Enterprise dengan kemampuan yang Anda gunakan pada OpenShift.

OpenShift GKE Enterprise
Project OpenShift
  • Namespace Kubernetes yang dikelola secara terpusat oleh Config Sync
  • Otorisasi RBAC Kubernetes yang dikelola secara terpusat oleh Config Sync
  • Kuota resource Kubernetes yang dikelola secara terpusat oleh Config Sync
OpenShift SDN dan isolasi jaringan
  • Kebijakan keamanan jaringan Calico yang dikelola secara terpusat oleh Config Sync
Batasan Konteks Keamanan OpenShift
  • Batasan Pengontrol Kebijakan
Pipeline OpenShift
  • Cloud Build
  • Integrasi Jenkins menggunakan plugin Google Cloud Jenkins
  • GitLab
OpenShift Sumber-ke-Gambar
  • Buildpack Berbasis Cloud
  • Jib
Integrasi identitas
  • Cloud Identity
  • Google Cloud Directory Sync
  • Integrasi GKE pada VMware

Mengoptimalkan lingkungan Anda

Pengoptimalan adalah fase terakhir dari migrasi Anda. Pada fase ini, Anda membuat lingkungan menjadi lebih efisien daripada sebelumnya. Pada fase ini, Anda menyetujui beberapa iterasi dari loop berulang hingga lingkungan Anda memenuhi persyaratan pengoptimalan. Langkah-langkah dari loop berulang ini adalah sebagai berikut:

  1. Menilai lingkungan, tim, dan loop pengoptimalan Anda saat ini.
  2. Menetapkan persyaratan dan sasaran pengoptimalan Anda.
  3. Mengoptimalkan lingkungan dan tim Anda.
  4. Menyesuaikan loop pengoptimalan.

Bagian berikut bergantung pada Migrasi ke Google Cloud: Mengoptimalkan lingkungan Anda.

Menilai lingkungan, tim, dan loop pengoptimalan Anda saat ini

Meskipun penilaian pertama berfokus pada migrasi dari lingkungan Anda saat ini ke GKE Enterprise, penilaian ini disesuaikan untuk fase pengoptimalan.

Menetapkan persyaratan pengoptimalan

Untuk GKE terkait persyaratan pengoptimalan Google Cloud, tinjau persyaratan pengoptimalan yang ditetapkan dalam artikel Mengoptimalkan lingkungan Anda.

Tinjau persyaratan pengoptimalan berikut untuk lingkungan GKE Enterprise Anda:

Selesaikan pengoptimalan

Setelah mengisi daftar persyaratan pengoptimalan, Anda akan menyelesaikan aktivitas fase pengoptimalan lainnya di Migrasi ke Google Cloud: Mengoptimalkan lingkungan Anda.

Menemukan bantuan

Google Cloud menawarkan berbagai opsi dan resource bagi Anda untuk menemukan bantuan dan dukungan yang diperlukan agar dapat menggunakan layanan Google Cloud sebaik mungkin:

  • Resource layanan mandiri. Jika tidak memerlukan dukungan khusus, Anda memiliki berbagai opsi yang dapat digunakan sesuai kemampuan.
  • Partner teknologi. Google Cloud telah berpartner dengan beberapa perusahaan untuk membantu Anda menggunakan produk dan layanan kami.
  • Layanan Profesional Google Cloud. Layanan profesional kami dapat membantu Anda mendapatkan hasil maksimal dari investasi Anda di Google Cloud.

Terdapat referensi lainnya untuk membantu memigrasikan workload ke Google Cloud di Pusat Migrasi Google Cloud.

Untuk mengetahui informasi selengkapnya tentang resource ini, lihat bagian menemukan bantuan dalam artikel Migrasi ke Google Cloud: Memulai.

Langkah selanjutnya