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混沌工程模块的 CRDCustom 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.2aptos0依赖上游 Chaos Mesh 官方 Chart版本2.5.2aptos0来自https://charts.chaos-mesh.org详见 Chart.yaml。值得注意的是仓库中的 Chart.lock 记录的依赖版本为2.2.0生成于 2022-06-07而 Chart.yaml 与本地打包的依赖包 charts/chaos-mesh-2.5.2aptos0.tgz 均已更新到2.5.2aptos0说明仓库对上游 Chaos Mesh 依赖做过一次升级并重新打包了 vendor 依赖。为什么需要先安装 CRDChaos 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这一行命令做了三件事kubectl create通过 Kubernetes API 将文件中的全部自定义资源定义提交给集群-f crd-2.5.2.yaml指定了本地文件即当前目录下的 crd-2.5.2.yaml命令执行成功后集群的 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 行起依次出现CRD 名称对应的 Chaos Kind主要用途awschaos.chaos-mesh.orgAWSChaosAWS 云资源故障ec2-stop / ec2-restart / detach-volumeazurechaos.chaos-mesh.orgAzureChaosAzure 云资源故障blockchaos.chaos-mesh.orgBlockChaos块设备故障如读写 IO 错误dnschaos.chaos-mesh.orgDNSChaosDNS 解析故障注入gcpchaos.chaos-mesh.orgGCPChaosGCP 云资源故障httpchaos.chaos-mesh.orgHTTPChaosHTTP 请求故障注入iochaos.chaos-mesh.orgIOChaos文件系统 IO 故障延迟、错误jvmchaos.chaos-mesh.orgJVMChaosJVM 应用故障注入kernelchaos.chaos-mesh.orgKernelChaosLinux 内核故障注入networkchaos.chaos-mesh.orgNetworkChaos网络故障丢包、延迟、分区physicalmachinechaos.chaos-mesh.orgPhysicalMachineChaos物理机故障physicalmachines.chaos-mesh.orgPhysicalMachine物理机资源注册podchaos.chaos-mesh.orgPodChaosPod 故障kill、容器暂停等podhttpchaos.chaos-mesh.orgPodHttpChaosPod 级 HTTP 故障podiochaos.chaos-mesh.orgPodIOChaosPod 级 IO 故障podnetworkchaos.chaos-mesh.orgPodNetworkChaosPod 级网络故障remoteclusters.chaos-mesh.orgRemoteCluster远端集群注册多集群混沌schedules.chaos-mesh.orgSchedule混沌实验定时调度statuschecks.chaos-mesh.orgStatusCheck混沌实验状态检查stresschaos.chaos-mesh.orgStressChaosCPU / 内存压力注入timechaos.chaos-mesh.orgTimeChaos系统时钟偏移注入workflownodes.chaos-mesh.orgWorkflowNode混沌工作流节点workflows.chaos-mesh.orgWorkflow混沌工作流编排2.2 一个 CRD 的内部结构示例以文件开头的awschaos.chaos-mesh.org为例crd-2.5.2.yaml 第 1–60 行附近可以看到每个 CRD 由三大部分组成metadata.nameCRD 在集群中的唯一名称遵循plural.group规则例如awschaos.chaos-mesh.orgspec.group / scope / names声明 API 组chaos-mesh.org、作用域Namespaced、kind 为AWSChaos、复数形式awschaosspec.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 的详细状态应看到 EstablishedTrue kubectl get crd networkchaos.chaos-mesh.org -o yaml # 确认自定义资源类型可用 kubectl api-resources | grep chaos-mesh.orgCRD 注册完成后即可在目标命名空间中创建混沌实验对象例如一个最简单的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 安装在整个部署链路中处于最前端理由有二Helm Chart 渲染的资源引用了这些 CRDChaos Mesh 部署时会创建Workflow、Schedule等 CRD 类型资源若 CRD 不存在helm install在提交清单时会直接失败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 再升级应用组件。四、配套的 RBACCRD 安装后谁有权操作CRD 装好之后还需要为 Chaos Mesh 的控制器和服务账号授予操作这些资源的权限这部分由 Chart 模板 templates/roles.yaml 负责它定义了三个核心 RBAC 对象ClusterRolerelease-manager对chaos-mesh.orgAPI 组的全部资源resources: [*]授予get/list/watch/create/delete/patch/update权限同时对核心 API 组的全部资源授予只读权限get/list/watchClusterRoleBindingrelease-manager将上述 ClusterRole 绑定到serviceAccountName模板生成的 manager 服务账号ClusterRoleBindingrelease-admin将内置的cluster-adminClusterRole 绑定到chaos-daemon服务账号使守护进程获得集群管理员权限混沌注入需要在宿主机层面操作网络、IO 与内核这是其特权模型的必然要求。ServiceAccount 本身由 templates/serviceaccount.yaml 创建默认仅在serviceAccount.createtrue时生成名称遵循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.enablefalse见 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 为例通过helm_release chaos-mesh引用本地 Chart 路径local.chaos_mesh_helm_chart_path即../../helm/chaos并仅在var.enable_forge开启时创建count var.enable_forge ? 1 : 0先创建kubernetes_namespace chaos-mesh命名空间通过 values 覆写启用 Ingress仅当存在 ACM 证书时domain chaos.${local.domain}acm_certificate aws_acm_certificate.ingress[0].arnloadBalancerSourceRanges join(,, var.client_sources_ipv4)为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说明该混沌测试能力是跨云部署的标配。七、常见问题与排查建议现象可能原因排查/解决kubectl create -f crd-2.5.2.yaml报the server could not find the requested resourcekubectl 与集群 API Server 版本不匹配或未配置 kubeconfig检查kubectl cluster-info与kubectl version创建 Chaos 对象被拒no matches for kind NetworkChaosCRD 尚未安装或安装在错误的集群/上下文重新执行kubectl create -f crd-2.5.2.yaml并用kubectl get crd确认创建 Chaos 对象报字段校验错误spec字段不在 OpenAPI schema 的枚举/类型范围内参考 crd-2.5.2.yaml 中对应 CRD 的schema定义核对字段Chaos 实验创建成功但未生效controller-manager 未运行或 manager 服务账号缺少 RBAC 权限检查 controller-manager Pod 日志核对 templates/roles.yaml 绑定helm install时报 CRD 相关错误手动安装的 CRD 版本与 Chart 依赖版本不一致确保 CRD 与 Chart 同为2.5.2版本八、小结CRD 安装是 Chaos Mesh 部署的第一步命令极简kubectl create -f crd-2.5.2.yamlcrd-2.5.2.yaml 包含chaos-mesh.org组下全部 23 个 Namespaced CRD覆盖网络、IO、Pod、云资源、JVM、时间、压力等故障类型安装后需配套 roles.yaml 中的 RBAC 授权混沌注入的权限模型为manager 最小权限 daemon cluster-admin生产环境建议默认关闭 Dashboard Ingressingress.enablefalse仅在具备 SSL 证书时通过 ingress.yaml 暴露并配合loadBalancerSourceRanges限制访问来源在 Aptos 测试网中AWS/GCP 的 Terraform 脚本如 terraform/aptos-node-testnet/aws/addons.tf会在enable_forgetrue时自动完成命名空间、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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考