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 Supportanforderungen an. Alle Cloud Customer Care-Pakete umfassen Support für GKE und Google Distributed Cloud. Wenn Sie bereits ein Cloud Customer Care-Supportpaket haben, steht Ihnen Support für GKE und Google Distributed Cloud bereits zur Verfügung.

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:

Support-Tools

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

Ihre Umgebungskonfiguration

Wenn Sie eine Supportanfrage eröffnen, können Sie mit den folgenden Befehlen wichtige Informationen über Ihre Clustereinrichtung abrufen:

  • 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 im Verzeichnis bmctl-workspace/[CLUSTER_NAME]/log/check-cluster-[TIMESTAMP] vorhanden sein.

  • 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 Namespace cluster-user1:

      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 mit dem Befehl kubectl verwaltet. Im Folgenden finden Sie einen Beispielbefehl, in dem die YAML-Datei verwendet wird, 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 der Systemdiagnosejob abgeschlossen ist. Prüfen Sie dazu, ob der Systemdiagnosejob abgeschlossen wurde. Im vorherigen Beispielbeispiel lautet der Name des Systemdiagnosejobs healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf. Im folgenden Beispieltest wird der Befehl kubectl verwendet. Er wartet 30 Minuten auf den Abschluss des Systemdiagnosejobs:

      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. Sammeln Sie alle Logs für den Systemdiagnose-Job-Pod in einer lokalen Datei mit dem Befehl kubectl. Hier ist ein Beispiel, in dem der vorherige Beispieljob 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 mit dem Cluster verknüpfte Google Cloud -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 Log-Explorer abfragen.

Weitere Informationen finden Sie unter Logging und Monitoring konfigurieren.

Google Cloud CLI und Remote-Clusterzugriff

Wenn Sie einen Supportfall 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 Clusterproblem 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 mit dem Cluster verknüpfte Google Cloud -Projekt repliziert. Messwerte auf Systemebene stammen von Kubernetes-Pods, die in denselben Namespaces ausgeführt werden, die im Abschnitt Clusterlogs aufgeführt sind.

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 der Google Cloud Console mit dem Cloud Customer Care. Anschließend wählen sie 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 Projekt Google Cloud. 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 Operations, 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

Das Ziel dieser Versionsunterstützungsrichtlinie ist es, Ihnen die Flexibilität zu 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.

Google Distributed Cloud (nur Software) folgt nur dem Versionsverwaltungsschema und dem Releasezyklus von Kubernetes. Nebenversionen werden ungefähr dreimal pro Jahr veröffentlicht. Patches für jede unterstützte Nebenversion werden etwa monatlich veröffentlicht. Wie bei Kubernetes werden in Google Distributed Cloud die drei neuesten Nebenversionen gleichzeitig unterstützt.

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 02.09.2025. Diese Nebenversion und alle zugehörigen Patches werden bis zum 2. September 2026 oder bis zum Release-Datum der Nebenversion 1.36 unterstützt, je nachdem, welches Datum später liegt.

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

Diese Versionsunterstützungsrichtlinie beinhaltet Folgendes:

  • Break/Fix-Unterstützung 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 Supportfälle für Folgendes öffnen:

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

Eine erweiterte Unterstützung kann unter bestimmten Bedingungen als einmaliges Ereignis mit Versionsfixierung und zukünftigen Upgrade-Zeitplananforderungen genehmigt werden. Weitere Informationen erhalten Sie vom Lead Customer Engineer für Ihr Konto oder vom Account Manager. Alternativ können Sie über die Google Cloud Console einen Supportfall einreichen. Solche Anfragen werden an die Customer Engineering-Gruppe für Ihr Konto weitergeleitet.

Supportzeitraum

In der folgenden Tabelle sind die unterstützten Nebenversionen für Google Distributed Cloud und die frühesten End-of-Life-Daten (EOL) aufgeführt:

Google Distributed Cloud-Version Releasedatum End-of-Life-Datum*
1.33 2025-09-02 02.09.2026 oder Releasedatum von 1.36
1,32 2025-05-06 06.05.2026 oder Releasedatum von 1.35
1,31 2024-12-18 18.12.2025 oder Releasedatum von 1.34

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

Weitere Informationen zur Versionskompatibilität für Google Distributed Cloud und zugehörigeGoogle Cloud -Produkte finden Sie unter Versions- und Upgrade-Support.

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. 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 geteilten 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. Die Liste ist jedoch nicht vollständig.

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 (z. B. 1.31 → 1.32 → 1.33, aber nicht 1.31 → 1.33). Wenn Sie Knotenpools aktualisieren, können Sie in einigen Fällen eine Nebenversion überspringen. Weitere Informationen zur Upgradelogik 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ührung, Wartung und Patchen der Rechenzentrumsinfrastruktur, einschließlich Netzwerken, Servern, Betriebssystem, Speicher und Konnektivität zuGoogle Cloud.
  • Das Ausführen, Warten und Patchen von Netzwerk-Load-Balancern, wenn eine manuelle Load-Balancer-Option ausgewählt wird.
  • Regelmäßiges Aktualisieren 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.