Support anfordern

Das Hauptziel von Google beim Support ist es, Produktionsvorfälle so schnell wie möglich zu beheben. Wenn wir Ihre Konfiguration verstehen, Logs und Messwerte analysieren und mit Partnern zusammenarbeiten, können wir Vorfälle schnell lösen.

Google Cloud bietet verschiedene Supportpakete für Ihre Supportanforderungen an. Alle Google Cloud-Supportpakete umfassen Support für die Google Kubernetes Engine (GKE) Enterprise Edition und die Google Distributed Cloud. Wenn Sie bereits ein Google Cloud-Supportpaket haben, steht Ihnen Support für GKE Enterprise und Google Distributed Cloud bereits zur Verfügung.

Weitere Informationen finden Sie in der Dokumentation zum Google Cloud-Support.

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 Supportzeiten für den Support befindet. Weitere Informationen finden Sie im Abschnitt Richtlinie für Versionsunterstützung.
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 der Google Cloud-Support drei Informationen:

Ihre Umgebungskonfiguration
Logs Ihrer Cluster
Messwerte aus Ihren Clustern

Ihre Umgebungskonfiguration

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

Führen Sie für alle Clustertypen den Befehl bmctl check cluster --snapshot aus, um Informationen über Kubernetes und Ihre Knoten zu erfassen. Hängen Sie die resultierende Tar-Datei an die Supportanfrage an.
Führen Sie für Administrator-, Hybrid- und eigenständige Cluster den Befehl bmctl check cluster aus, um den Integritätsstatus des Clusters und der Knoten zu prüfen. Hängen Sie die resultierenden Logs an die Supportanfrage an. Sie 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. 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, indem Sie testen, ob der Systemdiagnosejob abgeschlossen wurde. Im vorherigen Beispielbeispiel lautet der Name des Systemdiagnosejobs healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf. Hier ein 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 Vorgang abgeschlossen ist, gibt dieser 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 aller Systemdiagnose-Pods 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

Logs können über die Cloud Logging Console abgefragt werden.

Weitere Informationen hierzu finden Sie unter Logging and Monitoring.

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 das Supportteam 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 Remotezugriff mit Lesezugriff auf Ihre Cluster gewähren, finden Sie unter Google Cloud-Support für registrierte 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 in Logs aufgeführt sind.

Weitere Informationen hierzu finden Sie unter Logging and Monitoring.

So beheben wir Fehler in Ihrer Umgebung

Hier ist ein Beispiel für einen typischen Supportvorfall:

Der Clusteradministrator öffnet eine Supportanfrage in der Google Cloud Console oder dem Google Cloud-Supportcenter und wählt die Google Kubernetes Engine (GKE) Enterprise Edition und die Google Distributed Cloud als Kategorie bzw. als Komponente aus. Er gibt die erforderlichen Informationen ein und hängt die Ausgabe der relevanten bmctl-Befehle an die Anfrage an.
Die Supportanfrage wird an einen Mitarbeiter des technischen Supports weitergeleitet, der auf die Google Distributed Cloud spezialisiert ist.
Der Supportmitarbeiter untersucht den Inhalt des Snapshots, um einen Kontext zur Umgebung zu erhalten.
Der Supportmitarbeiter untersucht die Logs und Messwerte im Google Cloud-Projekt und gibt die Supportanfrage-ID als geschäftliche Rechtfertigung ein, die intern protokolliert wird.
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 das Cloud-Supportteam 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:

Unterstützt von Google Cloud	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

Der Support für Google Distributed Cloud folgt der GKE Enterprise-Supportrichtlinie. 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.

Die neuesten Veröffentlichungstermine für Nebenversionen von GKE Enterprise und die frühesten End-of-Life-Termine finden Sie unter Supportzeitraum: GKE Enterprise.

Listen der unterstützten und nicht unterstützten Google Distributed Cloud-Versionen finden Sie unter Versionsverwaltung.

Versionsinformationen zu Cluster-Upgrades finden Sie unter Versionsregeln für Upgrades.

Modell der geteilten Verantwortung

Für die Ausführung einer geschäftskritischen Produktionsanwendung in der Google Distributed Cloud müssen mehrere Parteien unterschiedliche Verantwortlichkeiten übernehmen. In den folgenden Abschnitten werden die Rollen und Verantwortlichkeiten 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 Upgrades (Beispiel: 1.2 → 1.3 → 1.4, nicht 1.2 → 1.4).
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 zu Google Cloud.
Das Ausführen, Warten und Patchen von Netzwerk-Load-Balancern, wenn eine manuelle Load-Balancer-Option ausgewählt wird.
Regelmäßige Upgrades der 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 der 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.