Memigrasikan container ke Google Cloud: Memigrasikan ke lingkungan GKE multi-cluster

Last reviewed 2023-05-08 UTC

Dokumen ini membantu Anda merencanakan, merancang, dan mengimplementasikan migrasi Anda dari lingkungan Google Kubernetes Engine (GKE) ke lingkungan GKE yang baru. Jika tidak dilakukan dengan benar, memindahkan aplikasi dari satu lingkungan ke lingkungan lain dapat menjadi tugas yang menantang. Oleh karena itu, Anda perlu merencanakan dan menyetujui migrasi Anda dengan hati-hati.

Dokumen ini adalah bagian dari seri multi-bagian tentang migrasi ke Google Cloud. Untuk ringkasan rangkaian ini, lihat Bermigrasi ke Google Cloud: Memilih jalur migrasi Anda.

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

Dokumen ini berguna jika Anda berencana untuk bermigrasi dari lingkungan GKE ke lingkungan GKE lainnya. Dokumen ini juga berguna jika Anda mengevaluasi peluang untuk bermigrasi dan ingin mempelajari seperti apa kemungkinannya.

Alasan bermigrasi dari lingkungan GKE ke lingkungan GKE lainnya dapat mencakup hal berikut:

  • Mengaktifkan fitur GKE hanya tersedia pada saat pembuatan cluster. GKE terus berkembang dengan fitur baru dan perbaikan keamanan. Untuk mendapatkan manfaat dari sebagian besar fitur dan perbaikan baru, Anda mungkin perlu mengupgrade clusters dan kumpulan node GKE ke versi GKE yang lebih baru, baik melalui upgrade otomatis atau secara manual.

    Beberapa fitur GKE baru tidak dapat diaktifkan di cluster yang ada, dan fitur tersebut mengharuskan Anda membuat cluster GKE baru dengan mengaktifkan fitur baru tersebut. Misalnya, Anda dapat mengaktifkan jaringan berbasis VPC di GKE, Dataplane V2 atau Penyembunyian metadata hanya saat Anda membuat cluster baru. Anda tidak dapat memperbarui konfigurasi cluster yang ada untuk mengaktifkan fitur tersebut setelah dibuat.

  • Menerapkan proses penyediaan dan konfigurasi otomatis untuk infrastruktur Anda. Jika Anda menyediakan dan mengonfigurasi infrastruktur secara manual, Anda dapat mendesain dan menerapkan proses otomatis untuk menyediakan dan mengonfigurasi cluster GKE Anda, bukan mengandalkan manual dan error metode yang rentan.

Saat Anda mendesain arsitektur lingkungan baru, sebaiknya pertimbangkan lingkungan GKE multi-cluster. Dengan menyediakan dan mengonfigurasi beberapa cluster GKE di lingkungan, Anda melakukan hal berikut:

  • Kurangi kemungkinan terjadinya titik tunggal kegagalan dalam arsitektur Anda. Misalnya, jika sebuah cluster mengalami pemadaman, cluster lain dapat mengambil alih.
  • Manfaatkan fleksibilitas lebih besar yang disediakan lingkungan multi-cluster. Misalnya, dengan menerapkan perubahan ke subset cluster Anda, Anda dapat membatasi dampak masalah yang disebabkan oleh perubahan konfigurasi yang keliru. Selanjutnya, Anda dapat memvalidasi perubahan sebelum Anda menerapkannya ke cluster Anda yang tersisa.
  • Biarkan workload Anda berkomunikasi lintas cluster. Misalnya, workload yang di-deploy dalam cluster dapat berkomunikasi dengan workload yang di-deploy di cluster lain.

Panduan dalam dokumen ini juga berlaku untuk lingkungan GKE cluster tunggal. Saat Anda bermigrasi ke lingkungan GKE cluster tunggal, lingkungan Anda tidak terlalu kompleks untuk dikelola dibandingkan dengan lingkungan multi-cluster. Namun, lingkungan cluster tunggal tidak mendapatkan manfaat dari peningkatan fleksibilitas, keandalan, dan ketahanan lingkungan GKE multi-cluster.

Diagram berikut menggambarkan jalur perjalanan migrasi Anda.

Jalur migrasi dengan empat fase.

Framework yang diilustrasikan dalam diagram sebelumnya memiliki fase berikut, yang dijelaskan dalam Migrasi ke Google Cloud: Memulai:

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

Anda akan mengikuti fase sebelumnya selama setiap langkah migrasi. Dokumen ini juga mengandalkan konsep yang dibahas dalam Memigrasikan container ke Google Cloud: Memigrasikan Kubernetes ke GKE. Menyertakan link yang sesuai.

Menilai lingkungan Anda

Pada fase penilaian, Anda mengumpulkan informasi tentang lingkungan sumber dan workload yang ingin dimigrasikan. Penilaian ini sangat penting untuk migrasi Anda dan untuk menyesuaikan resource yang Anda perlukan untuk migrasi dan lingkungan target Anda. Pada fase penilaian, Anda melakukan hal berikut:

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

Bagian berikut bergantung pada Migrasi ke Google Cloud: Menilai dan menemukan workload Anda. Namun, alat ini memberikan informasi yang spesifik untuk menilai workload yang ingin Anda migrasikan ke cluster GKE baru.

Dalam Memigrasikan Kubernetes ke GKE, artikel Menilai lingkungan Anda menjelaskan cara menilai cluster dan resource Kubernetes, seperti ServiceAccounts, dan PersistentVolumes. Informasi ini juga berlaku untuk menilai lingkungan GKE Anda.

Membangun inventaris Anda

Untuk menentukan cakupan migrasi, Anda harus memahami lingkungan GKE saat ini. Mulailah dengan mengumpulkan informasi tentang cluster Anda, lalu fokus pada workload Anda yang di-deploy di cluster tersebut dan dependensi workload. Pada akhir fase penilaian, Anda memiliki dua inventaris: satu untuk cluster Anda, dan satu untuk workload yang di-deploy di cluster tersebut.

Dalam Memigrasikan Kubernetes ke GKE, artikel Membangun inventaris Anda menjelaskan cara mem-build inventaris cluster dan workload Kubernetes Anda. Atribut ini juga berlaku untuk membangun inventaris lingkungan GKE Anda. Sebelum Anda melanjutkan dokumen ini, ikuti panduan tersebut untuk mem-build inventaris cluster Kubernetes Anda.

Setelah Anda mengikuti panduan Migrasi Kubernetes ke GKE untuk mem-build inventaris Anda, Anda perlu meningkatkan kualitas inventaris. Untuk menyelesaikan inventaris cluster GKE Anda dan kumpulan Node, pertimbangkan aspek dan fitur khusus GKE untuk setiap cluster dan kumpulan Node, termasuk yang berikut ini:

Saat Anda mem-build inventaris, Anda mungkin menemukan beberapa cluster GKE yang perlu dinonaktifkan sebagai bagian dari migrasi Anda. Beberapa resource Google Cloud tidak dihapus saat Anda menghapus cluster GKE yang membuatnya. Pastikan bahwa rencana migrasi Anda mencakup penghentian resource tersebut.

Untuk mengetahui informasi tentang potensi aspek dan fitur khusus GKE lainnya, lihat dokumentasi GKE.

Menyelesaikan penilaian

Setelah Anda mem-build inventaris yang terkait dengan cluster GKE dan workload Anda, selesaikan aktivitas fase penilaian lainnya dalam artikel Memigrasikan container ke Google Cloud: Memigrasikan Kubernetes ke GKE.

Merencanakan dan membangun fondasi Anda

Pada fase perencanaan, Anda menyediakan dan mengonfigurasi fondasi, infrastruktur cloud, dan layanan yang mendukung workload Anda di Google Cloud. Pada fase perencanaan, Anda melakukan hal berikut ini:

  • Membuat hierarki resource
  • Mengonfigurasi pengelolaan akses dan identitas.
  • Menyiapkan penagihan.
  • Menyiapkan konektivitas jaringan.
  • Memperketat keamanan Anda.
  • Menyiapkan pemantauan dan pemberitahuan.

Saat Anda menyiapkan konektivitas jaringan, pastikan Anda memiliki alamat IP yang cukup di subnet Anda untuk dialokasikan ke Node, Pod, dan Layanan. Saat Anda menyiapkan jaringan untuk cluster, rencanakan alokasi alamat IP dengan cermat—misalnya, Anda dapat mengonfigurasi IP publik yang digunakan secara pribadi untuk GKE. Rentang alamat IP sekunder yang Anda tetapkan untuk Pod dan Layanan di cluster Anda tidak dapat diubah setelah Anda mengalokasikannya. Berhati-hatilah jika Anda mengalokasikan Pod atau rentang Layanan /22 (1024 alamat) atau yang lebih kecil. Jika tidak, Anda mungkin akan kehabisan alamat IP untuk Pod dan Layanan seiring pertumbuhan cluster Anda. Untuk mengetahui informasi lebih lanjut, lihat Perencanaan rentang alamat IP.

Sebaiknya Anda gunakan subnet bersama yang terpisah untuk load balancer internal yang Anda buat untuk lingkungan GKE. Saat menggunakan Layanan Kubernetes type: LoadBalancer, Anda dapat menentukan subnet load balancer. Saat mengonfigurasi load balancer internal HTTP(S) internal, Anda harus mengonfigurasi subnet khusus proxy.

Untuk membangun fondasi lingkungan GKE Anda, selesaikan aktivitas fase perencanaan dan pembangunan dalam Memigrasikan container ke Google Cloud: Memigrasikan Kubernetes ke GKE.

Men-deploy workload Anda

Pada fase deployment, Anda melakukan hal berikut:

  1. Menyediakan dan mengonfigurasi lingkungan target.
  2. Migrasikan data dari lingkungan sumber ke lingkungan target.
  3. Deploy workload Anda di lingkungan target.

Bagian ini memberikan informasi yang khusus untuk men-deploy workload ke GKE. Layanan ini dibangun berdasarkan informasi dalam Memigrasikan Kubernetes ke GKE: Men-deploy workload Anda.

Mengevaluasi platform dan lingkungan runtime Anda

Untuk memiliki infrastruktur yang lebih fleksibel, andal, dan mudah dikelola, sebaiknya Anda mendesain dan menerapkan arsitektur multi-cluster. Dalam arsitektur multi-cluster, Anda memiliki beberapa cluster GKE produksi di lingkungan Anda. Misalnya, jika menyediakan beberapa cluster GKE di lingkungan Anda, Anda dapat menerapkan strategi siklus proses cluster lanjutan, seperti meluncurkan upgrade atau upgrade blue-green. Untuk mengetahui informasi selengkapnya tentang desain arsitektur GKE multi-cluster dan manfaatnya, lihat Upgrade multi-cluster GKE menggunakan Multi Cluster Ingress.

Saat Anda menjalankan lingkungan Anda di beberapa cluster, ada tantangan tambahan yang perlu dipertimbangkan, seperti berikut:

  • Anda perlu menyesuaikan manajemen konfigurasi, penemuan layanan dan komunikasi, peluncuran aplikasi, serta load balancing untuk traffic masuk.
  • Anda mungkin perlu menjalankan software tambahan di cluster, serta otomatisasi dan infrastruktur tambahan.

Untuk mengatasi tantangan ini, Anda mungkin memerlukan pipeline Continuous Integration/Deployment Berkelanjutan (CI/CD) untuk mengupdate konfigurasi cluster secara berurutan untuk meminimalkan dampak kesalahan. Anda mungkin juga memerlukan load balancer untuk mendistribusikan traffic dari satu cluster ke cluster lain.

Mengelola infrastruktur Anda secara manual rentan terhadap error dan menimbulkan masalah karena kesalahan konfigurasi, serta kurangnya dokumentasi internal tentang status infrastruktur Anda saat ini. Untuk membantu mengurangi risiko akibat masalah tersebut, sebaiknya Anda terapkan infrastruktur sebagai pola kode. Saat menerapkan pola ini, Anda memperlakukan penyediaan infrastruktur Anda dengan cara yang sama seperti Anda menangani kode sumber workload Anda.

Ada beberapa opsi arsitektur untuk lingkungan GKE multi-cluster Anda, yang akan dijelaskan nanti di bagian ini. Memilih satu opsi dibanding yang lain bergantung pada beberapa faktor, dan tidak ada opsi yang secara inheren lebih baik daripada yang lain. Setiap jenis memiliki kekuatan dan kelemahannya sendiri. Untuk memilih jenis arsitektur, lakukan hal berikut:

  1. Buat serangkaian kriteria untuk mengevaluasi jenis arsitektur lingkungan GKE multi-cluster.
  2. Evaluasi setiap opsi berdasarkan kriteria evaluasi.
  3. Pilih opsi yang paling sesuai dengan kebutuhan Anda.

Guna menetapkan kriteria untuk mengevaluasi jenis arsitektur lingkungan GKE multi-cluster, gunakan penilaian lingkungan yang telah Anda selesaikan untuk mengidentifikasi fitur yang Anda butuhkan. Urutkan fitur sesuai dengan tingkat kepentingannya. Misalnya, setelah menilai workload Anda dan lingkungan, Anda dapat mempertimbangkan kriteria evaluasi berikut, yang tercantum sesuai urutan kepentingannya:

  1. Solusi yang dikelola Google. Apakah Anda lebih memilih layanan dan produk yang dikelola Google atau dikelola sendiri?
  2. Antarmuka untuk berinteraksi dengan arsitektur. Apakah ada antarmuka yang dapat dibaca mesin yang dapat berinteraksi dengan Anda? Apakah antarmuka didefinisikan sebagai standar terbuka? Apakah antarmuka mendukung perintah deklaratif, perintah imperatif, atau keduanya?
  3. Mengekspos layanan di luar lingkungan GKE. Apakah arsitektur ini memungkinkan Anda mengekspos workload Anda di luar cluster GKE tempat workload tersebut di-deploy?
  4. Komunikasi antar-cluster. Apakah arsitekturnya mendukung saluran komunikasi antar cluster? Apakah workload Anda mendukung arsitektur terdistribusi? Kriteria ini penting untuk mendukung workload dengan desain terdistribusi, seperti Jenkins.
  5. Pengelolaan traffic. Apakah arsitekturnya mendukung fitur pengelolaan traffic lanjutan, seperti injeksi kesalahan, pergeseran traffic, permintaan waktu tunggu dan percobaan ulang, pemutus sirkuit, dan pencerminan traffic? Apakah fitur tersebut siap digunakan atau Anda harus menerapkannya sendiri?
  6. Menyediakan dan mengonfigurasi alat tambahan. Apakah Anda perlu menyediakan dan mengonfigurasi komponen hardware atau software tambahan?

Google Cloud menyediakan opsi berikut untuk mendesain arsitektur lingkungan GKE multi-cluster. Untuk memilih opsi terbaik bagi workload Anda, pertama-tama Anda menilainya berdasarkan kriteria evaluasi sebelumnya yang Anda tetapkan. Gunakan skala arbitrer yang diurutkan untuk menetapkan skor pada setiap opsi desain terhadap setiap kriteria evaluasi. Misalnya, Anda dapat menetapkan skor untuk setiap lingkungan dengan skala dari 1 hingga 10 terhadap setiap kriteria evaluasi. Opsi berikut disajikan dengan semakin meningkatnya upaya yang diperlukan untuk mengelola lingkungan GKE multi-cluster yang baru.

  1. Multi Cluster Ingress dan Penemuan Layanan Multi-Cluster
  2. Multi Cluster Ingress dan Anthos Service Mesh
  3. Traffic Director
  4. Pembaruan data DNS yang dikelola sendiri dan Kubernetes

Bagian berikut menjelaskan opsi tersebut secara mendetail, dan menyertakan daftar kriteria untuk mengevaluasi setiap opsi. Anda mungkin dapat menetapkan skor terhadap beberapa kriteria dengan membaca dokumentasi produk. Misalnya, dengan membaca dokumentasi, Anda dapat mengevaluasi Anthos Service Mesh berdasarkan beberapa kriteria evaluasi yang telah Anda tetapkan sebelumnya. Namun, untuk menetapkan skor terhadap kriteria lain, Anda mungkin perlu mendesain dan menyetujui benchmark dan simulasi yang lebih mendalam. Misalnya, Anda mungkin perlu membandingkan performa arsitektur GKE multi-cluster yang berbeda untuk menilai apakah arsitektur tersebut sesuai dengan workload Anda.

Multi Cluster Ingress dan Penemuan Layanan Multi-Cluster

Multi Cluster Ingress adalah layanan yang dikelola Google yang memungkinkan Anda mengekspos workload, terlepas dari cluster GKE tempat deployment tersebut. Multi Cluster Ingress juga memungkinkan Anda mengonfigurasi load balancer bersama di berbagai cluster GKE dan lintas region. Untuk informasi selengkapnya tentang cara menggunakan Multi Cluster Ingress di lingkungan GKE multi-cluster, lihat Upgrade GKE multi-cluster menggunakan Multi Cluster Ingress dan Mendukung migrasi Anda dengan perluasan mesh Istio.

Penemuan Layanan Multi-Cluster adalah mekanisme penemuan layanan dan konektivitas lintas cluster berbasis Kubernetes untuk GKE. Penemuan Layanan Multi-Cluster melakukan build di resource Service Kubernetes untuk membantu aplikasi menemukan dan terhubung satu sama lain di seluruh batas cluster. Untuk mengevaluasi Multi Cluster Ingress dan Penemuan Layanan Multi-Cluster berdasarkan kriteria yang Anda tetapkan sebelumnya, gunakan daftar berikut, yang diberi nomor sesuai urutan kepentingan relatif:

  1. Solusi yang dikelola Google. Penemuan Layanan Multi-Cluster adalah fitur GKE yang terkelola sepenuhnya. API ini mengonfigurasi resource (zona dan data Cloud DNS, aturan firewall, serta Traffic Director) sehingga Anda tidak perlu mengelolanya.
  2. Antarmuka untuk berinteraksi dengan arsitektur. Layanan diekspor ke cluster lain menggunakan resource Kubernetes deklaratif yang disebut ServiceExport.
  3. Mengekspos layanan di luar lingkungan GKE. Saat Anda menggunakan Multi Cluster Ingress dan Penemuan Layanan Multi-Cluster, Anda dapat mengekspos workload di luar cluster GKE, di mana pun Anda men-deploy-nya.
  4. Komunikasi antar-cluster. Anda mengekspor Layanan yang ada ke cluster GKE lainnya dengan mendeklarasikan objek ServiceExport. Cluster GKE dalam fleet yang sama secara otomatis mengimpor Layanan yang Anda ekspor menggunakan objek ServiceExport. Penemuan Layanan Multi-Cluster menyiapkan alamat IP virtual untuk setiap Layanan yang diekspor. Penemuan Layanan Multi-Cluster secara otomatis mengonfigurasi resource Traffic Director, Cloud DNS, dan aturan firewall untuk menemukan dan terhubung ke Layanan menggunakan variasi sederhana dari konvensi DNS Kubernetes. Misalnya, untuk menjangkau Layanan my-svc, Anda dapat menggunakan nama my-svc.my-ns.svc.clusterset.local.
  5. Pengelolaan traffic. Penemuan Layanan Multi-Cluster mengonfigurasi konektivitas lapisan 3/4 sederhana dan mengandalkan DNS untuk penemuan layanan. API ini tidak memberikan kemampuan pengelolaan traffic apa pun.
  6. Menyediakan dan mengonfigurasi alat tambahan. Anda dapat menyiapkan Penemuan Layanan Multi-Cluster dengan mengaktifkan Google API. Anda tidak memerlukan penginstalan alat tambahan apa pun. Untuk informasi selengkapnya, lihat Memigrasikan container ke Google Cloud: Bermigrasi ke lingkungan GKE multi-cluster dengan Penemuan Layanan Multi-Cluster dan Multi-Cluster Ingress

Multi Cluster Ingress dan Anthos Service Mesh

Mesh layanan adalah pola arsitektur yang membantu mengatasi tantangan jaringan aplikasi yang didistribusikan. Tantangan ini meliputi penemuan layanan, load balancing, fault tolerance, kontrol traffic, kemampuan observasi, autentikasi, otorisasi, dan enkripsi saat transit. Implementasi mesh layanan standar terdiri dari bidang data dan bidang kontrol. Bidang data bertanggung jawab untuk menangani traffic secara langsung dan meneruskannya ke workload tujuan, biasanya dengan menggunakan proxy file bantuan. Bidang kontrol mengacu pada komponen yang mengonfigurasi bidang data.

Saat menerapkan pola mesh layanan di infrastruktur Anda, Anda dapat memilih di antara dua produk Google Cloud: Anthos Service Mesh dan Traffic Director. Kedua produk tersebut menyediakan bidang kontrol untuk mengonfigurasi jaringan lapisan aplikasi (L7) di berbagai cluster GKE. Anthos Service Mesh didasarkan pada Istio dan menawarkan API open source deklaratif. Traffic Director didasarkan pada kombinasi fitur load balancing Google, teknologi open source, dan menawarkan Google API imperatif.

Anthos Service Mesh adalah rangkaian alat yang dikelola Google yang memungkinkan Anda menghubungkan, mengelola, mengamankan, dan memantau workload Anda, terlepas dari cluster GKE tempat di-deploy ke dan tanpa mengubah kode aplikasi Anda. Untuk mengetahui informasi selengkapnya tentang cara menggunakan Anthos Service Mesh untuk menyiapkan mesh yang mencakup beberapa cluster GKE, baca Menambahkan cluster GKE ke Anthos Service Mesh. Untuk mengevaluasi Multi Cluster Ingress dan Anthos Service Mesh berdasarkan kriteria yang Anda tetapkan sebelumnya, gunakan daftar berikut, yang diberi nomor sesuai urutan kepentingan relatif:

  1. Solusi yang dikelola Google. Multi Cluster Ingress dan Anthos Service Mesh adalah produk yang terkelola sepenuhnya. Anda tidak perlu menyediakan produk tersebut karena Google yang mengelolanya untuk Anda.
  2. Antarmuka untuk berinteraksi dengan arsitektur. Anthos Service Mesh menggunakan Istio sebagai intinya. Anthos Service Mesh API mendukung konfigurasi deklaratif berdasarkan model resource Kubernetes.
  3. Mengekspos layanan di luar lingkungan GKE. Ingress gateways Multi Cluster Ingress dan Anthos Service Mesh memungkinkan Anda mengekspos workload Anda di luar cluster GKE.
  4. Komunikasi antar-cluster. Anthos Service Mesh menyiapkan saluran komunikasi yang aman secara langsung antara Pod, terlepas dari cluster tempatnya berjalan. Dengan penyiapan ini, Anda tidak perlu mengeluarkan upaya tambahan untuk menyediakan dan mengonfigurasi saluran komunikasi ini. Anthos Service Mesh menggunakan konsep fleet dan kesamaan layanan untuk memperluas penemuan layanan GKE untuk beberapa cluster. Oleh karena itu, Anda tidak perlu memodifikasi workload Anda untuk menemukan workload yang berjalan di cluster lain di mesh.
  5. Pengelolaan traffic. Anthos Service Mesh menyediakan fitur pengelolaan traffic lanjutan yang dapat Anda gunakan untuk mengontrol cara traffic masuk diamankan dan dirutekan ke workload. Misalnya, Anthos Service Mesh mendukung semua fitur pengelolaan traffic Istio, seperti: injeksi kesalahan, permintaan waktu tunggu dan percobaan ulang, pemutus sirkuit, pencerminan traffic, dan pergeseran traffic. Anda juga dapat menggunakan fitur pengelolaan traffic ini untuk menyederhanakan migrasi Anda ke lingkungan GKE baru. Misalnya, Anda dapat secara bertahap mengalihkan traffic dari lingkungan lama Anda ke lingkungan baru.
  6. Menyediakan dan mengonfigurasi alat tambahan. Untuk menggunakan Multi Cluster Ingress, Anda harus memenuhi prasyarat Penemuan Layanan Multi-Cluster, tetapi Anda tidak perlu menginstal alat tambahan di cluster GKE Anda. Untuk menggunakan Anthos Service Mesh, Anda harus menginstalnya di cluster.

Traffic Director

Traffic Director adalah bidang kontrol terkelola untuk jaringan aplikasi. Dengan API ini, Anda dapat menyediakan dan mengonfigurasi topologi mesh layanan yang lengkap dengan fitur pengelolaan traffic dan kemampuan observasi yang canggih. Untuk mengetahui informasi selengkapnya tentang Traffic Director, lihat Ringkasan Traffic Director dan fitur Traffic Director. Untuk menyediakan dan mengonfigurasi mesh layanan yang mencakup beberapa cluster GKE, Anda dapat menggunakan multi-cluster atau multi-lingkungan konfigurasi Traffic Director. Untuk mengevaluasi Traffic Director berdasarkan kriteria yang Anda tetapkan sebelumnya, gunakan daftar berikut, yang diberi nomor sesuai dengan tingkat kepentingan relatif:

  1. Solusi yang dikelola Google. Traffic Director adalah produk yang terkelola sepenuhnya. Anda tidak perlu menyediakan produk tersebut karena Google yang mengelolanya untuk Anda.
  2. Antarmuka untuk berinteraksi dengan arsitektur. Anda dapat mengonfigurasi Traffic Director menggunakan Konsol Google Cloud, Google Cloud CLI, Traffic Director API, atau alat seperti Terraform. Traffic Director mendukung model konfigurasi imperatif, dan dibuat berdasarkan produk dan teknologi open source, seperti xDS dan gRPC.
  3. Mengekspos layanan di luar lingkungan GKE. Traffic Director menyediakan dan mengonfigurasi load balancer untuk menangani traffic masuk dari luar jaringan layanan.
  4. Komunikasi antar-cluster. Bidang kontrol Traffic Director menawarkan API yang memungkinkan Anda mengelompokkan endpoint (seperti pod GKE pada beberapa cluster) ke dalam backend layanan. Backend ini kemudian dapat dirutekan dari klien lain di mesh. Traffic Director tidak terintegrasi langsung dengan penemuan layanan GKE, tetapi Anda dapat mengotomatiskan integrasi secara opsional menggunakan pengontrol open source seperti gke-autoneg-controller. Secara opsional, Anda juga dapat menggunakan Penemuan Layanan Multi-Cluster untuk memperluas penemuan layanan GKE ke beberapa cluster.
  5. Pengelolaan traffic. Traffic Director menyediakan fitur pengelolaan traffic lanjutan yang dapat digunakan untuk menyederhanakan migrasi Anda ke lingkungan GKE baru dan meningkatkan keandalan arsitektur Anda. Untuk informasi tentang cara mengonfigurasi fitur seperti perutean traffic terperinci, pemisahan traffic berbasis bobot, pencerminan traffic, dan load balancing yang disesuaikan , lihat Mengonfigurasi pengelolaan traffic lanjutan.
  6. Menyediakan dan mengonfigurasi alat tambahan. Traffic Director tidak berjalan di cluster GKE Anda. Untuk informasi tentang cara menyediakan dan mengonfigurasi Traffic Director, lihat Menyiapkan untuk penyiapan Traffic Director. Untuk mengonfigurasi Pod file bantuan yang diperlukan Traffic Director untuk menyertakan workload Anda dalam jaringan layanan, lihat Men-deploy Traffic Director dengan Envoy di Pod GKE.

Pembaruan data DNS yang dikelola sendiri dan Kubernetes

Jika tidak ingin menginstal software tambahan di cluster Anda dan Anda tidak memerlukan fitur yang disediakan mesh layanan, Anda dapat memilih Kubernetes dan opsi update data DNS yang dikelola sendiri.

Meskipun Anda dapat mengonfigurasi penemuan dan konektivitas antar-cluster menggunakan opsi ini, sebaiknya Anda memilih salah satu opsi lain yang dijelaskan dalam dokumen ini. Upaya yang diperlukan untuk mengoperasikan solusi yang dikelola sendiri jauh lebih besar daripada manfaat yang bisa Anda dapatkan. Pertimbangkan juga batasan penting berikut:

Saat Anda membuat Layanantype: LoadBalancer atau Ingress dalam cluster GKE, GKE secara otomatis membuat Load Balancer Jaringan dan Load Balancer HTTP(S) untuk mengekspos Layanan tersebut menggunakan alamat IP load balancer. Anda dapat menggunakan alamat IP load balancer untuk berkomunikasi dengan Layanan Anda. Namun, sebaiknya Anda tidak bergantung pada alamat IP dengan memetakan alamat IP tersebut ke data DNS menggunakan Cloud DNS, atau ke Endpoint Direktori Layanan yang dapat Anda buat kueri menggunakan DNS, dan Anda mengonfigurasi klien Anda untuk menggunakan data DNS tersebut. Anda dapat men-deploy beberapa instance Layanan, dan memetakan semua alamat IP load balancer yang dihasilkan ke data DNS atau endpoint Direktori Layanan terkait.

Untuk menghentikan instance Layanan, pertama-tama Anda hapus alamat IP load balancer terkait dari data DNS atau endpoint Direktori Layanan yang relevan. Kemudian, Anda pastikan cache DNS klien telah diperbarui, lalu hentikan Layanan.

Anda dapat mengonfigurasi workload Anda agar dapat berkomunikasi satu sama lain di berbagai cluster GKE. Untuk melakukannya, pertama-tama Anda ekspos layanan Anda di luar cluster menggunakan Load Balancer TCP/UDP Internal atau Load Balancer HTTP(S) Internal. Kemudian, Anda memetakan alamat IP load balancer ke data DNS atau endpoint Direktori Layanan. Terakhir, Anda membuat Layanan type: ExternalName yang mengarah ke data DNS atau endpoint Direktori Layanan tersebut di setiap cluster.

Anda juga dapat menggunakan pengontrol Ingress tambahan untuk membagikan satu load balancer dan data Cloud DNS atau endpoint Direktori Layanan dengan beberapa workload. Misalnya, jika Anda menyediakan pengontrol Ingress dalam cluster, Anda dapat mengonfigurasinya untuk mengalihkan permintaan yang masuk ke load balancer yang dibuat GKE untuk pengontrol Ingress tersebut ke beberapa Layanan. Dengan menggunakan pengontrol Ingress tambahan, Anda dapat mengurangi jumlah data DNS atau endpoint Direktori Layanan yang perlu Anda kelola.

Untuk mengevaluasi pembaruan data DNS dan Kubernetes yang dikelola sendiri berdasarkan kriteria yang Anda tetapkan sebelumnya, gunakan daftar berikut, yang diberi nomor sesuai urutan kepentingan relatif:

  1. Solusi yang dikelola Google. Anda mengelola sendiri objek Kubernetes yang merupakan bagian dari solusi ini. Cloud DNS, Direktori Layanan, dan Load Balancing adalah layanan yang dikelola Google.
  2. Antarmuka untuk berinteraksi dengan arsitektur. GKE menggunakan Kubernetes sebagai intinya, dan ini mendukung model konfigurasi imperatif dan deklaratif.
  3. Mengekspos layanan di luar lingkungan GKE. Anda dapat menggunakan data DNS, Endpoint Direktori Layanan, dan load balancer untuk mengekspos layanan ke klien di luar cluster GKE Anda.
  4. Komunikasi antar-cluster. Layanan type: ExternalName memungkinkan Anda menentukan endpoint yang mengarah ke layanan yang di-deploy di cluster GKE lain. Dengan konfigurasi ini, layanan dapat berkomunikasi satu sama lain seolah-olah layanan di-deploy di cluster yang sama.
  5. Pengelolaan traffic. Solusi ini tidak menawarkan kemampuan pengelolaan traffic tambahan selain yang sudah ditawarkan oleh Kubernetes dan GKE. Misalnya, opsi ini tidak mendukung partisi traffic antara cluster yang berbeda.
  6. Menyediakan dan mengonfigurasi alat tambahan. Opsi ini tidak memerlukan software tambahan untuk disediakan dan dikonfigurasi di cluster GKE Anda. Secara opsional, Anda dapat menginstal pengontrol Ingress.

Memilih arsitektur

Setelah Anda menetapkan nilai pada setiap kriteria untuk setiap opsi, Anda menghitung total skor dari setiap opsi. Untuk menghitung total skor dari setiap opsi, Anda menambahkan semua peringkat untuk opsi desain tersebut berdasarkan kriteria. Misalnya, jika suatu lingkungan memiliki skor 10 untuk suatu kriteria, dan 6 terhadap kriteria lain, maka total skor opsi tersebut adalah 16.

Anda juga dapat menetapkan bobot yang berbeda untuk skor tersebut terhadap setiap kriteria, sehingga Anda dapat menunjukkan pentingnya setiap kriteria untuk evaluasi Anda. Misalnya, jika solusi yang dikelola Google lebih penting daripada dukungan arsitektur workload terdistribusi dalam evaluasi Anda, Anda dapat menentukan pengganda untuk mencerminkan bahwa: pengganda 1.0 untuk solusi yang dikelola Google dan pengganda 0.7 untuk arsitektur beban kerja terdistribusi. Anda kemudian menggunakan pengganda ini untuk menghitung total skor dari suatu opsi.

Setelah Anda menghitung total skor setiap lingkungan yang Anda evaluasi, atur lingkungan berdasarkan total skornya, dalam urutan menurun. Kemudian, pilih opsi dengan skor tertinggi sebagai lingkungan pilihan Anda.

Ada beberapa cara untuk merepresentasikan data ini—misalnya, Anda dapat memvisualisasikan hasil dengan diagram yang sesuai untuk merepresentasikan data multi-variasi, seperti diagram radar.

Memigrasikan data dari lingkungan lama Anda ke lingkungan baru

Untuk mendapatkan panduan tentang cara memigrasikan data dari lingkungan lama Anda ke lingkungan baru, baca artikel Memigrasikan Kubernetes ke GKE, Memigrasikan data dari lingkungan lama Anda ke lingkungan baru.

Men-deploy workload Anda

Untuk mendapatkan panduan tentang cara memigrasikan data dari lingkungan lama Anda ke lingkungan baru, lihat Men-deploy workload Anda.

Dengan semua arsitektur yang diusulkan dalam dokumen ini, Anda dapat memigrasikan workload Anda dari lingkungan GKE yang ada ke lingkungan multi-cluster baru tanpa periode nonaktif atau periode cut-over. Untuk memigrasikan workload Anda tanpa periode nonaktif, lakukan hal berikut:

  1. Integrasikan cluster GKE lama yang sudah ada di lingkungan GKE multi-cluster yang baru untuk sementara.
  2. Deploy instance workload Anda di lingkungan multi-cluster yang baru.
  3. Secara bertahap migrasikan traffic dari lingkungan yang ada, sehingga Anda dapat memigrasikan workload Anda secara bertahap ke cluster GKE baru, lalu menghentikan cluster GKE lama.

Menyelesaikan deployment

Setelah Anda menyediakan dan mengonfigurasi platform runtime dan lingkungan Anda, selesaikan aktivitas yang dijelaskan dalam Memigrasikan Kubernetes ke GKE, Men-deploy workload Anda.

Mengoptimalkan lingkungan Anda

Pengoptimalan adalah fase terakhir dari migrasi Anda. Pada fase ini, Anda membuat lingkungan Anda lebih efisien dari sebelumnya. Untuk mengoptimalkan lingkungan Anda, selesaikan beberapa iterasi dari loop berulang berikut hingga lingkungan Anda memenuhi persyaratan pengoptimalan Anda:

  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.

Untuk melakukan pengoptimalan lingkungan GKE Anda, lihat Memigrasi Kubernetes ke GKE, Mengoptimalkan lingkungan Anda.

Langkah selanjutnya