Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Mendapatkan dukungan

Tujuan dukungan utama Google adalah menyelesaikan insiden produksi secepat mungkin. Kami melakukannya dengan memahami konfigurasi Anda, menganalisis log dan metrik, serta berkolaborasi dengan partner untuk menyelesaikan insiden dengan cepat.

Cloud Customer Care menawarkan berbagai paket dukungan untuk mengakomodasi kebutuhan dukungan Anda. Semua paket Cloud Customer Care mencakup dukungan untuk GKE dan Google Distributed Cloud. Jika Anda memiliki paket dukungan Cloud Customer Care yang sudah ada, berarti Anda sudah memiliki dukungan untuk GKE dan Google Distributed Cloud.

Untuk mengetahui informasi selengkapnya, lihat hub Cloud Customer Care.

Persyaratan untuk dukungan Google Distributed Cloud

Untuk memecahkan masalah insiden yang penting bagi bisnis secara efektif, Anda harus melakukan hal berikut:

Pastikan lingkungan Anda saat ini berada dalam jangka waktu akhir dukungan yang dipublikasikan. Untuk mengetahui informasi selengkapnya, lihat bagian Kebijakan Dukungan Versi.
Aktifkan Cloud Logging dan Cloud Monitoring untuk komponen sistem. Untuk mengetahui informasi selengkapnya, lihat bagian Alat dukungan berikut.

Alat dukungan

Untuk memecahkan masalah insiden Google Distributed Cloud, Cloud Customer Care mengandalkan tiga informasi:

Konfigurasi lingkungan Anda
Log dari cluster Anda
Metrik dari cluster Anda

Konfigurasi lingkungan Anda

Saat membuka kasus dukungan, berikan informasi utama tentang penyiapan cluster Anda dengan menjalankan perintah berikut:

Untuk semua jenis cluster Anda, ambil informasi tentang Kubernetes dan node Anda dengan menjalankan perintah bmctl check cluster --snapshot. Lampirkan file tar yang dihasilkan ke kasus dukungan.
Untuk cluster admin, hybrid, dan mandiri, periksa status kesehatan cluster dan node dengan menjalankan perintah bmctl check cluster. Lampirkan log yang dihasilkan ke kasus dukungan. Log harus ada di direktori bmctl-workspace/[CLUSTER_NAME]/log/check-cluster-[TIMESTAMP].
Untuk cluster pengguna, buat terlebih dahulu file YAML health check dengan nama dan namespace cluster, lalu terapkan file di cluster admin yang sesuai:
1. Buat file YAML dengan properti healthcheck berikut. Berikut adalah contoh konten untuk cluster bernama user1 di cluster-user1 namespace:
```
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 cluster admin yang mengelola cluster pengguna menggunakan perintah kubectl. Berikut adalah contoh perintah yang menggunakan file YAML yang dibuat pada langkah sebelumnya. Dalam contoh ini, variabel ADMIN_KUBECONFIG menentukan jalur ke file kubeconfig cluster admin:
```
kubectl --kubeconfig ADMIN_KUBECONFIG create -f healthcheck-user1.yaml
```
  Perintah akan menampilkan respons berikut:
```
healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf created
```
3. Tunggu hingga tugas health check selesai. Untuk melakukannya, uji apakah tugas health check selesai melakukan rekonsiliasi. Dalam contoh kasus sebelumnya, nama tugas health check adalah healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf. Berikut adalah contoh pengujian yang menggunakan perintah kubectl, dan menunggu 30 menit hingga tugas health check selesai:
```
kubectl --kubeconfig ADMIN_KUBECONFIG wait healthcheck healthcheck-7c4qf \
    -n cluster-user1 --for=condition=Reconciling=False --timeout=30m
```
  Setelah tugas health check selesai, perintah kubectl sebelumnya 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 akan menampilkan hasil berikut:
```
NAME                PASS   AGE
healthcheck-7c4qf   true   17m
```
4. Kumpulkan semua log untuk Pod tugas health check ke dalam file lokal menggunakan perintah kubectl. Berikut adalah contoh yang menggunakan tugas health check contoh sebelumnya:
```
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, agen Cloud Logging akan diaktifkan secara default dan hanya dicakup ke komponen tingkat sistem. Hal ini mereplikasi log tingkat sistem ke Google Cloud project yang terkait dengan cluster. Log tingkat sistem berasal dari Pod Kubernetes di namespace berikut:

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

Anda dapat membuat kueri log dari Logs Explorer.

Untuk mengetahui detail selengkapnya, lihat Mengonfigurasi logging dan pemantauan.

Google Cloud CLI dan akses cluster jarak jauh

Jika Anda membuka kasus dukungan, Cloud Customer Care mungkin meminta akses baca-saja jarak jauh ke cluster Anda untuk membantu mendiagnosis dan menyelesaikan masalah dengan lebih efektif. Agar Cloud Customer Care memiliki akses yang memadai untuk memecahkan masalah cluster Anda dari jarak jauh, pastikan Anda telah menginstal dan mengupdate ke versi terbaru dari Google Cloud CLI. Google Cloud CLI harus berada di versi 401.0.0 atau yang lebih tinggi untuk memberikan izin yang diperlukan kepada Cloud Customer Care. Sebaiknya update Google Cloud CLI secara rutin untuk mendapatkan izin tambahan dan peningkatan lainnya.

Untuk menginstal komponen gcloud CLI terbaru, gunakan perintah gcloud components update. Untuk mengetahui informasi selengkapnya tentang cara memberikan akses baca-saja jarak jauh ke cluster Anda kepada Cloud Customer Care, lihat Dukungan Cluster GKE Jarak Jauh.

Metrik cluster

Selain log, agen Cloud Monitoring juga mengambil metrik. Hal ini mereplikasi metrik tingkat sistem ke Google Cloud project yang terkait dengan cluster. Metrik tingkat sistem berasal dari Pod Kubernetes yang berjalan di namespace yang sama yang tercantum di bagian Log cluster.

Untuk mengetahui detail selengkapnya, lihat Mengonfigurasi logging dan pemantauan.

Cara kami memecahkan masalah lingkungan Anda

Berikut adalah contoh insiden dukungan umum:

Administrator cluster membuka kasus dukungan di Google Cloud konsol dengan Cloud Customer Care. Kemudian, mereka memilih GKE dan Google Distributed Cloud sebagai Category dan Component. Mereka memasukkan informasi yang diperlukan dan melampirkan output perintah bmctl yang relevan ke kasus tersebut.
Kasus dukungan dirutekan ke Technical Support Engineer yang berspesialisasi dalam Google Distributed Cloud.
Support engineer memeriksa konten snapshot untuk mendapatkan konteks lingkungan.
Support engineer memeriksa log dan metrik dalam the Google Cloud project. Mereka memasukkan ID kasus dukungan sebagai justifikasi bisnis, yang dicatat secara internal.
Support engineer merespons kasus tersebut dengan penilaian dan rekomendasi. Support engineer dan pengguna terus memecahkan masalah hingga mereka mencapai penyelesaian.

Apa yang didukung Google?

Secara umum, Cloud Customer Care mendukung semua komponen software yang dikirimkan sebagai bagian dari Google Distributed Cloud dan Cloud Service Mesh, Policy Controller, Config Sync, dan Config Controller. Tabel berikut memberikan daftar yang lebih lengkap tentang apa yang didukung dan tidak didukung:

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

Kebijakan Dukungan Versi

Tujuan Kebijakan Dukungan Versi ini adalah memberi Anda fleksibilitas untuk menjadwalkan upgrade saat memenuhi kebutuhan bisnis Anda, sekaligus menyeimbangkan evolusi cepat Kubernetes dan Google Distributed Cloud.

Software Google Distributed Cloud hanya mengikuti skema pembuatan versi dan siklus rilis Kubernetes. Rilis minor terjadi sekitar tiga kali per tahun. Patch untuk setiap versi minor yang didukung terjadi sekitar setiap bulan. Seperti Kubernetes, Google Distributed Cloud mendukung tiga versi minor terbaru secara bersamaan.

Google mendukung setiap versi minor Google Distributed Cloud untuk yang terbaru dari:

12 bulan setelah rilis awal versi minor.
Rilis versi minor ketiga berikutnya.

Misalnya, versi minor 1.33 dirilis pada 2 September 2025. Versi minor ini dan semua patch-nya didukung hingga 2 September 2026 atau tanggal rilis versi minor 1.36, mana pun yang lebih baru.

Sebaiknya pertahankan lingkungan Google Distributed Cloud Anda dengan rilis minor terbaru produk dan versi patch yang direkomendasikan.

Kebijakan dukungan versi ini mencakup:

Dukungan perbaikan dari Cloud Customer Care.
Kerentanan keamanan CVE ke Kubernetes dan komponen terkait.
Patch umum ke Kubernetes dan komponen terkait.

Saat versi Anda mencapai akhir masa pakainya, Anda dapat terus membuka kasus untuk menerima dukungan terkait hal berikut:

Bantuan terkait masalah teknis.
Bantuan terkait masalah penagihan.
Panduan tentang penggunaan produk, termasuk bantuan terkait pemecahan masalah dan pengujian.

Dukungan diperpanjang dapat disetujui secara kondisional sebagai peristiwa satu kali, dengan penyematan versi, dan persyaratan linimasa upgrade mendatang. Untuk mengetahui informasi tambahan, hubungi customer engineer utama untuk akun Anda atau account manager. Atau, Anda dapat mengajukan kasus dukungan melalui Google Cloud konsol. Permintaan tersebut dirutekan ke grup customer engineering untuk akun Anda.

Periode dukungan

Tabel berikut menunjukkan rilis minor yang didukung untuk Google Distributed Cloud dan tanggal akhir masa pakai (EOL) paling awal:

Versi Google Distributed Cloud	Tanggal rilis	Tanggal akhir masa pakai^*
1.35	2026-04-29	2027-04-29 atau tanggal rilis 1.38
1.34	2025-12-11	2026-12-11 atau tanggal rilis 1.37
1.33	2025-09-02	2026-09-02 atau tanggal rilis 1.36
1.32	2025-05-06	2026-05-06 atau tanggal rilis 1.35

* EOL akan menjadi tanggal yang lebih baru dari kedua tanggal ini.

Untuk mempelajari lebih lanjut kompatibilitas versi untuk Google Distributed Cloud dan produk terkait Google Cloud , lihat Dukungan versi dan upgrade support.

Skema pembuatan versi

Google Distributed Cloud menggunakan pembuatan versi semantik Kubernetes untuk merujuk ke versi Kubernetes yang didukung, tetapi menambahkan versi patch GKE. Hal ini menghasilkan nomor versi dalam bentuk: x.y.z-gke.N.

Versi utama Kubernetes (x): Versi utama biasanya bertambah jika perubahan yang tidak kompatibel dengan versi lama diperkenalkan ke API publik. Versi utama menambahkan versi Kubernetes dari x.y ke x+1.y.
Versi minor Kubernetes (y): Kubernetes merilis versi minor baru tiga kali setahun. Setiap siklus rilis berdurasi sekitar 15 minggu. API yang tidak digunakan lagi mungkin dihapus dengan versi minor baru. Versi minor menambahkan versi Kubernetes dari 1.y ke 1.y+1; misalnya, Kubernetes 1. 29 adalah rilis minor yang mengikuti Kubernetes 1.28.
Rilis patch Google Distributed Cloud (z-gke.N): Rilis patch, seperti 1.28.300-gke.131, menambahkan versi patch (z) sebesar 100 dan menyertakan akhiran -gke.N, yang menunjukkan build. Rilis patch mencakup update keamanan dan perbaikan bug. Versi rilis patch Google Distributed Cloud tidak berkorelasi dengan versi patch Kubernetes.

Model tanggung jawab bersama

Menjalankan aplikasi produksi yang penting bagi bisnis di Google Distributed Cloud memerlukan banyak pihak untuk mengemban tanggung jawab yang berbeda-beda. Meskipun bukan daftar lengkap, bagian berikut mencantumkan peran dan tanggung jawab berbagai pihak.

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 upgrade untuk versi sebelumnya.

Google Distributed Cloud hanya mendukung upgrade cluster berurutan (contoh: 1.33 → 1.34 → 1.35, tetapi bukan 1.33 → 1.35). Saat mengupgrade node pool, dalam beberapa kasus, Anda dapat melewati versi minor. Untuk mengetahui informasi selengkapnya tentang logika upgrade, lihat Aturan versi.
Mengoperasikan layanan Connect dan Cloud Operations.
Memecahkan masalah, memberikan solusi sementara, dan memperbaiki akar masalah terkait komponen yang disediakan Google.

Tanggung jawab pengguna

Administrasi sistem secara keseluruhan untuk cluster lokal.
Mempertahankan workload aplikasi yang di-deploy di cluster.
Menjalankan, memelihara, dan menerapkan patch pada infrastruktur pusat data, termasuk jaringan, server, sistem operasi, penyimpanan, dan konektivitas ke Google Cloud.
Menjalankan, memelihara, dan menerapkan patch pada load balancer jaringan jika opsi load balancer manual dipilih.
Mengupgrade versi Google Distributed Cloud secara rutin.
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 developer upaya terbaik untuk memastikan developer Anda dapat menjalankan aplikasi di Google Distributed Cloud. Kami yakin bahwa keterlibatan lebih awal selama pengembangan dapat mencegah insiden penting di kemudian hari dalam deployment.

Dukungan developer upaya terbaik ini tersedia untuk pelanggan dengan paket dukungan berbayar apa pun dan diperlakukan sebagai prioritas P3 untuk masalah yang memblokir peluncuran, atau prioritas P4 untuk konsultasi umum. Dalam klasifikasi ini, tingkat prioritas 0 adalah prioritas tertinggi.