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:
- Memigrasikan container ke Google Cloud: Memigrasikan Kubernetes ke Google Kubernetes Engine (GKE)
- Memigrasikan container ke Google Cloud: Bermigrasi ke lingkungan GKE baru
- Memigrasikan container ke Google Cloud: Bermigrasi dari OpenShift ke GKE Enterprise (dokumen ini)
- Memigrasikan container ke Google Cloud: Memigrasikan project OpenShift ke GKE Enterprise
- Bermigrasi dari OpenShift ke GKE Enterprise: Memigrasikan OpenShift SCC ke Batasan Pengontrol Kebijakan
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:
- Menilai dan menemukan workload Anda.
- Merencanakan dan membangun fondasi.
- Men-deploy workload Anda
- Mengoptimalkan lingkungan Anda.
Diagram berikut menggambarkan jalur perjalanan migrasi Anda.
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:
- Buat inventaris yang komprehensif untuk proses dan aplikasi Anda.
- Buat katalog proses dan aplikasi Anda sesuai dengan properti dan dependensinya.
- Latih dan ajari tim Anda di Google Cloud.
- Membangun eksperimen dan bukti konsep di Google Cloud.
- Menghitung total biaya kepemilikan (TCO) lingkungan target.
- 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:
- Proses build image container berjalan sepenuhnya di luar OpenShift. Proses build dapat didasarkan pada langkah-langkah manual atau dapat didasarkan pada pipeline continuous integration dan continuous deployment (CI/CD) otomatis yang memiliki image container dan manifes Kubernetes sebagai produk akhir.
- Proses build image container berjalan di dalam OpenShift. OpenShift mendukung berbagai opsi, seperti menyediakan Dockerfile dan semua artefak yang diperlukan untuk mem-build image container, mengonfigurasi sumber build -to-image, mengonfigurasi build pipeline, atau mengonfigurasi build kustom. Strategi build ini membuat resource BuildConfig yang menentukan pilihan build, lokasi artefak sumber, image container target, dan peristiwa yang dapat memicu container proses pembuatan gambar.
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:
- Objek OpenShift DeploymentConfig atau Kubernetes Deployment. Untuk informasi selengkapnya tentang perbedaan antara objek ini, lihat Membandingkan Deployment dan DeploymentConfig.
- Layanan Kubernetes untuk membuat aplikasi Anda dapat dijangkau oleh klien, dan OpenShift Route untuk terhubung ke Layanan Kubernetes tersebut dari luar cluster
- OpenShift ImageStream untuk memberikan abstraksi guna mereferensikan gambar container. OpenShift ImageStream mencakup satu atau beberapa gambar container, masing-masing diidentifikasi oleh tag, dan menyajikan satu tampilan abstrak gambar terkait, mirip dengan repositori gambar container.
- OpenShift BuildConfig untuk mem-build image container aplikasi OpenShift tersebut di OpenShift.
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:
- Pengontrol Kubernetes lainnya
- Penskalaan Otomatis Pod Horizontal
- Konteks keamanan pod.
- Workload stateless dan stateful
- Penyimpanan
- Konfigurasi dan injeksi rahasia
- Ingress
- Logging dan pemantauan
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:
- Mem-build hierarki resource.
- Mengonfigurasi pengelolaan akses dan identitas.
- Menyiapkan penagihan.
- Menyiapkan konektivitas jaringan.
- Memperketat keamanan Anda.
- 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:
- Pastikan lingkungan lokal Anda memenuhi persyaratan untuk Anthos GKE secara lokal. Anda harus menyediakan kapasitas yang cukup di lingkungan VMware vSphere untuk mengakomodasi cluster admin dan cluster pengguna tersebut. Persyaratan ini bergantung pada jumlah permintaan resource beban kerja Anda, dan jumlah cluster yang Anda butuhkan. Anda menilai kedua aspek dalam tahap penilaian.
Menyiapkan jaringan Anda harus mengonfigurasi jaringan lokal agar dapat memenuhi persyaratan konektivitas jaringan aplikasi yang dikumpulkan dalam penilaian, selain persyaratan penginstalan GKE on VMware. Pertimbangkan kebutuhan jaringan berikut:
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:
- Pastikan lingkungan Amazon Web Services (AWS) dan Google Cloud Anda memenuhi persyaratan untuk GKE di AWS. GKE di AWS memerlukan akun (AWS) dengan akses command line dan kunci AWS Key Management Service (KMS) untuk mengenkripsi secret lapisan aplikasi dalam cluster. Anda memerlukan Terraform dan kubectl.
- Mengonfigurasi lingkungan AWS. Anda perlu mengonfigurasi lingkungan AWS, menginstal alat, seperti Antarmuka Command Line (CLI) AWS, mengonfigurasi kredensial AWS IAM, dan menyediakan resource di lingkungan AWS Anda, seperti kunci AWS KMS.
- Mengonfigurasi lingkungan Google Cloud. Anda perlu mengonfigurasi lingkungan Google Cloud, membuat project dan akun layanan Google Cloud yang diperlukan, serta mengonfigurasi IAM.
Men-deploy beban kerja Anda
Pada fase deployment, Anda akan men-deploy workload di GKE Enterprise:
- Menyediakan dan mengonfigurasi platform dan lingkungan runtime.
- Migrasikan data dari lingkungan lama ke lingkungan baru.
- 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:
- Sediakan dan konfigurasi platform runtime dan lingkungan Anda untuk cluster GKE di Google Cloud.
- Membuat cluster pengguna dan admin untuk GKE pada cluster VMware.
- Menginstal cluster pengelolaan dan membuat cluster pengguna untuk GKE di cluster AWS.
Setelah membuat cluster dan sebelum men-deploy workload, konfigurasikan komponen berikut untuk memenuhi persyaratan yang Anda kumpulkan di project OpenShift dan klaster penilaian:
- Pengelolaan akses dan identitas. Anda dapat mengonfigurasi pengelolaan akses dan identitas seperti yang dijelaskan dalam Mengonfigurasi pengelolaan akses dan identitas. Anda dapat bermigrasi ke Cloud Identity sebagai penyedia identitas utama, atau menggunakan Google Cloud Directory Sync untuk menyinkronkan Cloud Identity dengan yang ada di LDAP atau Active Directory Server GKE di VMware mendukung OpenID Connect (OIDC) untuk melakukan autentikasi terhadap cluster pengguna menggunakan command line. Ikuti bagian Mengautentikasi dengan OIDC dan Google untuk mengintegrasikan autentikasi command line dengan Cloud Identity.
- Pemantauan. Anda dapat menyesuaikan solusi pemantauan saat ini dengan lingkungan GKE Enterprise target sesuai dengan batasan dan persyaratan Anda. Jika solusi Anda saat ini dihosting di OpenShift, Anda dapat mengimplementasikan Cloud Monitoring seperti yang dijelaskan dalam Membangun fondasi atau menerapkan Prometheus dan Grafana dengan GKE di VMware.
- Logging. Anda dapat menyesuaikan solusi logging saat ini dengan lingkungan GKE Enterprise target sesuai dengan batasan dan persyaratan Anda. Jika solusi Anda saat ini dihosting di OpenShift, Anda dapat menerapkan Cloud Logging seperti yang dijelaskan dalam Membangun fondasi Anda - Pemantauan dan Pemberitahuan.
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:
- Kontrol akses berbasis peran (RBAC). Setelah mengonfigurasi autentikasi, Anda dapat menerapkan kebijakan otorisasi menggunakan kombinasi Identity and Access Management dan Kubernetes RBAC ini. Kebijakan ini memenuhi persyaratan yang Anda kumpulkan dalam penilaian Project OpenShift dan model multi-tenancy yang Anda pilih.
- Kuota resource. Anda dapat menerapkan Kuota resource ke namespace untuk menetapkan kuota ke tim developer sesuai kebutuhan.
- Konteks keamanan untuk beban kerja Anda. Anda dapat menggunakan Pengontrol Kebijakan untuk membuat batasan guna menerapkan keamanan Pod sesuai dengan persyaratan Anda dan konfigurasi Batasan Konteks Keamanan OpenShift yang dikumpulkan dalam fase penilaian.
- Kebijakan dan isolasi jaringan. Anda dapat menerapkan isolasi jaringan yang diperlukan antara namespace atau workload menggunakan Kebijakan Jaringan Kubernetes.
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:
- Google Cloud Marketplace
- operatorhub.io
- Situs vendor software tertentu atau repositori GitHub
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:
- Pertahankan repositori image container yang ada. Jika Anda menggunakan repositori image container eksternal yang tidak berjalan di OpenShift, dan belum siap melakukan migrasi,Anda dapat terus menggunakan repositori tersebut untuk menyimpan image container Anda.
- Container Registry. Jika lebih menyukai layanan terkelola sepenuhnya, Anda dapat menggunakan Container Registry untuk menyimpan image container Anda. Jika memerlukan lapisan keamanan tambahan, Anda dapat mengelola kunci enkripsi Container Registry sendiri, mengonfigurasi perimeter aman untuk mengakses Container Registry, meningkatkan keamanan supply chain software Anda, dan memindai image container untuk menemukan kerentanan yang diketahui dengan Artifact Analysis. Container Registry juga mendukung image dasar terkelola yang dikelola oleh Google, sebagai dasar untuk image container Anda.
- Repositori lokal. Jika Anda perlu bermigrasi dari repositori saat ini karena dihosting di OpenShift, dan Anda perlu menyimpan image container secara lokal, Anda dapat memilih registry yang disediakan dengan GitLab.
- Pendekatan hybrid. Anda dapat menggabungkan opsi sebelumnya untuk mendapatkan manfaat dari keunggulan masing-masing opsi. Misalnya, Anda dapat menggunakan Container Registry sebagai repositori utama, dan mencerminkannya ke repositori lokal. Dalam hal ini, Anda menggunakan fitur Container Registry dan tetap mendapatkan manfaat karena memiliki repositori lokal.
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 |
|
OpenShift SDN dan isolasi jaringan |
|
Batasan Konteks Keamanan OpenShift |
|
Pipeline OpenShift |
|
OpenShift Sumber-ke-Gambar |
|
Integrasi identitas |
|
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:
- Menilai lingkungan, tim, dan loop pengoptimalan Anda saat ini.
- Menetapkan persyaratan dan sasaran pengoptimalan Anda.
- Mengoptimalkan lingkungan dan tim Anda.
- 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:
- Mulai deploy beban kerja di lingkungan serverless. Jika perlu mengurangi beban pada tim operasi, Anda dapat mulai menggunakan platform serverless yang terkelola sepenuhnya seperti Cloud Run dan Cloud Run for Anthos.
- Perbarui proses deployment Anda. Migrasi ke Google Cloud: Men-deploy workload Anda menjelaskan proses deployment menyeluruh yang umum dan cara memodernisasi proses yang ada. Jika Anda ingin memodernisasi proses deployment yang ada, atau ingin mendesain proses deployment baru, lihat Migrasi ke Google Cloud: Bermigrasi dari deployment manual ke deployment dalam container otomatis untuk panduan.
- Deploy dengan Spinnaker. Jika Anda perlu menerapkan logika deployment, seperti deployment canary dan deployment biru/hijau, untuk meningkatkan keandalan lingkungan Anda dan mengurangi dampaknya bagi pengguna, Anda dapat menggunakan Spinnaker. Untuk menggunakan Spinnaker di Google Cloud, Anda harus menginstalnya. Setelah itu, terapkan proses deployment dengan Spinnaker. Misalnya, Anda dapat mendaftarkan cluster GKE yang ada di Spinnaker, mengaktifkan dukungan Kustomize untuk Spinnaker, atau mengimplementasikan pipeline continuous delivery dengan Spinnaker dan GKE.
- Implementasikan supply-chain software yang aman. Untuk beban kerja yang penting bagi keamanan, Anda dapat menerapkan supply chain software yang aman di cluster GKE Enterprise menggunakan Otorisasi Biner.
- Beralih ke Anthos Service Mesh. Jika Anda sudah menggunakan Mesh Layanan OpenShift atau mencari kemampuan pengelolaan traffic, kemampuan observasi, dan keamanan yang disediakan mesh layanan, yang dapat Anda gunakanAnthos Service Mesh singkat ini. Anthos Service Mesh menyediakan distribusi Istio yang sudah teruji dan didukung oleh GKE Enterprise, beserta kemampuan backend yang dikelola Google untuk kemampuan observasi, pengelolaan sertifikat mTLS, dan integrasi dengan Identity Aware Proxy (IAP).
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
- Migrasi ke Google Cloud: Memulai.
- Pelajari GKE Enterprise dan Migrate to Containers lebih lanjut.
- Baca cara mendukung migrasi dengan perluasan mesh Istio.
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.