ate-setup 实战指南：用 Go 原生安装器在 Kubernetes 上部署与卸载 Agent Substrate

人工智能AI AgentAgent 沙箱云原生容器运行时零信任【免费下载链接】substrateAgent Substrate: the core system项目地址https://gitcode.com/GitHub_Trending/substrate7/substrate点击查看免费下载ate-setup是 Agent Substrate 仓库中一个 Go 编写的 Kubernetes 安装/卸载工具它以hack/install-ate.sh及七份hack/install-demo-*.sh、hack/setup-csi-*-kind.sh等 shell 脚本为蓝本做了逐标志移植既保留了对存量集群的兼容又引入了预构建镜像安装、服务端应用SSA、单命令执行模型等新能力。读完本文你将掌握ate-setup的全部子命令与全局标志、--image-repo/--image-tag发布版安装机制以及它与 shell 安装器在行为上有意保持一致与刻意不同的边界。什么是 ate-setupate-setup是一个安装并卸载 Agent Substrate 控制平面CRDs、RBAC、PostgreSQL 存储、ate-api-server、ate-controller、atenet 数据面、atelet DaemonSet的命令行工具入口位于 cmd/ate-setup/main.go命令树实现在 cmd/ate-setup/internal/cmd。它的定位很明确是hack/install-ate.sh的 Go 移植版本两者目前共存、都能用、可作用于同一个集群。官方说明README.md强调 shell 脚本不会立刻退役而是作为增量的替代方案存在因此迁移者不需要一次性完成切换。使用方式只有两种等价入口go run ./cmd/ate-setup [global flags] command [flags] make build-ate-setup # 构建出 bin/ate-setup 二进制命令树基于 cobra 构建见 root.go全局标志在PersistentPreRunE中解析为一个统一的config.Config保证每个子命令看到完全一致的环境。全局标志一次解析、处处生效ate-setup的全局标志与hack/install-ate.sh的对应关系如下完整引自 commands.md。与 shell 安装器标志可任意顺序、每个标志触发一个动作不同ate-setup一次调用只执行一个子命令因此原本一行--deploy-*多标志的写法要拆成多次ate-setup调用ate-setuphack/install-ate.sh说明--kindhack/install-ate-kind.sh或ATE_INSTALL_KINDtrue使用 Kind overlays、本地镜像仓库与宿主架构镜像构建--atenet-dataplane envoy\|agentgateway--atenet-dataplane envoy\|agentgatewayatenet 入向/出向数据面默认envoy--rollout-timeout DURATION--rollout-timeout DURATION工作负载就绪超时默认60s。与 shell 不同它一旦传入也会接管 podcertificate-controller 与 CSI 等待这两处历史默认 120s--podcert-workers-per-signer N--podcert-workers-per-signer N每个 podcertificate-controller 签名器的并发 worker 数--experimental-use-sdsmint--experimental-use-sdsmint在 atenet 出向网关中通过 SDS 按需签发 TLS 证书--experimental-additional-egress-extproc-service NS/SVC:PORT--experimental-additional-egress-extproc-service NS/SVC:PORT额外的 ext_proc 外部处理器授权过滤器--experimental-egress-credential-injection--experimental-egress-credential-injection在 sdsmint 网关的 MITM 分支上做出向凭证注入--credential-provider-name/--credential-provider-address选择 provider--context NAMEKUBECTL_CONTEXTNAMEkubeconfig 上下文仍默认取KUBECTL_CONTEXT--kubeconfig PATHKUBECONFIGPATH显式 kubeconfig 路径--no-dev-envNO_DEV_ENV1跳过仓库根目录的.ate-dev-env.sh--version/-v—新增能力shell 安装器没有版本号--image-repo REPO—新增能力。从REPO安装预构建镜像而不是用ko从源码构建--image-tag TAG—新增能力。这些镜像所携带的 tag两者必须成对出现--image-repo/--image-tag还有环境变量等价物ATE_IMAGE_REPO/ATE_IMAGE_TAG当标志缺席时读取。从源码看配置解析的优先级是.ate-dev-env.sh最低→ 进程环境 → 命令行标志最高实现在 config.go。开发者环境脚本通过 bash 子进程source后再以 NUL 分隔导出变量shellenv.go因此.ate-dev-env.sh里任意 shell 逻辑调用 gcloud、插值${USER}等都能原样工作且进程环境中已显式导出的变量优先于文件——显式导出被视为有意覆盖。值得一提的是 Kind 默认值逻辑config.go--kind会清空PROJECT_ID/CLUSTER_LOCATION把 context 默认成kind-cluster把KO_DOCKER_REPO默认成localhost:5001平台限定为linux/$GOARCH——这复刻了 shell 安装器防止开发者已 source 的云环境变量污染本地安装的做法。安装发布版本--image-repo / --image-tag默认情况下ate-setup用ko从当前 checkout 构建所有镜像并推送到KO_DOCKER_REPO——这是开发者安装路径与 shell 安装器完全一致。若要安装已发布的镜像则指定镜像仓库与 tagate-setup deploy ate-system \ --image-repo registry.example.com/substrate \ --image-tag v0.0.0此时不构建任何东西、不推送任何镜像manifest 仍然来自 checkout所以仍需要一个源码检出但移除了构建、Go 工具链和对注册表的写权限。以下是这条路径的关键约束来自 differences.md 与 images.go清单引用以ko://导入路径书写形如ko://github.com/agent-substrate/substrate/cmd/ateapi。--image-repo模式在images.Components中逐一查找重写为repo/导入路径基名:tag——这正是 ko 的--base-import-paths命名ateapi、atelet、atenet、ateom-gvisor等因此与发布镜像的命名一致。REPO必须持有 manifest 引用的全部组件镜像且都在同一 tag 下。发布流程是全部组件一起打 tag新增组件时必须先把新镜像与其余组件一同发布预构建安装才能使用它。每个引用都会被钉死到 tag 所对应的 digest重写后的引用形如repo/image:tagsha256:...。解析 digest 需要对每个镜像发一次 HEAD 请求digest.go因此安装器所在环境需要对REPO有读权限——不只是集群有。digest 钉死不是可选项ActorTemplate 的容器镜像、镜像卷的引用、SandboxConfig 的pauseImage都带有 CEL 规则self.contains()未钉死的引用会被准入拒绝导致所有 demo 部署失败。钉死同时带来 ko 安装免费拥有的性质——tag 之后移动不会改变实际运行的镜像。该 tag 还成为 substrate 版本用于命名 atelet DaemonSet 并设置划分节点的 node label。VERSION变量可覆盖它。TAG本身可以携带 digest如--image-tag v0.0.0sha256:...此时按原样使用、不做查询。重写是文本级的逐 token 匹配整个引用不是替换清单中列出的字段名所以workerImage:之类的 CRD 字段也会被重写凡不在images.Components列表中的引用、未展开的${PLACEHOLDER}、不可安装的包都会在安装前一次性报出全部未映射引用而不是让不可拉取的镜像二十多分钟后以ImagePullBackOff失败。凭证方面digest 查询使用 docker config 文件及其命名的 credential helpers外加 gcloud 自身凭证Application Default Credentials回退到gcloudCLI所以往 GKE 安装发布版无需~/.docker/config.json条目Amazon ECR 与 Azure Container Registry 需要仓库未依赖的 credential-helper 模块因此这些注册表需要先docker login。子命令全览ate-setup一次调用执行恰好一个子命令各子命令与hack/install-ate.sh标志的映射完整罗列如下引自 commands.md。Deployate-setuphack/install-ate.shdeploy ate-system--deploy-ate-systemdeploy ate-system --setup-csinfs--deploy-ate-system --setup-csinfsdeploy atelet--deploy-ateletdeploy apiserver--deploy-ate-apiserverdeploy ate-controller无 shell 等价deploy atenet--deploy-atenetdeploy postgres--deploy-postgresdeploy ate-system是整个控制平面CRDs、RBAC、存储、apiserver、controller、atenet、atelet。它顺带创建下面create的每个资源因此那些子命令只用于在已运行的集群上重做其中某一项。从 deploy.go 可以看到更细的行为deploy ate-system在ATE_API_POSTGRES_CONNECTION_STRING指向外部数据库时跳过内置 PostgreSQL StatefulSetdeploy postgres的 Long 说明明确标注为实验性的单副本 StatefulSet。deploy ate-system还带--setup-csi标志nfs、hostpath、both、none默认none且支持--setup-csi无参写法等价于none。Publishate-setuphack/install-ate.shpublish worker-images无 shell 等价构建并推送当前 checkout 构建对应的 ateom worker 镜像并打印其 refsWorkerPool 通过spec.workerImage指向某个构建以使用 ateom。Deleteate-setuphack/install-ate.shdelete ate-system--delete-ate-systemdelete atenet--delete-atenetdelete all--delete-alldelete all会先移除每个已注册的 demo再拆除控制平面。Createdeploy ate-system会自动创建的独立 Secret 与配置项ate-setuphack/install-ate.shcreate jwt-authority-pool--create-jwt-authority-pool-secretcreate actor-id-ca-pool--create-actor-id-ca-pool-secretcreate actor-id-ca-certs--create-actor-id-ca-certs-secretcreate egress-mitm-ca-pool--create-egress-mitm-ca-pool-secretcreate podcertificate-controller-cas--create-podcertificate-controller-cascreate api-server-env-vars--create-api-server-env-varscreate api-authentication-config--create-api-authentication-configSetupate-setuphack/install-ate.shsetup csi [driver]--setup-csi[DRIVER]driver取值为nfs、hostpath、both、none之一setup csi不带参数时默认none。hostpath 仅适用于 Kind 集群NFS 无此限制但要求节点加载了nfsd内核模块。Benchmarksate-setuphack/install-ate.shdeploy benchmarks--deploy-benchmarksdelete benchmarks--delete-benchmarks--worker-count N--benchmark-worker-count N默认1--sandbox-class gvisor\|microvm--benchmark-sandbox-class CLASS默认gvisor这两个标志在ate-setup中是子命令级、在hack/install-ate.sh中是全局并转发给实际执行的 benchmark 动作。详见 benchmarking/README.md。Demosate-setuphack/install-ate.shdeploy demo NAME--deploy-demo-NAMEdelete demo NAME--delete-demo-NAMENAME是不带demo-前缀的 demo 名。完整清单每个都有对应的delete demo NAME/--delete-demo-NAMEdemo 标志只绑定到部署侧拆除从不读取它们ate-setup说明deploy demo counter一个 counter actor练习 snapshot、resume 与 atenet 入向deploy demo counter --with-external-volume [--storage-class NAME]同上外加外部卷与预置文件用于校验。先setup csi并指定其创建的 storage class如csi-nfs-sc默认standarddeploy demo egress通过 atenet 的出向策略强制deploy demo sandbox由 sandbox client 驱动的按需 sandbox actordeploy demo multi-template共享一个 WorkerPool 的两个 ActorTemplatedeploy demo parking在小型 WorkerPool 上的 actor parking / unparkingdeploy demo autoscaled-workerpool由 HPA 基于自定义指标伸缩的 WorkerPool仅 Kinddeploy demo claude-code-multiplex多个 Claude Code agent 复用同一个 WorkerPool需要ANTHROPIC_API_KEY、BUCKET_NAME、KO_DOCKER_REPOdemo 列表不是硬编码的它由 cmd/ate-setup/internal/demos 中的注册表构建每个 demo 一个包因此go run ./cmd/ate-setup deploy demo --help对有哪些 demo、每个 demo 带哪些标志是权威答案。与 shell 安装器什么保持一致什么刻意不同differences.md 用一整篇文档划定了移植边界。先看被当作契约、逐字复刻的部分步骤日志行log.Step打印同样的青色[step]: name与同样的步骤名deploy_ate_system、create_api_server_env_vars、demo-counter_deploy (with_external_volumetrue)CI 日志采集器无需改动。Manifest 排序应用目录是非递归、按字典序的同kubectl apply -f dirdeploy_ate_system依赖该顺序shell 注释专门点名过某些文件名风险kube.LoadPath保留了它。Overlay 选择steps.SystemOverlay是 kind × router 的乘积与 shell 中嵌套if计算出的render_ate_system_manifests一致。超时60s 命名空间、60s rollout--rollout-timeout/ATE_INSTALL_ROLLOUT_TIMEOUT、120s podcertificate-controller 与 CSI 等待、300s demo。--rollout-timeout现在也会影响那两处 120s 等待shell 中不会但仅在显式传入时Config.WaitTimeout默认让每处保持历史值所以 60s 默认值不会缩短缓慢的引导路径config.go。渲染字节authentication.yaml被去掉尾部换行因为 shell 在$(...)中构建它时会剥离换行——在两个安装器间切换不能重写该 ConfigMap。ko 的 ldflagsmake ldflags产出-Xversion pkg.Version$(git describe --tags --always --dirty)ko.Runner.ldflags在不依赖 make 的情况下算出相同字符串。执行模型对比shellate-setup每次运行的动作数多个每标志一个按命令行顺序恰好一个子命令参数错误派发循环遇到标志时才检测更早的动作已经执行cobra 在任何操作前拒绝值标志预扫描、可出现在任意位置位置参数、按命令、标准标志解析配置环境变量ATE_INSTALL_KIND、ATE_ATENET_DATAPLANE、KUBECTL_CONTEXT等标志为主环境变量仍作为默认值被尊重仓库根目录git rev-parse --show-toplevel后cd向上找go.mod不chdir所有路径绝对化一次运行一个动作是最显眼的变化原本--deploy-ate-system --deploy-demo-counter的一行要拆成两次ate-setup调用。另一个重要改进是非法输入在任何集群变更前失败--atenet-dataplanenginx过去由预扫描校验捕获而--worker-count 0根本不会被捕获会在 microvm 依赖已经安装之后才从deploy_locust.sh内部暴露出来。外部二进制依赖大幅缩减被彻底剔除的依赖kubectl、kubectl kustomize、jq、openssl、sed、base64、grep、make以及go run ./cmd/kubectl-ate。仍然需要的二进制用途ko构建并发布镜像仅ko resolve--image-repo时不用go定位钉死的 ko 工具同hack/run-tool.sh--image-repo时不用git传给 ko 的git describe版本戳--image-repo时不用dockerKind 的 CSI 设置docker exec进节点与 claude-code-multiplex 工作负载构建gcloud仅在PROJECT_ID已设置且未给 context 时执行 GKEget-credentialsbashsource.ate-dev-env.sh两份 shell 脚本仍被调用而非重写因为它们是镜像构建、资产组装与对象存储暂存的编排超出安装器职责范围benchmarking/deploy_locust.sh与hack/install-microvm-deps.sh。它们收到Config.ScriptEnv()即 shell 安装器本会导出给它们的重建环境。另外ko不再被要求 apply 任何东西——脚本时代的run_ko apply会让 ko 转调 kubectl 并被迫处理别扭的-- --context特例现在 ko 只 resolve得到的 manifest 通过 client-go 应用。集群访问方式的本质变化服务端应用SSAkubectl apply -f -默认是客户端应用。ate-setup通过动态 client 使用 SSAfield manager 为ate-setup且force: true。这是重复调和的支持路径也避免了大型生成 CRD 上last-applied-configuration注解无限增长。之前客户端应用过的对象在下次 apply 调和前会显示两个 manager。发现缓存成为新的失败模式每次kubectl调用都以冷发现缓存启动所以kubectl apply -f generated后接着应用SandboxConfig能直接工作而一个长驻进程会缓存 RESTMapper继续提供 CRD 之前的发现文档并报no matches for kind。三处缓解同一流中出现 CRD 文档后Apply使缓存失效、DeployCRDs显式失效、resourceFor在放弃前用新发现重试一次。Rollout 状态被重实现kubectl rollout status不是库调用kube.RolloutStatus用与 kubectl 状态查看器相同的条件轮询 Deployment、DaemonSet、StatefulSet——包括ProgressDeadlineExceeded检查与分区 StatefulSet 情形。两处有意差异尚不存在的工作负载会被等待而不是立刻报错失败信息携带最后观察到的状态如3/5 replicas available而不是只有超时。删除更精确以kubectl delete --ignore-not-found -f为模型——NotFound 被忽略无法解析的 kind 也被忽略CRD 已删除后的拆除不能失败除此之外删除是严格的。\|\| true消失了CSI hostpath 包自带一个VolumeSnapshotClass其 CRD 在标准 Kind 集群上不存在shell 脚本通过忽略整个包的 kubectl 退出码来处理这同时也掩盖了真实失败。ApplyTolerant只跳过 kind 无法映射的对象、逐个记录跳过日志其余保持严格。Kind 节点上的尽力而为docker exec清理仍然尽力而为。证书与密钥处理CA 池进程内生成create_*_ca_pool_secret过去每次调用 shell 出go run ./cmd/kubectl-ate admin make-ca-pool每次支付一次编译。steps.createCAPool直接调用internal/localca与internal/localjwtauthority——即kubectl-ate所用的同一批库。创建已存在的池不再报错make-ca-pool是裸Create对已存在的池会以AlreadyExists失败ate-setup create actor-id-ca-pool则记录already exists; keeping it并成功。它仍然拒绝覆盖——重新生成等于把已签发证书的根轮换掉。池提取是精确的旧的ca_pool_root_pem管道jsonpath | base64 -d | grep -o ... | sed | base64 -d | openssl x509有两个问题grep -o只返回第一个根、静默丢弃多 CA 池的其余部分管道任一步失败都会得到空字符串变成没有根证书的信任包。kube.CAPoolRootPEM用写出它的同一个库反序列化池、输出每一个CA 的根并对缺失键、无法解码的池、空池、无根证书的 CA 返回错误。Demos 的工程化注册表取代命名约定脚本向ATE_DEMOS数组追加、用declare -F发现${name}_deploy等函数——拼错一个函数名就静默失去该能力。现在demos.Demo是接口每个 demo 是独立包、从init自注册internal/demos/all是唯一链接清单且有测试断言没有 demo 包遗漏。Kind-only demo 可见但拒绝demo-autoscaled-workerpool过去只在ATE_INSTALL_KINDtrue时注册在 GKE 上--deploy-demo-autoscaled-workerpool会被当作未知选项拒绝。cobra 树在标志解析前构建此时还不知道--kind所以子命令始终存在、在运行时失败并提示demo-autoscaled-workerpool is only supported for Kind installations; re-run with --kind。delete all在非 Kind 安装上仍通过demos.For跳过它。模板展开不再是 seddemo 模板过去由一串sed -e展开——替换${PLACEHOLDER}或在占位符不参与时删除整行/${NAME}/d。internal/render精确实现这两种操作、输出字节一致但值不再被当作 sed 替换文本——含|、或反斜杠的ANTHROPIC_API_KEY或 bucket 名现在会被字面替换。既未替换也未删除的占位符会留在原地于是意外的模板变量表现为非法 YAML而不是悄悄消失。Actor 清理走 APIdelete_demo_actors需要 jq、用kubectl-ate get actors -A -o json列 actor 再过滤。steps.DeleteDemoActors改用internal/ateclient并分页ListActors。容错保留没有 ate-api-server 或无法到达时跳过清理而不是失败因为delete all会对每个 demo 执行它。docker buildx imagetools inspect输出按 JSON 解析不再管道给jq -r .manifest.digest。构建输出仍走 stderr保证 CI 日志捕获下的 stdout/stderr 分离一致。错误与诊断set -o errexit能传播失败却看不到参数列表内失败的命令替换——这正是 shell 注释在 CA 提取处两次标注的问题。Go 在每个调用点返回错误。错误携带其所涉及的对象while applying deployment/ate-api-server -n ate-system: ...。警告以Warning:前缀走 stderr步骤与进度输出走 stdout与从前一致。ate-setup不带子命令时打印帮助并以 0 退出不加载配置、不触碰集群脚本是打印用法并以 1 退出。无论哪种方式都不会隐式安装任何东西——命名要执行的 setup 的子命令始终是显式的。已知差异与限制--setup-csi在非 Kind 集群上两个安装器现在都接受非 Kind 上的nfs——只有 hostpath 插件按单节点 Kind 布局打了补丁——且两者对那里的hostpath/both都硬报错而不是 shell 旧的警告并继续。Cloud SQL 仅限 shellhack/install-ate.sh自动化了带 IAM 认证、合成 DSN 与 Auth Proxy sidecar 的 Cloud SQL 设置见 tools/setup-gcp/cloud-sql.md。ate-setup尚未移植它尊重ATE_API_POSTGRES_CONNECTION_STRING用于通用外部数据库但忽略ATE_API_POSTGRES_CLOUDSQL_*并部署内置 StatefulSet。在 Cloud SQL 集群上运行ate-setup会把 DSN 回退到集群内数据库留下孤儿 proxy。Cloud SQL 集群在移植完成前请继续使用hack/install-ate.sh。测试保障shell 安装器没有任何测试cmd/ate-setup则为模板渲染、overlay 选择、配置解析、认证配置、apiserver 环境 ConfigMap、委派脚本参数、manifest 删除、逐 demo 渲染与镜像引用重写提供了单元测试对应 cmd/ate-setup/internal 下各包的*_test.go文件。其中 images_test.go 的TestComponentsCoverTheManifests保证了images.Components与真实 manifest 同步——新增组件会先让测试失败而不是让安装失败。小结ate-setup的价值在于把 Agent Substrate 的整套安装/卸载从一串有状态、按标志顺序执行动作的 shell 脚本收敛为一次调用一个子命令、错误在触碰集群前暴露、镜像来源可选源码构建或预构建发布版的 Go 工具同时把步骤日志、manifest 排序、超时与渲染字节等对外契约逐字保留。对于日常开发安装直接go run ./cmd/ate-setup deploy ate-system对于发布版安装用--image-repo--image-tag走预构建镜像路径需要逐标志对照 shell 安装器时commands.md 是权威映射表differences.md 则解释了所有行为差异背后的原因。赞分享人工智能AI AgentAgent 沙箱云原生容器运行时零信任【免费下载链接】substrateAgent Substrate: the core system项目地址https://gitcode.com/GitHub_Trending/substrate7/substrate点击查看免费下载相关推荐Agent Substrate 安装器 ate-setup 命令完全指南从安装部署到基准测试与 Demo 的一站式 CLIAgent Substrate 安装器 ate setup 命令完全指南从安装部署到基准测试与 Demo 的一站式 CLI ate setup 是 Agent人工智能AI AgentAgent 沙箱云原生容器运行时零信任使用 Helm 在 Kubernetes 上部署 Higress安装、卸载与全部 Values 参数实战指南使用 Helm 在 Kubernetes 上部署 Higress安装、卸载与全部 Values 参数实战指南 Higress 是基于阿里巴巴内部网关实践、由API网关后端云原生LLM 网关人工智能MCP 服务使用 Crossplane 与 OAM 在 Kubernetes 上管理云原生应用安装、部署与实战使用 Crossplane 与 OAM 在 Kubernetes 上管理云原生应用安装、部署与实战 本文以 Kubernetes 云原生基础设施为背景系统介教程云原生容器编排创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考