Mendapatkan dukungan

Tujuan dukungan utama Google adalah menyelesaikan insiden produksi secepat mungkin mungkin. Memahami konfigurasi Anda, menganalisis log dan metrik, serta berkolaborasi dengan partner membantu kami memecahkan insiden dengan cepat.

Google Cloud menawarkan berbagai paket dukungan untuk mengakomodasi dukungan Anda mereka. Semua paket Dukungan Google Cloud mencakup dukungan untuk Edisi Google Kubernetes Engine (GKE) Enterprise dan Google Distributed Cloud. Jika Anda sudah memiliki paket Dukungan Google Cloud, maka Anda sudah memiliki untuk GKE Enterprise dan Google Distributed Cloud.

Untuk informasi selengkapnya, lihat Dokumentasi Dukungan Google Cloud.

Persyaratan untuk dukungan Google Distributed Cloud

Untuk memecahkan masalah insiden yang penting bagi bisnis secara efektif:

Alat dukungan

Untuk memecahkan masalah insiden Google Distributed Cloud, Dukungan Google Cloud bergantung pada tiga bagian informasi:

Konfigurasi lingkungan Anda

Saat Anda membuka kasus dukungan, menjalankan perintah berikut akan memberikan tentang penyiapan cluster Anda:

  • Untuk semua jenis cluster, jalankan perintah bmctl check cluster --snapshot untuk mengambil informasi tentang Kubernetes dan node Anda. Lampirkan hasil file tar ke kasus dukungan.

  • Untuk cluster admin, hybrid, dan mandiri, jalankan bmctl check cluster untuk memeriksa status respons cluster dan node. Lampirkan log yang dihasilkan ke kasus dukungan. Tema tersebut harus ada di bawah Direktori bmctl-workspace/[CLUSTER_NAME]/log/check-cluster-[TIMESTAMP].

  • Untuk cluster pengguna, buat file YAML health check terlebih dahulu dengan cluster dan namespace, lalu menerapkan file tersebut pada admin yang sesuai :

    1. Buat file YAML dengan properti healthcheck berikut. Berikut contoh konten untuk cluster bernama user1 di cluster-user1 ruang nama:

      apiVersion: baremetal.cluster.gke.io/v1
      kind: HealthCheck
      metadata:
        generateName: healthcheck-
        namespace: cluster-user1
      spec:
        clusterName: user1
      
    2. Setelah membuat file YAML, terapkan resource kustom di bagian admin yang mengelola cluster pengguna dengan perintah kubectl. Berikut ini contoh perintah menggunakan {i>file<i} YAML yang dibuat di langkah waktu ini. Dalam contoh, variabel ADMIN_KUBECONFIG menentukan jalur ke file kubeconfig cluster admin:

      kubectl --kubeconfig ADMIN_KUBECONFIG create -f healthcheck-user1.yaml
      

      Perintah tersebut menampilkan respons berikut:

      healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf created
      
    3. Tunggu hingga tugas health check selesai dengan melakukan pengujian untuk melihat apakah tugas health check telah selesai merekonsiliasi. Dalam kasus contoh sebelumnya, nama tugas health check healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf. Berikut adalah pengujian contoh dengan perintah kubectl yang menunggu 30 menit tugas health check yang harus diselesaikan:

      kubectl --kubeconfig ADMIN_KUBECONFIG wait healthcheck healthcheck-7c4qf \
          -n cluster-user1 --for=condition=Reconciling=False --timeout=30m
      

      Setelah selesai, perintah ini akan menampilkan:

      healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf condition met
      

      Anda dapat melihat hasil tugas health check dengan perintah berikut:

      kubectl --kubeconfig ADMIN_KUBECONFIG get healthcheck healthcheck-7c4qf \
          -n cluster-user1
      

      Perintah tersebut menampilkan hasil berikut:

      NAME                PASS   AGE
      healthcheck-7c4qf   true   17m
      
    4. Kumpulkan semua log pod tugas health check ke dalam file lokal dengan Perintah kubectl. Berikut ini contoh yang menggunakan sampel respons sebelumnya periksa tugas:

      kubectl --kubeconfig ADMIN_KUBECONFIG logs -n cluster-user1 \
          -l baremetal.cluster.gke.io/check-name=healthcheck-7c4qf --tail=-1 > \
          healthcheck-7c4qf.log
      

Log cluster

Saat Anda membuat cluster Google Distributed Cloud baru, Cloud Logging agen diaktifkan secara default dan hanya mencakup komponen level sistem. Ini mereplikasi log tingkat sistem ke project Google Cloud yang terkait dengan gugus ini. Log tingkat sistem berasal dari pod Kubernetes di berikut ini namespace:

  • kube-system
  • gke-system
  • gke-connect
  • istio-system
  • config-management-system
  • gatekeeper-system
  • cnrm-system
  • knative-serving

Log dapat dikueri dari Cloud Logging konsol.

Untuk detail lebih lanjut, lihat Pencatatan log dan Pemantauan.

Google Cloud CLI dan akses cluster jarak jauh

Jika Anda membuka kasus dukungan, Cloud Customer Care mungkin meminta akses hanya baca jarak jauh akses ke cluster Anda untuk membantu mendiagnosis dan menyelesaikan masalah secara lebih efektif. Agar tim dukungan memiliki akses yang memadai untuk memecahkan masalah cluster Anda masalah dari jarak jauh, pastikan Anda telah menginstal dan memperbarui ke versi terbaru dari Google Cloud CLI. Google Cloud CLI harus memiliki 401.0.0 atau yang lebih tinggi untuk memberi Cloud Customer Care izin yang diperlukan. Saran dari kami memperbarui Google Cloud CLI secara rutin untuk mendapatkan izin tambahan dan penyempurnaan.

Untuk menginstal komponen terbaru gcloud CLI, gunakan perintah gcloud components update. Untuk selengkapnya informasi tentang cara memberikan akses hanya baca jarak jauh Cloud Customer Care ke cluster, lihat Dukungan Google Cloud untuk cluster.

Metrik cluster

Selain log, agen Cloud Monitoring juga merekam metrik. Ini mereplikasi metrik tingkat sistem ke project Google Cloud yang terkait dengan cluster. Metrik tingkat sistem berasal dari pod Kubernetes yang berjalan di {i>namespace<i} yang sama terdaftar dalam Log.

Untuk detail lebih lanjut, lihat Pencatatan log dan Pemantauan.

Cara kami memecahkan masalah lingkungan Anda

Berikut adalah contoh insiden dukungan pada umumnya:

  1. Administrator cluster membuka kasus dukungan di Konsol Google Cloud Pusat Dukungan Google Cloud, dan memilih edisi Google Kubernetes Engine (GKE) Enterprise dan Google Distributed Cloud sebagai Kategori dan Komponen. Mereka masuk informasi yang diperlukan dan lampirkan output perintah bmctl yang relevan pada kasus tersebut.

  2. Kasus dukungan diteruskan ke Teknisi Dukungan Teknis yang memiliki spesialisasi dalam Google Distributed Cloud.

  3. Engineer dukungan memeriksa konten snapshot untuk mendapatkan konteks lingkungan.

  4. Engineer dukungan memeriksa log dan metrik di Google Cloud project Anda, dengan memasukkan ID kasus dukungan sebagai justifikasi bisnis, dicatat secara internal.

  5. Engineer dukungan merespons kasus tersebut dengan memberikan penilaian rekomendasi. Engineer dukungan dan pengguna melanjutkan pemecahan masalah sampai mereka menghasilkan suatu resolusi.

Apa saja yang didukung oleh Google?

Umumnya, tim Dukungan {i>Cloud<i} mendukung semua komponen perangkat lunak yang dikirimkan bagian dari Google Distributed Cloud dan Cloud Service Mesh, Config Sync, dan Config Controller. Lihat tabel berikut untuk daftar lebih lengkap terkait apa saja yang didukung dan tidak didukung:

Didukung Google Cloud Tidak didukung
Kubernetes dan runtime container Pilihan pelanggan untuk load balancer (load balancing manual)
Connect dan Agen Connect Kode pelanggan (lihat Dukungan Developer)
Google Cloud Operations, Monitoring, Logging, dan agen Pilihan sistem operasi pilihan pelanggan
Load balancer yang dipaket Server, penyimpanan, dan jaringan fisik atau virtual
Pengontrol ingress DNS eksternal, DHCP, dan sistem identitas
GKE Identity Service
Mesh Layanan Cloud
Pengontrol Kebijakan
Config Sync
Pengontrol Konfigurasi

Kebijakan Dukungan Versi

Dukungan untuk Google Distributed Cloud mengikuti Kebijakan Dukungan GKE Enterprise. Google mendukung setiap versi minor Google Distributed Cloud untuk:

  • 12 bulan setelah rilis awal versi minor.
  • Rilis versi minor ketiga berikutnya.
Untuk mengetahui tanggal rilis minor terbaru untuk GKE Enterprise dan tanggal akhir siklus proses yang paling awal, lihat Periode dukungan GKE Enterprise.

Untuk mengetahui daftar versi Google Distributed Cloud yang didukung dan tidak didukung, lihat Pembuatan Versi.

Untuk informasi versi terkait upgrade cluster, lihat Aturan versi untuk upgrade.

Model Tanggung Jawab Bersama

Menjalankan aplikasi produksi yang penting bagi bisnis di Google Distributed Cloud mengharuskan beberapa pihak untuk membawa tanggung jawab yang berbeda. Meskipun bukan daftar lengkapnya, bagian berikut mencantumkan peran dan tanggung jawab.

Tanggung jawab Google

  • Pemeliharaan dan distribusi paket software Google Distributed Cloud.
  • Memberi tahu pengguna tentang upgrade yang tersedia untuk Google Distributed Cloud, dan membuat skrip {i>upgrade <i}untuk versi sebelumnya; Google Distributed Cloud hanya mendukung upgrade berurutan (contoh: 1.2 → 1.3 → 1.4 dan bukan 1.2 → 1,4).
  • Mengoperasikan layanan Connect dan Cloud Operations.
  • Pemecahan masalah, memberikan solusi, dan memperbaiki akar masalah dari masalah terkait komponen yang disediakan Google

Tanggung jawab pengguna

  • Administrasi sistem secara keseluruhan untuk cluster lokal.
  • Mempertahankan beban kerja aplikasi apa pun yang di-deploy di cluster.
  • Menjalankan, memelihara, dan mem-patch infrastruktur pusat data, termasuk jaringan, server, sistem operasi, penyimpanan, dan konektivitas ke Google Cloud.
  • Menjalankan, memelihara, dan membuat patch load balancer jaringan jika dilakukan secara manual opsi penyeimbang dipilih.
  • Mengupgrade versi Google Distributed Cloud secara berkala.
  • Memantau cluster dan aplikasi, serta merespons setiap insiden.
  • Memastikan agen Cloud Operations di-deploy ke cluster.
  • Memberikan detail lingkungan kepada Google untuk tujuan pemecahan masalah.

Dukungan Developer

Google tidak memberikan dukungan khusus untuk workload aplikasi Anda. Namun, kami memberikan dukungan upaya terbaik kepada developer untuk memastikan bahwa developer Anda dapat menjalankan aplikasi di Google Distributed Cloud. Kami yakin bahwa interaksi dengan audiens selama pengembangan dapat mencegah terjadinya insiden kritis pada tahapan deployment.

Upaya terbaik Dukungan Developer ini tersedia bagi pelanggan dengan semua {i>support<i} dan diperlakukan sebagai prioritas P3 untuk masalah yang memblokir peluncuran, atau prioritas P4 untuk konsultasi umum. Dalam klasifikasi ini, prioritas tingkat 0 adalah prioritas tertinggi.