Support anfordern

Das Hauptziel von Google beim Support ist es, Produktionsvorfälle so schnell wie möglich zu beheben. Dazu bestimmen wir Ihre Konfiguration, analysieren Logs und Messwerte und arbeiten mit Partnern zusammen, um Vorfälle schnell zu beheben.

Cloud Customer Care bietet verschiedene Supportpakete für Ihre Support anforderungen an. Alle Cloud Customer Care-Pakete umfassen Support für GKE und Google Distributed Cloud. Wenn Sie bereits ein Cloud Customer Care-Supportpaket haben, erhalten Sie bereits Support für GKE und Google Distributed Cloud.

Weitere Informationen finden Sie im Cloud Customer Care-Hub.

Anforderungen für den Google Distributed Cloud-Support

So beheben Sie geschäftskritische Vorfälle effektiv:

• Prüfen Sie, ob Ihre Umgebung aktuell ist und sich innerhalb der veröffentlichten Supportzeiträume für das Ende des Supports befindet. Weitere Informationen finden Sie im Abschnitt Versionsunterstützungsrichtlinie.
• Aktivieren Sie Cloud Logging und Cloud Monitoring für Systemkomponenten. Weitere Informationen finden Sie im folgenden Abschnitt zu Support-Tools.

Support-Tools

Zur Fehlerbehebung bei einem Google Distributed Cloud-Vorfall benötigt Cloud Customer Care drei Informationen:

• Ihre Umgebungskonfiguration
• Logs Ihrer Cluster
• Messwerte aus Ihren Clustern

Ihre Umgebungskonfiguration

Wenn Sie eine Supportanfrage eröffnen, geben Sie mit den folgenden Befehlen wichtige Informationen zu Ihrer Clustereinrichtung an:

• Erfassen Sie für alle Clustertypen Informationen zu Kubernetes und Ihren Knoten, indem Sie den Befehl bmctl check cluster --snapshot ausführen. Hängen Sie die resultierende Tar-Datei an die Supportanfrage an.

• Prüfen Sie für Administrator-, Hybrid- und eigenständige Cluster den Integritätsstatus des Clusters und der Knoten, indem Sie den Befehl bmctl check cluster ausführen. Hängen Sie die resultierenden Logs an die Supportanfrage an. Die Logs sollten sich im Verzeichnis bmctl-workspace/[CLUSTER_NAME]/log/check-cluster-[TIMESTAMP] befinden.

• Erstellen Sie für Nutzercluster zuerst eine YAML-Datei der Systemdiagnose mit dem Clusternamen und dem Namespace. Wenden Sie dann die Datei auf den entsprechenden Administratorcluster an:

  1. Erstellen Sie eine YAML-Datei mit den folgenden healthcheck-Attributen. Hier sehen Sie Beispielinhalt für einen Cluster namens user1 im cluster-user1 Namespace:

     apiVersion: baremetal.cluster.gke.io/v1
     kind: HealthCheck
     metadata:
       generateName: healthcheck-
       namespace: cluster-user1
     spec:
       clusterName: user1
     

  2. Nachdem Sie die YAML-Datei erstellt haben, wenden Sie die benutzerdefinierte Ressource im Administratorcluster an, der den Nutzercluster verwaltet, indem Sie den Befehl kubectl verwenden. Hier sehen Sie einen Beispielbefehl mit der YAML-Datei, die im vorherigen Schritt erstellt wurde: Im Beispiel gibt die Variable ADMIN_KUBECONFIG den Pfad zur kubeconfig-Datei des Administratorclusters an:

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

     Der Befehl gibt die folgende Antwort zurück:

     healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf created
     

  3. Warten Sie, bis die Systemdiagnose abgeschlossen ist. Testen Sie dazu, ob der Systemdiagnosejob abgeschlossen wurde. Im vorherigen Beispielbeispiel lautet der Name des Systemdiagnosejobs healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf. Hier sehen Sie einen Beispieltest mit dem Befehl kubectl, der 30 Minuten auf den Abschluss des Systemdiagnosejobs wartet:

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

     Wenn der Systemdiagnosejob abgeschlossen ist, gibt der vorherige kubectl-Befehl Folgendes zurück:

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

     Sie können die Ergebnisse der Systemdiagnose mit dem folgenden Befehl aufrufen:

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

     Der Befehl gibt das folgende Ergebnis zurück:

     NAME                PASS   AGE
     healthcheck-7c4qf   true   17m
     

  4. Erfassen Sie alle Logs für den Pod des Systemdiagnosejobs in einer lokalen Datei mit dem Befehl kubectl. Hier ist ein Beispiel, bei dem der vorherige Beispiel einer Systemdiagnose verwendet wird:

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

Cluster-Logs

Wenn Sie einen neuen Google Distributed Cloud-Cluster erstellen, sind Cloud Logging-Agents standardmäßig aktiviert und ausschließlich auf Komponenten auf Systemebene beschränkt. Dadurch werden Logs auf Systemebene in das Google Cloud mit dem Cluster verknüpfte Projekt repliziert. Logs auf Systemebene stammen von Kubernetes-Pods in den folgenden Namespaces:

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

Sie können Logs über den Logs-Explorer abfragen.

**Hinweis**: Wenn Cloud Logging deaktiviert ist, wird der Support nur auf Best-Effort-Basis angeboten und erfordert möglicherweise erheblichen Zusatzaufwand von Ihrem Entwicklerteam vor Ort.

Weitere Informationen finden Sie unter Logging und Monitoring konfigurieren.

Google Cloud CLI und Remote-Clusterzugriff

Wenn Sie eine Supportanfrage eröffnen, fordert der Cloud Customer Care Sie möglicherweise auf, Lesezugriff auf Ihre Cluster aus der Ferne zu gewähren, damit Probleme effektiver diagnostiziert und behoben werden können. Damit Cloud Customer Care ausreichend Zugriff hat, um Ihr Cluster Problem aus der Ferne zu beheben, müssen Sie die Google Cloud CLI installiert und auf die aktuelle Version aktualisiert haben. Die Google Cloud CLI muss Version 401.0.0 oder höher haben, damit der Cloud Customer Care die erforderlichen Berechtigungen erhalten kann. Wir empfehlen, die Google Cloud CLI regelmäßig zu aktualisieren, um zusätzliche Berechtigungen und andere Verbesserungen zu erhalten.

Verwenden Sie den gcloud components update Befehl, um die aktuellen Komponenten der gcloud CLI zu installieren. Weitere Informationen dazu, wie Sie Cloud Customer Care Remote-Lesezugriff auf Ihre Cluster gewähren, finden Sie unter Remote-Support für GKE-Cluster.

Clustermesswerte

Neben den Logs erfasst der Cloud Monitoring-Agent auch Messwerte. Dadurch werden Messwerte auf Systemebene in das Google Cloud mit dem Cluster verknüpfte Projekt repliziert. Messwerte auf Systemebene stammen von Kubernetes-Pods, die in denselben Namespaces ausgeführt werden, die im Abschnitt Cluster-Logs aufgeführt sind.

Hinweis: Wenn Cloud Monitoring deaktiviert ist, wird der Support nur auf Best-Effort Basis angeboten und erfordert möglicherweise erheblichen Zusatzaufwand von Ihrem Entwicklerteam vor Ort.

Weitere Informationen finden Sie unter Logging und Monitoring konfigurieren.

So beheben wir Fehler in Ihrer Umgebung

Hier ist ein Beispiel für einen typischen Supportvorfall:

1. Der Clusteradministrator öffnet eine Supportanfrage in Google Cloud der Console bei Cloud Customer Care. Anschließend wählt er GKE und Google Distributed Cloud als Kategorie bzw. Komponente aus. Er gibt die erforderlichen Informationen ein und hängt die Ausgabe der relevanten bmctl-Befehle an die Anfrage an.

2. Die Supportanfrage wird an einen technischen Supportmitarbeiter weitergeleitet, der auf Google Distributed Cloud spezialisiert ist.

3. Der Supportmitarbeiter untersucht den Inhalt des Snapshots, um einen Kontext zur Umgebung zu erhalten.

4. Der Supportmitarbeiter untersucht die Logs und Messwerte im Google Cloud Projekt. Er gibt die Supportanfrage-ID als geschäftliche Rechtfertigung ein, die intern protokolliert wird.

5. Der Supportmitarbeiter antwortet auf die Anfrage mit einer Bewertung und einer Empfehlung. Der Supportmitarbeiter und der Nutzer fahren mit der Fehlerbehebung fort, bis sie eine Lösung gefunden haben.

Welche Supportleistungen bietet Google?

Im Allgemeinen bietet Cloud Customer Care Support für alle Softwarekomponenten, die im Lieferumfang von Google Distributed Cloud, Cloud Service Mesh, Policy Controller, Config Sync und Config Controller enthalten sind. In der folgenden Tabelle finden Sie eine vollständige Liste der unterstützten und nicht unterstützten Funktionen:

Google Cloud wird unterstützt.	Nicht unterstützt
Kubernetes und die Containerlaufzeit	Vom Kunden gewählte Load-Balancer (manuelles Load-Balancing)
Connect und der Connect-Agent	Kundencode (siehe Entwicklersupport)
Google Cloud Vorgänge, Monitoring, Logging und Agents	Vom Kunden gewähltes Betriebssystem
Gebündelter Load-Balancer	Physischer oder virtueller Server, Speicher und Netzwerk
Ingress-Controller	Externe DNS-, DHCP- und Identitätssysteme
GKE Identity Service
Cloud Service Mesh
Policy Controller
Config Sync
Config Controller

Versionsunterstützungsrichtlinie

Diese Versionsunterstützungsrichtlinie soll Ihnen die Möglichkeit geben, Upgrades so zu planen, dass der Zeitplan Ihren geschäftlichen Anforderungen entspricht. Gleichzeitig soll die schnelle Entwicklung von Kubernetes und Google Distributed Cloud berücksichtigt werden.

Die Google Distributed Cloud-Software folgt nur dem Kubernetes-Versionsverwaltungsschema und Releasezyklus. Nebenversionen werden etwa dreimal pro Jahr veröffentlicht. Patches für jede unterstützte Nebenversion werden etwa monatlich veröffentlicht. Wie Kubernetes unterstützt Google Distributed Cloud gleichzeitig die drei neuesten Nebenversionen.

Google unterstützt jede Nebenversion von Google Distributed Cloud mindestens bis zu einem der folgenden Zeitpunkte:

• Bis 12 Monate nach der Erstveröffentlichung der Nebenversion.
• Bis zur Veröffentlichung der dritten nachfolgenden Nebenversion.

Beispiel: Nebenversion 1.33, veröffentlicht am 2. September 2025. Diese Nebenversion und alle zugehörigen Patches werden bis zum 2. September 2026 oder bis zum Veröffentlichungsdatum der Nebenversion 1.36 unterstützt, je nachdem, welcher Zeitpunkt später liegt.

Wir empfehlen Ihnen, Ihre Google Distributed Cloud-Umgebung mit der neuesten Nebenversion und der empfohlenen Patch version des Produkts aktuell zu halten.

Diese Versionsunterstützungsrichtlinie beinhaltet Folgendes:

• Break-Fix-Support von Cloud Customer Care.
• CVE-Sicherheitslücken in Kubernetes und den zugehörigen Komponenten.
• Allgemeine Patches für Kubernetes und die zugehörigen Komponenten.

Wenn Ihre Version das End of Life erreicht hat, können Sie weiterhin Anfragen eröffnen, um Support für Folgendes zu erhalten:

• Hilfe bei technischen Problemen.
• Unterstützung bei Abrechnungsproblemen.
• Anleitung zur Produktnutzung, einschließlich Hilfe bei der Fehlerbehebung und beim Testen.

Erweiterter Support kann bedingt als einmaliges Ereignis mit Versionsfixierung und zukünftigen Anforderungen an den Upgradezeitplan genehmigt werden. Weitere Informationen erhalten Sie vom leitenden Customer Engineer für Ihr Konto oder vom Account Manager. Alternativ können Sie über die Console eine Supportanfrage einreichen. Google Cloud Solche Anfragen werden an die Customer Engineering-Gruppe für Ihr Konto weitergeleitet.

Supportzeitraum

Die folgende Tabelle zeigt die unterstützten Nebenversionen für Google Distributed Cloud und die frühesten End-of-Life-Termine (EOL):

Google Distributed Cloud-Version	Releasedatum	End-of-Life-Datum^*
1,35	2026-04-29	2027-04-29 oder Releasedatum von 1.38
1,34	2025-12-11	2026-12-11 oder Releasedatum von 1.37
1.33	2025-09-02	2026-09-02 oder Releasedatum von 1.36
1,32	2025-05-06	2026-05-06 oder Releasedatum von 1.35

* Das EOL-Datum ist der spätere der beiden Termine.

Weitere Informationen zur Versionskompatibilität für Google Distributed Cloud und zugehörige Google Cloud Produkte finden Sie unter Support für Versionen und Upgrades.

Versionsverwaltungsschema

Google Distributed Cloud verwendet die semantische Versionsverwaltung von Kubernetes , um auf unterstützte Kubernetes-Versionen zu verweisen, hängt aber eine GKE-Patchversion an. Dies führt zu einer Versionsnummer im Format x.y.z-gke.N.

Kubernetes-Hauptversion (x)

Hauptversionen werden in der Regel erhöht, wenn nicht abwärtskompatible Änderungen an der öffentlichen API vorgenommen werden. Eine Hauptversion erhöht die Kubernetes-Version von x.y auf x+1.y.

Kubernetes-Nebenversion (y)

Kubernetes veröffentlicht dreimal pro Jahr eine neue Nebenversion. Jeder Releasezyklus ist etwa 15 Wochen lang. Verworfene APIs können mit einer neuen Nebenversion entfernt werden. Eine Nebenversion erhöht die Kubernetes-Version von 1.y auf 1.y+1. Kubernetes 1. 29 ist die Nebenversion, die auf Kubernetes 1 folgt.28.

Google Distributed Cloud-Patchrelease (z-gke.N)

Ein Patchrelease wie 1.28.300-gke.131 erhöht die Patchversion (z) um 100 und enthält ein Suffix -gke.N, das den Build angibt. Patchreleases enthalten Sicherheitsupdates und Fehlerkorrekturen. Eine Google Distributed Cloud-Patch-Releaseversion entspricht nicht einer Kubernetes-Patchversion.

Modell der gemeinsamen Verantwortung

Für die Ausführung einer geschäftskritischen Produktionsanwendung in Google Distributed Cloud müssen mehrere Parteien unterschiedliche Verantwortlichkeiten übernehmen. In den folgenden Abschnitten werden die Rollen und Verantwortlichkeiten der verschiedenen Parteien aufgeführt.

Verantwortlichkeit von Google

• Wartung und Verteilung des Google Distributed Cloud-Softwarepakets.

• Benachrichtigung der Nutzer über verfügbare Upgrades für Google Distributed Cloud und Erstellen von Upgrade-Scripts für die vorherige Version.

  Google Distributed Cloud unterstützt nur sequenzielle Cluster-Upgrades (Beispiel: 1.33 → 1.34 → 1.35, aber nicht 1.33 → 1.35). Beim Upgrade von Knotenpools können Sie in einigen Fällen eine Nebenversion überspringen. Weitere Informationen zur Upgrade logik finden Sie unter Versionsregeln.

• Ausführen der Connect- und Cloud-Betriebsdienste

• Beheben von Fehlern, Bereitstellen von Problemumgehungen und Beheben der Ursache von Problemen im Zusammenhang mit von Google bereitgestellten Komponenten

Verantwortlichkeit der Nutzer

• Gesamte Systemverwaltung für lokale Cluster.
• Verwalten von auf dem Cluster bereitgestellten Anwendungsarbeitslasten.
• Ausführen, Pflegen und Patchen der Infrastruktur des Rechenzentrums, einschließlich Netzwerk, Server, Betriebssystem, Speicher und Konnektivität mit Google Cloud.
• Das Ausführen, Warten und Patchen von Netzwerk-Load-Balancern, wenn eine manuelle Load-Balancer-Option ausgewählt wird.
• Regelmäßiges Upgrade von Google Distributed Cloud-Versionen.
• Monitoring des Clusters und von Anwendungen sowie Reagieren auf Vorfälle.
• Bereitstellung von Cloud Operations-Agents auf Clustern sicherstellen
• Bereitstellen von Umgebungsdaten zur Fehlerbehebung für Google.

Entwicklersupport

Google bietet keinen speziell an Ihre Anwendungsarbeitslasten angepassten Support. Wir bieten jedoch Best-Effort-Entwicklersupport, damit Ihre Entwickler Anwendungen in Google Distributed Cloud ausführen können. Wir sind der Meinung, dass unsere frühzeitige Einbindung kritische Vorfälle später während der Bereitstellung verhindern kann.

Dieser Best-Effort-Entwicklersupport steht Kunden mit einem kostenpflichtigen Supportpaket zur Verfügung und wird als P3-Priorität für Probleme behandelt, die den Start verhindern, bzw. als P4-Priorität für allgemeine Beratungen. In dieser Klassifizierung hat die Priorität 0 die höchste Priorität.