共用方式為

教學課程：自動化驗證測試

  • 發行項

在建置已啟用 Arc 的資料服務的每個認可中，Microsoft 會執行執行端對端測試的自動化 CI/CD 管線。 這些測試會透過與核心產品一起維護的兩個容器進行協調 (資料控制器、Azure Arc 和 PostgreSQL 伺服器啟用的 SQL 受控執行個體)。 這些容器包括：

  • arc-ci-launcher：包含部署相依性 (例如 CLI 延伸模組)，以及產品部署程式碼 (使用 Azure CLI)，以用於直接和間接連線模式。 一旦 Kubernetes 使用資料控制器上線，容器會利用 Sonobuoy 來觸發平行整合測試。
  • arc-sb-plugin：包含 Pytest 型端對端整合測試的 Sonobuoy 外掛程式，範圍從簡單的煙霧測試 (部署、刪除)，到複雜的高可用性案例、混亂測試 (資源刪除) 等。

這些測試容器會公開提供給客戶和合作夥伴，在其於任何位置執行的 Kubernetes 叢集中執行已啟用 Arc 的資料服務驗證測試，以驗證：

  • Kubernetes 發行版本/版本
  • 主機發行版本/版本
  • 儲存體 (StorageClass/CSI)、網路功能 (例如 LoadBalancers、DNS)
  • 其他 Kubernetes 或基礎結構特定設定

對於想要在未記載的發行版本上執行已啟用 Arc 的資料服務的客戶，他們必須成功執行這些驗證測試，才能被視為受支援。 此外，合作夥伴可以使用這種方法來認證其解決方案符合已啟用 Arc 的資料服務規範 - 請參閱已啟用 Azure Arc 的資料服務 Kubernetes 驗證。

下圖概述此概括流程：

顯示已啟用 Arc 的資料服務 Kube 原生整合測試的圖表。

在本教學課程中，您會了解如何：

  • 使用 kubectl 部署 arc-ci-launcher
  • 檢查 Azure Blob 儲存體帳戶中的驗證測試結果

必要條件

  • 認證：

  • 用戶端工具：

    • kubectl 已安裝 - 最低版本 (主要：「1」，次要：「21」)
    • git 命令列介面 (或 UI 型替代方案)

Kubernetes 資訊清單準備

啟動器會作為 microsoft/azure_arc 存放庫的一部分提供，以作為 Kustomize 資訊清單，而 Kustomize 會內建於 kubectl，因此不需要額外的工具。

  1. 在本機複製存放庫：
git clone https://github.com/microsoft/azure_arc.git
  1. 瀏覽至 azure_arc/arc_data_services/test/launcher，以檢視下列資料夾結構：
├── 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

在本教學課程中，我們將著重於 AKS 的步驟，但可以擴充上述重疊結構以包含額外的 Kubernetes 發行版本。

準備部署資訊清單將代表下列事項：

├── 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

需要產生兩個檔案，才能將啟動器當地語系化，以在特定環境中執行。 上述每個檔案都可以透過複製貼上和填寫上述每個範本 (*.tmpl) 檔案來產生：

  • .test.env：填寫來源 .test.env.tmpl
  • patch.json：填寫來源 patch.json.tmpl

提示

.test.env 是一組驅動啟動器行為的單一環境變數。 針對指定的環境時產生它可確保啟動器行為的重現性。

組態 1：.test.env

根據 .test.env.tmpl 產生的 .test.env 檔案填滿範例會與內嵌註解共用。

重要

下列 export VAR="value" 語法不是用於本機執行以從您的電腦獲得環境變數，而是針對啟動器。 啟動器會使用 Kustomize 的 secretGenerator 以現況掛接此 .test.env 檔案作為 Kubernetes secret (Kustomize 會採用檔案、base64 編碼整個檔案的內容，並將其轉換成 Kubernetes 祕密)。 初始化期間，啟動器會執行 bash 的 source 命令，它會將環境變數從以現況掛接的 .test.env 檔案匯入啟動器的環境。

換句話說，在複製貼上 .test.env.tmpl 並編輯以建立 .test.env 之後，產生的檔案看起來應該類似下列範例。 填寫 .test.env 檔案的流程在作業系統和終端之間完全相同。

提示

有幾個環境變數需要額外的說明，以清楚說明重現性。 這些會以 see detailed explanation below [X] 加上註解。

提示

請注意，下列 .test.env 範例適用於直接模式。 其中某些變數，例如 ARC_DATASERVICES_EXTENSION_VERSION_TAG 不適用於間接模式。 為了簡單起見，最好使用直接模式變數來設定 .test.env 檔案，切換 CONNECTIVITY_MODE=indirect 會讓啟動器忽略直接模式特定設定，並使用清單中的子集。

換句話說，規劃直接模式可讓我們滿足間接模式變數。

已完成的 .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"

重要

如果在 Windows 電腦中執行組態檔產生，您必須將行結尾序列從 CRLF (Windows) LF 轉換為 (Linux)，以 arc-ci-launcher Linux 容器的形式執行。 將行結尾保留為 CRLF 可能會在 arc-ci-launcher 容器啟動時造成錯誤，例如：/launcher/config/.test.env: $'\r': command not found 例如，使用 VSCode 執行變更 (視窗右下角)：
此螢幕擷取畫面顯示變更行結尾序列 (CRLF) 的位置。

特定變數的詳細說明

1. ARC_DATASERVICES_EXTENSION_* - 延伸模組版本和定型

必要：這是 direct 模式部署的必要項目。

啟動器可以部署正式發行和正式發行前版本。

用於發行版本定型 (ARC_DATASERVICES_EXTENSION_RELEASE_TRAIN) 對應的延伸模組版本從這裡取得：

2. ARC_DATASERVICES_WHL_OVERRIDE - Azure CLI 舊版下載 URL

選擇性：在 .test.env 中將此保留空白，以使用預先封裝的預設值。

啟動器映像會在每個容器映像發行時，使用最新的 arcdata CLI 版本預先封裝。 不過，若要使用較舊的版本和升級測試，可能需要提供啟動器與 Azure CLI Blob URL 下載連結，以覆寫預先封裝的版本；例如，若要指示啟動器安裝 1.4.3 版，請填入：

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

您可以在這裡找到 CLI 版本與 Blob URL 對應。

3. CUSTOM_LOCATION_OID - 來自特定 Microsoft Entra 租用戶的自訂位置物件識別碼

必要：這是連線叢集自訂位置建立的必要項目。

下列步驟來自啟用叢集上的自訂位置，以擷取 Microsoft Entra 租用戶的唯一自訂位置物件識別碼。

有兩種方法可取得 Microsoft Entra 租用戶的 CUSTOM_LOCATION_OID。

  1. 透過 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.

    PowerShell 終端機的螢幕擷取畫面，其中顯示 az ad sp show --id <>。

  2. 透過 Azure 入口網站 - 瀏覽至您的 Microsoft Entra 刀鋒視窗，然後搜尋 Custom Locations RP：

    自訂位置 RP 的螢幕擷取畫面。

4. SPN_CLIENT_* - 服務主體認證

必要：這是直接模式部署的必要項目。

啟動器會使用這些認證登入 Azure。

驗證測試是要在非生產/測試 Kubernetes 叢集和 Azure 訂用帳戶上執行，著重於 Kubernetes/基礎結構設定的功能驗證。 因此，若要避免執行啟動所需的手動步驟數目，建議您在資源群組 (或訂用帳戶) 層級提供具有 Owner 的 SPN_CLIENT_ID/SECRET，因為它會在此資源群組中建立數個資源，以及針對部署期間所建立的數個受控識別指派權限給這些資源 (這些角色指派接著需要服務主體擁有 Owner)。

5. LOGS_STORAGE_ACCOUNT_SAS - Blob 儲存體帳戶 SAS URL

建議：將此項目保留空白表示您不會取得測試結果和記錄。

啟動器需要持續性位置 (Azure Blob 儲存體) 才能將結果上傳，因為 Kubernetes 尚未允許從已停止/已完成的 Pod 複製檔案 - 請參閱這裡。 啟動器會使用帳戶範圍的 SAS URL 來達到 Azure Blob 儲存體的連線能力 (而不是容器或 Blob 範圍) - 具有時間限制存取定義的已簽署 URL - 請參閱使用共用存取簽章授與有限的 Azure 儲存體資源存取權，以便：

  1. 如果儲存體帳戶不存在，請在預先存在的儲存體帳戶 (LOGS_STORAGE_ACCOUNT) 中建立新的儲存體容器 (根據 LOGS_STORAGE_CONTAINER 命名)
  2. 建立新的、唯一命名的 Blob (測試記錄 tar 檔案)

下列步驟來自於使用共用存取簽章 (SAS) 對 Azure 儲存體資源授與有限存取權。

提示

SAS URL 與儲存體帳戶金鑰不同，SAS URL 的格式如下。

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

有數種方法可以產生 SAS URL。 這個範例顯示入口網站：

Azure 入口網站上共用存取簽章詳細資料的螢幕擷取畫面。

若要改為使用 Azure CLI，請參閱 az storage account generate-sas

6. SKIP_* - 跳過特定階段來控制啟動器行為

選擇性：將此空白保留在 .test.env 中以執行所有階段 (相當於 0 或空白)

啟動器會公開 SKIP_* 變數，以執行和略過特定階段 - 例如，執行「僅清除」執行。

雖然啟動器是設計來在每次執行的開頭和結尾進行清除，但啟動和/或測試失敗可能會留下殘留資源。 若要以「僅清除」模式執行啟動器，請在 .test.env 中設定下列變數：

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

上述設定會指示啟動器清除所有 Arc 和 Arc 資料服務資源，以及不要部署/測試/上傳記錄。

組態 2：patch.json

根據 patch.json.tmpl 產生的 patch.json 檔案填滿範例會在下方共用：

請注意，spec.docker.registry, repository, imageTag 應該與上述的 .test.env 值相同

已完成的 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"
        }                  
    ]
}

啟動器部署

建議您在非生產/測試叢集中部署啟動器，因為它會在 Arc 和其他已使用的 Kubernetes 資源上執行破壞性動作。

imageTag 規格

啟動器會在 Kubernetes 資訊清單內定義為 Job，其需要指示 Kubernetes 在何處尋找啟動器映像。 這是在 base/kustomization.yaml 中設定的：

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

提示

回顧一下，此時我們指定 imageTag 的 3 個地方，為了清楚起見，以下是每個不同用途的說明。 通常 - 測試指定的版本時，所有 3 個值都會相同 (符合指定的版本)：

# 檔案名稱 變數名稱 為什麼？ 使用者？
1 .test.env DOCKER_TAG 來自於延伸模組安裝期間的啟動載入器映像 az k8s-extension create 在啟動器中
2 patch.json value.imageTag 來自於資料控制器映像 az arcdata dc create 在啟動器中
3 kustomization.yaml images.newTag 來自於啟動器的映像 kubectl apply 啟動器

kubectl apply

若要驗證資訊清單是否已正確設定，請使用 --dry-run=client 嘗試客戶端驗證，以列印要為啟動器建立的 Kubernetes 資源：

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)

若要部署啟動器和追蹤記錄，請執行下列操作：

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

此時，啟動器應該啟動，而您應該會看到下列內容：

啟動器啟動後主控台終端機的螢幕擷取畫面。

雖然最好在沒有預先存在的 Arc 資源叢集中部署啟動器，但啟動器包含行前驗證，以探索預先存在的 Arc 和 Arc 資料服務 CRD 與 ARM 資源，並嘗試在部署新版本之前，盡最大努力清除它們 (使用所提供的服務主體認證)：

主控台終端機探索 Kubernetes 和其他資源的螢幕擷取畫面。

這個相同的中繼資料探索和清除流程也會在啟動器結束時執行，讓叢集在啟動前盡可能接近其現有狀態。

啟動器執行的步驟

概括而言，啟動器會執行下列步驟順序：

  1. 使用 Pod 掛接的服務帳戶向 Kubernetes API 進行驗證

  2. 使用祕密掛接的服務主體向 ARM API 進行驗證

  3. 執行 CRD 中繼資料掃描以探索現有的 Arc 和 Arc 資料服務自訂資源

  4. 清除 Kubernetes 中的任何現有自訂資源，以及 Azure 中的後續資源。 如果與叢集中現有資源相比，.test.env 中認證之間有任何不相符的情況，則會結束。

  5. 根據 Arc 叢集名稱、資料控制器和自訂位置/命名空間的時間戳記，產生一組唯一的環境變數。 印出環境變數、模糊化敏感性值 (例如服務主體密碼等)

  6. a. 針對直接模式 - 將叢集上線至 Azure Arc，然後部署控制器。

    b. 針對間接模式：部署資料控制器

  7. 一旦資料控制器是 Ready，請產生一組 Azure CLI (az arcdata dc debug) 記錄並儲存在本機，標示為 setup-complete - 作為基準。

  8. 使用 .test.env 的 TESTS_DIRECT/INDIRECT 環境變數，根據以空格分隔的陣列 (TESTS_(IN)DIRECT) 啟動一組平行化的 Sonobuoy 測試回合。 這些測試會在新的 sonobuoy 命名空間中執行，並使用包含 Pytest 驗證測試的 arc-sb-plugin Pod。

  9. Sonobuoy 匯總工具會累積每個 arc-sb-plugin 測試回合的junit測試結果和記錄，其會匯出至啟動器 Pod。

  10. 傳回測試的結束代碼，並產生另一組偵錯記錄 - Azure CLI 和 sonobuoy - 儲存在本機，標示為 test-complete。

  11. 執行類似步驟 3 的 CRD 中繼資料掃描，以探索現有的 Arc 和 Arc 資料服務自訂資源。 然後，繼續以反向順序從部署終結所有 Arc 和 Arc 資料資源，以及 CRD、Role/ClusterRoles、PV/PVC 等。

  12. 嘗試使用提供的 SAS 權杖 LOGS_STORAGE_ACCOUNT_SAS，在預先存在的儲存體帳戶 LOGS_STORAGE_ACCOUNT 中建立根據 LOGS_STORAGE_CONTAINER 命名的新儲存體帳戶容器。 如果儲存體帳戶容器已經存在，請使用它。 將所有本機測試結果和記錄上傳至此儲存體容器作為 tarball (請參閱下方)。

  13. 結束。

每個測試套件執行的測試

在 27 個測試套件中 ，有大約 375 個唯一整合測試可供使用，每個測試都會有個別的功能。

套件編號 測試套件名稱 測試的描述
1 ad-connector 測試 Active Directory 連接器 (AD 連接器) 的部署和更新。
2 billing 測試各種業務關鍵授權類型會反映在控制器中的資源資料表中，以用於計費上傳。
3 ci-billing 類似於 billing，但具有更多 CPU/記憶體排列。
4 ci-sqlinstance 長時間執行多複本建立、更新、GP -> BC 更新、備份驗證和 SQL Server Agent 的測試。
5 controldb 測試控制資料庫 - SA 祕密檢查、系統登入驗證、稽核建立，以及 SQL 組建版本的健全性檢查。
6 dc-export 間接模式計費和使用量上傳。
7 direct-crud 使用 ARM 呼叫建立 SQL 執行個體，並在 Kubernetes 和 ARM 中驗證。
8 direct-fog 建立多個 SQL 執行個體，並使用 ARM 呼叫在它們之間建立容錯移轉群組。
9 direct-hydration 使用 Kubernetes API 建立 SQL 執行個體，驗證 ARM 中的目前狀態。
10 direct-upload 驗證直接模式中的計費上傳
11 kube-rbac 確保 Arc 資料服務的 Kubernetes 服務帳戶權限符合最低權限預期。
12 nonroot 確保容器以非根使用者身分執行
13 postgres 完成各種 Postgres 建立、調整、備份/還原測試。
14 release-sanitychecks 針對每月版本的健全性檢查，例如 SQL Server 組建版本。
15 sqlinstance 較短版本的 ci-sqlinstance，以進行快速驗證。
16 sqlinstance-ad 使用 Active Directory 連接器測試 SQL 執行個體的建立。
17 sqlinstance-credentialrotation 測試一般用途和業務關鍵性的自動化認證輪替。
18 sqlinstance-ha 各種高可用性壓力測試，包括 Pod 重新啟動、強制容錯移轉和暫停。
19 sqlinstance-tde 各種透明資料加密測試。
20 telemetry-elasticsearch 驗證對 Elasticsearch 的記錄擷取。
21 telemetry-grafana 驗證 Grafana 是否可連線。
22 telemetry-influxdb 驗證 InfluxDB 中的計量擷取。
23 telemetry-kafka 使用 SSL、單一/多訊息代理程式設定針對 Kafka 的各種測試。
24 telemetry-monitorstack 測試監視元件，例如 Fluentbit 和 Collectd 都正常運作。
25 telemetry-telemetryrouter 測試開啟遙測。
26 telemetry-webhook 使用有效和無效的呼叫測試資料服務 Webhook。
27 upgrade-arcdata 升級完整的 SQL 執行個體套件 (GP、BC 2 複本、BC 3 複本、Active Directory)，以及從上個月的版本升級至最新組建。

例如，針對 sqlinstance-ha，會執行下列測試：

  • test_critical_configmaps_present：確定 SQL 執行個體有 ConfigMaps 和相關欄位。
  • test_suspended_system_dbs_auto_heal_by_orchestrator：確保 master 和 msdb 是否以任何方式暫停 (在此案例中為使用者)。 協調器維護協調會自動修復它。
  • test_suspended_user_db_does_not_auto_heal_by_orchestrator：確保使用者資料庫是否由使用者刻意暫停，協調器維護協調不會自動修復它。
  • test_delete_active_orchestrator_twice_and_delete_primary_pod：刪除協調器 Pod 多次，後面接著主要複本，並確認所有複本都已同步。 2 個複本的容錯移轉時間預期會放寬。
  • test_delete_primary_pod：刪除主要複本，並確認所有複本都已同步。 2 個複本的容錯移轉時間預期會放寬。
  • test_delete_primary_and_orchestrator_pod：刪除主要複本和協調器 Pod，並確認所有複本都已同步。
  • test_delete_primary_and_controller：刪除主要複本和資料控制器 Pod，並確認可存取主要端點，然後同步新的主要複本。 2 個複本的容錯移轉時間預期會放寬。
  • test_delete_one_secondary_pod：刪除次要複本和資料控制器 Pod，並確認所有複本都已同步。
  • test_delete_two_secondaries_pods：刪除次要複本和資料控制器 Pod，並確認所有複本都已同步。
  • test_delete_controller_orchestrator_secondary_replica_pods：
  • test_failaway：強制 AG 容錯移轉遠離目前的主要複本，確保新的主要複本與舊的主要複本不同。 確認所有複本都已同步。
  • test_update_while_rebooting_all_non_primary_replicas：儘管發生各種動蕩的情況，但測試控制器驅動的更新仍具有復原性。

注意

某些測試可能需要特定硬體，例如網域控制站的特殊權限存取，以用於帳戶和 DNS 項目建立的 ad 測試 - 這可能不適用於所有想要使用 arc-ci-launcher 的環境。

檢查測試結果

啟動器上傳的範例儲存體容器和檔案：

啟動器儲存體容器的螢幕擷取畫面。

啟動器 tarball 的螢幕擷取畫面。

以及從執行中產生的測試結果：

啟動器測試結果的螢幕擷取畫面。

清除資源

若要刪除啟動器，請執行：

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

這會清除部署為啟動器一部分的資源資訊清單。

相關內容

發行前測試