Aptos 公网全节点 Helm 部署指南基于 aptos-core 的 aptos-fullnode 图表配置与运维全解析【免费下载链接】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本指南以 terraform/helm/fullnode/README.md 为骨架系统讲解 Aptos 公网全节点Public FullnodePFN的 Kubernetes Helm 部署方式。你将掌握如何用一条helm install命令拉起一个与 Aptos 验证者网络同步的全节点、如何通过values.yaml控制网络选择devnet/testnet/mainnet、存储、服务暴露、备份与恢复等全部参数以及这些参数在图表模板StatefulSet、ConfigMap、Service、CronJob中如何被真正消费。图表定位图表部署了什么该 Helm Chartaptos-fullnodeChart 版本与 App 版本均为 1.0.0见 Chart.yaml部署的是一个 Aptos 公网全节点。它的职责可以概括为连接 Aptos 验证者网络通过状态同步把区块链状态同步到持久卷Persistent Volume对外提供REST API端口 8080供查询账户、交易、事件等链上数据API 规范见 api/doc/spec.yaml可选对外提供 aptosnet 协议端口6182用于 P2P 通信、metrics 端口9101、admin 端口9102与 gRPC 端口50051。从模板结构看图表渲染出的核心资源包括目录 terraform/helm/fullnode/templates资源模板文件说明StatefulSetfullnode.yaml全节点主工作负载含 init 容器、探针、安全上下文ConfigMapconfigmap.yaml生成fullnode.yaml节点配置文件Service ×2service.yaml外部负载均衡 Service 与内部 ServiceIngressingress.yaml可选通过 Ingress 暴露 REST APIPVCstorage.yaml全节点持久化存储支持从 VolumeSnapshot 恢复备份/校验/压缩backup.yaml、backup-verify.yaml、backup-compaction.yamlbackup.enabletrue时启用连通性测试tests/test-fullnode-connection.yaml安装后测试 Pod快速开始三步部署官方文档给出的部署流程非常简单前置条件只有两条安装Helm v3图表使用 Helm v2 风格的apiVersion: v2与命名模板要求 Helm 3配置好指向目标集群的kubectl。然后执行安装命令把storage.class替换为你集群中实际的存储类例如 AWS EKS 常见gp2helm install fullnode --set storage.classgp2 .命令在terraform/helm/fullnode目录下执行fullnode是 release 名称。安装后可用模板中的测试 Pod 验证连通性helm test fullnode默认情况下该图表以ClusterIP方式部署service.type默认值REST API 只在集群内部可达需要对外暴露时将service.type改为LoadBalancer或启用ingress.enabled详见下文服务暴露小节。连接目标网络genesis.blob 与 waypoint.txtAptos 全节点要加入某个网络必须持有该网络的两份链上事实source of truth文件genesis.blob创世区块数据节点从它开始校验链的起点waypoint.txt检查点waypoint用于在同步时锚定信任根。这两份文件的下载 URL 统一在.Values.aptos_chains中按链名配置。图表会在运行时容器启动命令中用curl下载它们而不是在构建镜像时固化见 fullnode.yaml# Download genesis and waypoint if necessary curl -o /opt/aptos/genesis/waypoint.txt {{ (get .Values.aptos_chains .Values.chain.name).waypoint_txt_url }} curl -o /opt/aptos/genesis/genesis.blob {{ (get .Values.aptos_chains .Values.chain.name).genesis_blob_url }}切换网络只需修改chain.name并确保它在aptos_chains中有对应条目。values.yamlterraform/helm/fullnode/values.yaml中默认内置了五个网络aptos_chains: devnet: waypoint_txt_url: https://devnet.aptoslabs.com/waypoint.txt genesis_blob_url: https://devnet.aptoslabs.com/genesis.blob netna: waypoint_txt_url: https://netna.data-staging.gcp.aptosdev.com/waypoint.txt genesis_blob_url: https://netna.data-staging.gcp.aptosdev.com/genesis.blob shelbynet: waypoint_txt_url: https://shelbynet.data-staging.gcp.aptosdev.com/waypoint.txt genesis_blob_url: https://shelbynet.data-staging.gcp.aptosdev.com/genesis.blob testnet: waypoint_txt_url: https://raw.githubusercontent.com/aptos-labs/aptos-networks/main/testnet/genesis_waypoint.txt genesis_blob_url: https://raw.githubusercontent.com/aptos-labs/aptos-networks/main/testnet/genesis.blob mainnet: waypoint_txt_url: https://raw.githubusercontent.com/aptos-labs/aptos-networks/main/mainnet/waypoint.txt genesis_blob_url: https://raw.githubusercontent.com/aptos-labs/aptos-networks/main/mainnet/genesis.blob说明README 的 Values 表格仅摘录了 devnet/testnet/mainnet 三条链实际 values.yaml 还内置了netna与shelbynet两个测试网络可原样使用。除 URL 外图表还支持三种替代来源chain.genesisConfigmap从指定 Kubernetes ConfigMap 挂载 genesis 与 waypoint以只读方式挂载为aptos-genesis卷chain.genesisSecret从指定 Kubernetes Secret 挂载genesis_bucket_path设置 GCS 路径后会启用名为fetch-genesis的 init 容器用gcloud storage cp从 GCS 拉取fullnode.yaml适用于 genesis 制品由内部流水线产出的场景。三种来源的优先级由模板中的卷定义逻辑决定ConfigMap/Secret/emptyDir 三选一其中 URL 下载方式对应的卷为emptyDir。Values 参数完整参考以下参数完整继承自 README 的 Values 表格并按功能分组每组补充了 values.yaml 中的默认值与说明。未在 README 表格中列出、但实际存在于 values.yaml 的参数已单独标注。镜像与发布控制Key类型默认值说明image.repostringaptoslabs/validator全节点镜像仓库。全节点与验证者共用同一镜像image.tagstringnil全节点镜像 tag若设置则覆盖imageTagimage.pullPolicystringIfNotPresent全节点镜像拉取策略imageTagstringdevnet所有全节点镜像的默认 tagmanageImagesbooltrue为 true 时 Helm 始终用 values 中的镜像覆盖已部署工作负载的镜像为 false 时沿用当前运行中工作负载的镜像适合用 rollout 等独立流程更新镜像的场景imagePullSecretstringnilREADME 未列出用于从私有仓库拉镜像的kubernetes.io/dockerconfigjson类型 Secret 名非 GCP 环境如 Azure AKS从 GCP Artifact Registry 拉取时必需tools.image.repostringaptoslabs/toolsREADME 未列出init 容器如 fetch-genesis使用的工具镜像仓库tools.image.tagstringnilREADME 未列出工具镜像 tag设置则覆盖imageTagtools.image.pullPolicystringIfNotPresentREADME 未列出工具镜像拉取策略补充README 表格中的image.tag/image.repo/image.pullPolicy与manageImages、imageTag均为 README 原生条目已完整保留。链与创世配置Key类型默认值说明chain.eraint1提升该值会抹掉底层存储PVC 名称含 era 后缀见下文chain.namestringdevnet要连接的网络名必须在.Values.aptos_chains中有对应条目chain.labelstringnilchain_name标签的值为空时默认取.Values.chain.namechain.genesisConfigmapstringnil从该 ConfigMap 加载 genesis.blob 与 waypoint.txtchain.genesisSecretstringnil从该 Secret 加载 genesis.blob 与 waypoint.txtaptos_chainsobjectdevnet/testnet/mainnet netna/shelbynet每个受支持网络对应的 genesis.blob 与 waypoint.txt 下载 URLgenesis_bucket_pathstringnilREADME 未列出GCS bucket 路径设置后启用 fetch-genesis init 容器节点配置、日志与指标Key类型默认值说明fullnode.configobject{full_node_networks:[{identity:{},network_id:public}]}全节点配置对应 NodeConfig 结构见 config/src/config/mod.rsrust_logstringinfo全节点日志级别RUST_LOGlogging.addressstringnil远程日志上报地址metrics.destinationstringdev指标上报目标支持dev与prodfullnode.config是核心配置入口模板会把用户提供的fullnode.config与内置基础配置合并后生成 ConfigMap。合并逻辑见 configmap.yaml{{ $fullnodeBaseConfig : tpl ($.Files.Get files/fullnode-base.yaml) $ | fromYaml }} {{ $fullnodeMergedConfig : mustMergeOverwrite $.Values.fullnode.config $fullnodeBaseConfig }}基础配置files/fullnode-base.yaml规定了角色、创世文件路径与关键监听地址base: role: full_node waypoint: from_file: /opt/aptos/genesis/waypoint.txt execution: genesis_file_location: /opt/aptos/genesis/genesis.blob full_node_networks: - network_id: public discovery_method: onchain listen_address: /ip4/0.0.0.0/tcp/6182 storage: backup_service_address: 0.0.0.0:6186 api: address: 0.0.0.0:8080注意其中full_node_networks数组第一项必须是公网全节点网络network_id: public并兼容旧的fullnode_identity/seeds/max_inbound_connections顶层字段写法模板中保留了向后兼容逻辑。资源与调度Key类型默认值说明resources.limits.cpuint30CPU 上限resources.limits.memorystring60Gi内存上限resources.requests.cpuint30CPU 请求resources.requests.memorystring60Gi内存请求nodeSelectorobject{}节点选择器tolerationslist[]污点容忍affinityobject{}亲和性规则topologySpreadConstraintslist[]README 未列出拓扑分布约束存储Key类型默认值说明storage.classstringnilPVC 使用的 Kubernetes StorageClassstorage.sizestring1000Gi全节点持久卷大小默认 1TBAptos 链数据量级决定了大存储需求storage.snapshotRefForRestorestringnil恢复用的 VolumeSnapshot 名称不设置则从零开始同步PVC 在 storage.yaml 中定义命名带 era 后缀{{ fullname }}-e{{ .Values.chain.era }}访问模式为ReadWriteOnce。当设置snapshotRefForRestore时PVC 通过dataSourceRef指向snapshot.storage.k8s.io的 VolumeSnapshot 创建。服务暴露Key类型默认值说明service.typestringClusterIP全节点 Service 类型改为LoadBalancer可对外暴露 REST API 与 aptosnet 端点service.exposeApibooltrue是否暴露节点 REST API80 → 8080service.exposeMetricsboolfalse是否在外部 Service 暴露 metrics 端口9101service.exposeAdminboolfalse是否在外部 Service 暴露 admin 端口9102service.exposeGrpcPortboolfalse是否在外部 Service 暴露 gRPC 端口50051service.externalTrafficPolicystringnil外部流量策略service.loadBalancerSourceRangeslist[]若 ServiceType 为 LoadBalancer限制来源 CIDRservice.annotationsobject{}Service 注解service.internal.typestringClusterIP内部 Service 类型service.internal.hostnamestringnil若设置作为内部 LB 的 hostname触发 external-dns 注解service.internal.exposeGrpcPortboolfalse是否在内部 Service 暴露 gRPC 端口service.internal.exposeApiboolfalseREADME 未列出是否在内部 Service 暴露 REST APIingress.enabledboolfalse改为 true 并填写其余字段通过 Ingress 控制器对外暴露 REST APIingress.hostNamestringnilIngress 使用的 hostnameingress.ingressClassNamestringnilIngress 类留空则隐式使用默认类ingress.annotationsobject{}Ingress 注解serviceAccount.createbooltrue是否创建 ServiceAccountserviceAccount.namestringnilServiceAccount 名称create 为 true 且未设置时按 fullname 模板生成serviceAccount.annotationsobject{}ServiceAccount 注解模板中实际渲染出两个 Service见 service.yaml-lb后缀的外部 Service 暴露 api/metrics/admin/grpc/aptosnet6182端口无后缀的内部 Service 暴露 backup6186、metrics9101以及按需的 grpc/api供备份等集群内部组件访问。Ingress 则把/路径转发到-lbService 的 80 端口。备份backup.*Key类型默认值说明backup.enableboolfalse是否启用备份backup.image.repostringaptoslabs/tools备份镜像仓库backup.image.tagstringnil备份镜像 tag设置则覆盖imageTagbackup.image.pullPolicystringIfNotPresent备份镜像拉取策略backup.resources.limits.cpuint6CPU 上限backup.resources.limits.memorystring8Gi内存上限backup.resources.requests.cpuint4CPU 请求backup.resources.requests.memorystring4Gi内存请求backup.nodeSelector / tolerations / affinity / topologySpreadConstraintsobject/list{}/[]调度控制backup.config.locationstringnil使用下面哪个备份目标配置s3/gcs/r2/azure/scw_s3/ocibackup.config.s3.bucketstringnilS3 bucketbackup.config.gcs.bucketstringnilGCS bucketbackup.config.r2.bucket / r2.endpoint_urlstringnilCloudflare R2 bucket 与端点backup.config.azure.account / container / sasstringnilAzure Blob 账号、容器与 SAS tokenbackup.config.state_snapshot_interval_epochsint2状态快照间隔epoch 数backup.config.transaction_batch_sizeint1000000交易批大小backup.config.concurrent_data_requestsstringnil对 PFN 备份端口的并发请求数启用备份后backup.yaml会额外渲染一个包含全部备份目标配置的 ConfigMapfiles/backup/*.yaml打包以及一个运行aptos-debugger aptos-db backup continuously的备份 StatefulSet它通过内部 Service 的 6186 端口backup 端口持续消费全节点的备份服务。备份命令适配器文件如 files/backup/s3.yaml、files/backup/azure.yaml定义了create_for_write、open_for_read、save_metadata_line、list_metadata_files、backup_metadata_file等命令模板分别对接 aws cli、azcopy、gcloud storage 等工具。备份校验与压缩backup_verify.* / backup_compaction.*Key类型默认值说明backup_verify.schedulestringdaily备份校验 CronJob 的调度表达式backup_verify.resources.limits.cpuint32CPU 上限backup_verify.resources.limits.memorystring60Gi内存上限backup_verify.resources.requests.cpuint16CPU 请求backup_verify.resources.requests.memorystring30Gi内存请求backup_verify.config.concurrent_downloadsint50校验时的并发下载数backup_verify.nodeSelector / tolerations / affinityobject/list{}/[]调度控制backup_compaction.schedulestringdaily备份压缩 CronJob 的调度表达式backup_compaction.resources.limits.cpuint8CPU 上限backup_compaction.resources.limits.memorystring32Gi内存上限backup_compaction.resources.requests.cpuint4CPU 请求backup_compaction.resources.requests.memorystring16Gi内存请求backup_compaction.nodeSelector / tolerations / affinityobject/list{}/[]调度控制两个 CronJob 均在backup.enabletrue时渲染且复用备份的config.location命令适配器配置见 backup-verify.yaml、backup-compaction.yaml。压缩任务以concurrencyPolicy: Replace运行aptos-debugger aptos-db backup-maintenance compact三种文件状态快照、交易、epoch 结束文件的 compact factor 均为 100校验任务运行aptos-debugger aptos-db backup verify并支持从restore.config.trusted_waypoints传入信任的 waypoint。恢复restore.*Key类型默认值说明restore.enabledboolfalse是否从备份恢复restore.image.repostringaptoslabs/tools恢复镜像仓库restore.image.tagstringnil恢复镜像 tag设置则覆盖imageTagrestore.image.pullPolicystringIfNotPresent恢复镜像拉取策略restore.resources.limits.cpuint16CPU 上限restore.resources.limits.memorystring120Gi内存上限restore.resources.requests.cpuint16CPU 请求restore.resources.requests.memorystring120Gi内存请求restore.nodeSelector / tolerations / affinityobject/list{}/[]调度控制restore.config.locationstringnil备份目标配置与 backup.config.location 对应restore.config.s3.bucket / gcs.bucket / azure.account / azure.container / azure.sasstringnil备份源凭据restore.config.trusted_waypointslist[]恢复时信任的 waypoint 列表restore.config.concurrent_downloadsint16恢复并发下载数restore.config.restore_erastringnil指定不同于chain.era的恢复 erarestore.config.restore_epochint0提升该值会触发从零恢复并抹掉数据库restore.config.start_versionint0从 genesis 开始恢复restore.config.target_versionstringnil恢复到最新版本恢复以init 容器方式运行fullnode.yaml在节点主容器启动前把备份拉回本地db目录。它通过标记文件实现幂等restore-uid记录本次restore_epoch若数据库缺失、上次失败存在restore-failed或 uid 不匹配则清库重做完成后写入restore-complete下次启动直接跳过。核心命令为/usr/local/bin/aptos-debugger aptos-db restore bootstrap-db \ --concurrent-downloads 并发数 \ [--trust-waypoint waypoint]... \ --target-db-dir /opt/aptos/data/db \ --metadata-cache-dir /opt/aptos/data/aptos-restore-metadata \ --ledger-history-start-version start_version \ [--target-version target_version] \ --command-adapter-config /opt/aptos/etc/location.yaml运行原理StatefulSet 内部的完整生命周期fullnode.yaml 渲染的 StatefulSet 揭示了全节点从启动到提供服务的完整链路1. 启动前准备init 容器若设置了genesis_bucket_pathfetch-genesis从 GCS 拉取 genesis/waypoint若设置了restore.enabledrestore从备份恢复数据库含清库逻辑与wipe-db标记文件机制——主容器启动时若发现/opt/aptos/data/wipe-db文件会删除数据库并只执行一次。2. 主容器启动若未提供 genesisConfigmap/Secret/GCS 路径先用curl下载 genesis.blob 与 waypoint.txt执行exec /usr/local/bin/aptos-node -f /opt/aptos/etc/fullnode.yaml启动节点容器以runAsNonRoot: true、runAsUser/runAsGroup/fsGroup: 6180、seccompProfile: RuntimeDefault、只读根文件系统运行安全上下文较严格。3. 暴露的端口端口用途6182aptosnet P2P公网网络监听6186backup 服务供备份 StatefulSet 消费8080REST API8081备用 API 端口容器内声明9101metrics9102admin50051gRPC仅当任一 Service 启用exposeGrpcPort时暴露4. 健康检查探针startupProbe请求/v1/-/healthyfailureThreshold: 20×periodSeconds: 15即最多等待 300 秒让节点冷启动完成livenessProbeREST API 若连续 60 秒无响应则重启 PodreadinessProbe请求/v1/-/healthy?duration_secs30Pod 只有在状态同步追平30 秒内响应后才就绪落后超过 10 秒会从 Service 摘除。同时 Pod 上带prometheus.io/scrape: true与prometheus.io/port: 9101注解metrics 目的地通过aptos.dev/metrics-destination注解标记对应metrics.destination的 dev/prod。关键运维手法结合参数与模板实现以下几个隐藏技巧值得专门说明用 era 清空存储重建节点PVC 命名为{release}-aptos-fullnode-e{era}见 storage.yaml 与 _helpers.tpl 中的backup.persistentVolumeClaim定义。把chain.era从 1 提升到 2Helm 会创建一块全新的 PVC从零开始重新同步实现换血式重建备份目录的SUB_DIR也以e{era}隔离不同 era 的数据互不干扰。从快照快速拉起设置storage.snapshotRefForRestore指向已存在的 VolumeSnapshotPVC 创建时直接以快照为数据源跳过完整同步适合快速扩容出多个全节点。滚动更新镜像但不让 Helm 覆盖将manageImages设为false模板通过lookup读取当前 StatefulSet/CronJob 的镜像并沿用fullnode.yaml 等处的lookup逻辑适合已有独立镜像更新流程如 rollout的团队。自定义节点配置通过fullnode.config传入完整的 NodeConfig 覆盖项模板会用mustMergeOverwrite与基础配置深度合并后生成 ConfigMapConfigMap 内容变更会通过checksum/config注解触发 Pod 滚动重启。验证与排障入口安装后运行helm test fullnode执行连通性测试测试模板见 tests/test-fullnode-connection.yaml查看节点同步状态curl http://service/v1/-/healthy?duration_secs30查看 REST API 返回体与错误格式对照 api/doc/spec.yaml节点配置结构NodeConfig定义于 config/src/config/mod.rsfullnode.config的所有字段均遵循该结构备份/恢复底层由aptos-debugger aptos-db子命令驱动相关实现位于 aptos-move/aptos-debugger 与 storage/backup。至此你已经掌握了 aptos-fullnode 图表的全部配置面从一行helm install拉起节点到通过网络/存储/服务/备份恢复各维度精细调参再到理解 StatefulSet 内部 init 容器、探针、era 机制等运行细节。无论是加入 devnet 做开发测试还是部署 mainnet 公网全节点都可以直接以本指南的配置表作为参照落地。【免费下载链接】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），仅供参考