尧图网页设计 
Velero 安装定制完全指南插件、命名空间、文件系统备份、特性开关与资源限额配置【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero本篇技术指南以 Velero 官方文档中的《Customize Velero Install》为骨架系统讲解在velero install基础命令之上如何针对生产环境进行安装定制包括插件选择、自定义命名空间、非凭证文件身份机制、启用文件系统备份FSB、特性开关Feature Flags、资源请求与限额、多存储位置配置、仅生成 YAML 以及 CLI 自动补全等。读完本文你将掌握一套可复制的 Velero 安装定制方案并能结合仓库源码理解每个定制项在安装流程中的真实作用。前提至少添加一个插件velero install在安装时必须通过--plugins标志添加至少一个提供方插件例如 AWS、GCP、Azure 的对象存储与卷快照插件。这一点在源码中有强制校验在 install.go 的Validate中当存在默认备份存储位置或使用卷快照时如果--plugins为空会直接报错--plugins flag is required。插件以容器镜像的形式注入 Velero Deployment例如velero install \ --provider aws \ --plugins velero/velero-plugin-for-aws:v1.0.0 \ --bucket backups \ --secret-file ./aws-iam-creds关于各提供方插件镜像的完整清单参见 supported-providers 与 overview-plugins。安装到任意命名空间Velero 默认安装在velero命名空间velero install命令也支持通过--namespace标志安装到任意命名空间。需要说明的是默认命名空间常量定义于 pkg/apis/velero/v1/constants.goDefaultNamespace velero同时被 CLI 与服务端共同使用从 resources.go 可以看到当命名空间不是默认的velero时安装器生成的 ClusterRoleBinding 名称会带上命名空间后缀velero-namespace以避免跨命名空间冲突若使用自定义命名空间安装器还会为该命名空间打上 Pod Security 强制标签pod-security.kubernetes.io/enforceprivileged等见 resources.go。在非默认命名空间运行时的注意事项参见 run in custom namespace。使用非文件型身份机制--no-secret默认情况下velero install期望通过--secret-file提供一个包含云厂商 IAM 凭证的文件安装器会读取该文件内容并生成名为cloud-credentials的 Secret见 resources.go数据键为cloud。如果你使用不依赖凭证文件的身份机制例如AWS 上的 kube2iam / kiam基于 Pod 注解注入临时角色GKE 上的 Workload Identity其他通过 Service Account 注解或 Pod 注解完成鉴权的方案则可以改用--no-secret标志替代--secret-file。源码中的校验逻辑要求二者必须二选一见 install.go两个标志都未指定 → 报错One of --secret-file or --no-secret is required两个标志同时指定 → 报错Cannot use both --secret-file and --no-secret。配合 Workload Identity 等场景通常还需要用--sa-annotations为 Velero 的 ServiceAccount 注入注解如iam.gke.io/gcp-service-accountGSAPROJECT.iam.gserviceaccount.com或使用--pod-annotations注入角色注解例如velero install \ --provider aws \ --plugins velero/velero-plugin-for-aws:v1.0.0 \ --bucket backups \ --backup-location-config regionus-west-2 \ --snapshot-location-config regionus-west-2 \ --no-secret \ --pod-annotations iam.amazonaws.com/rolearn:aws:iam::AWS_ACCOUNT_ID:role/VELERO_ROLE_NAME启用文件系统备份File System Backupvelero install默认不会安装 Velero 的 File System BackupFSB原 restic由 node-agent 承载。启用它的方式是追加--use-node-agent标志velero install \ --provider PROVIDER \ --plugins PLUGIN_IMAGE \ --bucket BUCKET \ --secret-file PATH_TO_FILE \ --use-node-agent该标志会触发安装器额外生成node-agent的 DaemonSet见 resources.go。如果你此前已经执行过不带--use-node-agent的安装可以再次运行相同命令并加上该标志即可把文件系统备份能力补加到现有安装中无需卸载重装。从源码看安装器还会等待 node-agent DaemonSet 在全部目标节点上就绪NodeAgentIsReady会持续轮询直到Status.NumberAvailable Status.DesiredNumberScheduled且连续观测到 5 次以上就绪状态见 install.go配合--wait标志使用可确保安装完成后组件真正可用。另外还有两个相关标志值得了解定义于 install.go--use-node-agent-windows额外创建面向 Windows 节点的 node-agent-windows DaemonSet--privileged-node-agent以特权模式运行 node-agent备份裸块设备block device时必需。默认对所有 Pod 卷启用文件系统备份--default-volumes-to-fs-backup默认情况下即使安装了 node-agentVelero 也不会自动对所有 Pod 卷使用 FSB——你必须在每个包含卷的 Pod 上打上 启用注解Velero 才会对其使用 FSB 进行备份。如果你计划仅用 FSB 完成卷备份可以在velero install时加上--default-volumes-to-fs-backup标志使所有 Pod 卷默认走 FSB无需逐个 Pod 打注解velero install \ --provider PROVIDER \ --plugins PLUGIN_IMAGE \ --bucket BUCKET \ --secret-file PATH_TO_FILE \ --use-node-agent \ --default-volumes-to-fs-backup需要特别注意两点均为源码中的强制约束见 install.go--default-volumes-to-fs-backup必须以--use-node-agent为前提二者同时使用时校验器会直接报错--use-node-agent is required when using --default-volumes-to-fs-backup该标志是全局默认行为设置后 Velero 对每次备份都优先尝试 FSB即使你在velero backup create时用--snapshot-volumes指定某个备份希望走卷快照也无法覆盖这一全局默认。因此若你的集群中既存在需要快照的卷、又存在需要 FSB 的卷建议不要全局开启而是保留逐 Pod 打注解的细粒度方式也可以对个别备份使用--default-volumes-to-fs-backup标志单独指定该备份全部走 FSB。启用特性Enable FeaturesVelero 的新特性通常以 beta 状态隐藏在特性开关Feature Flags之后默认不开启。完整特性清单可在 pkg/apis/velero/v1/constants.go 中看到例如EnableCSI、EnableAPIGroupVersions等常量定义。启用服务端特性服务端特性通过velero install的--features标志启用取值为逗号分隔的特性名列表。例如启用 CSI 卷快照velero install --featuresEnableCSI另一个例子是启用多 API 组版本支持详见 enable-api-group-versions-featurevelero install --featuresEnableAPIGroupVersions从源码的安装流程resources.go 与 resources.go可以确认--features中列出的特性会被同时写入Velero Deployment 的启动参数--features若使用了--use-node-agent也会同步写入 node-agent DaemonSet 的启动参数。同样的禁用特性只需从--features中移除对应项即可。启用/禁用特性本质上是修改 Velero Deployment 与 node-agent DaemonSet两种途径任选其一通过 CLI 卸载后重新安装直接在集群内编辑这两个资源kubectl -n velero edit deploy/velero kubectl -n velero edit daemonset/node-agent启用客户端特性部分特性需要 Velero 客户端CLI也开启对应开关。有两种方式每次运行命令时显式传入--features将特性持久化写入客户端配置文件velero client config set featuresEnableCSI该命令会把配置写入$HOME/.config/velero/config.json。清除所有客户端侧特性开关velero client config set features彩色 CLI 输出控制Velero CLI 对部分命令如velero describe使用彩色输出。当运行环境不支持彩色输出时会自动禁用你也可以手动关闭velero client config set colorizedfalse注意如果在命令行显式指定--colorizedtrue该选项会覆盖配置文件中的设置。定制资源请求与限额Resource Requests and Limits安装时Velero 会为 Velero pod 与启用文件系统备份时的node-agent pod 设置默认资源请求与限额。关于默认值的版本差异说明v1.12 文档给出的默认值如下表。需要注意当前仓库源码 pkg/install/resources.go 中 node-agent 的默认值已调整为0即不设置 request/limitQoS 为 BestEffort而 Velero 主 pod 的默认值仍与下表一致具体默认值请以你所安装的 Velero 版本实际生成的 YAML 为准。设置项Velero pod 默认值v1.12node-agent pod 默认值v1.12CPU request500m500mMemory request128Mi512MiCPU limit1000m1 CPU1000m1 CPUMemory limit512Mi1024Mi默认值的适用规模根据维护者的测试经验这些默认值在备份/恢复资源数不超过 1000 个、文件总大小不超过 100GB的场景下表现良好。如果你的备份或恢复规模超过该范围就需要调大 Velero 可用的 CPU 或内存。总体规律是备份操作比恢复操作更消耗 CPU 与内存但耗时更短针对同一份数据的备份与恢复对比。具体所需的限额取决于你的资源文件/目录规模与硬件条件强烈建议基于自己的集群和资源做压测来确定最佳限额。若使用了文件系统备份可能还需要相应调大限额详见 File System Backup。安装时定制资源请求与限额在首次安装时通过velero install的相关标志即可定制velero install \ --velero-pod-cpu-request CPU_REQUEST \ --velero-pod-mem-request MEMORY_REQUEST \ --velero-pod-cpu-limit CPU_LIMIT \ --velero-pod-mem-limit MEMORY_LIMIT \ [--use-node-agent] \ [--default-volumes-to-fs-backup] \ [--node-agent-pod-cpu-request CPU_REQUEST] \ [--node-agent-pod-mem-request MEMORY_REQUEST] \ [--node-agent-pod-cpu-limit CPU_LIMIT] \ [--node-agent-pod-mem-limit MEMORY_LIMIT]这些标志的取值格式与 Kubernetes 资源需求量resource requirements一致如500m、128Mi、1、2Gi等。从源码看install.go每个标志的说明中都注明值0会被视为无上限unbounded随后由ParseCPUAndMemoryResources解析为corev1api.ResourceRequirements注入 pod 模板见 install.go。完整示例同时定制 Velero pod 与 node-agent podvelero install \ --provider gcp \ --plugins velero/velero-plugin-for-gcp:v1.0.0 \ --bucket gcp-backups \ --secret-file ./gcp-creds.json \ --use-node-agent \ --velero-pod-cpu-request1000m \ --velero-pod-cpu-limit5000m \ --velero-pod-mem-request512Mi \ --velero-pod-mem-limit1024Mi \ --node-agent-pod-cpu-request1000m \ --node-agent-pod-cpu-limit5000m \ --node-agent-pod-mem-request512Mi \ --node-agent-pod-mem-limit1024Mi安装后调整资源请求与限额安装完成后可以直接修改 Velero Deployment 或 node-agent DaemonSet 的spec.template.spec.containers.resources字段。Velero pod更新spec.template.spec.containers.resources.limits与requestskubectl patch deployment velero -n velero --patch \ {spec:{template:{spec:{containers:[{name: velero, resources: {limits:{cpu: 1, memory: 512Mi}, requests: {cpu: 1, memory: 128Mi}}}]}}}}node-agent podkubectl patch daemonset node-agent -n velero --patch \ {spec:{template:{spec:{containers:[{name: node-agent, resources: {limits:{cpu: 1, memory: 1024Mi}, requests: {cpu: 1, memory: 512Mi}}}]}}}}调整文件系统备份超时时间--fs-backup-timeout对于大型备份你可能还需要调大默认的 FSB 操作超时时间默认 240 分钟让大备份有更充裕的时间完成。通过向 Velero Deployment 添加--fs-backup-timeout启动参数即可打开 Velero Deployment 配置kubectl edit deploy velero -n velero在spec.template.spec.containers下添加该参数spec: template: spec: containers: - args: - --fs-backup-timeout240m从源码看该参数在 deployment.go 中由安装时的--pod-volume-operation-timeout选项驱动生成默认 4h即 240m。注意如果你重新运行velero install命令这个手动修改的超时值会被重置回默认值。配置多个备份存储位置或卷快照位置Velero 支持任意数量的备份存储位置BackupStorageLocation与卷快照位置VolumeSnapshotLocation详细说明见 locations。但velero install最多只能配置一个默认备份存储位置和一个卷快照位置。安装完成后要增加更多位置请使用velero backup-location create与velero snapshot-location create命令并配合提供方特定的配置各命令的详细参数请用--help查看。设置默认备份存储位置与默认卷快照位置执行备份时Velero 必须知道把数据备份到哪里。因此当你配置了多个位置时每次velero backup create都要显式指定使用哪个位置或者提前设置默认备份存储位置与默认卷快照位置。如果某个提供方下只有一个备份存储位置或卷快照位置Velero 会自动将其作为默认。为备份存储位置设置默认值在velero backup-location create时传入--default标志velero backup-location create backups-primary \ --provider aws \ --bucket velero-backups \ --config regionus-east-1 \ --default为卷快照位置设置默认值则使用velero server命令的--default-volume-snapshot-locations标志取值格式为提供方名:位置名的逗号分隔列表velero server --default-volume-snapshot-locationsPROVIDER-NAME:LOCATION-NAME,PROVIDER2-NAME:LOCATION2-NAME安装时不配置备份存储位置--no-default-backup-location某些场景下你需要安装 Velero 但暂不指定默认备份存储位置即不传--bucket和--provider。此时必须显式加上--no-default-backup-location标志作为确认否则校验会失败。源码中的校验规则非常严格见 install.go--no-default-backup-location不能与--bucket、--prefix、--backup-location-config同时使用未加该标志时--provider与--bucket均为必填结合--use-volume-snapshotsfalse时--provider也必须留空见 install.go。安装额外的卷快照提供方Velero 支持卷快照使用与对象存储不同的提供方。例如用 AWS S3 做对象存储同时用 Portworx 做块设备卷快照。不过velero install只支持为对象存储和卷快照配置同一个提供方。要使用不同的卷快照提供方请按以下步骤操作先按照你的对象存储提供方的安装指引安装好 Velero 服务端组件参见 basic-install把卷快照提供方的插件添加到 Velero镜像名请查阅对应提供方的文档velero plugin add registry/image:version为你的提供方创建卷快照位置配置项参考对应提供方文档velero snapshot-location create NAME \ --provider PROVIDER-NAME \ [--config PROVIDER-CONFIG]仅生成 YAML--dry-run -o yamlvelero install默认会生成一套定制化的 Kubernetes 配置YAML并直接应用到集群。如果只想生成 YAML 而不应用到集群使用--dry-run -o yaml标志velero install \ --provider PROVIDER \ --plugins PLUGIN_IMAGE \ --bucket BUCKET \ --secret-file PATH_TO_FILE \ --dry-run -o yaml这在以下场景非常有用对生成的资源做自定义修改后再统一应用接入 GitOps 工作流将 YAML 纳入版本管理后由 CI/CD 自动应用。从源码看velero install的生成流程是Run中先调用install.AllResources(vo)生成按依赖顺序排列的 unstructured 资源列表CRD 在前其余资源在后然后交给 install.Install 依次创建先安装全部 CRD 并轮询等待其就绪最长 1 分钟再创建其余资源而--dry-run会在发送到集群之前直接返回见 install.go。新增的--apply标志则使用服务端应用server-side apply而非 create可用于更新已有安装。兼容性提示如果目标集群是 Kubernetes 1.14.x 及更早版本应用生成的配置时需要使用kubectl apply --validatefalse相关背景可参考 Velero 仓库的历史 issue#2077、#2311。使用自签名证书保护的存储提供方如果你要对接由自签名证书保护的存储提供方如内部对象存储/MinIO可能需要让 Velero 信任该证书。详细配置方法见 use Velero with a storage provider secured by a self-signed certificate。安装时可通过--cacert标志传入包含证书 bundle 的文件见 install.go安装器会将其注入到默认 BackupStorageLocation 的spec.storage.objectStorage.cacert字段见 resources.go。更多安装选项velero install还提供大量其他选项包括但不限于均可从源码 install.go 中确认--pod-annotations/--pod-labels为 Velero 与 node-agent pod 注入注解/标签--sa-annotations为 ServiceAccount 注入注解如 Workload Identity 所需--restore-only以仅恢复模式运行服务端--wait安装后等待 Velero Deployment 就绪--image覆盖 Velero 与 node-agent 使用的镜像--uploader-type设置 pod 卷数据的上传器类型当前支持kopia--default-snapshot-move-data、--csi-snapshot-early-frequent-polling、--disable-informer-cache、--schedule-skip-immediately等行为开关--default-repo-maintain-frequency、--garbage-collection-frequency、--pod-volume-operation-timeout等周期/超时参数--backup-repository-configmap、--repo-maintenance-job-configmap、--default-resource-modifier-configmap、--node-agent-configmap等 ConfigMap 关联选项指定后安装器会校验其 JSON 内容合法性--item-block-worker-count、--concurrent-backups调整备份处理的并发度--server-priority-class-name、--node-agent-priority-class-name为组件指定 PriorityClass--kubelet-root-dir、--node-agent-disable-host-pathnode-agent 的节点侧挂载与路径定制--crds-only仅生成/更新 CRD 资源适合升级已有安装的 CRD。完整的标志清单与说明请运行velero install --help查看安装命令的基础用法见 velero-install。可选的 Velero CLI 配置Shell 自动补全Velero CLI 为 Bash 与 Zsh 提供自动补全支持。补全脚本由velero completion子命令生成对应源码入口为cmd/velero/velero.go下的 completion 命令族。BashLinux生成 Bash 补全脚本的命令是velero completion bash在 shell 中 source 该脚本即可启用补全。补全脚本依赖bash-completion软件包。先确认是否已安装运行type _init_completion检查未安装则通过包管理器安装apt-get install bash-completion # Debian/Ubuntu 系 yum install bash-completion # RHEL/CentOS 系安装后主脚本位于/usr/share/bash-completion/bash_completion。重新加载 shell 后再执行type _init_completion验证若提示未找到则在~/.bashrc中手动 sourcesource /usr/share/bash-completion/bash_completion然后二选一启用 Velero 补全在~/.bashrc中 source 补全脚本echo source (velero completion bash) ~/.bashrc将补全脚本放入/etc/bash_completion.d目录bash-completion 会自动加载该目录下的所有脚本velero completion bash /etc/bash_completion.d/velero如果你为 velero 设置了别名可以让补全对别名同样生效echo alias vvelero ~/.bashrc echo complete -F __start_velero v ~/.bashrc重新加载 shell 后Velero 自动补全即可生效。BashmacOSmacOS 上默认的 Bash 版本是 3.2而 Velero 的补全脚本不兼容bash-completion v1 与 Bash 3.2需要Bash 4.1与bash-completion v2。因此使用前请先升级 Bash 到 4.1 或更高版本后续步骤均假设你已使用 Bash 4.1。安装 bash-completion v2用type _init_completion先确认是否已装brew install bash-completion2按安装输出提示在~/.bashrc中添加export BASH_COMPLETION_COMPAT_DIR/usr/local/etc/bash_completion.d [[ -r /usr/local/etc/profile.d/bash_completion.sh ]] . /usr/local/etc/profile.d/bash_completion.sh重新加载 shell用type _init_completion验证 bash-completion v2 是否就绪。之后启用 Velero 补全三选一在~/.bashrc中 source 补全脚本echo source (velero completion bash) ~/.bashrc将脚本放入/usr/local/etc/bash_completion.dvelero completion bash /usr/local/etc/bash_completion.d/velero如果你通过 Homebrew 安装了 Velero补全脚本通常已自动位于/usr/local/etc/bash_completion.d/velero无需额外操作。若设置了别名同样可以扩展补全echo alias vvelero ~/.bashrc echo complete -F __start_velero v ~/.bashrcHomebrew 的 bash-completion v2 会 sourceBASH_COMPLETION_COMPAT_DIR目录下的全部脚本因此后两种方式均有效。重新加载 shell 后补全即可生效。Zsh生成 Zsh 补全脚本的命令是velero completion zsh。在~/.zshrc中添加source (velero completion zsh)如需对别名生效echo alias vvelero ~/.zshrc echo complete -F __start_velero v ~/.zshrc重新加载 shell 后补全生效。若出现如下错误complete:13: command not found: compdef则在~/.zshrc文件开头添加autoload -Uz compinit compinit小结velero install虽然只暴露了一个命令但其定制能力覆盖了命名空间、凭证方式、备份通道卷快照 vs 文件系统备份、特性开关、资源配额、存储位置、输出方式等多个维度。理解这些标志背后的校验逻辑与资源生成流程主要在 pkg/cmd/cli/install/install.go 与 pkg/install 包中可以帮助你在生产环境中一次性安装出贴合自身规模与安全要求的 Velero 集群并在后续通过编辑 Deployment / DaemonSet 或kubectl patch完成细粒度调整。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Velero 安装定制完全指南：插件、命名空间、文件系统备份、特性开关与资源限额配置
Velero 安装定制完全指南插件、命名空间、文件系统备份、特性开关与资源限额配置【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero本篇技术指南以 Velero 官方文档中的《Customize Velero Install》为骨架系统讲解在velero install基础命令之上如何针对生产环境进行安装定制包括插件选择、自定义命名空间、非凭证文件身份机制、启用文件系统备份FSB、特性开关Feature Flags、资源请求与限额、多存储位置配置、仅生成 YAML 以及 CLI 自动补全等。读完本文你将掌握一套可复制的 Velero 安装定制方案并能结合仓库源码理解每个定制项在安装流程中的真实作用。前提至少添加一个插件velero install在安装时必须通过--plugins标志添加至少一个提供方插件例如 AWS、GCP、Azure 的对象存储与卷快照插件。这一点在源码中有强制校验在 install.go 的Validate中当存在默认备份存储位置或使用卷快照时如果--plugins为空会直接报错--plugins flag is required。插件以容器镜像的形式注入 Velero Deployment例如velero install \ --provider aws \ --plugins velero/velero-plugin-for-aws:v1.0.0 \ --bucket backups \ --secret-file ./aws-iam-creds关于各提供方插件镜像的完整清单参见 supported-providers 与 overview-plugins。安装到任意命名空间Velero 默认安装在velero命名空间velero install命令也支持通过--namespace标志安装到任意命名空间。需要说明的是默认命名空间常量定义于 pkg/apis/velero/v1/constants.goDefaultNamespace velero同时被 CLI 与服务端共同使用从 resources.go 可以看到当命名空间不是默认的velero时安装器生成的 ClusterRoleBinding 名称会带上命名空间后缀velero-namespace以避免跨命名空间冲突若使用自定义命名空间安装器还会为该命名空间打上 Pod Security 强制标签pod-security.kubernetes.io/enforceprivileged等见 resources.go。在非默认命名空间运行时的注意事项参见 run in custom namespace。使用非文件型身份机制--no-secret默认情况下velero install期望通过--secret-file提供一个包含云厂商 IAM 凭证的文件安装器会读取该文件内容并生成名为cloud-credentials的 Secret见 resources.go数据键为cloud。如果你使用不依赖凭证文件的身份机制例如AWS 上的 kube2iam / kiam基于 Pod 注解注入临时角色GKE 上的 Workload Identity其他通过 Service Account 注解或 Pod 注解完成鉴权的方案则可以改用--no-secret标志替代--secret-file。源码中的校验逻辑要求二者必须二选一见 install.go两个标志都未指定 → 报错One of --secret-file or --no-secret is required两个标志同时指定 → 报错Cannot use both --secret-file and --no-secret。配合 Workload Identity 等场景通常还需要用--sa-annotations为 Velero 的 ServiceAccount 注入注解如iam.gke.io/gcp-service-accountGSAPROJECT.iam.gserviceaccount.com或使用--pod-annotations注入角色注解例如velero install \ --provider aws \ --plugins velero/velero-plugin-for-aws:v1.0.0 \ --bucket backups \ --backup-location-config regionus-west-2 \ --snapshot-location-config regionus-west-2 \ --no-secret \ --pod-annotations iam.amazonaws.com/rolearn:aws:iam::AWS_ACCOUNT_ID:role/VELERO_ROLE_NAME启用文件系统备份File System Backupvelero install默认不会安装 Velero 的 File System BackupFSB原 restic由 node-agent 承载。启用它的方式是追加--use-node-agent标志velero install \ --provider PROVIDER \ --plugins PLUGIN_IMAGE \ --bucket BUCKET \ --secret-file PATH_TO_FILE \ --use-node-agent该标志会触发安装器额外生成node-agent的 DaemonSet见 resources.go。如果你此前已经执行过不带--use-node-agent的安装可以再次运行相同命令并加上该标志即可把文件系统备份能力补加到现有安装中无需卸载重装。从源码看安装器还会等待 node-agent DaemonSet 在全部目标节点上就绪NodeAgentIsReady会持续轮询直到Status.NumberAvailable Status.DesiredNumberScheduled且连续观测到 5 次以上就绪状态见 install.go配合--wait标志使用可确保安装完成后组件真正可用。另外还有两个相关标志值得了解定义于 install.go--use-node-agent-windows额外创建面向 Windows 节点的 node-agent-windows DaemonSet--privileged-node-agent以特权模式运行 node-agent备份裸块设备block device时必需。默认对所有 Pod 卷启用文件系统备份--default-volumes-to-fs-backup默认情况下即使安装了 node-agentVelero 也不会自动对所有 Pod 卷使用 FSB——你必须在每个包含卷的 Pod 上打上 启用注解Velero 才会对其使用 FSB 进行备份。如果你计划仅用 FSB 完成卷备份可以在velero install时加上--default-volumes-to-fs-backup标志使所有 Pod 卷默认走 FSB无需逐个 Pod 打注解velero install \ --provider PROVIDER \ --plugins PLUGIN_IMAGE \ --bucket BUCKET \ --secret-file PATH_TO_FILE \ --use-node-agent \ --default-volumes-to-fs-backup需要特别注意两点均为源码中的强制约束见 install.go--default-volumes-to-fs-backup必须以--use-node-agent为前提二者同时使用时校验器会直接报错--use-node-agent is required when using --default-volumes-to-fs-backup该标志是全局默认行为设置后 Velero 对每次备份都优先尝试 FSB即使你在velero backup create时用--snapshot-volumes指定某个备份希望走卷快照也无法覆盖这一全局默认。因此若你的集群中既存在需要快照的卷、又存在需要 FSB 的卷建议不要全局开启而是保留逐 Pod 打注解的细粒度方式也可以对个别备份使用--default-volumes-to-fs-backup标志单独指定该备份全部走 FSB。启用特性Enable FeaturesVelero 的新特性通常以 beta 状态隐藏在特性开关Feature Flags之后默认不开启。完整特性清单可在 pkg/apis/velero/v1/constants.go 中看到例如EnableCSI、EnableAPIGroupVersions等常量定义。启用服务端特性服务端特性通过velero install的--features标志启用取值为逗号分隔的特性名列表。例如启用 CSI 卷快照velero install --featuresEnableCSI另一个例子是启用多 API 组版本支持详见 enable-api-group-versions-featurevelero install --featuresEnableAPIGroupVersions从源码的安装流程resources.go 与 resources.go可以确认--features中列出的特性会被同时写入Velero Deployment 的启动参数--features若使用了--use-node-agent也会同步写入 node-agent DaemonSet 的启动参数。同样的禁用特性只需从--features中移除对应项即可。启用/禁用特性本质上是修改 Velero Deployment 与 node-agent DaemonSet两种途径任选其一通过 CLI 卸载后重新安装直接在集群内编辑这两个资源kubectl -n velero edit deploy/velero kubectl -n velero edit daemonset/node-agent启用客户端特性部分特性需要 Velero 客户端CLI也开启对应开关。有两种方式每次运行命令时显式传入--features将特性持久化写入客户端配置文件velero client config set featuresEnableCSI该命令会把配置写入$HOME/.config/velero/config.json。清除所有客户端侧特性开关velero client config set features彩色 CLI 输出控制Velero CLI 对部分命令如velero describe使用彩色输出。当运行环境不支持彩色输出时会自动禁用你也可以手动关闭velero client config set colorizedfalse注意如果在命令行显式指定--colorizedtrue该选项会覆盖配置文件中的设置。定制资源请求与限额Resource Requests and Limits安装时Velero 会为 Velero pod 与启用文件系统备份时的node-agent pod 设置默认资源请求与限额。关于默认值的版本差异说明v1.12 文档给出的默认值如下表。需要注意当前仓库源码 pkg/install/resources.go 中 node-agent 的默认值已调整为0即不设置 request/limitQoS 为 BestEffort而 Velero 主 pod 的默认值仍与下表一致具体默认值请以你所安装的 Velero 版本实际生成的 YAML 为准。设置项Velero pod 默认值v1.12node-agent pod 默认值v1.12CPU request500m500mMemory request128Mi512MiCPU limit1000m1 CPU1000m1 CPUMemory limit512Mi1024Mi默认值的适用规模根据维护者的测试经验这些默认值在备份/恢复资源数不超过 1000 个、文件总大小不超过 100GB的场景下表现良好。如果你的备份或恢复规模超过该范围就需要调大 Velero 可用的 CPU 或内存。总体规律是备份操作比恢复操作更消耗 CPU 与内存但耗时更短针对同一份数据的备份与恢复对比。具体所需的限额取决于你的资源文件/目录规模与硬件条件强烈建议基于自己的集群和资源做压测来确定最佳限额。若使用了文件系统备份可能还需要相应调大限额详见 File System Backup。安装时定制资源请求与限额在首次安装时通过velero install的相关标志即可定制velero install \ --velero-pod-cpu-request CPU_REQUEST \ --velero-pod-mem-request MEMORY_REQUEST \ --velero-pod-cpu-limit CPU_LIMIT \ --velero-pod-mem-limit MEMORY_LIMIT \ [--use-node-agent] \ [--default-volumes-to-fs-backup] \ [--node-agent-pod-cpu-request CPU_REQUEST] \ [--node-agent-pod-mem-request MEMORY_REQUEST] \ [--node-agent-pod-cpu-limit CPU_LIMIT] \ [--node-agent-pod-mem-limit MEMORY_LIMIT]这些标志的取值格式与 Kubernetes 资源需求量resource requirements一致如500m、128Mi、1、2Gi等。从源码看install.go每个标志的说明中都注明值0会被视为无上限unbounded随后由ParseCPUAndMemoryResources解析为corev1api.ResourceRequirements注入 pod 模板见 install.go。完整示例同时定制 Velero pod 与 node-agent podvelero install \ --provider gcp \ --plugins velero/velero-plugin-for-gcp:v1.0.0 \ --bucket gcp-backups \ --secret-file ./gcp-creds.json \ --use-node-agent \ --velero-pod-cpu-request1000m \ --velero-pod-cpu-limit5000m \ --velero-pod-mem-request512Mi \ --velero-pod-mem-limit1024Mi \ --node-agent-pod-cpu-request1000m \ --node-agent-pod-cpu-limit5000m \ --node-agent-pod-mem-request512Mi \ --node-agent-pod-mem-limit1024Mi安装后调整资源请求与限额安装完成后可以直接修改 Velero Deployment 或 node-agent DaemonSet 的spec.template.spec.containers.resources字段。Velero pod更新spec.template.spec.containers.resources.limits与requestskubectl patch deployment velero -n velero --patch \ {spec:{template:{spec:{containers:[{name: velero, resources: {limits:{cpu: 1, memory: 512Mi}, requests: {cpu: 1, memory: 128Mi}}}]}}}}node-agent podkubectl patch daemonset node-agent -n velero --patch \ {spec:{template:{spec:{containers:[{name: node-agent, resources: {limits:{cpu: 1, memory: 1024Mi}, requests: {cpu: 1, memory: 512Mi}}}]}}}}调整文件系统备份超时时间--fs-backup-timeout对于大型备份你可能还需要调大默认的 FSB 操作超时时间默认 240 分钟让大备份有更充裕的时间完成。通过向 Velero Deployment 添加--fs-backup-timeout启动参数即可打开 Velero Deployment 配置kubectl edit deploy velero -n velero在spec.template.spec.containers下添加该参数spec: template: spec: containers: - args: - --fs-backup-timeout240m从源码看该参数在 deployment.go 中由安装时的--pod-volume-operation-timeout选项驱动生成默认 4h即 240m。注意如果你重新运行velero install命令这个手动修改的超时值会被重置回默认值。配置多个备份存储位置或卷快照位置Velero 支持任意数量的备份存储位置BackupStorageLocation与卷快照位置VolumeSnapshotLocation详细说明见 locations。但velero install最多只能配置一个默认备份存储位置和一个卷快照位置。安装完成后要增加更多位置请使用velero backup-location create与velero snapshot-location create命令并配合提供方特定的配置各命令的详细参数请用--help查看。设置默认备份存储位置与默认卷快照位置执行备份时Velero 必须知道把数据备份到哪里。因此当你配置了多个位置时每次velero backup create都要显式指定使用哪个位置或者提前设置默认备份存储位置与默认卷快照位置。如果某个提供方下只有一个备份存储位置或卷快照位置Velero 会自动将其作为默认。为备份存储位置设置默认值在velero backup-location create时传入--default标志velero backup-location create backups-primary \ --provider aws \ --bucket velero-backups \ --config regionus-east-1 \ --default为卷快照位置设置默认值则使用velero server命令的--default-volume-snapshot-locations标志取值格式为提供方名:位置名的逗号分隔列表velero server --default-volume-snapshot-locationsPROVIDER-NAME:LOCATION-NAME,PROVIDER2-NAME:LOCATION2-NAME安装时不配置备份存储位置--no-default-backup-location某些场景下你需要安装 Velero 但暂不指定默认备份存储位置即不传--bucket和--provider。此时必须显式加上--no-default-backup-location标志作为确认否则校验会失败。源码中的校验规则非常严格见 install.go--no-default-backup-location不能与--bucket、--prefix、--backup-location-config同时使用未加该标志时--provider与--bucket均为必填结合--use-volume-snapshotsfalse时--provider也必须留空见 install.go。安装额外的卷快照提供方Velero 支持卷快照使用与对象存储不同的提供方。例如用 AWS S3 做对象存储同时用 Portworx 做块设备卷快照。不过velero install只支持为对象存储和卷快照配置同一个提供方。要使用不同的卷快照提供方请按以下步骤操作先按照你的对象存储提供方的安装指引安装好 Velero 服务端组件参见 basic-install把卷快照提供方的插件添加到 Velero镜像名请查阅对应提供方的文档velero plugin add registry/image:version为你的提供方创建卷快照位置配置项参考对应提供方文档velero snapshot-location create NAME \ --provider PROVIDER-NAME \ [--config PROVIDER-CONFIG]仅生成 YAML--dry-run -o yamlvelero install默认会生成一套定制化的 Kubernetes 配置YAML并直接应用到集群。如果只想生成 YAML 而不应用到集群使用--dry-run -o yaml标志velero install \ --provider PROVIDER \ --plugins PLUGIN_IMAGE \ --bucket BUCKET \ --secret-file PATH_TO_FILE \ --dry-run -o yaml这在以下场景非常有用对生成的资源做自定义修改后再统一应用接入 GitOps 工作流将 YAML 纳入版本管理后由 CI/CD 自动应用。从源码看velero install的生成流程是Run中先调用install.AllResources(vo)生成按依赖顺序排列的 unstructured 资源列表CRD 在前其余资源在后然后交给 install.Install 依次创建先安装全部 CRD 并轮询等待其就绪最长 1 分钟再创建其余资源而--dry-run会在发送到集群之前直接返回见 install.go。新增的--apply标志则使用服务端应用server-side apply而非 create可用于更新已有安装。兼容性提示如果目标集群是 Kubernetes 1.14.x 及更早版本应用生成的配置时需要使用kubectl apply --validatefalse相关背景可参考 Velero 仓库的历史 issue#2077、#2311。使用自签名证书保护的存储提供方如果你要对接由自签名证书保护的存储提供方如内部对象存储/MinIO可能需要让 Velero 信任该证书。详细配置方法见 use Velero with a storage provider secured by a self-signed certificate。安装时可通过--cacert标志传入包含证书 bundle 的文件见 install.go安装器会将其注入到默认 BackupStorageLocation 的spec.storage.objectStorage.cacert字段见 resources.go。更多安装选项velero install还提供大量其他选项包括但不限于均可从源码 install.go 中确认--pod-annotations/--pod-labels为 Velero 与 node-agent pod 注入注解/标签--sa-annotations为 ServiceAccount 注入注解如 Workload Identity 所需--restore-only以仅恢复模式运行服务端--wait安装后等待 Velero Deployment 就绪--image覆盖 Velero 与 node-agent 使用的镜像--uploader-type设置 pod 卷数据的上传器类型当前支持kopia--default-snapshot-move-data、--csi-snapshot-early-frequent-polling、--disable-informer-cache、--schedule-skip-immediately等行为开关--default-repo-maintain-frequency、--garbage-collection-frequency、--pod-volume-operation-timeout等周期/超时参数--backup-repository-configmap、--repo-maintenance-job-configmap、--default-resource-modifier-configmap、--node-agent-configmap等 ConfigMap 关联选项指定后安装器会校验其 JSON 内容合法性--item-block-worker-count、--concurrent-backups调整备份处理的并发度--server-priority-class-name、--node-agent-priority-class-name为组件指定 PriorityClass--kubelet-root-dir、--node-agent-disable-host-pathnode-agent 的节点侧挂载与路径定制--crds-only仅生成/更新 CRD 资源适合升级已有安装的 CRD。完整的标志清单与说明请运行velero install --help查看安装命令的基础用法见 velero-install。可选的 Velero CLI 配置Shell 自动补全Velero CLI 为 Bash 与 Zsh 提供自动补全支持。补全脚本由velero completion子命令生成对应源码入口为cmd/velero/velero.go下的 completion 命令族。BashLinux生成 Bash 补全脚本的命令是velero completion bash在 shell 中 source 该脚本即可启用补全。补全脚本依赖bash-completion软件包。先确认是否已安装运行type _init_completion检查未安装则通过包管理器安装apt-get install bash-completion # Debian/Ubuntu 系 yum install bash-completion # RHEL/CentOS 系安装后主脚本位于/usr/share/bash-completion/bash_completion。重新加载 shell 后再执行type _init_completion验证若提示未找到则在~/.bashrc中手动 sourcesource /usr/share/bash-completion/bash_completion然后二选一启用 Velero 补全在~/.bashrc中 source 补全脚本echo source (velero completion bash) ~/.bashrc将补全脚本放入/etc/bash_completion.d目录bash-completion 会自动加载该目录下的所有脚本velero completion bash /etc/bash_completion.d/velero如果你为 velero 设置了别名可以让补全对别名同样生效echo alias vvelero ~/.bashrc echo complete -F __start_velero v ~/.bashrc重新加载 shell 后Velero 自动补全即可生效。BashmacOSmacOS 上默认的 Bash 版本是 3.2而 Velero 的补全脚本不兼容bash-completion v1 与 Bash 3.2需要Bash 4.1与bash-completion v2。因此使用前请先升级 Bash 到 4.1 或更高版本后续步骤均假设你已使用 Bash 4.1。安装 bash-completion v2用type _init_completion先确认是否已装brew install bash-completion2按安装输出提示在~/.bashrc中添加export BASH_COMPLETION_COMPAT_DIR/usr/local/etc/bash_completion.d [[ -r /usr/local/etc/profile.d/bash_completion.sh ]] . /usr/local/etc/profile.d/bash_completion.sh重新加载 shell用type _init_completion验证 bash-completion v2 是否就绪。之后启用 Velero 补全三选一在~/.bashrc中 source 补全脚本echo source (velero completion bash) ~/.bashrc将脚本放入/usr/local/etc/bash_completion.dvelero completion bash /usr/local/etc/bash_completion.d/velero如果你通过 Homebrew 安装了 Velero补全脚本通常已自动位于/usr/local/etc/bash_completion.d/velero无需额外操作。若设置了别名同样可以扩展补全echo alias vvelero ~/.bashrc echo complete -F __start_velero v ~/.bashrcHomebrew 的 bash-completion v2 会 sourceBASH_COMPLETION_COMPAT_DIR目录下的全部脚本因此后两种方式均有效。重新加载 shell 后补全即可生效。Zsh生成 Zsh 补全脚本的命令是velero completion zsh。在~/.zshrc中添加source (velero completion zsh)如需对别名生效echo alias vvelero ~/.zshrc echo complete -F __start_velero v ~/.zshrc重新加载 shell 后补全生效。若出现如下错误complete:13: command not found: compdef则在~/.zshrc文件开头添加autoload -Uz compinit compinit小结velero install虽然只暴露了一个命令但其定制能力覆盖了命名空间、凭证方式、备份通道卷快照 vs 文件系统备份、特性开关、资源配额、存储位置、输出方式等多个维度。理解这些标志背后的校验逻辑与资源生成流程主要在 pkg/cmd/cli/install/install.go 与 pkg/install 包中可以帮助你在生产环境中一次性安装出贴合自身规模与安全要求的 Velero 集群并在后续通过编辑 Deployment / DaemonSet 或kubectl patch完成细粒度调整。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考