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

教程:自动验证测试

作为构建已启用 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 存储帐户中的验证测试结果

先决条件

  • 凭据

  • 客户端工具

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

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) 映射的扩展版本:

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

  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.
    

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

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

    自定义位置 RP 的屏幕截图。

4. SPN_CLIENT_* - 服务主体凭据

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

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

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

5. LOGS_STORAGE_ACCOUNT_SAS - Blob 存储帐户 SAS URL

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

启动器需要一个永久性位置(Azure Blob 存储)来上传结果,因为 Kubernetes(尚)不允许从已停止/已完成的 Pod 复制文件 - 请参阅此处。 启动器使用“帐户范围的 SAS URL”(相对于容器或 blob 范围)实现与 Azure Blob 存储的连接 - 具有时间限制访问定义的签名 URL - 请参阅使用共享访问签名 (SAS) 授予对 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 数据服务资源,且不部署/测试/上传日志。

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 和其他资源的屏幕截图。

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

启动器执行的步骤

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

  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.envTESTS_DIRECT/INDIRECT 环境变量来启动一组基于空格分隔数组 (TESTS_(IN)DIRECT) 的并行化 Sonobuoy 测试运行。 这些运行使用包含 Pytest 验证测试的 arc-sb-plugin Pod 在新的 sonobuoy 命名空间中执行。

  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 代理的长期测试。
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 测试监控组件,如 FluentbitCollectd,是否正常工作。
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:确保 mastermsdb 是否以任何方式挂起(在本例中为用户)。 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

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