Auf dieser Seite finden Sie Überlegungen und Empfehlungen zur Migration von Arbeitslasten von Standard-Google Kubernetes Engine-Clustern (GKE) zu Autopilot-Clustern mit minimaler Unterbrechung Ihrer Dienste. Diese Seite richtet sich an Clusteradministratoren, die sich bereits für die Migration zu Autopilot entschieden haben. Weitere Informationen vor der Migration finden Sie unter GKE-Betriebsmodus auswählen und GKE Autopilot und Standard vergleichen.
Funktionsweise der Migration
Autopilot-Cluster automatisieren viele der optionalen Features und Funktionen, die eine manuelle Konfiguration in Standardclustern erfordern. Darüber hinaus erzwingen Autopilot-Cluster sicherere Standardkonfigurationen für Anwendungen, um eine produktionsbereitere Umgebung zu bieten und den erforderlichen Verwaltungsaufwand im Vergleich zum Standardmodus zu reduzieren. Autopilot-Cluster wenden standardmäßig viele Best Practices und Empfehlungen von GKE an. Autopilot verwendet ein arbeitslastorientiertes Konfigurationsmodell, bei dem Sie anfordern, was Sie in Ihren Kubernetes-Manifesten benötigen und GKE die entsprechende Infrastruktur bereitstellt.
Wenn Sie Ihre Standardarbeitslasten zu Autopilot migrieren, sollten Sie Ihre Arbeitslastmanifeste vorbereiten, damit sie mit Autopilot-Clustern kompatibel sind. Dazu müssen Sie beispielsweise sicherstellen, dass Ihre Manifeste Infrastruktur anfordern, die Sie normalerweise selbst bereitstellen müssen.
Für die Vorbereitung und Ausführung einer erfolgreichen Migration führen Sie die folgenden allgemeinen Aufgaben aus:
- Führen Sie eine Preflight-Prüfung auf Ihrem vorhandenen Standardcluster aus, um die Kompatibilität mit Autopilot zu bestätigen.
- Ändern Sie gegebenenfalls Ihre Arbeitslastmanifeste, damit sie Autopilot-kompatibel sind.
- Führen Sie einen Probelauf aus, um zu prüfen, ob Ihre Arbeitslasten auf Autopilot ordnungsgemäß funktionieren.
- Autopilot-Cluster planen und erstellen
- Aktualisieren Sie gegebenenfalls Ihre Infrastruktur als Code-Tools.
- Führen Sie die Migration aus.
Hinweise
Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:
- Aktivieren Sie die Google Kubernetes Engine API. Google Kubernetes Engine API aktivieren
- Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit
gcloud components updateab.
- Prüfen Sie, ob Sie einen vorhandenen Standardcluster mit laufenden Arbeitslasten haben.
- Achten Sie darauf, dass Sie einen Autopilot-Cluster ohne Arbeitslasten haben, um Probeläufe auszuführen. Informationen zum Erstellen eines neuen Autopilot-Clusters finden Sie unter Autopilot-Cluster erstellen.
Preflight-Prüfung für den Standardcluster ausführen
Die Google Cloud CLI und die Google Kubernetes Engine API bieten ein Preflight-Prüfungstool, mit dem die Spezifikationen Ihrer ausgeführten Standardarbeitslasten validiert werden, um Inkompatibilitäten mit Autopilot-Clustern zu identifizieren. Dieses Tool ist in der GKE-Version 1.26 und höher verfügbar.
- Führen Sie den folgenden Befehl aus, um dieses Tool in der Befehlszeile zu verwenden:
gcloud container clusters check-autopilot-compatibility CLUSTER_NAME
Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Standardclusters. Fügen Sie diesem Befehl optional --format=json hinzu, um die Ausgabe in einer JSON-Datei abzurufen.
Die Ausgabe enthält Ergebnisse, die für alle ausgeführten Standardarbeitslasten enthält, die kategorisiert und mit umsetzbaren Empfehlungen ausgestattet sind, um gegebenenfalls die Kompatibilität mit Autopilot zu gewährleisten. In der folgenden Tabelle werden die Kategorien beschrieben:
| Ergebnisse des Preflight-Tools | |
|---|---|
Passed |
Die Arbeitslast wird wie erwartet ausgeführt und es ist keine Konfiguration für Autopilot erforderlich. |
Passed with optional configuration |
Die Arbeitslast wird auf Autopilot ausgeführt. Sie können jedoch optionale Konfigurationsänderungen vornehmen, um die Umgebung zu optimieren. Wenn Sie keine Konfigurationsänderungen vornehmen, wendet Autopilot eine Standardkonfiguration für Sie an. Wenn Ihre Arbeitslast beispielsweise auf N2-Maschinen im Standardmodus ausgeführt wurde, wendet GKE die allgemeine Compute-Klasse für Autopilot an. Sie können die Arbeitslast optional ändern, um die ausgeglichene Compute-Klasse anzufordern, die von N2-Maschinen unterstützt wird. |
Additional configuration required |
Die Arbeitslast wird nur auf Autopilot ausgeführt, wenn Sie eine Konfigurationsänderung vornehmen. Betrachten Sie beispielsweise einen Container, der die NET_ADMIN-Funktion in Standard verwendet. Autopilot löscht diese Funktion standardmäßig, um die Sicherheit zu verbessern. Daher müssen Sie NET_ADMIN im Cluster aktivieren, bevor Sie die Arbeitslast bereitstellen. |
Incompatibility |
Die Arbeitslast wird nicht auf Autopilot ausgeführt, da sie Funktionen verwendet, die von Autopilot nicht unterstützt werden. Beispielsweise lehnen Autopilot-Cluster privilegierte Pods ab ( |
Arbeitslastspezifikationen basierend auf den Preflight-Ergebnissen ändern
Führen Sie nach der Preflight-Prüfung die JSON-Ausgabe durch und identifizieren Sie Arbeitslasten, die sich ändern müssen. Wir empfehlen, sogar die optionalen Konfigurationsempfehlungen zu implementieren. Jedes Ergebnis enthält auch einen Link zur Dokumentation, in der Sie sehen, wie die Arbeitslastspezifikation aussehen sollte.
Der wichtigste Unterschied zwischen Autopilot und Standard ist, dass die Infrastrukturkonfiguration in Autopilot basierend auf der Arbeitslastspezifikation automatisiert wird. Kubernetes-Planungssteuerungen wie Knotenmarkierungen und -toleranzen werden den ausgeführten Arbeitslasten automatisch hinzugefügt. Bei Bedarf sollten Sie auch Ihre Infrastruktur als Code-Konfigurationen ändern, z. B. Helm-Diagramme oder Kustomize-Overlays.
Einige häufige Konfigurationsänderungen, die Sie vornehmen müssen, sind:
| Häufige Konfigurationsänderungen für Autopilot | |
|---|---|
| Computing- und Architekturkonfiguration | Autopilot-Cluster verwenden standardmäßig den Maschinentyp der E-Serie. Wenn Sie andere Maschinentypen benötigen, muss Ihre Arbeitslastspezifikation eine Compute-Klasse anfordern, die Autopilot anweist, diese Pods auf Knoten zu platzieren, die bestimmte Maschinentypen oder Architekturen verwenden. Weitere Informationen finden Sie unter Compute-Klassen in Autopilot. |
| Beschleuniger | GPU-basierte Arbeitslasten müssen in der Arbeitslastspezifikation GPUs anfordern. Autopilot stellt Knoten automatisch mit dem erforderlichen Maschinentyp und den Beschleunigern bereit. Weitere Informationen finden Sie unter GPU-Arbeitslasten in Autopilot bereitstellen. |
| Ressourcenanforderungen | Alle Autopilot-Arbeitslasten müssen Werte für Weitere Informationen finden Sie unter Ressourcenanfragen in Autopilot. |
| Fehlertolerante Arbeitslasten auf Spot-VMs | Wenn Ihre Arbeitslasten auf Spot-VMs in Standard ausgeführt werden, fordern Sie Spot-Pods in der Arbeitslastkonfiguration an. Legen Sie dazu einen Knotenselektor für Weitere Informationen finden Sie unter Spot-Pods. |
Probelauf für einen Autopilot-Staging-Cluster ausführen
Nachdem Sie jedes Arbeitslastmanifest geändert haben, führen Sie einen Probelauf für die Bereitstellung in einem neuen Autopilot-Cluster aus, um sicherzustellen, dass die Arbeitslast wie erwartet ausgeführt wird.
Befehlszeile
Führen Sie dazu diesen Befehl aus:
kubectl create --dry-run=server -f=PATH_TO_MANIFEST
Ersetzen Sie PATH_TO_MANIFEST durch den Pfad zum geänderten Arbeitslastmanifest.
IDE
Wenn Sie den Cloud Shell-Editor verwenden, ist der Probelaufbefehl eingebunden und wird für alle offenen Manifeste ausgeführt. Wenn Sie Visual Studio Code oder Intellij-IDEs verwenden, installieren Sie die Cloud Code-Erweiterung, um den Probelauf automatisch für alle offenen Manifeste auszuführen.
Der Bereich Probleme in der IDE zeigt alle Probelaufprobleme, z. B. in der folgenden Abbildung, die einen fehlgeschlagenen Probelauf für ein Manifest zeigt, das privileged: true angegeben hat.
Autopilot-Zielcluster planen
Wenn im Probelauf keine Probleme mehr auftreten, planen und erstellen Sie den neuen Autopilot-Cluster für Ihre Arbeitslasten. Dieser Cluster unterscheidet sich vom Autopilot-Cluster, den Sie zum Testen Ihrer Manifeständerungen im vorherigen Abschnitt verwendet haben.
Informationen zu den grundlegenden Konfigurationsanforderungen finden Sie unter Best Practices für das Onboarding für GKE. Anschließend lesen Sie die Übersicht über Autopilot, die Informationen zu Ihrem Anwendungsfall auf verschiedenen Ebenen enthält.
Beachten Sie außerdem Folgendes:
- Autopilot-Cluster sind VPC-nativ. Daher wird die Migration zu Autopilot von routenbasierten Standardclustern nicht empfohlen.
- Verwenden Sie dieselbe oder eine ähnliche VPC für den Autopilot-Cluster und den Standardcluster, einschließlich aller benutzerdefinierten Firewallregeln und VPC-Einstellungen.
- Autopilot-Cluster verwenden GKE Dataplane V2 und unterstützen nur Cilium NetworkPolicies. Calico NetworkPolicies werden nicht unterstützt.
- Wenn Sie die IP-Maskierung in Autopilot verwenden möchten, verwenden Sie eine NAT-Richtlinie für ausgehenden Traffic.
- Wenn Sie einen privaten Standardcluster haben, erstellen Sie einen privaten Autopilot-Cluster mit ähnlichen Isolationseinstellungen.
- Geben Sie den primären IPv4-Bereich für den Cluster während der Clustererstellung an. Verwenden Sie dabei dieselbe Bereichsgröße wie der Standardcluster.
- Weitere Informationen zu den Kontingentunterschieden zwischen Modi, insbesondere bei großen Clustern.
- Weitere Informationen zu den Maximalwerten von Pods pro Knoten für Autopilot, die sich von Standard unterscheiden. Dies ist wichtig, wenn Sie häufig die Knoten- oder Pod-Affinität verwenden.
- Alle Autopilot-Cluster verwenden Cloud DNS.
Autopilot-Cluster erstellen
Wenn Sie bereit sind, den Cluster zu erstellen, verwenden Sie Autopilot-Cluster erstellen. Alle Autopilot-Cluster sind regional und werden automatisch in einer Release-Version registriert. Sie können jedoch die Kanal- und Clusterversion angeben. Wir empfehlen, eine kleine Beispielarbeitslast im Cluster bereitzustellen, um die automatische Knotenbereitstellung auszulösen, damit Ihre Produktionsarbeitslasten sofort geplant werden können.
Infrastruktur als Code-Tools aktualisieren
Die folgenden Infrastruktur als Code-Anbieter unterstützen Autopilot:
Lesen Sie die Dokumentation Ihres bevorzugten Anbieters und ändern Sie Ihre Konfigurationen.
Migrationsansatz wählen
Welche Migrationsmethode Sie verwenden, hängt von der individuellen Arbeitslast und davon ab, wie gut Sie sich mit Netzwerkkonzepten wie Multi-Cluster-Diensten und Multi- Cluster-Ingress auskennen, und wie Sie den Status der Kubernetes-Objekte in dem Cluster verwalten.
| Arbeitslasttyp | Ergebnisse des Preflight-Tools | Migrationsansatz |
|---|---|---|
| Zustandslos |
|
Für |
| Zustandsorientiert |
|
Gehen Sie nach einer der folgenden Methoden vor:
|
| Zusätzliche Konfiguration erforderlich | Aktualisieren Sie Ihre Kubernetes-Manifeste und stellen Sie sie bei geplanten Ausfallzeiten auf Autopilot noch einmal bereit. Allgemeine Schritte finden Sie unter Zustandsorientierte Arbeitslasten manuell migrieren. |
Allgemeine Migrationsschritte
Prüfen Sie vor Beginn der Migration, ob alle Incompatible- oder Additional configuration required-Ergebnisse aus der Preflight-Prüfung aufgelöst wurden. Wenn Sie Arbeitslasten mit diesen Ergebnissen auf Autopilot ohne Änderungen bereitstellen, schlagen die Arbeitslasten fehl.
Die folgenden Abschnitte bieten einen allgemeinen Überblick über eine hypothetische Migration. Die tatsächlichen Schritte variieren je nach Umgebung und Arbeitslast. Planen, testen und testen Sie Arbeitslasten noch einmal auf Probleme, bevor Sie die Produktionsumgebung migrieren. Folgendes sollte dabei berücksichtigt werden:
- Die Dauer des Migrationsprozesses hängt von der Anzahl der Arbeitslasten ab, die Sie migrieren.
- Ausfallzeiten sind erforderlich, während Sie zustandsorientierte Arbeitslasten migrieren.
- Bei einer manuellen Migration können Sie sich auf einzelne Arbeitslasten konzentrieren, um Probleme in Echtzeit zu beheben.
- In allen Fällen müssen Sie dafür sorgen, dass Dienste, Ingress-Objekte und andere Kubernetes-Objekte migriert werden, die die Funktionalität Ihrer zustandslosen und zustandsorientierten Arbeitslasten ermöglichen.
Alle Arbeitslasten mit Backup for GKE migrieren
Wenn alle (zustandsorientierten und zustandslosen) Arbeitslasten in Ihrem Standardcluster mit Autopilot kompatibel sind und das Preflight-Tool entweder Passed oderPassed with optional configuration mit optionaler Konfiguration für jede Arbeitslast zurückgibt, können Sie Backup for GKE verwenden, um den gesamten Status Ihres Standardclusters und der Arbeitslasten zu sichern und die Sicherung im Autopilot-Cluster wiederherzustellen.
Dieser Ansatz bietet folgende Vorteile:
- Sie können alle Arbeitslasten mit minimalem Konfigurationsaufwand von Standard zu Autopilot verschieben.
- Sie können zustandslose und zustandsorientierte Arbeitslasten verschieben und die Beziehungen zwischen Arbeitslasten sowie die zugehörigen PersistentVolumes beibehalten.
- Rollbacks sind intuitiv und werden von Google verwaltet. Sie können die gesamte Migration rückgängig machen oder bestimmte Arbeitslasten selektiv zurücksetzen.
- Sie können zustandsorientierte Arbeitslasten in Google Cloud-Regionen migrieren. Die manuelle Migration zustandsorientierter Arbeitslasten kann nur in derselben Region erfolgen.
Wenn Sie diese Methode verwenden, wendet GKE Autopilot-Standardkonfigurationen auf Arbeitslasten an, die ein Passed with optional configuration-Ergebnis vom Preflight-Tool erhalten haben. Prüfen Sie vor der Migration dieser Arbeitslasten, ob Sie mit diesen Standardeinstellungen vertraut sind.
Zustandslose Arbeitslasten ohne Ausfallzeiten manuell migrieren
Wenn Sie zustandslose Arbeitslasten ohne Ausfallzeiten für Ihre Dienste migrieren möchten, registrieren Sie die Quell- und Zielcluster bei einer GKE Fleet und verwenden Multi-Cluster-Services und Multi-Cluster-Ingress, die dafür sorgen, dass Ihre Arbeitslasten während der Migration verfügbar bleiben.
- Aktivieren Sie Multi-Cluster-Services und Multi-Cluster-Ingress für den Quell- und Zielcluster. Eine Anleitung finden Sie unter Multi-Cluster-Services konfigurieren und Multi-Cluster-Ingress einrichten.
- Wenn Sie Backend-Abhängigkeiten wie eine Datenbankarbeitslast haben, exportieren Sie diese Dienste mit Multi-Cluster-Diensten aus Ihrem Standardcluster. Dadurch können Arbeitslasten in Ihrem Autopilot-Cluster auf die Abhängigkeiten im Standardcluster zugreifen. Eine Anleitung finden Sie unter Dienst für den Export registrieren.
- Stellen Sie einen Multi-Cluster-Ingress und einen Multi-Cluster-Dienst bereit, um den eingehenden Traffic zwischen Clustern zu steuern. Konfigurieren Sie den Multi-Cluster-Service so, dass nur Traffic an den Standard-Cluster gesendet wird. Eine Anleitung finden Sie unter Ingress clusterübergreifend bereitstellen.
- Stellen Sie zustandslose Arbeitslasten mit aktualisierten Manifesten im Autopilot-Cluster bereit. Ihre exportierten Multi-Cluster-Dienste stimmen automatisch mit den entsprechenden zustandsorientierten Arbeitslasten überein und senden sie an diese.
- Aktualisieren Sie den Multi-Cluster-Service, um eingehenden Traffic an den Autopilot-Cluster weiterzuleiten. Eine Anleitung finden Sie unter Clusterauswahl.
Sie stellen jetzt Ihre zustandslosen Arbeitslasten über den Autopilot-Cluster bereit. Wenn Sie im Quellcluster nur zustandslose Arbeitslasten hatten und keine Abhängigkeiten bestehen, fahren Sie mit Migration abschließen fort. Wenn Sie zustandsorientierte Arbeitslasten haben, fahren Sie mit Zustandsorientierte Arbeitslasten manuell migrieren fort.
Zustandsorientierte Arbeitslasten manuell migrieren
Nach der Migration Ihrer zustandslosen Arbeitslasten müssen Sie Ihre zustandsorientierten Arbeitslasten aus dem Standardcluster stilllegen und migrieren. Bei diesem Schritt kommt es zu einer Ausfallzeit für Ihren Cluster.
- Starten Sie die Ausfallzeit Ihrer Umgebung.
- Legen Sie Ihre zustandsorientierten Arbeitslasten still.
- Prüfen Sie, ob die Arbeitslastmanifeste für die Autopilot-Kompatibilität geändert wurden. Weitere Informationen finden Sie unter Arbeitslastspezifikationen basierend auf den Preflight-Ergebnissen ändern.
Arbeitslasten auf Ihrem Autopilot-Cluster bereitstellen
Stellen Sie die Dienste für Ihre zustandsorientierten Arbeitslasten im Autopilot-Cluster bereit.
Aktualisieren Sie das clusterinterne Netzwerk, damit Ihre zustandslosen Arbeitslasten weiterhin mit ihren Backend-Arbeitslasten kommunizieren können:
- Wenn Sie eine statische IP-Adresse in Ihren Backend-Diensten für Standardcluster verwendet haben, verwenden Sie diese IP-Adresse in Autopilot wieder.
- Wenn Kubernetes eine IP-Adresse zuweisen soll, stellen Sie Ihre Backend-Dienste bereit, rufen Sie die neue IP-Adresse ab und aktualisieren Sie Ihr DNS so, dass die neue IP-Adresse verwendet wird.
In dieser Phase sollte Folgendes zutreffen:
- Sie führen alle Ihre zustandslosen Arbeitslasten in Autopilot aus.
- Alle zustandsorientierten Backend-Arbeitslasten werden auch in Autopilot ausgeführt.
- Ihre zustandslosen und zustandsorientierten Arbeitslasten können miteinander kommunizieren.
- Der Multi-Cluster-Service leitet den gesamten eingehenden Traffic an Ihren Autopilot-Cluster weiter.
Wenn Sie alle Arbeitslasten und Kubernetes-Objekte zum neuen Cluster migriert haben, fahren Sie mit Migration abschließen fort.
Alternative: Alle Arbeitslasten während der Ausfallzeit manuell migrieren
Wenn Sie Multi-Cluster-Services und Multi-Cluster-Ingress nicht zum Migrieren von Arbeitslasten mit minimalen Ausfallzeiten verwenden möchten, migrieren Sie alle Arbeitslasten während der Ausfallzeit. Diese Methode führt zu einer längeren Ausfallzeit für Ihre Dienste, erfordert jedoch keine Arbeit mit Multi-Cluster-Features.
- Starten Sie die Ausfallzeit.
- Stellen Sie zustandslose Manifeste im Autopilot-Cluster bereit.
- Migrieren Sie Ihre zustandsorientierten Arbeitslasten manuell. Eine Anleitung dazu finden Sie im Abschnitt Zustandsorientierte Arbeitslasten manuell migrieren.
- Ändern Sie DNS-Einträge für clusterinternen und eingehenden externen Traffic so, dass sie die neuen IP-Adressen von Services verwenden.
- Beenden Sie die Ausfallzeit.
Migration abschließen
Nachdem Sie alle Arbeitslasten und Dienste in den neuen Autopilot-Cluster verschoben haben, beenden Sie die Ausfallzeit und lassen Sie zu, dass Ihre Umgebung für eine vorgegebene Dauer genutzt wird. Wenn Sie mit dem Status der Migration zufrieden sind und sicher sind, dass Sie die Migration nicht rückgängig machen müssen, können Sie die Migrationsartefakte bereinigen und die Migration abschließen.
Optional: Multi-Cluster-Features bereinigen
Wenn Sie Multi-Cluster-Ingress und Multi-Cluster-Services zur Migration verwendet haben und der Autopilot-Cluster nicht bei einer Flotte registriert bleiben soll, gehen Sie so vor:
- Stellen Sie für eingehenden externen Traffic einen Ingress bereit und legen Sie ihn auf die IP-Adresse der Dienste fest, die Ihre Arbeitslasten verfügbar machen. Eine Anleitung finden Sie unter Ingress für externe Anwendungs-Load-Balancer.
- Aktualisieren Sie für Cluster-internen Traffic von Frontend-Arbeitslasten auf zustandsorientierte Abhängigkeiten Cluster-DNS-Einträge, um die IP-Adressen dieser Dienste zu verwenden.
- Löschen Sie den Multi-Cluster-Ingress und die Multi-Cluster-Service-Ressourcen, die Sie während der Migration erstellt haben.
- Multi-Cluster-Ingress und Multi-Cluster-Dienste deaktivieren.
- Heben Sie die Registrierung des Autopilot-Clusters in der Flotte auf.
Standardcluster löschen
Wenn genügend Zeit verstrichen ist, nachdem die Migration abgeschlossen ist und Sie mit dem Status des neuen Clusters zufrieden sind, löschen Sie den Standardcluster. Wir empfehlen Ihnen, Ihre gesicherten Standardmanifeste beizubehalten.
Fehlerhafte Migration rückgängig machen
Wenn Probleme auftreten und Sie zum Standardcluster zurückkehren möchten, führen Sie je nach Art der Migration einen der folgenden Schritte aus:
Wenn Sie während der Migration „Backup for GKE“ verwendet haben, stellen Sie die Sicherungen im ursprünglichen Standardcluster wieder her. Eine Anleitung finden Sie unter Sicherung wiederherstellen.
Wenn Sie Arbeitslasten manuell migriert haben, wiederholen Sie die Migrationsschritte in den vorherigen Abschnitten mit dem Standardcluster als Ziel und dem Autopilot-Cluster als Quelle. Auf übergeordneter Ebene umfasst dies die folgenden Schritte:
- Starten Sie die Ausfallzeit.
- Migrieren Sie manuell zustandsorientierte Arbeitslasten manuell zum Standardcluster. Eine Anleitung dazu finden Sie im Abschnitt Zustandsorientierte Arbeitslasten manuell migrieren.
- Verschieben Sie zustandslose Arbeitslasten in den Standardcluster mit den ursprünglichen Manifesten, die Sie vor der Migration gesichert haben.
- Stellen Sie das Ingress im Standardcluster bereit und stellen Sie das DNS auf die neuen IP-Adressen für Services um.
- Löschen Sie den Autopilot-Cluster.
Nächste Schritte
- Autopilot-Anfragen anfordern
- Monitoring einrichten
- Sicherheitsstatus-Dashboard einrichten und verwenden