Kubernetes RBAC中UPDATE权限作用及详细RBAC动词列表咨询
我完全懂你的困扰——找一份清晰的Kubernetes RBAC动词作用对照表确实难，很多资料都语焉不详，只能靠自己踩坑试出来。你遇到的UPDATE权限不符合预期的问题，核心是没搞清楚Kubernetes里UPDATE和PATCH的本质区别，以及RBAC动词对应API操作的映射关系。
一、为什么你的操作提示需要PATCH权限？
先明确一个关键：Kubernetes的RBAC动词和HTTP请求方法是严格对应的。UPDATE对应的是HTTP的PUT请求（全量替换资源），而你用的kubectl set image、kubectl edit、kubectl apply这些操作，实际上发送的是HTTP PATCH请求（增量更新资源）——这就是为什么你明明有UPDATE权限，却还是提示需要PATCH权限的原因。
举几个具体例子：
kubectl edit：你修改资源的部分字段后，K8s会用strategic merge patch的方式发送PATCH请求，只更新你改动的部分kubectl set image：本质是修改Deployment的spec.template.spec.containers[*].image字段，属于增量更新，触发PATCHkubectl apply：对比本地配置和集群现有资源的差异，只更新变化的部分，同样是PATCH操作（除非是创建全新资源）
至于kubectl rollout undo失败，是因为这个操作不仅要操作Deployment，还要关联修改对应的ReplicaSet资源，所以你还需要ReplicaSet的相关权限（比如GET、PATCH/UPDATE等）。
二、UPDATE权限到底能做什么？
UPDATE对应的是全量替换资源的操作：你必须提交整个资源的完整YAML/JSON配置，用PUT请求覆盖集群中已有的资源。在kubectl里，只有少数操作会触发UPDATE：
- 使用
kubectl replace命令：比如kubectl replace -f updated-deployment.yaml，这个命令会把你本地的完整Deployment配置发送到API服务器，执行PUT操作，这时候就需要UPDATE权限 - 直接通过API发送
PUT请求：比如用curl调用/apis/apps/v1/namespaces/default/deployments/hello-node接口，提交完整的Deployment JSON数据
简单说：UPDATE权限允许你全量替换一个已存在的资源，而不是修改它的部分字段。这也是它和PATCH权限最核心的区别。
三、详细的RBAC动词与API操作对照表
我整理了日常最常用的RBAC动词，对应它们的HTTP方法和典型kubectl操作场景：
| RBAC动词 | 对应的HTTP方法 | 典型kubectl操作场景 |
|---|---|---|
get | GET | kubectl get、kubectl describe、查看单个资源的详情信息 |
list | GET（集合路径） | kubectl get deployments、kubectl get pods（列出命名空间下所有同类型资源） |
watch | GET（带watch参数） | kubectl get -w deployment hello-node（实时监控资源的状态变化） |
create | POST | kubectl create、kubectl apply（创建全新的资源） |
update | PUT | kubectl replace -f <file>（全量替换已存在的资源） |
patch | PATCH | kubectl edit、kubectl set、kubectl apply（更新现有资源的部分字段）、kubectl annotate、kubectl label |
delete | DELETE | kubectl delete deployment hello-node（删除单个资源） |
deletecollection | DELETE（集合路径） | kubectl delete deployments --all（删除命名空间下所有同类型资源） |
impersonate | 特殊请求头 | kubectl --as=user1 get pods（模拟其他用户/服务账号执行操作） |
另外还有一些特殊场景的动词，比如use（针对RoleBinding/ClusterRoleBinding的权限）、escalate（允许提升自身权限），但日常开发运维中用得最多的还是上面这些。
四、快速验证UPDATE权限的小实验
如果你想亲手验证UPDATE权限的作用，可以做这个简单实验：
- 确保你的用户/ServiceAccount已经拥有
default命名空间下deployments的get和update权限 - 导出当前Deployment的完整配置：
kubectl get deployment hello-node -o yaml > original.yaml - 修改
original.yaml里的某个字段，比如把spec.replicas从1改成2 - 执行全量替换：
kubectl replace -f original.yaml——这时候应该能成功，因为触发的是UPDATE（PUT）操作 - 再尝试
kubectl edit deployment hello-node——依然会提示权限不足，因为这是PATCH操作，需要patch权限
总结
- UPDATE权限对应全量替换资源的
PUT操作，和日常常用的增量更新（PATCH）是完全独立的权限 - 大多数kubectl修改资源的操作都是增量更新，需要授予
patch权限（而不是只给update） - 如果要让用户能完整管理Deployment，通常需要授予
get、list、watch、create、update、patch、delete这些权限
内容的提问来源于stack exchange，提问作者Hebe Hilhorst
