AWS EBS CSI快照未生成及csi-snapshotter与snapshot-controller差异问询

一、核心作用差异 #

• snapshot-controller：集群控制平面组件，负责管理Kubernetes原生快照资源（VolumeSnapshot、VolumeSnapshotClass、VolumeSnapshotContent）的全生命周期，是集群内快照请求的调度中枢，不直接与CSI驱动交互。
• csi-snapshotter：CSI驱动的辅助sidecar容器，作为集群控制平面和CSI驱动之间的桥梁，负责将集群层面的快照请求转换成CSI标准协议指令，直接调用目标CSI驱动（比如AWS EBS CSI Driver）的快照相关接口。

二、各自工作原理 #

Snapshot Controller #

1. 监听Kubernetes API服务器上快照相关资源的变更事件
2. 当用户创建VolumeSnapshot时，根据关联VolumeSnapshotClass中指定的驱动信息，生成绑定底层存储快照的VolumeSnapshotContent资源
3. 维护快照资源的状态同步：比如底层快照创建完成后，将VolumeSnapshot状态更新为Ready；若创建失败，则标记对应错误状态
4. 处理快照删除请求：先触发VolumeSnapshotContent的删除操作，进而驱动底层存储快照的清理

CSI Snapshotter #

1. 监听Kubernetes API服务器上的VolumeSnapshotContent资源，仅处理与自身驱动名称匹配的资源（通过spec.driver字段，比如ebs.csi.aws.com）
2. 发现待创建快照的VolumeSnapshotContent后，调用CSI驱动的CreateSnapshot RPC接口，将Kubernetes层面的请求转换为CSI标准请求发送给EBS CSI Driver
3. 等待EBS驱动完成AWS侧快照创建后，更新VolumeSnapshotContent的status.snapshotHandle字段为AWS快照ID，并标记状态为Ready
4. 处理快照删除请求时，调用CSI驱动的DeleteSnapshot RPC接口，通知EBS CSI Driver删除对应的AWS EBS快照

三、是否需要同时部署？ #

必须同时部署二者，它们是Kubernetes CSI快照功能的核心组成部分，缺一不可：

• 没有snapshot-controller：用户提交的VolumeSnapshot请求无法被处理，也无法生成对应的VolumeSnapshotContent，集群层面的快照资源完全无法运作
• 没有csi-snapshotter：snapshot-controller生成的VolumeSnapshotContent无法传递到CSI驱动，AWS侧根本接收不到创建快照的指令，自然不会生成实际快照

针对你的AWS快照未生成问题的排查提示 #

既然集群内资源状态正常但AWS侧无快照，可以从以下几点排查：

• 查看csi-snapshotter的日志，确认是否有调用CreateSnapshot接口的记录，是否存在未同步到Kubernetes资源状态的错误
• 检查VolumeSnapshotClass的driver字段是否准确设置为ebs.csi.aws.com，与EBS CSI Driver的名称完全匹配
• 确认EBS CSI Driver的服务账号具备足够的IAM权限：需要ec2:CreateSnapshot、ec2:DescribeSnapshots、ec2:DeleteSnapshots等权限
• 验证VolumeSnapshot关联的PVC对应的PV是由EBS CSI Driver创建的，且处于可用状态

内容的提问来源于stack exchange，提问作者user1015214