Bidang kontrol terkelola

<0x0

ISTIOD Anda harus memodernisasi semua fleet ISTIOD terkelola ke penerapan TRAFFIC_DIRECTOR.

Dokumen ini menjelaskan perbedaan arsitektur antara penerapan bidang kontrol ISTIOD yang tidak digunakan lagi dan penerapan bidang kontrol TRAFFIC_DIRECTOR modern Google, serta menguraikan langkah-langkah selanjutnya jika cluster Anda masih menggunakan bidang kontrol yang tidak digunakan lagi.

Ringkasan bidang kontrol

Dalam mesh layanan, bidang kontrol menyediakan pengelolaan traffic, pengelolaan proxy saat proxy Envoy digunakan, dan kemampuan jaringan lainnya.

Cloud Service Mesh yang menggunakan Istio API di cluster GKE menyediakan penerapan Istio API yang didukung sepenuhnya. API diimplementasikan dan didukung oleh bidang kontrol TRAFFIC_DIRECTOR yang terkelola sepenuhnya dan terintegrasi dengan Cloud Networking. Sebelumnya, dua penerapan bidang kontrol tambahan didukung:

• Implementasi terkelola ISTIOD yang tidak digunakan lagi, yang menjalankan bidang kontrol khusus satu cluster.
• Implementasi dalam cluster ISTIOD yangtidak digunakan lagi, yang menjalankan komponen bidang kontrol yang dikelola pelanggan di dalam cluster Anda.

Karakteristik operasional bidang kontrol TRAFFIC_DIRECTOR

Cloud Service Mesh dengan bidang kontrol TRAFFIC_DIRECTOR menggunakan infrastruktur jaringan terkelola Google Cloud, bukan instance bidang kontrol per-cluster.

API Istio (CRD) dan konfigurasi xDS yang dikirim ke sidecar Envoy tetap kompatibel, tetapi Anda harus mengharapkan karakteristik operasional berikut:

• Penyebaran konfigurasi kebijakan dan layanan: Saat Anda membuat layanan baru atau memperbarui kebijakan perutean dan keamanan, konfigurasi akan divalidasi dan disebarkan di seluruh sistem Google Cloud sebelum diterapkan pada sidecar. Akibatnya, propagasi kebijakan dan layanan awal memerlukan waktu lebih lama dibandingkan dengan bidang kontrol dalam cluster atau ISTIOD. Untuk panduan tentang cara mengoptimalkan alur kerja deployment, lihat Penyebaran konfigurasi.
• Penskalaan Pod dan update endpoint: Perubahan pada endpoint workload—seperti Pod baru yang dibuat oleh penskalaan otomatis Pod horizontal atau Pod yang dimulai ulang dengan alamat IP baru—dipropagasi langsung oleh bidang kontrol tanpa latensi yang terkait dengan update kebijakan. Pod yang ada yang mengambil konfigurasi yang ada akan dimulai tanpa penundaan.
• Penemuan endpoint multi-cluster: Dalam mesh multi-cluster, cluster membagikan endpointnya secara langsung melalui Google Cloud , bukan mensinkronkannya secara point-to-point di antara setiap kombinasi cluster. Hal ini memastikan status endpoint lintas cluster berkonvergensi lebih cepat dan konsisten saat mesh Anda diskalakan.

Apa pengaruhnya bagi Anda?

Langkah berikutnya bergantung pada implementasi bidang kontrol Cloud Service Mesh yang digunakan oleh cluster Anda:

• Bidang kontrol terkelola (penerapan TRAFFIC_DIRECTOR):
  • Anda sudah menggunakan arsitektur yang dapat diskalakan secara global saat ini (baik yang dikonfigurasi menggunakan Istio API, Gateway API, atau Google Cloud API).
  • Anda tidak perlu melakukan tindakan apa pun.
• Bidang kontrol terkelola (penerapan ISTIOD):
  • Penerapan ini tidak digunakan lagi.
  • Anda harus mengambil tindakan untuk memeriksa fleet Anda terkait pemblokir kompatibilitas, memperbarui konfigurasi, dan menyelesaikan modernisasi bidang kontrol terkelola, atau menghapus instalasi Cloud Service Mesh terkelola.
• Bidang kontrol dalam cluster:
  • Bidang kontrol dalam cluster di GKE tidak digunakan lagi.
  • Penginstalan dalam cluster tidak dapat dimodernisasi di tempat. Anda harus mengambil tindakan untuk bermigrasi dari bidang kontrol dalam cluster ke bidang kontrol terkelola di cluster baru atau meng-uninstal Cloud Service Mesh.

Modernisasi bidang kontrol untuk Cloud Service Mesh terkelola dengan penerapan ISTIOD

Semua fleet terkelola yang menjalankan penerapan ISTIOD yang tidak digunakan lagi harus menyelesaikan modernisasi ke penerapan TRAFFIC_DIRECTOR sebelum batas waktu akhir dukungan yang ditentukan dalam pemberitahuan penghentian penggunaan. Anda dapat memodernisasi armada menggunakan modernisasi yang dipicu pelanggan (direkomendasikan untuk kontrol per-cluster dan pengalihan traffic bertahap) atau modernisasi yang didorong Google (peluncuran otomatis untuk armada yang memenuhi syarat).

Untuk mengetahui petunjuk langkah demi langkah, lihat Modernisasi bidang kontrol terkelola.

Memeriksa kompatibilitas bidang kontrol

Untuk mengevaluasi perangkat Anda berdasarkan fitur yang didukung dan mengidentifikasi pemblokir konfigurasi sebelum melakukan modernisasi, lihat:

• Memahami kompatibilitas Cloud Service Mesh
• Pembaruan konfigurasi untuk modernisasi

Lampiran: Jadwal peluncuran dan penghentian penggunaan bidang kontrol

Transisi dari bidang kontrol ISTIOD ke penerapan bidang kontrol TRAFFIC_DIRECTOR terkelola telah mengikuti linimasa ini:

• 23 Mei 2024: Anthos Service Mesh dan Traffic Director digabungkan menjadi Cloud Service Mesh, yang memperkenalkan penerapan bidang kontrol TRAFFIC_DIRECTOR untuk Istio API.
• 1 Juli 2024: Kumpulan instance baru yang di-onboarding ke Cloud Service Mesh terkelola mulai menerima penerapan TRAFFIC_DIRECTOR secara default.
• 8 September 2024: Penyediaan penerapan ISTIOD untuk armada baru telah berakhir untuk ketersediaan umum (dengan pengecualian sementara untuk organisasi tertentu dalam daftar yang diizinkan).
• 28 September 2026: Penghentian penggunaan resmi diumumkan untuk penerapan bidang kontrol ISTIOD terkelola dan bidang kontrol dalam cluster di GKE.