企业官网建设流程全解析

Aptos 节点混沌工程实践：在 Kubernetes 上安装 Chaos Mesh CRD 的完整指南

【免费下载链接】aptos-coreAptos is a layer 1 blockchain built to support the widespread use of blockchain through better technology and user experience.项目地址: https://gitcode.com/GitHub_Trending/ap/aptos-core

本篇技术指南聚焦 Aptos 仓库中terraform/helm/chaos混沌工程模块的 CRD（Custom Resource Definition，自定义资源定义）安装环节，完整介绍 CRD 文件的来源、作用、安装命令与验证方法，并结合仓库内的 Helm Chart、RBAC 模板与 Terraform 编排，讲清楚 Chaos Mesh 在 Aptos 验证节点集群中从安装到运行的全链路。读完本文，你将掌握在 Kubernetes 集群中安全安装 Chaos Mesh CRD 的标准流程，并能独立排查常见的安装与校验问题。

一、背景：Chaos Mesh 与 Aptos 的混沌测试

Aptos 是面向大规模区块链应用构建的 Layer 1 区块链，其验证者网络对节点可用性、网络分区、磁盘与 CPU 异常等故障场景的韧性要求极高。为了在受控环境中验证网络韧性，Aptos 仓库引入了 Chaos Mesh——一个面向 Kubernetes 的混沌工程平台，用于注入 Pod 级、网络级、文件系统级乃至云资源级的故障。

在仓库中，这一能力被封装在 Helm Chart terraform/helm/chaos 中。该 Chart 的描述为 "Chaos Mesh for Aptos"，版本号为2.5.2+aptos0，依赖上游 Chaos Mesh 官方 Chart（版本2.5.2+aptos0，来自https://charts.chaos-mesh.org），详见 Chart.yaml。

值得注意的是，仓库中的 Chart.lock 记录的依赖版本为2.2.0（生成于 2022-06-07），而 Chart.yaml 与本地打包的依赖包 charts/chaos-mesh-2.5.2+aptos0.tgz 均已更新到2.5.2+aptos0，说明仓库对上游 Chaos Mesh 依赖做过一次升级并重新打包了 vendor 依赖。

为什么需要先安装 CRD？Chaos Mesh 的核心组件（chaos-controller-manager、chaos-daemon 等）通过 Kubernetes API 扩展机制管理混沌实验对象。Kubernetes 本身并不认识NetworkChaos、PodChaos这些资源类型，必须先将 CRD 注册到集群的 API Server，控制器才能监听这些资源的增删改事件。因此，"安装 CRD" 是整个 Chaos Mesh 部署流程中最早、也最关键的一步。

二、CRD 安装：官方文档的唯一命令

关联文档 crd/README.md 的主题非常聚焦，它给出了 CRD 上传到 Kubernetes 的标准操作：

$ kubectl create -f crd-2.5.2.yaml

这一行命令做了三件事：

1. kubectl create通过 Kubernetes API 将文件中的全部自定义资源定义提交给集群；
2. -f crd-2.5.2.yaml指定了本地文件，即当前目录下的 crd-2.5.2.yaml；
3. 命令执行成功后，集群的 API Server 即具备识别chaos-mesh.org组下所有混沌资源类型的能力。

2.1 文件来源：一份 5 万行的 CRD 合集

crd-2.5.2.yaml 是一份约 5 万行的大文件（50011 行），其中按顺序串联了23 个CustomResourceDefinition（对应kind: CustomResourceDefinition出现的次数）。每个 CRD 均属于chaos-mesh.orgAPI 组，且作用域均为Namespaced（命名空间级），apiVersion 统一为apiextensions.k8s.io/v1。

这 23 个 CRD 的具体名称与作用如下（从文件第 7 行起依次出现）：

2.2 一个 CRD 的内部结构示例

以文件开头的awschaos.chaos-mesh.org为例（crd-2.5.2.yaml 第 1–60 行附近），可以看到每个 CRD 由三大部分组成：

• metadata.name：CRD 在集群中的唯一名称，遵循<plural>.<group>规则，例如awschaos.chaos-mesh.org；
• spec.group / scope / names：声明 API 组chaos-mesh.org、作用域Namespaced、kind 为AWSChaos、复数形式awschaos；
• spec.versions[].schema.openAPIV3Schema：完整的 OpenAPI v3 结构校验定义，描述spec下每个字段的类型、默认值与可选枚举。

例如 AWSChaos 的spec.action字段被定义为字符串枚举：

action: description: >- Action defines the specific aws chaos action. Supported action: ec2-stop / ec2-restart / detach-volume Default action: ec2-stop enum: - ec2-stop - ec2-restart - detach-volume type: string

这些校验规则在安装后立即生效：后续任何提交到集群的AWSChaos对象，如果spec.action不在上述枚举内，API Server 会直接拒绝，而不会进入控制器处理流程。这正是 CRD 先行安装的意义——它把"类型安全"从控制器内部提前到了 API 层。

2.3 安装后的验证方式

安装命令执行成功后，可以用以下命令验证 CRD 是否就绪：

# 查看 chaos-mesh.org 组下的全部 CRD kubectl get crd | grep chaos-mesh.org # 查看单个 CRD 的详细状态（应看到 Established=True） kubectl get crd networkchaos.chaos-mesh.org -o yaml # 确认自定义资源类型可用 kubectl api-resources | grep chaos-mesh.org

CRD 注册完成后，即可在目标命名空间中创建混沌实验对象，例如一个最简单的NetworkChaos对象（丢包注入）：

apiVersion: chaos-mesh.org/v1alpha1 kind: NetworkChaos metadata: name: packet-loss namespace: chaos-mesh spec: action: loss mode: all selector: namespaces: ["validator"] labelSelectors: app: aptos-validator loss: loss: "25" correlation: "100" duration: "30s"

提交方式同样是kubectl create -f或kubectl apply -f，之后由 Chaos Mesh 的 controller-manager 负责实际执行。

三、安装顺序：CRD 必须早于 Helm Chart 部署

CRD 安装在整个部署链路中处于最前端，理由有二：

1. Helm Chart 渲染的资源引用了这些 CRD：Chaos Mesh 部署时会创建Workflow、Schedule等 CRD 类型资源，若 CRD 不存在，helm install在提交清单时会直接失败；
2. CRD 属于集群级 API 扩展，而 Helm 默认的helm install对 CRD 采用"安装时单独管理"的策略（即使 Chart 的crds/目录带 CRD，后续升级时也不会自动更新），因此在生产实践中，运维团队往往显式、先行地安装 CRD 文件，以便对版本变更做到显式控制。

在 Aptos 仓库中，crd/crd-2.5.2.yaml 被单独放在crd/子目录而非 Chart 的crds/目录，并配套了独立的 crd/README.md，正是这种"显式安装、先行安装"思路的体现——CRD 版本与 Chart 版本（均为2.5.2）一一对应，升级时先替换 CRD 再升级应用组件。

四、配套的 RBAC：CRD 安装后谁有权操作

CRD 装好之后，还需要为 Chaos Mesh 的控制器和服务账号授予操作这些资源的权限，这部分由 Chart 模板 templates/roles.yaml 负责，它定义了三个核心 RBAC 对象：

• ClusterRole<release>-manager：对chaos-mesh.orgAPI 组的全部资源（resources: ['*']）授予get/list/watch/create/delete/patch/update权限，同时对核心 API 组的全部资源授予只读权限（get/list/watch）；
• ClusterRoleBinding<release>-manager：将上述 ClusterRole 绑定到serviceAccountName模板生成的 manager 服务账号；
• ClusterRoleBinding<release>-admin：将内置的cluster-adminClusterRole 绑定到chaos-daemon服务账号，使守护进程获得集群管理员权限（混沌注入需要在宿主机层面操作网络、IO 与内核，这是其特权模型的必然要求）。

ServiceAccount 本身由 templates/serviceaccount.yaml 创建，默认仅在serviceAccount.create=true时生成，名称遵循chaos.serviceAccountName模板，后缀为-manager。

从模板注释 "Chaos Mesh manager can edit chaos-mesh API resources and read cluster resources" 可以看出权限设计的边界：manager 只写混沌资源、只读集群资源，而真正需要高权限的只有 daemon。这一最小权限原则值得在自建混沌平台时借鉴。

五、可选 Ingress：给 Chaos Dashboard 开一个入口

Chaos Mesh 自带 Web 控制台（chaos-dashboard）。templates/ingress.yaml 提供了一个面向 AWS ALB 的 Ingress 模板，默认关闭（ingress.enable=false，见 values.yaml 的注释："do not enable the ingress by default, especially when there is no SSL certificate"——没有 SSL 证书时不要默认开启）。

该 Ingress 的关键配置：

• 使用alb.ingress.kubernetes.io注解族，scheme 为internet-facing；
• 支持loadBalancerSourceRanges限制来源 CIDR（通过alb.ingress.kubernetes.io/inbound-cidrs注入）；
• 支持 ACM 证书（alb.ingress.kubernetes.io/certificate-arn）与 external-dns 域名（external-dns.alpha.kubernetes.io/hostname）；
• 第一条路径固定为ssl-redirect动作（HTTP 301 重定向到 HTTPS），随后将/前缀路由到chaos-dashboard服务的http端口。

注意：Ingress 中引用的后端服务ssl-redirect与chaos-dashboard并非本 Chart 直接创建，而是来自上游 chaos-mesh 依赖 Chart，这也再次印证了本 Chart 是"薄封装 + 依赖上游"的设计。

六、仓库内自动化：Terraform 如何编排 Chaos Mesh

在 Aptos 的测试网基础设施中，Chaos Mesh 的部署已被 Terraform 自动化。以 terraform/aptos-node-testnet/aws/addons.tf 为例：

1. 通过helm_release "chaos-mesh"引用本地 Chart 路径local.chaos_mesh_helm_chart_path（即../../helm/chaos），并仅在var.enable_forge开启时创建（count = var.enable_forge ? 1 : 0）；
2. 先创建kubernetes_namespace "chaos-mesh"命名空间；
3. 通过 values 覆写启用 Ingress（仅当存在 ACM 证书时）：
   • domain = "chaos.${local.domain}"
   • acm_certificate = aws_acm_certificate.ingress[0].arn
   • loadBalancerSourceRanges = join(",", var.client_sources_ipv4)
4. 为chaosDaemon注入容忍（tolerations），允许其调度到 validator 节点组（key = "aptos.org/nodepool", value = "validators", effect = "NoExecute"），这是混沌注入能作用到验证者节点的关键配置。

值得注意的是，Terraform 通过helm_release安装 Chart 时，Helm 会处理 Chart 内声明的 CRD（上游 chaos-mesh Chart 自带 crds 目录），因此 Terraform 路径与手工kubectl create -f crd-2.5.2.yaml路径是两条等价但并行的部署方式；手工方式更适合在 CRD 需先行升级或 Helm 不便操作的场景下使用。

GCP 侧同样存在对应的编排（terraform/aptos-node-testnet/gcp/addons.tf），说明该混沌测试能力是跨云部署的标配。

七、常见问题与排查建议

八、小结

• CRD 安装是 Chaos Mesh 部署的第一步，命令极简：kubectl create -f crd-2.5.2.yaml；
• crd-2.5.2.yaml 包含chaos-mesh.org组下全部 23 个 Namespaced CRD，覆盖网络、IO、Pod、云资源、JVM、时间、压力等故障类型；
• 安装后需配套 roles.yaml 中的 RBAC 授权，混沌注入的权限模型为"manager 最小权限 + daemon cluster-admin"；
• 生产环境建议默认关闭 Dashboard Ingress（ingress.enable=false），仅在具备 SSL 证书时通过 ingress.yaml 暴露，并配合loadBalancerSourceRanges限制访问来源；
• 在 Aptos 测试网中，AWS/GCP 的 Terraform 脚本（如 terraform/aptos-node-testnet/aws/addons.tf）会在enable_forge=true时自动完成命名空间、Chart 与 tolerations 的编排，CRD 手工安装主要服务于显式升级与独立管控场景。

掌握以上内容后，你即可在任意 Kubernetes 集群上为 Chaos Mesh 正确落地 CRD，进而基于NetworkChaos、StressChaos、TimeChaos等故障类型，对 Aptos 验证者节点开展系统化的韧性验证。

【免费下载链接】aptos-coreAptos is a layer 1 blockchain built to support the widespread use of blockchain through better technology and user experience.项目地址: https://gitcode.com/GitHub_Trending/ap/aptos-core