你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

教程：自动验证测试

项目
09/25/2024

作为构建已启用 Arc 的数据服务的每个提交的一部分，Microsoft 会运行执行端到端测试的自动化 CI/CD 管道。这些测试通过两个容器进行编排，这些容器与核心产品（数据控制器、由 Azure Arc 启用的 SQL 托管实例以及 PostgreSQL 服务器）一起进行维护。这些容器包括：

arc-ci-launcher：包含直接和间接连接模式的部署依赖项（例如 CLI 扩展）以及产品部署代码（使用 Azure CLI）。 Kubernetes 载入数据控制器后，容器会利用 Sonobuoy 触发并行集成测试。
arc-sb-plugin：包含基于 Pytest 的端到端集成测试的 Sonobuoy 插件，包括简单的冒烟测试（部署、删除）、复杂的高可用性方案、混沌测试（资源删除）等。

这些测试容器公开提供给客户和合作伙伴，用于在他们自己的 Kubernetes 群集中执行已启用 Arc 的数据服务验证测试，以验证以下内容：

Kubernetes 发行版/版本
主机发行版/版本
存储 (StorageClass/CSI)、网络（例如 LoadBalancer、DNS）
Kubernetes 或基础结构特定的其他设置

对于打算在未记录的分发版上运行已启用 Arc 的数据服务的客户，必须成功运行这些验证测试才能确认支持这些服务。此外，合作伙伴可以使用此方法来验证其解决方案是否符合已启用 Arc 的数据服务 - 请参阅已启用 Azure Arc 的数据服务 Kubernetes 验证。

下图概述了该过程：

显示已启用 Arc 的数据服务 Kube 原生集成测试的示意图。

在本教程中，你将了解如何执行以下操作：

使用 kubectl 部署 arc-ci-launcher
检查 Azure Blob 存储帐户中的验证测试结果

先决条件

凭据：
- test.env.tmpl 文件包含所需的必要凭据，并且是加入 Azure Arc 已连接群集和直接连接数据控制器所需的现有先决条件的组合。下面的示例介绍如何设置此文件。
- 已测试 Kubernetes 群集的 kubeconfig 文件，具有 cluster-admin 访问权限（加入连接的群集时需要用到）
客户端工具：
- 已安装 kubectl - 最低版本（主要版本：“1”，次要版本：“21”）
- git 命令行接口（或基于 UI 的替代方法）

准备 Kubernetes 清单

启动器作为 microsoft/azure_arc 存储库的一部分提供使用，因为 Kustomize 清单 - Kustomize 内置于 kubectl - 因此不需要其他工具。

在本地克隆存储库：

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

导航到 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 是驱动启动器行为的一组环境变量。在给定环境下谨慎生成该变量可确保启动器行为的可重现性。

Config 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 示例适用于 direct 模式。其中一些变量，例如 ARC_DATASERVICES_EXTENSION_VERSION_TAG，不适用于 indirect 模式。为简单起见，最好在设置 .test.env 文件时考虑到 direct 模式变量，切换 CONNECTIVITY_MODE=indirect 将使启动器忽略 direct 模式特定设置并使用列表中的子集。

换句话说，可以通过规划 direct 模式来满足需要 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) 映射的扩展版本：

正式发布版：stable - 版本日志
预正式发布版：preview - 预发布测试

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"

可在此处找到 Blob URL 映射的 CLI 版本。

3. `CUSTOM_LOCATION_OID` - 特定 Microsoft Entra 租户的自定义位置对象 ID

必需：对于创建连接的群集自定义位置是必需的。

以下步骤来自在群集上启用自定义位置，用于检索 Microsoft Entra 租户的唯一自定义位置对象 ID。

有两种方法来获取 Microsoft Entra 租户的 CUSTOM_LOCATION_OID。

通过 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.

显示 az ad sp show --id <> 的 PowerShell 终端的屏幕截图。

通过 Azure 门户 - 导航到 Microsoft Entra 边栏选项卡，然后搜索 Custom Locations RP：

4. `SPN_CLIENT_*` - 服务主体凭据

必需：对于 Direct 模式部署是必需的。

启动器使用这些凭据登录到 Azure。

验证测试旨在针对“非生产/测试 Kubernetes 群集和 Azure 订阅”执行——主要对 Kubernetes/基础结构设置进行功能验证。因此，为避免执行启动所需的大量手动步骤，建议在资源组（或订阅）级别提供具有 Owner 的 SPN_CLIENT_ID/SECRET，因为它也会在此资源组中创建多个资源，并根据在部署过程中创建的多个托管标识为这些资源分配权限（这些角色分配转而要求服务主体具有 Owner）。

5. `LOGS_STORAGE_ACCOUNT_SAS` - Blob 存储帐户 SAS URL

建议：将此项保留为空意味着不会获得测试结果和日志。

启动器需要一个永久性位置（Azure Blob 存储）来上传结果，因为 Kubernetes（尚）不允许从已停止/已完成的 Pod 复制文件 - 请参阅此处。启动器使用“帐户范围的 SAS URL”（相对于容器或 blob 范围）实现与 Azure Blob 存储的连接 - 具有时间限制访问定义的签名 URL - 请参阅使用共享访问签名 (SAS) 授予对 Azure 存储资源的有限访问权限，以执行以下操作：

在预先存在的存储帐户 (LOGS_STORAGE_ACCOUNT) 中创建新的存储容器（如果容器不存在（名称基于 LOGS_STORAGE_CONTAINER））
创建新的、唯一命名的 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 数据服务资源，且不部署/测试/上传日志。

Config 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

提示

回顾一下，此时有 3 个位置指定了 imageTag，为清楚起见，下面介绍每个位置的不同用途。通常 - 测试给定版本时，所有 3 个值都是相同的（与给定版本保持一致）：

#	文件名	变量名称	为什么？	使用者？
1	`.test.env`	`DOCKER_TAG`	在扩展安装过程中获取 Bootstrapper 映像	启动器中的 `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 和其他资源的屏幕截图。

启动器退出时也会运行相同的元数据发现和清理过程，使群集尽可能接近启动前处于的状态。

启动器执行的步骤

启动器大致按以下步骤顺序执行：

使用 Pod 装载的服务帐户向 Kubernetes API 进行身份验证
使用机密装载的服务主体向 ARM API 进行身份验证
执行 CRD 元数据扫描以发现现有的 Arc 和 Arc 数据服务自定义资源
清理 Kubernetes 中的任何现有自定义资源，以及 Azure 中的后续资源。如果 .test.env 中的凭据与群集中现有的资源存在任何不匹配，请退出。
根据 Arc 群集名称、数据控制器和自定义位置/命名空间的时间戳生成唯一的环境变量集。输出环境变量、模糊处理敏感值（例如服务主体密码等）
a. 对于直接模式 - 将群集加入 Azure Arc，然后部署控制器。

b. 对于间接模式：部署数据控制器
数据控制器 Ready 后，生成一组 Azure CLI (az arcdata dc debug) 日志并在本地存储，标记为 setup-complete - 作为基线。
使用 .test.env 的 TESTS_DIRECT/INDIRECT 环境变量来启动一组基于空格分隔数组 (TESTS_(IN)DIRECT) 的并行化 Sonobuoy 测试运行。这些运行使用包含 Pytest 验证测试的 arc-sb-plugin Pod 在新的 sonobuoy 命名空间中执行。
Sonobuoy 聚合器会累积每次 arc-sb-plugin 测试运行的 junit 测试结果和日志，这些结果会导出到启动器 Pod。
返回测试的退出代码，并生成另一组调试日志 - Azure CLI 和 sonobuoy - 存储在本地，标记为 test-complete。
执行步骤 3 类似的 CRD 元数据扫描，以发现现有的 Arc 和 Arc 数据服务自定义资源。然后，继续按照与部署过程相反的顺序销毁所有 Arc 和 Arc 数据资源，以及 CRD、Role/ClusterRoles、PV/PVC 等。
尝试使用提供的 SAS 令牌 LOGS_STORAGE_ACCOUNT_SAS 在“预先存在的”存储帐户 LOGS_STORAGE_ACCOUNT 中创建一个基于 LOGS_STORAGE_CONTAINER 命名的新存储帐户容器。如果存储帐户容器已存在，请使用它。将所有本地测试结果和日志作为 tarball 上传到此存储容器（见下文）。
退出。

每个测试套件执行的测试

在 27 个测试套件中，大约有 375 个独特的集成测试可用，每个测试套件都测试一个单独功能。

套件 #	测试套件名称	测试说明
1	`ad-connector`	测试 Active Directory 连接器（AD 连接器）的部署和更新。
2	`billing`	测试各种反映在控制器的资源表中的业务关键型许可证类型，用于计费上传。
3	`ci-billing`	与 `billing` 类似，但有更多的 CPU/内存排列。
4	`ci-sqlinstance`	适用于多副本创建、更新、GP -> BC 更新、备份验证和 SQL Server 代理的长期测试。
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 Data Services 的 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`	测试 Open Telemetry。
26	`telemetry-webhook`	使用有效和无效调用测试 Data Services 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 是否以任何方式挂起（在本例中为用户）。 Orchestrator 维护协调会自动修复它。
test_suspended_user_db_does_not_auto_heal_by_orchestrator：确保如果用户故意挂起用户数据库，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

这会清理作为启动器一部分部署的资源清单。

预发布测试

通过

教程：自动验证测试

先决条件

准备 Kubernetes 清单

Config 1：.test.env

特定变量的详细说明

1. ARC_DATASERVICES_EXTENSION_* - 扩展版本和训练

2. ARC_DATASERVICES_WHL_OVERRIDE - Azure CLI 以前版本的下载 URL

3. CUSTOM_LOCATION_OID - 特定 Microsoft Entra 租户的自定义位置对象 ID

4. SPN_CLIENT_* - 服务主体凭据

5. LOGS_STORAGE_ACCOUNT_SAS - Blob 存储帐户 SAS URL

6. SKIP_* - 通过跳过某些阶段来控制启动器的行为

Config 2：patch.json