kOps etcd 备份、恢复与加密完整指南：从 etcd-manager 到 EBS 卷加密

kOps etcd 备份、恢复与加密完整指南从 etcd-manager 到 EBS 卷加密【免费下载链接】kopsKubernetes Operations (kOps) - Production Grade k8s Installation, Upgrades and Management项目地址: https://gitcode.com/gh_mirrors/kop/kopskOpsKubernetes Operations将集群全部状态存放在 etcd 中因此 etcd 的数据安全直接决定了生产集群的可用性。本文围绕 kOps 的 etcd 备份、灾难恢复与数据卷加密三大主题完整讲解 kOps 默认的备份机制etcd-manager、基于etcd-manager-ctl的恢复流程、master 租约一致性问题的排查修复以及通过encryptedVolume/kmsKeyId参数实现 EBS 卷加密的两种方式并结合仓库源码说明这些参数在底层是如何生效的帮助你为 kOps 集群构建一套可落地的数据安全方案。为什么 etcd 备份是硬性需求Kubernetes 依赖 etcd 作为整个集群的状态存储kOps 集群的元数据Pod、Service、Deployment、Secret 等都保存在其中。kOps 在每个 master 节点上为 etcd 分配两个独立的 AWS EBS 卷一个存放 Kubernetes 主数据mainetcd 集群另一个存放事件数据eventsetcd 集群。对于三节点 HA master这意味着共 6 个用于 etcd 数据的卷每个可用区 2 个。EBS 卷并非永不损坏的设备其年故障率在设计上约为 0.1%–0.2%。在多个 master 的规模下这个概率会随卷数量累加加上误删、异常写入等运维事故仅依赖单卷的可用性远远不够。因此为 etcd 建立周期性备份是 kOps 生产集群的基本要求否则一旦数据损坏整个 Kubernetes 集群的状态将无法恢复。备份机制etcd-manager 与对象存储从 kOps 1.12 开始kOps 使用etcd-manager来管理 etcd详见 etcd 管理它负责 etcd 的优雅升级、TLS 以及备份/恢复在控制面需要更高冗余时还会负责 etcd 集群的扩缩容。kOps 会将main与events两个 etcd 集群的备份统一存储在与集群配置相同的位置——对象存储如 S3中。kOps 默认的备份周期与保留策略如下项目默认值说明备份间隔每 15 分钟一次通过manager.backupInterval调整小时级备份保留1 周kOps 1.27 之前通过 env 变量控制天级备份保留90 天kOps 1.27 之前为 2 年通过manager.backupRetentionDays调整在源码中pkg/apis/kops/cluster.go 的EtcdBackupSpec与EtcdManagerSpec明确定义了这些语义EtcdBackupSpec.BackupStore备份数据的 VFS 读写路径对象存储地址EtcdBackupSpec.Imageetcd 备份 sidecar 容器镜像设置后会在 etcd Pod 中以 sidecar 方式运行备份EtcdManagerSpec.BackupInterval备份间隔默认 15 分钟EtcdManagerSpec.BackupRetentionDays备份保留天数默认 90 天EtcdManagerSpec.DiscoveryPollInterval成员发现轮询间隔默认 60 秒。调整备份间隔与保留期备份间隔与保留期都可以通过kops edit cluster修改字段说明详见 集群配置文档。调整备份间隔该参数默认值自 kOps 1.24.1 起提供etcdClusters: - etcdMembers: - instanceGroup: master-us-east-1a name: a name: main manager: backupInterval: 1h调整备份保留天数自 kOps 1.27 起默认值为 90 天etcdClusters: - etcdMembers: - instanceGroup: master-us-east-1a name: a name: main manager: backupRetentionDays: 30对于旧版 kOps则通过 env 变量分别设置小时级与天级备份的保留时长etcdClusters: - etcdMembers: - instanceGroup: master-us-east-1a name: a name: main manager: env: - name: ETCD_MANAGER_HOURLY_BACKUPS_RETENTION value: 7d - name: ETCD_MANAGER_DAILY_BACKUPS_RETENTION value: 1y灾难恢复使用 etcd-manager-ctl 恢复备份当 etcd 遭遇灾难性情况数据丢失、集群异常等时可以通过etcd-manager-ctl恢复 etcd 集群。etcd-manager-ctl不必运行在集群内只要你有集群状态存储如 S3的访问权限即可直接使用。恢复前必须了解的三点风险恢复过程会导致 master进而导致 API Server停机恢复操作不可撤销除非再次执行恢复覆盖备份之后创建的资源会丢失包括 Pod、事件以及其他新写入的数据。以下示例假设集群名为test.my.clusters状态存储在 S3 bucketmy.clusters中。第一步列出可用备份注意main与events集群的备份文件不同需要分别查询etcd-manager-ctl --backup-stores3://my.clusters/test.my.clusters/backups/etcd/main list-backups etcd-manager-ctl --backup-stores3://my.clusters/test.my.clusters/backups/etcd/events list-backups备份对象位于状态存储的backups/etcd/{main,events}路径下这也印证了 kOps 将备份与集群配置存放在同一对象存储的设计。第二步为两个 etcd 集群下发恢复指令etcd-manager-ctl --backup-stores3://my.clusters/test.my.clusters/backups/etcd/main restore-backup [main backup dir] etcd-manager-ctl --backup-stores3://my.clusters/test.my.clusters/backups/etcd/events restore-backup [events backup dir][main backup dir]、[events backup dir]替换为第一步list-backups输出的具体备份目录。第三步重启各 master 上的 etcd-manager 容器恢复不会立即开始需要重启所有 master 上的 etcd 才能触发。通过docker stop或kill停止 etcd-manager 容器即可容器名称以k8s_etcd-manager_etcd-manager开头。容器会自动重启并拾取恢复指令。也可以快速滚动 master但推荐优先采用重启容器的方式。重启后etcd-manager 会创建全新的 etcd 集群并将备份数据恢复到新集群中。恢复耗时取决于集群数据量的大小。第四步跟踪恢复进度在主 leader 节点上查看 etcd 日志/var/log/etcd(-events).log跟踪恢复进度。可以通过查看所有 master 的 etcd 日志判断哪台是 leader——注意main与events两个 etcd 集群的 leader 可能不同。补充直接访问 etcd 数据如果需要在恢复之外直接查看或操作 etcd 数据例如排查问题可参考 etcd 管理 中给出的步骤先通过kops get cluster --full -o yaml查看 etcd 版本再进入etcd-manager-mainPod最后配置etcdctl别名并连接https://127.0.0.1:4001使用 kube-apiserver 目录下的 CA 与客户端证书用etcdctl member list验证连通性。修复 master 租约一致性问题Kubernetes 存在一个已知 bug旧的 apiserver 租约lease可能残留在 etcd 中无法清理。要判断集群是否受此问题影响检查 kubernetes apiserver 的 endpoints 资源kubectl get endpoints/kubernetes -o yaml如果看到的地址数量多于 master 数量就需要手动从 etcd 集群中移除多余租约。访问 etcd 的方式见 etcd 管理。拿到可用的 etcd 客户端后先查看/registry/masterleases下的所有租约etcdctl get --prefix --keys-only /registry/masterleases确认后可以一次性删除全部残留租约etcdctl del --prefix /registry/masterleases/存活的 apiserver 会立即重新创建自己的租约随后再次检查上述 endpoints 资源确认问题已解决。由于各节点本地状态可能与 etcd 中的状态不一致建议对整个集群执行一次滚动更新kops rolling-update cluster --force --yesetcd 卷加密两种 AWS KMS 方案kOps 支持对 etcd 数据卷进行加密但必须在集群创建之前配置——无法对已运行的集群事后追加卷加密。在源码层面加密能力由 pkg/apis/kops/cluster.go 的EtcdMemberSpec承载EncryptedVolume *bool是否加密该卷KmsKeyID *string用于加密卷的 AWS KMS 密钥 IDARN。这两个字段会直接传递到 EBS 卷的创建任务中pkg/model/master_volumes.go 在构造awstasks.EBSVolume时将KmsKeyId与Encrypted一并设置从而在底层云资源层面落实加密。方案一使用 AWS 默认 KMS 密钥执行kops edit cluster ${CLUSTER_NAME}为每个 etcd 卷添加encryptedVolume: true... etcdClusters: - etcdMembers: - instanceGroup: master-us-east-1a name: a encryptedVolume: true name: main - etcdMembers: - instanceGroup: master-us-east-1a name: a encryptedVolume: true name: events ...方案二使用自定义 AWS KMS 密钥在需要满足合规要求或希望用自有密钥管理加密时可以同时指定kmsKeyId填入 KMS 密钥的完整 ARN... etcdClusters: - etcdMembers: - instanceGroup: master-us-east-1a name: a encryptedVolume: true kmsKeyId: full-arn-of-your-kms-key name: main - etcdMembers: - instanceGroup: master-us-east-1a name: a encryptedVolume: true kmsKeyId: full-arn-of-your-kms-key name: events ...应用配置两种方案修改完成后都执行相同的更新命令kops update cluster ${CLUSTER_NAME} # 先审查变更确认无误后再应用 kops update cluster ${CLUSTER_NAME} --yeskops update cluster会先输出将要应用的变更清单务必逐项审查确认 EBS 卷加密属性已进入变更列表确认后再加--yes实际应用。总结备份kOps 通过 etcd-manager 每 15 分钟自动备份main与events两个 etcd 集群到对象存储备份间隔与保留天数可通过backupInterval、backupRetentionDays调整字段定义见 pkg/apis/kops/cluster.go恢复使用etcd-manager-ctl下发恢复指令并重启各 master 的 etcd-manager 容器即可完成恢复注意恢复会造成停机且会丢失备份之后的数据一致性修复apiserver endpoints 地址数异常时可通过etcdctl清理/registry/masterleases下的残留租约并配合kops rolling-update cluster --force --yes完成全集群滚动更新加密务必在集群创建前通过encryptedVolume可选配kmsKeyId为 etcd 卷启用 EBS 加密该配置在 pkg/model/master_volumes.go 中会转换为底层 EBSVolume 任务的加密属性。【免费下载链接】kopsKubernetes Operations (kOps) - Production Grade k8s Installation, Upgrades and Management项目地址: https://gitcode.com/gh_mirrors/kop/kops创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考