Cloud Service Mesh dan Traffic Director kini bergabung menjadi Cloud Service Mesh. Untuk mengetahui informasi selengkapnya, lihat ringkasan Cloud Service Mesh.

Halaman ini diterjemahkan oleh Cloud Translation API.

Menyelesaikan masalah Layanan Kanonik di Cloud Service Mesh

Catatan: Layanan Kanonik didukung secara otomatis di Cloud Service Mesh versi 1.6.8 dan yang lebih baru.

Bagian ini menjelaskan masalah umum Cloud Service Mesh dan cara mengatasinya. Jika Anda memerlukan bantuan tambahan, lihat Mendapatkan dukungan.

Cluster di mesh Anda menjalankan Cloud Service Mesh versi lama

Jika ada cluster Anda yang menjalankan Cloud Service Mesh versi sebelumnya (<1.6.8) atau cluster menjalankan Cloud Service Mesh dengan pengontrol Layanan Kanonik dinonaktifkan, cluster tersebut (dan layanan yang berjalan di dalamnya) tidak akan muncul di UI Service Mesh. Untuk menggunakan Layanan Kanonis, Anda harus mengupgrade setiap cluster ke Cloud Service Mesh 1.6.8 atau yang lebih tinggi dan menggunakan opsi penginstalan default yang menyertakan pengontrol Layanan Kanonis. Untuk mengetahui informasi selengkapnya, lihat Mengupgrade Cloud Service Mesh ke versi terbaru jika cluster Anda berada di GKE atau Mengupgrade Cloud Service Mesh di lokasi Anda.

Atau, jika tidak ingin menginstal pengontrol di cluster, Anda dapat mengaktifkan Pengontrol Layanan Kanonik Terkelola (saat ini dalam Pratinjau) untuk mesh.

Untuk informasi selengkapnya tentang cara mengaktifkan pengontrol Layanan Canonical, lihat Mengaktifkan pengontrol Layanan Canonical.

Cloud Service Mesh tidak diinstal di cluster

Jika Cloud Service Mesh tidak diinstal di cluster Anda, cluster tersebut tidak akan muncul di UI Service Mesh. Untuk mengetahui informasi selengkapnya tentang cara menginstal Cloud Service Mesh, lihat dokumentasi Cloud Service Mesh.

Anda tidak login ke cluster on-premise

Jika memiliki cluster on-premise di mesh dan tidak login ke cluster, Anda tidak akan dapat melihat layanan yang sesuai dengan cluster tersebut. Untuk melihat layanan tersebut di dasbor, Anda harus login ke cluster. Untuk informasi selengkapnya tentang Login ke cluster, lihat Login ke cluster dari Cloud Console.

Cluster on-premise Anda tidak dapat dijangkau

Jika Anda memiliki cluster on-premise dalam mesh dan cluster tersebut tidak dapat dijangkau melalui agen koneksi, Anda tidak akan dapat melihat layanan yang sesuai dengan cluster tersebut. Untuk melihat layanan tersebut di dasbor, pastikan cluster Anda berjalan dan terhubung ke Google Cloud. Untuk informasi selengkapnya tentang cara menghubungkan cluster ke Google Cloud, lihat Ringkasan Menghubungkan.

Layanan dengan SLO yang ditentukan tidak dipetakan 1:1 dengan Layanan Kanonik

Sebelum beralih ke Layanan Kanonik, Cloud Service Mesh menampilkan dasbor untuk Layanan Kubernetes. Meskipun Layanan Kubernetes dan Layanan Kanonik default sering kali selaras, ada kemungkinan Layanan Kubernetes tidak dapat otomatis dicocokkan dengan Layanan Kanonik yang sesuai atau batas Layanan Kanonik default tidak diinginkan.

Jika Anda telah menyiapkan Tujuan Tingkat Layanan (SLO) di layanan yang ada yang tidak dapat otomatis dicocokkan dengan Layanan Kanonik default, SLO tersebut tidak dapat dimigrasikan. Untuk mulai menggunakan Layanan Kanonik, Anda harus menghapus SLO untuk layanan yang bermasalah. Jika mau, Anda dapat membuat SLO baru untuk Layanan Kanonis yang paling cocok dengan layanan tersebut sebelum menghapus SLO lama.

Dasbor saya tidak memiliki konten yang saya harapkan

Dasbor layanan Service Mesh masing-masing dicakup untuk Layanan Kanonis di mesh layanan Anda, dengan Layanan Kanonis adalah konsep layanan logis tingkat tinggi yang mencakup semua workload, region, dll. yang relevan.

Secara default, label yang ada di setiap instance beban kerja (Pod atau WorkloadEntry) menentukan Layanan Kanonik dan mengikuti aturan ini dalam prioritas menurun:

Label service.istio.io/canonical-name telah ditetapkan secara eksplisit. Tidak ada tindakan lebih lanjut yang dilakukan.
Jika tidak, label service.istio.io/canonical-name akan ditambahkan dan nilainya ditetapkan ke label app.kubernetes.io/name.
Jika tidak, label service.istio.io/canonical-name akan ditambahkan dan nilainya ditetapkan ke label app.
Jika tidak, label service.istio.io/canonical-name akan ditambahkan dan nilainya ditetapkan ke name beban kerja pemilik. "Beban kerja pemilik" dalam hal ini jika Pod di-deploy sendiri, atau Deployment, StatefulSet, dll. jika menggunakan orkestrasi tingkat lebih tinggi.

Untuk sebagian besar pengguna idiomatik Kubernetes dan Kube Run / Knative, aturan ini dipetakan secara langsung ke cara Anda mengelola layanan dan beban kerja.

Namun, dalam beberapa kasus penggunaan yang lebih kustom atau lebih kompleks, heuristik default tidak menangkap layanan Anda dengan tepat, dan sebagai hasilnya, dasbor Cloud Service Mesh yang Anda lihat tidak menyertakan konten yang Anda harapkan.

Hal ini dapat diperbaiki dengan menentukan cakupan Layanan Kanonik secara manual.

Menentukan cakupan layanan secara manual

Jika memungkinkan, sebaiknya gunakan mekanisme pengelompokan default otomatis. Namun, jika ingin mengganti pengelompokan default ini, Anda dapat melakukannya dengan menerapkan label Kubernetes service.istio.io/canonical-name ke konfigurasi WorkloadEntry dan Pod Kubernetes.

Untuk mengetahui detailnya, lihat menentukan Layanan Kanonik secara manual.

Menyelesaikan masalah pengontrol kanonis terkelola

1. Periksa Status Fitur: Jalankan perintah berikut, dengan FLEET_PROJECT_ID adalah ID project Host Flotte Anda. Umumnya, FLEET_PROJECT_ID dibuat secara default dan memiliki nama yang sama dengan project.

  gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Contoh output:

      membershipStates:
        projects/<project-number>/locations/<location>/memberships/<membership-name>:
          state:
            code: OK
            description: 
              Revision(s) ready for use: istiod-asm-183-2.
              All Canonical Services have been reconciled successfully.

2. Ambil tindakan berdasarkan state.code:

Pada output status fitur, periksa status cluster Anda. Periksa nilai state.code, yang membantu memahami status CSC terkelola saat ini. Berdasarkan nilai state.code, terapkan tindakan yang sesuai:

MISSING:
1. Tunggu selama satu jam untuk mengantisipasi potensi penundaan inisialisasi.
2. Jalankan kembali perintah gcloud container fleet mesh describe --project <FLEET_PROJECT_ID>. Jika state.code masih tidak ada, hubungi Dukungan Google Cloud untuk mendapatkan bantuan.
WARNING/ERROR:
1. Periksa servicemesh.conditions untuk mengetahui informasi error mendetail.
2. Jika kondisi CANONICAL_SERVICE_ERROR ditemukan, Pengontrol Layanan Kanonik terkelola mengalami masalah. Jika tidak, masalahnya mungkin bersifat eksternal terhadap Pengontrol Layanan Canonical.
3. Dalam kedua skenario tersebut, hubungi Dukungan Google Cloud untuk pemecahan masalah lebih lanjut
OK: Lihat tabel berikut untuk tindakan berdasarkan teks state.description:

State.Description	Tindakan yang Diperlukan
Semua Layanan Kanonik telah berhasil direkonsiliasi	CSC beroperasi seperti yang diharapkan. Tidak diperlukan intervensi lebih lanjut.
Pengontrol Layanan Kanonik Terkelola memberikan hasil ke pengontrol dalam cluster	Ikuti panduan untuk bermigrasi dari pengontrol dalam cluster
Tidak ada informasi spesifik tentang layanan kanonis yang disebutkan dalam `state.description`	Jika cluster Anda tidak memiliki entri layanan atau pod yang dimasukkan sidecar, situasi ini dapat terjadi. Untuk mengonfirmasi status operasional pengontrol kanonis terkelola, ikuti langkah-langkah yang diuraikan di bagian pengontrol terkelola beroperasi. Jika layanan kanonis yang diperlukan masih belum ada, pastikan layanan kanonis Anda ditentukan dengan benar. Lihat: Menentukan layanan kanonis .