你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
教程：自动验证测试
作为构建已启用 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)、网络（例如LoadBalancer、DNS） - Kubernetes 或基础结构特定的其他设置
对于打算在未记录的分发版上运行已启用 Arc 的数据服务的客户，必须成功运行这些验证测试才能确认支持这些服务。 此外，合作伙伴可以使用此方法来验证其解决方案是否符合已启用 Arc 的数据服务 - 请参阅已启用 Azure Arc 的数据服务 Kubernetes 验证。
下图概述了该过程：
本教程介绍如何执行下列操作：
- 使用
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（窗口右下角）执行更改：
特定变量的详细说明
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"
可在此处找到 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.
通过 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 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 资源，并尝试（使用提供的服务主体凭据）对其进行清理：
启动器退出时也会运行相同的元数据发现和清理过程，使群集尽可能接近启动前处于的状态。
启动器执行的步骤
启动器大致按以下步骤顺序执行：
使用 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-pluginPod 在新的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 的环境。
检查测试结果
启动器上传的示例存储容器和文件：
以及运行中生成的测试结果：
清理资源
若要删除启动器，请运行：
kubectl delete -k arc_data_services/test/launcher/overlays/aks
这会清理作为启动器一部分部署的资源清单。