Velero：基于 Tilt 构建快速迭代开发环境——从 tilt-settings.json 到 Delve 调试

Velero基于 Tilt 构建快速迭代开发环境——从 tilt-settings.json 到 Delve 调试【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero本文以 Velero 官方文档 Rapid iterative Velero development with Tilt 为主线完整讲解如何用 Tilt 在任意 Kubernetes 集群中搭建 Velero 的持续部署与热更新开发环境包括tilt-settings.json各配置字段的含义、备份存储位置对象存储/MinIO与凭据 Secret 的配置方法、Delve 远程调试接入以及 provider 插件的 live reload 机制。读完本文你将能够从零配置并运行tilt up在本地完成 Velero server、插件二进制的快速编译与热更新并深入理解 Tiltfile 中local_resource、docker_build与live_update的协作原理。Tilt 开发工作流的总体思路Tilt 方案适用于任意 Kubernetes 集群不局限于 Kind它通过三步实现 Velero 服务及其可选组件provider 插件、node-agent DaemonSet的持续部署部署必要的 Kubernetes 资源如 Velero 的 CRDs 和 Velero Deployment将 Velero 二进制以及指定的 provider 插件作为local_resource在本地构建通过docker_build的 live update 机制把新二进制同步进容器/init 容器并触发重启。Tilt 会从velero/tilt-resources目录读取配置。该目录下大部分文件被 gitignore你可以按自身需求自定义仓库中tilt-resources/examples提供了全套示例文件。对应到 Tiltfile 源码这一流程的具体落点如下k8s_yaml([CRD...])部署全部 v1/v2alpha1 CRDsTiltfile#L3-L17k8s_yaml(kustomize(tilt-resources))加载用户提供的 Kustomize 资源Tiltfile#L35k8s_yaml(tilt-resources/deployment.yaml)部署 Velero DeploymentTiltfile#L36按配置开关部署 node-agent、备份存储位置、MinIOTiltfile#L40-L45。前置条件Docker v19.03 或更新版本Kubernetes 集群 v1.16 或更高版本无需使用 KindTilt v0.12.0 或更新版本本地克隆 Velero 仓库可访问的 S3 兼容对象存储可选克隆并配置好你要修改、部署的 provider 插件仓库详见下文“provider 插件”一节。提示插件的具体配置方式请遵循各插件自身文档。快速上手tl;dr将velero/tilt-resources/examples下的所有示例文件复制到velero/tilt-resources配置velero_v1_backupstoragelocation.yaml文件以及存放存储凭据的cloud文件运行tilt up。创建并理解 tilt-settings.json在本地velero/tilt-resources目录下创建名为tilt-settings.json的配置文件也可以直接复制 示例文件。示例内容如下{ default_registry: , enable_providers: [ aws, gcp, azure, csi ], providers: { aws: ../velero-plugin-for-aws, gcp: ../velero-plugin-for-gcp, azure: ../velero-plugin-for-microsoft-azure, csi: ../velero-plugin-for-csi }, allowed_contexts: [ development ], use_node_agent: false, create_backup_locations: true, setup-minio: true, enable_debug: false, debug_continue_on_start: true }从源码结构看Tiltfile 首先定义一组默认值default_registry、use_node_agent、enable_debug等见 Tiltfile#L19-L27然后通过read_json(tilt-resources/tilt-settings.json, default{})读取你的配置文件并用settings.update(...)覆盖默认值Tiltfile#L30-L33。也就是说示例中省略的字段会沿用 Tiltfile 内置默认值配置文件只需写差异项。配置字段说明字段类型/默认值说明default_registryString默认需要推送镜像时使用的镜像仓库。Tiltfile 中默认值为docker.io/velero配置文件可覆盖provider_repos/providersMap默认{}各 provider 插件的本地路径。每个 provider 必须提供tilt-provider.json描述其构建方式enable_providersArray默认[]要启用的 provider 插件列表。注意当不修改某插件时无需将其加载进 Tilt——可以在 Velero deployment 中直接指定现有镜像与版本Tilt 会拉取该镜像allowed_contextsArray默认[]Tilt 允许使用的 kubeconfig context 列表对应allow_k8s_contextsKind 会被自动允许use_node_agentBool默认false是否部署 node-agent DaemonSet。为true时Tilt 会查找velero/tilt-resources/node-agent.yaml中的配置create_backup_locationsBool默认false是否创建一个或多个备份存储位置。为true时Tilt 会查找velero/tilt-resources/velero_v1_backupstoragelocation.yaml至少包含一个 BSL 配置setup-minioBool默认false是否使用集群内的 MinIO 实例作为备份存储。为true时Tiltfile 会加载 examples/minio/00-minio-deployment.yamlTiltfile#L44-L45enable_debugBool默认false是否启用基于 Delve 的 Velero 进程调试debug_continue_on_startBool默认true调试模式下 Velero 进程启动时是否自动继续运行这些开关在 Tiltfile 中的消费位置非常直接allowed_contexts传给allow_k8s_contextsTiltfile#L48use_node_agent控制加载tilt-resources/node-agent.yamlTiltfile#L40-L41create_backup_locations控制加载tilt-resources/velero_v1_backupstoragelocation.yamlTiltfile#L42-L43。准备待部署的 Kubernetes 资源文件所需的全部 Kubernetes 资源文件都以即用型样例的形式放在velero/tilt-resources/examples目录你只需把它们移动到velero/tilt-resources一级目录下。由于 Velero Deployment 和 node-agent DaemonSet 内部携带了所用插件的配置这些资源文件由用户自行提供——你可以在 deployment.yaml 样例 中自行选择要加载哪些 provider 插件以 init 容器形式挂载。示例文件默认配置了 Velero 支持的全部插件可按需删减。deployment 样例中的关键细节值得注意velero 容器以server --log-level debug启动镜像为velero/velero由 Tiltfile 构建并暴露8085metrics与2345Delve端口通过AWS_SHARED_CREDENTIALS_FILE、AZURE_CREDENTIALS_FILE、GOOGLE_APPLICATION_CREDENTIALS环境变量把凭据统一指向/credentials/cloud挂载点每个 provider 插件是一个 init 容器把二进制复制到共享的pluginsemptyDir 卷的/target路径供 velero 容器以LD_LIBRARY_PATH/plugins方式加载同时创建了velero命名空间、ServiceAccount 和指向cluster-admin的 ClusterRoleBinding开发环境用法。要完全可用Velero 还需要至少一个备份存储位置。示例 BSL 文件需要按你的对象存储进行修改下一节详细说明。配置备份存储位置你需要根据所用存储提供商配置velero/tilt-resources/velero_v1_backupstoragelocation.yaml所需字段/值对请参考对应插件的文档。仓库提供的 BSL 样例 本身就是一个指向集群内 MinIO 的完整配置spec: config: region: minio s3ForcePathStyle: true s3Url: http://minio.velero.svc:9000 objectStorage: bucket: velero provider: aws方式一使用云服务商的对象存储按对应提供商文档完成存储配置即可spec.provider设为相应提供商、spec.config填入 endpoint/region 等。方式二使用 MinIO 作为对象存储使用 MinIO 时必须配合 AWS 插件将 BSL 的spec.provider设为aws、spec.config.region设为minio即上面示例的写法。有两种典型用法1集群内运行的 MinIO 实例切勿用于生产在tilt-settings.json中设置setup-minio: trueTiltfile 会加载 MinIO 部署清单。从清单源码看它在velero命名空间下创建一个minioDeployment使用minio/minio:latest镜像环境变量MINIO_ACCESS_KEYminio、MINIO_SECRET_KEYminio12300-minio-deployment.yaml#L54-L57监听 9000 端口一个 ClusterIP 类型的minioService如需在 Minikube 等环境从集群外访问可改为 NodePort一个minio-setupJob用mc客户端执行alias set velero http://minio:9000 minio minio123 mc mb -p velero/velero自动创建名为velero的 bucket00-minio-deployment.yaml#L110。要访问该存储还需把 MinIO 端口转发到本地机器kubectl port-forward -n velero-namespace svc/minio 9000并把它作为“公共 URL”加入 BSL 配置publicUrl: http://localhost:9000——下载备份文件等操作依赖这个地址。注意采用该方案时集群一旦销毁存储及其中的全部备份/恢复数据也随之消失。2本地 Docker 容器中独立运行的 MinIO也可以把 MinIO 作为独立进程跑在本机 Docker 中而不是 Pod 内此时s3Url指向本机端口即可凭据仍放在cloud文件见下节。配置 provider 凭据Secret无论使用哪种对象存储提供商凭据都要写入velero/tilt-resources/cloud文件。仓库中的 cloud 样例 是一份为 MinIO 正确格式化好的 INI 文件[default] aws_access_key_id minio aws_secret_access_key minio123Tilt 会调用 Kustomize 基于tilt-resources目录生成 Secret。从 kustomization.yaml 源码看secretGenerator把cloud文件的内容以固定键secret.cloud-credentials.data.cloud生成在velero命名空间中对应 Tiltfile 中k8s_yaml(kustomize(tilt-resources))见 Tiltfile#L35deployment 中再把cloud-credentialsSecret 挂载为/credentials卷供各云 SDK 通过环境变量读取。使用 Delve 配置调试若需调试 Velero 进程把tilt-resources/tilt-settings.json中enable_debug设为true即可启用基于 Delve 的调试。从源码看这条链路包含三个环节调试构建Tiltfile 的get_debug_flag()在enable_debug为真时向构建命令追加DEBUG1Tiltfile#L81-L89。hack/build.sh 中DEBUG1会把-gcflags设为all-N -l即禁用优化与内联hack/build.sh#L63-L66调试入口get_velero_entrypoint()会把容器入口改写为dlv --listen:2345 --headlesstrue --api-version2 --accept-multiclient exec [--continue] -- /veleroTiltfile#L125-L146容器镜像中已预装dlvTiltfile 通过go install github.com/go-delve/delve/cmd/dlvlatest安装端口转发开启调试后Tiltfile 对velero资源配置了port_forwards2345把调试端口转发到本机Tiltfile#L37-L38。Tilt 运行且 Velero 资源就绪后在本地用 Delve CLI 连接dlv connect 127.0.0.1:2345Delve 也可集成到多种编辑器与 IDE 中使用。默认情况下debug_continue_on_start: trueVelero 进程在调试模式下启动即继续运行直到命中断点。将其设为false后进程不会运行直到你在 Delve 会话中发出continue指令。重要提示退出调试会话时CLI 和编辑器集成通常会询问是否停止远程进程。务必只断开连接、让远程进程继续运行——停止远程进程会使 Velero 容器退出、Pod 重启而进行中的备份不会被恢复会停留在陈旧状态。本地 Velero CLI 构建与 provider 插件Tiltfile 同时构建两个本地资源local_resourcevelero_server_binary交叉编译为GOOSlinux GOARCHamd64的 server 二进制输出到_tiltbuild/velero依赖cmd、internal、pkg目录忽略pkg/cmdTiltfile#L93-L98velero_local_binary按本机GOOS编译的 CLI输出到_tiltbuild/local/velero依赖internal与pkg/cmdTiltfile#L100-L104。两者都调用 hack/build.sh通过-ldflags注入Version、GitSHA、ImageRegistry等构建信息。因此你可以把 shell alias 指向velero/_tiltbuild/local/velero无需手动执行make local就能始终使用最新的 CLI 版本。provider 插件接入每个要接入 Tilt 的 provider 插件必须在其仓库中提供tilt-provider.json描述构建方式示例{ plugin_name: velero-plugin-for-aws, context: ., image: velero/velero-plugin-for-aws, live_reload_deps: [ velero-plugin-for-aws ], go_main: ./velero-plugin-for-aws }字段含义plugin_name是插件及二进制名称context是构建上下文相对路径会与tilt-settings.json中providers映射的仓库路径拼接image是生成的插件镜像引用live_reload_deps是 Tilt 监听的变更依赖go_main是 Go 主包路径缺省为main.go。这些解析逻辑见load_provider_tiltfiles()Tiltfile#L167-L193它会校验插件仓库路径存在、tilt-provider.json可读并把context解析为仓库路径与相对上下文拼接后的绝对路径。Live update 热更新机制热更新是这套方案的核心优势其机制在 Tiltfile 中分两段实现Velero 服务端docker_build以_tiltbuild为构建上下文、以本地velero二进制的初始副本作为COPY velero .的基底镜像Tiltfile#L107-L116并声明live_update [ sync(./_tiltbuild/velero, /velero), run(sh /restart.sh), ]Tiltfile#L151-L160。当cmd/internal/pkg下代码变化时velero_server_binary在本地机器重新编译Tilt 仅把新二进制同步进运行中的容器并执行由 rerun-process-wrapper 提供的restart.sh重启进程——无需重建整个镜像。Provider 插件enable_provider()为每个启用的插件创建local_resource按go_main构建 linux/amd64 二进制到插件仓库的_tiltbuild/目录依赖为live_reload_deps拼接后的完整路径与docker_build后者的live_update只有一条sync把新二进制同步到 init 容器的插件路径从而触发 Velero 容器重启Tiltfile#L209-L254。这一设计带来两个实际收益本地编译加同步远快于每次变更都重建容器镜像开发镜像也保持最小体积容器内不需要完整的 Go 工具链、源码或模块依赖。运行 Tilt启动开发环境tilt upTilt 会输出一个 Web 界面地址可在浏览器中监视各 Tilt 资源的状态与日志。稍等片刻后即可创建备份/恢复并完整操作 Velero。注意事项退出 Tilt 后运行tilt down会删除 Tiltfile 中定义的全部资源调试模式下请只断开 Delve 会话、不要停止远程进程原因见“使用 Delve 配置调试”一节。小结Velero 的 Tilt 开发环境把「CRD Deployment 可选插件/BSL/MinIO」的部署、本地二进制的local_resource构建、容器内sync 重启的 live update以及 Delve 远程调试整合进单一tilt up命令。配置文件集中于tilt-resources/目录且多数被 gitignore你只需按上文调整tilt-settings.json、BSL 与cloud三个文件即可适配自己的集群与对象存储所有行为均可在 Tiltfile 与 hack/build.sh 中逐行对照验证。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考