Tutorial: Automatisierte Validierungstests

Bei jedem Commit, das Arc-fähige Data Services aufbaut, führt Microsoft automatisierte CI/CD-Pipelines aus, die End-to-End-Tests durchführen. Diese Tests werden über zwei Container koordiniert, die neben dem Kernprodukt verwaltet werden. Bei diesen Containern handelt es sich um:

• arc-ci-launcher: Enthält Abhängigkeiten bei der Bereitstellung (z. B. CLI-Erweiterungen) sowie Code für die Bereitstellung von Produkten (mit der Azure CLI) sowohl für den direkten als auch den indirekten Verbindungsmodus. Sobald Kubernetes mit dem Datenverantwortlichen integriert ist, nutzt der Container Sonobuoy , um parallele Integrationstests auszulösen.
• arc-sb-plugin: Ein Sonobuoy-Plug-In mit Pytest-basierten End-to-End-Integrationstests, von einfachen Smoke-Tests (Bereitstellungen, Löschvorgänge) bis hin zu komplexen Hochverfügbarkeitsszenarien, Chaostests (Löschen von Ressourcen) usw.

Diese Testcontainer werden öffentlich zugänglich gemacht, damit Kunden und Partner Arc-fähige Data Services in ihren eigenen, an beliebigen Standorten betriebenen Kubernetes-Clustern testen und validieren können:

• Kubernetes-Distro/-Versionen
• Hostdistributionen/-versionen
• Speicher (StorageClass/CSI), Netzwerk (z. B. LoadBalancers, DNS)
• Weitere Kubernetes- oder infrastrukturspezifische Einrichtung

Kunden, die beabsichtigen, Arc-fähige Data Services auf einer nicht dokumentierten Distribution auszuführen, müssen diese Validierungstests erfolgreich durchführen, damit die Version als unterstützt betrachtet wird. Darüber hinaus können Partner diesen Ansatz nutzen, um die Konformität ihrer Lösung mit Arc-fähigen Data Services zu zertifizieren – siehe Kubernetes-Validierung von Data Services mit Azure Arc-Unterstützung.

Die folgende Abbildung skizziert diesen allgemeinen Prozess:

In diesem Tutorial lernen Sie Folgendes:

Prerequisites

• Credentials:

  • Die Datei test.env.tmpl enthält die erforderlichen Anmeldeinformationen und ist eine Kombination der vorhandenen Voraussetzungen, die zum Einbinden eines mit Azure Arc verbundenen Clusters und eines direkt verbundenen Datencontrollers erforderlich sind. Die Einrichtung dieser Datei wird im Folgenden anhand von Beispielen erläutert.
  • Eine kubeconfig-Datei für den getesteten Kubernetes-Cluster mit cluster-admin-Zugriff (derzeit zum Onboarding des verbundenen Clusters erforderlich)

• Client-tooling:

  • kubectl installiert - Mindestversion (Major: "1", Minor: "21")
  • git Befehlszeilenschnittstelle (oder UI-basierte Alternativen)

Vorbereitung des Kubernetes-Manifests

Das Startprogramm wird als Teil des microsoft/azure_arc-Repositories als Kustomize-Manifest verfügbar gemacht – Kustomize ist in kubectl integriert. Daher sind keine zusätzlichen Tools erforderlich.

1. Klonen Sie das Repository lokal:

git clone https://github.com/microsoft/azure_arc.git

2. Navigieren Sie zu azure_arc/arc_data_services/test/launcher, um die folgende Ordnerstruktur anzuzeigen:

├── base                                         <- Comon base for all Kubernetes Clusters
│   ├── configs
│   │   └── .test.env.tmpl                       <- To be converted into .test.env with credentials for a Kubernetes Secret
│   ├── kustomization.yaml                       <- Defines the generated resources as part of the launcher
│   └── launcher.yaml                            <- Defines the Kubernetes resources that make up the launcher
└── overlays                                     <- Overlays for specific Kubernetes Clusters
    ├── aks
    │   ├── configs
    │   │   └── patch.json.tmpl                  <- To be converted into patch.json, patch for Data Controller control.json
    │   └── kustomization.yaml
    ├── kubeadm
    │   ├── configs
    │   │   └── patch.json.tmpl
    │   └── kustomization.yaml
    └── openshift
        ├── configs
        │   └── patch.json.tmpl
        ├── kustomization.yaml
        └── scc.yaml

In diesem Tutorial konzentrieren wir uns auf die Schritte für AKS, aber die obige Overlaystruktur kann auf weitere Kubernetes-Distributionen erweitert werden.

Das einsatzbereite Manifest enthält Folgendes:

├── base
│   ├── configs
│   │   ├── .test.env                           <- Config 1: For Kubernetes secret, see sample below
│   │   └── .test.env.tmpl
│   ├── kustomization.yaml
│   └── launcher.yaml
└── overlays
    └── aks
        ├── configs
        │   ├── patch.json.tmpl
        │   └── patch.json                      <- Config 2: For control.json patching, see sample below
        └── kustomization.yam

Es gibt zwei Dateien, die erstellt werden müssen, um das Startprogramm für die Ausführung in einer bestimmten Umgebung zu lokalisieren. Jede dieser Dateien kann durch Kopieren und Ausfüllen der obigen Vorlagendateien (*.tmpl) erstellt werden:

• .test.env: ausfüllen von .test.env.tmpl
• patch.json: ausfüllen von patch.json.tmpl

Konfiguration 1: .test.env

Nachfolgend finden Sie ein ausgefülltes Beispiel Datei .test.env, die auf der Grundlage von .test.env.tmpl erstellt wurde (einschließlich von Inline-Kommentaren).

Anders ausgedrückt: Nachdem Sie .test.env.tmpl kopiert und bearbeitet haben, um .test.env zu erstellen, sollte die generierte Datei ähnlich wie das nachstehende Beispiel aussehen. Der Vorgang zum Ausfüllen der .test.env-Datei ist für alle Betriebssysteme und Terminals identisch.

Fertiges Beispiel für .test.env:

# ======================================
# Arc Data Services deployment version =
# ======================================

# Controller deployment mode: direct, indirect
# For 'direct', the launcher will also onboard the Kubernetes Cluster to Azure Arc
# For 'indirect', the launcher will skip Azure Arc and extension onboarding, and proceed directly to Data Controller deployment - see `patch.json` file
export CONNECTIVITY_MODE="direct"

# The launcher supports deployment of both GA/pre-GA trains - see detailed explanation below [1]
export ARC_DATASERVICES_EXTENSION_RELEASE_TRAIN="stable"
export ARC_DATASERVICES_EXTENSION_VERSION_TAG="1.11.0"

# Image version
export DOCKER_IMAGE_POLICY="Always"
export DOCKER_REGISTRY="mcr.microsoft.com"
export DOCKER_REPOSITORY="arcdata"
export DOCKER_TAG="v1.11.0_2022-09-13"

# "arcdata" Azure CLI extension version override - see detailed explanation below [2]
export ARC_DATASERVICES_WHL_OVERRIDE=""

# ================
# ARM parameters =
# ================

# Custom Location Resource Provider Azure AD Object ID - this is a single, unique value per Azure AD tenant - see detailed explanation below [3]
export CUSTOM_LOCATION_OID="..."

# A pre-rexisting Resource Group is used if found with the same name. Otherwise, launcher will attempt to create a Resource Group
# with the name specified, using the Service Principal specified below (which will require `Owner/Contributor` at the Subscription level to work)
export LOCATION="eastus"
export RESOURCE_GROUP_NAME="..."

# A Service Principal with "sufficient" privileges - see detailed explanation below [4]
export SPN_CLIENT_ID="..."
export SPN_CLIENT_SECRET="..."
export SPN_TENANT_ID="..."
export SUBSCRIPTION_ID="..."

# Optional: certain integration tests test upload to Log Analytics workspace:
# https://learn.microsoft.com/azure/azure-arc/data/upload-logs
export WORKSPACE_ID="..."
export WORKSPACE_SHARED_KEY="..."

# ====================================
# Data Controller deployment profile =
# ====================================

# Samples for AKS
# To see full list of CONTROLLER_PROFILE, run: az arcdata dc config list
export CONTROLLER_PROFILE="azure-arc-aks-default-storage"

# azure, aws, gcp, onpremises, alibaba, other
export DEPLOYMENT_INFRASTRUCTURE="azure"

# The StorageClass used for PVCs created during the tests 
export KUBERNETES_STORAGECLASS="default"

# ==============================
# Launcher specific parameters =
# ==============================

# Log/test result upload from launcher container, via SAS URL - see detailed explanation below [5]
export LOGS_STORAGE_ACCOUNT="<your-storage-account>"
export LOGS_STORAGE_ACCOUNT_SAS="?sv=2021-06-08&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=...&spr=https&sig=..."
export LOGS_STORAGE_CONTAINER="arc-ci-launcher-1662513182"

# Test behavior parameters
# The test suites to execute - space seperated array, 
# Use these default values that run short smoke tests, further elaborate test suites will be added in upcoming releases
export SQL_HA_TEST_REPLICA_COUNT="3"
export TESTS_DIRECT="direct-crud direct-hydration controldb"
export TESTS_INDIRECT="billing controldb kube-rbac"
export TEST_REPEAT_COUNT="1"
export TEST_TYPE="ci"

# Control launcher behavior by setting to '1':
#
# - SKIP_PRECLEAN: Skips initial cleanup
# - SKIP_SETUP: Skips Arc Data deployment
# - SKIP_TEST: Skips sonobuoy tests
# - SKIP_POSTCLEAN: Skips final cleanup
# - SKIP_UPLOAD: Skips log upload
#
# See detailed explanation below [6]
export SKIP_PRECLEAN="0"
export SKIP_SETUP="0"
export SKIP_TEST="0"
export SKIP_POSTCLEAN="0"
export SKIP_UPLOAD="0"

Ausführliche Erläuterung für bestimmte Variablen

1. ARC_DATASERVICES_EXTENSION_* – Erweiterungsversion und Train

Obligatorisch: Diese Variable ist für Bereitstellungen im Modus direct erforderlich.

Das Startprogramm kann sowohl GA- als auch Prä-GA-Versionen bereitstellen.

Die Zuordnung der Erweiterungsversion zum Releasetrain (ARC_DATASERVICES_EXTENSION_RELEASE_TRAIN) wird von hier aus abgerufen:

• GA: stable - Versionsprotokoll
• Vor AV: preview - Vor-Release-Tests

2. ARC_DATASERVICES_WHL_OVERRIDE – Download-URL für vorherige Azure CLI-Version

Optional: Lassen Sie diese Variable in .test.env leer, um die vordefinierte Standardeinstellung zu verwenden.

Das Startprogrammimage ist zum Veröffentlichungszeitpunkt der einzelnen Containerimages mit der neuesten arcdata-CLI-Version vorkonfiguriert. Um jedoch mit älteren Versionen und Upgradetests zu arbeiten, kann es erforderlich sein, das Startprogramm mit dem Downloadlink für Azure CLI Blob URL bereitzustellen, um die vorab verpackte Version außer Kraft zu setzen; Geben Sie z. B. das Startprogramm an, Version 1.4.3 zu installieren, folgendes ausfüllen:

export ARC_DATASERVICES_WHL_OVERRIDE="https://azurearcdatacli.blob.core.windows.net/cli-extensions/arcdata-1.4.3-py2.py3-none-any.whl"

Die CLI-Version zur BLOB-URL-Zuordnung finden Sie hier.

3. CUSTOM_LOCATION_OID – Benutzerdefinierte Objekt-ID des Locations-Objekts von Ihrem spezifischen Microsoft Entra-Mandanten

Obligatorisch: Diese Variable ist zum Erstellen des benutzerdefinierten Speicherorts für den verbundenen Cluster erforderlich.

Anhand der folgenden Schritte aus Aktivieren benutzerdefinierter Speicherorte im Cluster können Sie die eindeutige Objekt-ID eines benutzerdefinierten Speicherorts für Ihren Microsoft Entra-Mandanten abrufen.

Es gibt zwei Ansätze zum Abrufen des CUSTOM_LOCATION_OID Microsoft Entra-Mandanten.

1. Über die Azure CLI:

   az ad sp show --id bc313c14-388c-4e7d-a58e-70017303ee3b --query objectId -o tsv
   # 51dfe1e8-70c6-4de...      <--- This is for Microsoft's own tenant - do not use, the value for your tenant will be different, use that instead to align with the Service Principal for launcher.
   

   

2. Navigieren Sie über das Azure-Portal zu Ihrem Microsoft Entra-Blatt, und suchen Sie nach Custom Locations RP:

   

4. SPN_CLIENT_* – Anmeldeinformationen für Dienstprinzipal

Obligatorisch: Diese Variable ist für Bereitstellungen im direkten Modus erforderlich.

Das Startprogramm meldet sich mit diesen Anmeldeinformationen bei Azure an.

Die Validierungstests sollen auf Nicht-Produktions-/Test-Kubernetes Cluster & Azure-Abonnements durchgeführt werden - mit Schwerpunkt auf der funktionalen Validierung der Kubernetes/Infrastruktur-Einrichtung. Um die zur Durchführung von Starts erforderlichen manuellen Schritte zu vermeiden, empfiehlt es sich daher, ein SPN_CLIENT_ID/SECRET anzugeben, das über die Rolle Owner auf Ebene der Ressourcengruppe (oder des Abonnements) verfügt. Dadurch werden mehrere Ressourcen in dieser Ressourcengruppe erstellt, und diesen Ressourcen werden Berechtigungen für verschiedene verwaltete Identitäten zugewiesen, die im Rahmen der Bereitstellung erstellt wurden (diese Rollenzuweisungen erfordern wiederum, dass dem Dienstprinzipal die Rolle Owner zugewiesen ist).

5. LOGS_STORAGE_ACCOUNT_SAS – SAS-URL für Blob Storage-Konto

Empfohlen: Wenn Sie diese Variable leer lassen, erhalten Sie keine Testergebnisse und Protokolle.

Das Startprogramm benötigt einen persistenten Speicherort (Azure Blob Storage), um Ergebnisse hochzuladen, da Kubernetes (noch) das Kopieren von Dateien von angehaltenen/abgeschlossenen Pods nicht zulässt – siehe hier. Das Startprogramm stellt die Verbindung mit Azure Blob Storage über eine kontospezifische SAS-URL (im Gegensatz zur container- oder blobspezifischen URL) her. Dabei handelt es sich um eine signierte URL mit einer Definition für den zeitlich begrenzten Zugriff – siehe Gewähren von eingeschränktem Zugriff auf Azure Storage-Ressourcen mithilfe von SAS (Shared Access Signature). Dies geschieht, um folgende Aufgaben auszuführen:

1. Erstellen eines neuen Speichercontainers im bestehenden Speicherkonto (LOGS_STORAGE_ACCOUNT), sofern dieser noch nicht vorhanden ist (Name basiert auf LOGS_STORAGE_CONTAINER)
2. Erstellen eines neuen, eindeutig benannten Blobs (Testprotokoll-TAR-Dateien)

Die folgenden Schritte stammen aus Gewähren von eingeschränktem Zugriff auf Azure Storage-Ressourcen mithilfe von SAS (Shared Access Signature).

?sv=2021-06-08&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=...&spr=https&sig=...

Es gibt verschiedene Ansätze zum Generieren einer SAS-URL. In diesem Beispiel wird das Portal gezeigt:

Wenn Sie stattdessen die Azure CLI verwenden möchten, finden Sie weitere Informationen unter az storage account generate-sas.

6. SKIP_* – Steuern des Startprogrammverhaltens durch Überspringen bestimmter Stufen

Optional: Lassen Sie diese Variable in .test.env leer, um alle Stufen auszuführen (gleichbedeutend mit 0 oder leer).

Das Startprogramm macht SKIP_*-Variablen verfügbar, um bestimmte Schritte auszuführen und zu überspringen – etwa, um eine Ausführung ausschließlich zur Bereinigung durchzuführen.

Wenngleich das Startprogramm so konzipiert ist, dass sowohl zu Beginn als auch am Ende jeder Ausführung eine Bereinigung stattfindet, bleiben aufgrund von Start- und/oder Testfehlern möglicherweise Ressourcenrückstände zurück. Um das Startprogramm im reinen Bereinigungsmodus auszuführen, legen Sie die folgenden Variablen in .test.env fest:

export SKIP_PRECLEAN="0"         # Run cleanup
export SKIP_SETUP="1"            # Do not setup Arc-enabled Data Services
export SKIP_TEST="1"             # Do not run integration tests
export SKIP_POSTCLEAN="1"        # POSTCLEAN is identical to PRECLEAN, although idempotent, not needed here
export SKIP_UPLOAD="1"           # Do not upload logs from this run

Die obigen Einstellungen weisen das Startprogramm an, alle Ressourcen von Arc und Arc-Data Services zu bereinigen und keine Protokolle bereitzustellen/zu testen/zu laden.

Konfiguration 2: patch.json

Nachfolgend finden Sie ein ausgefülltes Beispiel der Datei patch.json, die auf der Grundlage von patch.json.tmpl erstellt wurde (einschließlich von Inline-Kommentaren):

Hinweis: spec.docker.registry, repository, imageTag sollte mit den Werten in der obigen .test.env-Datei identisch sein.

Fertiges Beispiel für patch.json:

{
    "patch": [
        {
            "op": "add",
            "path": "spec.docker",
            "value": {
                "registry": "mcr.microsoft.com",
                "repository": "arcdata",
                "imageTag": "v1.11.0_2022-09-13",
                "imagePullPolicy": "Always"
            }
        },        
        {
            "op": "add",
            "path": "spec.storage.data.className",
            "value": "default"
        },  
        {
            "op": "add",
            "path": "spec.storage.logs.className",
            "value": "default"
        }                  
    ]
}

Launcher-Bereitstellung

Es wird empfohlen, das Startprogramm in einem Nicht-Produktions-/Testcluster bereitzustellen – da es destruktive Aktionen für Arc- und andere verwendete Kubernetes-Ressourcen ausführt.

imageTag Spezifikation

Das Startprogramm wird im Kubernetes-Manifest als Job definiert. Dazu muss Kubernetes mitgeteilt werden, wo das Image des Startprogramms zu finden ist. Diese Festlegung erfolgt in base/kustomization.yaml:

images:
- name: arc-ci-launcher
  newName: mcr.microsoft.com/arcdata/arc-ci-launcher
  newTag: v1.11.0_2022-09-13

kubectl apply

Um sicherzustellen, dass das Manifest ordnungsgemäß eingerichtet wurde, führen Sie eine clientseitige Validierung mit --dry-run=client durch. Diese gibt die Kubernetes-Ressourcen aus, die für das Startprogramm erstellt werden müssen:

kubectl apply -k arc_data_services/test/launcher/overlays/aks --dry-run=client
# namespace/arc-ci-launcher created (dry run)
# serviceaccount/arc-ci-launcher created (dry run)
# clusterrolebinding.rbac.authorization.k8s.io/arc-ci-launcher created (dry run)
# secret/test-env-fdgfm8gtb5 created (dry run)                                        <- Created from Config 1: `patch.json`
# configmap/control-patch-2hhhgk847m created (dry run)                                <- Created from Config 2: `.test.env`
# job.batch/arc-ci-launcher created (dry run)

Führen Sie die folgenden Schritte aus, um das Startprogramm und die Protokollfragmente bereitzustellen:

kubectl apply -k arc_data_services/test/launcher/overlays/aks
kubectl wait --for=condition=Ready --timeout=360s pod -l job-name=arc-ci-launcher -n arc-ci-launcher
kubectl logs job/arc-ci-launcher -n arc-ci-launcher --follow

Nun sollte das Startprogramm starten – und Sie sollten Folgendes sehen:

Am besten stellen Sie das Startprogramm in einem Cluster ohne bereits vorhandene Arc-Ressourcen bereit. Das Startprogramm umfasst jedoch eine Preflight-Überprüfung, um bereits vorhandene benutzerdefinierte Ressourcendefinitionen und ARM-Ressourcen von Arc und Arc-Data Services zu erkennen, und versucht, diese vor der Bereitstellung der neuen Version bestmöglich zu bereinigen (unter Verwendung der bereitgestellten Anmeldeinformationen für den Dienstprinzipal):

Derselbe Prozess der Metadatenermittlung und -bereinigung wird auch beim Beenden des Startprogramms durchgeführt, um den Cluster weitestgehend in dem Zustand zurückzuversetzen, in dem er sich vor dem Start befand.

Vom Startprogramm ausgeführte Schritte

Allgemein betrachtet führt das Startprogramm die folgende Abfolge von Schritten durch:

1. Authentifizierung bei der Kubernetes-API mithilfe eines podgebundenen Dienstkontos.

2. Authentifizierung bei der ARM-API mithilfe eines geheimnisgebundenen Dienstkontos.

3. Durchführen einer CRD-Metadatenüberprüfung zum Ermitteln vorhandener benutzerdefinierter Ressourcen von Arc und Arc-Data Services.

4. Bereinigen aller vorhandenen benutzerdefinierten Ressourcen in Kubernetes sowie nachfolgend der Ressourcen in Azure. Beendigung, falls die Anmeldedaten in .test.env nicht mit den im Cluster vorhandenen Ressourcen übereinstimmen.

5. Generieren eines eindeutigen Satzes von Umgebungsvariablen basierend auf dem Zeitstempel für den Arc-Clusternamen, den Datencontroller und den benutzerdefinierten Speicherort/Namespace. Ausgabe der Umgebungsvariablen, wobei vertrauliche Werte unkenntlich gemacht werden (z. B. das Kennwort für den Dienstprinzipal usw.).

6. a. Für den direkten Modus – Durchführen des Onboarding des Clusters in Azure Arc, anschließend Bereitstellung des Controllers.

   b. Für den indirekten Modus: Bereitstellen des Datencontrollers.

7. Sobald der Datencontroller in den Zustand Ready übergegangen ist, werden verschiedene Azure CLI-Protokolle (az arcdata dc debug) erstellt und lokal gespeichert, gekennzeichnet als setup-complete – als Baseline.

8. Verwenden der Umgebungsvariable TESTS_DIRECT/INDIRECT aus .test.env zum Starten einer Reihe parallelisierter Sonobuoy-Testläufe basierend auf einem durch Leerzeichen getrennten Array (TESTS_(IN)DIRECT). Diese Ausführungen erfolgen in einem neuen sonobuoy-Namespace unter Verwendung eines arc-sb-plugin-Pods, der die Pytest-Validierungstests enthält.

9. Der Sonobuoy-Aggregator sammelt die junit Testergebnisse und Protokolle pro arc-sb-plugin Testlauf, welche in den Startpod exportiert werden.

10. Rückgabe des Exitcodes der Tests und Generierung eines weiteren Satzes von Debugprotokollen – Azure CLI und sonobuoy –, die lokal gespeichert und als test-complete gekennzeichnet werden.

11. Durchführen einer CRD-Metadatenüberprüfung (ähnlich wie in Schritt 3) zum Ermitteln vorhandener benutzerdefinierter Ressourcen von Arc und Arc-Data Services Anschließende Zerstörung aller Arc-Ressourcen und Arc-Datenressourcen in umgekehrter Reihenfolge ihrer Bereitstellung sowie der benutzerdefinierten Ressourcendefinitionen, Rollen/Clusterrollen, PV/PVCs usw.

12. Versuchen Sie, das bereitgestellte LOGS_STORAGE_ACCOUNT_SAS zu verwenden, um einen neuen Speicherkonto-Container zu erstellen, der basierend auf LOGS_STORAGE_CONTAINER im bereits vorhandenen Speicherkonto LOGS_STORAGE_ACCOUNT benannt werden soll. Wenn der Speicherkontocontainer bereits vorhanden ist, wird er verwendet. Hochladen aller lokalen Testergebnisse und Protokolle in diesen Speichercontainer als Tarball (siehe unten).

13. Exit.

Pro Testsammlung durchgeführte Tests

Es gibt ca. 375 einzigartige Integrationstests, die über 27 Testsuiten verteilt sind – jede testet eine separate Funktionalität.

Zum Beispiel werden für sqlinstance-ha die folgenden Tests durchgeführt:

• test_critical_configmaps_present: Stellt sicher, dass die ConfigMaps und die relevanten Felder für eine SQL-Instanz vorhanden sind.
• test_suspended_system_dbs_auto_heal_by_orchestrator: Stellt sicher, dass master und msdb auf irgendeine Weise suspendiert sind (in diesem Fall durch einen Benutzer). Der Abstimmungsvorgang bei der Orchestratorwartung behebt dies automatisch.
• test_suspended_user_db_does_not_auto_heal_by_orchestrator: Stellt sicher, dass der Orchestrator-Wartungsabgleich eine Benutzerdatenbank nicht automatisch wiederherstellt, wenn sie von einem Benutzer absichtlich ausgesetzt wurde.
• test_delete_active_orchestrator_twice_and_delete_primary_pod: Löscht den Orchestrator Pod mehrfach, gefolgt von der primären Replik, und verifiziert, dass alle Repliken synchronisiert sind. Die Erwartungen im Hinblick auf die Failoverzeit für 2 Replikate sind gelockert.
• test_delete_primary_pod: Löscht das primäre Replikat und verifiziert, dass alle Repliken synchronisiert sind. Die Erwartungen im Hinblick auf die Failoverzeit für 2 Replikate sind gelockert.
• test_delete_primary_and_orchestrator_pod: Löscht das primäre Replikat und den Orchestrator Pod und verifiziert, dass alle Repliken synchronisiert sind.
• test_delete_primary_and_controller: Löscht die primäre Replik und den Data Controller Pod und verifiziert, dass der primäre Endpunkt zugänglich ist und die neue primäre Replik synchronisiert ist. Die Erwartungen im Hinblick auf die Failoverzeit für 2 Replikate sind gelockert.
• test_delete_one_secondary_pod: Löscht die sekundäre Replik und den Data Controller Pod und verifiziert, dass alle Repliken synchronisiert sind.
• test_delete_two_secondaries_pods: Löscht sekundäre Repliken und den Data Controller Pod und verifiziert, dass alle Repliken synchronisiert sind.
• test_delete_controller_orchestrator_secondary_replica_pods:
• test_failaway: Erzwingt ein Failover der AG weg vom aktuellen primären Replikat und stellt sicher, dass das neue primäre Replikat nicht mit dem alten primären Replikat identisch ist. Überprüft, ob alle Replikate synchronisiert wurden.
• test_update_while_rebooting_all_non_primary_replicas: Testet, ob Controller-gesteuerte Aktualisierungen trotz verschiedener turbulenter Umstände resilient sind und wiederholt werden.

Untersuchen der Testergebnisse

Ein Beispiel für einen Speichercontainer und eine Datei, die vom Startprogramm hochgeladen wurden:

Und hier die Testergebnisse, die für die Ausführung generiert wurden:

Bereinigen von Ressourcen

Führen Sie zum Löschen des Startprogramm den folgenden Befehl aus:

kubectl delete -k arc_data_services/test/launcher/overlays/aks

Hierdurch werden die Ressourcenmanifeste bereinigt, die als Bestandteil des Startprogramms bereitgestellt wurden.

Verwandte Inhalte