K8s RBAC 和持久化存储

一、访问 Kubernetes 要过三关：认证、授权、准入

你可以把 k8s 的 API Server 当成一个小区大门，想进去得三步：

认证：你是谁？拿出身份证（用户名/密码、token、证书）。
授权：你有权限干什么？比如能不能进某个楼、能不能坐电梯。
准入：进去之前保安再检查一下，甚至帮你改改"进门单"（比如自动加上默认配置）。

这三步走完，你的请求才能真正被执行。

二、两种"用户"要分清

普通用户（User Account）：真实的人，比如管理员、开发人员。用证书或 token 登录。
服务账号（ServiceAccount） ：给 Pod 里的程序用的。每个命名空间默认都有一个叫 default 的服务账号，Pod 用它来跟 API Server 说话。

简单记：人用 User，Pod 用 ServiceAccount。

三、RBAC 是什么？------"角色控制权限"

RBAC 就是"你是什么角色，就给你对应的权限"。

Role（角色）：规定能对某个命名空间里的哪些资源（比如 Pod）做哪些操作（增删改查）。
ClusterRole（集群角色）：跟 Role 差不多，但是管整个集群的，比如操作 Node、或者所有命名空间的资源。

然后通过 RoleBinding（角色绑定） 把某个用户/服务账号绑到一个 Role 上，他就有了那个命名空间里的权限。

如果是 ClusterRoleBinding，就把权限给到整个集群。

举例：

你想让用户"张三"能在 dev 命名空间里看 Pod，就创建一个 Role（允许 get,list Pod），再用 RoleBinding 把张三绑上去。

四、为什么要用 ClusterRole + RoleBinding

一个 ClusterRole 可以定义"管理员全部权限"，然后你在每个命名空间里用 RoleBinding 把它绑给不同用户，这样每个用户在自己的命名空间里就是管理员，但跨了命名空间就不行------非常灵活，不用重复写 Role。

五、实际操作：创建一个用户并给权限（重点）

文档里的 "九、限制不同的用户操作k8s集群" 讲得很细，我简化一下：

生成证书 ：用 openssl 给新用户（比如叫 lucky）生成私钥和证书，证书里写上 /CN=lucky。
把 lucky 加入 kubeconfig：告诉 kubectl 这个用户的存在。
切换上下文 ：用 kubectl config use-context lucky@kubernetes 切换到 lucky 用户，此时他没有任何权限，一查 Pod 就报错。
给 lucky 授权 ：创建一个命名空间 lucky，然后做一个 RoleBinding，把 cluster-admin（集群管理员角色）绑给 lucky，但限定在 lucky 命名空间里。
现在 lucky 只能操作 lucky 命名空间 ：切回用户 lucky，kubectl get pods -n lucky 可以，看别的命名空间就不行。

这样你就实现了一个普通用户只能管理自己的命名空间。

六、ServiceAccount 怎么授权？

Pod 里默认的 ServiceAccount 没权限。如果你想让它能看 Pod，就创建一个 RoleBinding，把 ServiceAccount 绑上去，例如：

bash

复制代码

kubectl create rolebinding my-sa-view --clusterrole=view --serviceaccount=my-namespace:my-sa --namespace=my-namespace

意思：在 my-namespace 里，把名为 my-sa 的 ServiceAccount 绑上 view 角色，让它能看资源。

七、常见权限 verbs（动词）

文档最后给了个表，我挑几个常用的解释：

get：看某个具体资源（比如 kubectl get pod nginx）
list：列出所有同类资源（比如 kubectl get pods）
watch：实时监控（比如 kubectl get pods -w）
create / update / patch / delete：增、改、局部改、删
exec：进容器执行命令

八、总结一句话

K8s 的权限控制就是：先证明你是谁，再看你的角色允许你干啥，最后过一遍"安检"才能动手。 角色可以按命名空间分（Role），也可以整个集群通用（ClusterRole），然后把人或 Pod 绑上去就行。

如果你想创建一个"只能管理自己项目的普通用户"，就按第五步那样生成证书、建命名空间、做 RoleBinding。

一、为什么要做持久化存储？

Pod 是有"生命周期"的，可能随时被删除或重启。如果 Pod 里的应用（比如 MySQL、Redis）把数据存在 Pod 内部，那 Pod 一死，数据就没了。
持久化存储就是给 Pod 配一个"外部硬盘"，Pod 没了，数据还在。

二、几种常见的存储方式（由简单到复杂）

1. emptyDir --- 临时"小纸条"

特点：Pod 运行时会自动在宿主机上创建一个空目录，Pod 里的容器可以读写它。
生命周期：跟 Pod 走，Pod 删除，目录和数据一起消失。
用途：临时缓存、共享数据（比如两个容器共用一份临时文件）。
大白话：相当于你做事时随手拿的一张草稿纸，事情做完，纸就扔了。

2. hostPath --- 宿主机上的"固定抽屉"

特点：Pod 挂载宿主机上的一个目录（比如 /data）。
生命周期：Pod 删了，目录和数据还在宿主机上，但前提是 Pod 下次还要被调度到同一台宿主机，否则就找不到数据了。
用途：需要访问宿主机文件（比如监控日志），或者对调度节点没要求的测试环境。
大白话：你固定在某个工位（宿主机）的私人抽屉，换了工位就找不到抽屉了。

3. NFS --- 网络上的"公共文件柜"

特点：一台 NFS 服务器共享一个目录，多个 Pod 可以跨节点挂载同一个目录。
生命周期：Pod 随便删、随便换节点，数据都在 NFS 服务器上，只要 NFS 不坏。
用途：多 Pod 共享数据、需要持久化且节点不固定的场景。
大白话：公司里放在公共区域的文件柜，谁去都能用，文件一直保存在柜子里。

三、PVC / PV --- "申请-分配"机制

概念

PV：管理员提前准备好的"存储资源"（比如 NFS 里划出 10 个目录，每个目录就是一个 PV）。
PVC：用户提交的"存储申请单"，写明需要多大空间、怎么访问（只读/读写等）。
绑定：PVC 会根据你的要求，自动匹配一个符合条件、还没被占用的 PV 绑定在一起。

生命周期

管理员创建一批 PV（静态供应）。
用户创建 PVC（申请）。
Kubernetes 把 PVC 和一个 PV 绑定。
Pod 使用这个 PVC 作为存储卷。

大白话

你（用户）写一张"申请单（PVC）"：我要 2GB 空间，能多台机器一起读写。管理员（K8s）看了你申请单，从仓库里找一块符合要求的"硬盘（PV）"给你用。你往 Pod 里插上这块硬盘，数据就存住了。Pod 删了，硬盘还留着，你下次还可以继续用。

四、StorageClass --- "自动造硬盘的机器"

问题

如果用户很多，管理员要提前准备一堆 PV，很麻烦。

解决办法

StorageClass + Provisioner（自动制备器）：

你只需要创建一个 PVC，并指明用哪个 StorageClass。
StorageClass 会自动调用 Provisioner（比如 NFS 制备器）去 动态创建 一个 PV，然后绑定给你的 PVC。
整个过程不需要管理员手动创建 PV。

例子（文档里 NFS 方式）

先部署一个 nfs-provisioner（专门在 NFS 上自动创建目录的"小机器人"）。
创建 StorageClass，指明用这个 storage-nfs 制备器。
用户创建 PVC 时，指定 storageClassName: nfs-storage。
系统自动在 NFS 共享目录下新建一个子目录作为 PV，并绑定 PVC。

回收策略

Delete：删除 PVC 时，自动删除对应的 PV 和数据（可设置归档保留）。
Retain：删除 PVC 后，PV 变成"已释放"状态，数据还在，但需要手动处理才能再用。

大白话

StorageClass 就像一台"自动售货机"。你投一个"申请单（PVC）"，机器（Provisioner）就立刻给你造一块符合要求的硬盘（PV），不用管理员事先堆一堆硬盘在仓库里。用完之后，如果选了"Delete"模式，硬盘也会被自动回收清理。