k8s存储：临时存储和持久化存储

• 临时存储

  • emptyDir：在同一个Pod内的不同容器间公享数据，与Pod生命周期相同，Pod创建时创建，Pod销毁时销毁，临时存储

  • configMap：(配置映射）存储配置文件，例如：my.cnf,redis.conf,nginx.conf

  • secret：存储敏感数据。例如：密码、私钥、证书

  • downwardAPI：存储Pod与容器元数据，例如名称、ID...

• 持久化存储：将数据存储到磁盘空间中

  • hostPath：让Pod中容器直接挂载当前Node节点的目录

  • PV：持久化存储卷，用于关联存储介质，相当于“硬盘”；每个PV都有权限、容量

  • PVC：在Pod中设置持久化存储需求，启动Pod时，根据需求自动匹配相应的PV，从而实现数据目录的映射；在容器中的目录上挂载存储介质

  • StorageClass：存储类，根据PVC的需求自动创建PV，使用时更加方便便捷

  PV和PVC概念

  为什么需要 PV/PVC？

  在 Kubernetes 中，Pod（容器组）是 “临时的、可销毁的”：当 Pod 重启、重建或迁移到其他节点时，其内部的临时存储（如容器内的文件系统）会被清空。但实际应用（如数据库、日志存储、用户文件）需要长期保存数据，这就需要 “独立于 Pod 生命周期的存储”。

  PV 是 Kubernetes集群中预先创建的、可被 Pod 长期使用的 “存储资源实例”，本质是对底层实际存储（如本地磁盘、NFS、云存储 S3/OSS、块存储 Ceph 等）的 “抽象封装”。

  可以理解为：PV 是运维人员在集群中 “提前备好的存储盘”，有固定的大小、访问模式和存储类型，等待被 Pod 使用。

  PVC 是开发人员（或应用部署者）向 Kubernetes 集群提交的 “存储资源申请单”，用于声明所需的存储资源规格（如大小、访问模式、存储类型）。

  Kubernetes 会自动匹配 “满足 PVC 规格的 PV” 并绑定：若匹配成功，PVC 就可以被 Pod 挂载使用；若没有匹配的 PV，PVC 会处于 “Pending（等待）” 状态，直到有符合条件的 PV 被创建。

• 存储方式

  • NFS

  • CEPH

  • MINIO

存算分离：

• 将存储与运算分离，集中存储，方便管理

k8s认证授权

角色

• User Account：普通用户 私钥 ->CA -> kubeconfig

• ServiceAccount：让Pod和ApiServer通信使用的用户

角色与授权

• Role：局部的角色，某个命名空间内生效

• ClusterRole：全局的角色，所有命名空间都生效

• 权限

  • 只读：查询权限

    get（查询单个资源）

    list（列出资源清单）

    watch（实时监听资源变化）

  • 只写：修改创建权限

    create（创建）

    update（更新）

    patch（部分更新）；

  • 删除权限

    delete（删除单个资源）

    deletecollection（删除资源集合，如所有Pod）

• 资源：要操作的K8s对象，比如Pod、Deployment、Service、Node（节点）、Namespace（命名空间）等；

用户与角色绑定

• RoleBinding ：局部绑定

  • 分配Role权限给命名空间内部用户

  • 让ClusterRole的权限仅在单个命名空间生效

• ClusterRoleBinding：给用户/用户组分配集群级权限（运维管理原）

# 生成私钥（dev-user.key）
openssl genrsa -out dev-user.key 2048
​
# 生成CSR（dev-user.csr），CN为用户名，O为组（可多个，用逗号分隔）
openssl req -new -key dev-user.key -out dev-user.csr -subj "/CN=dev-user/O=dev-group"
 
 
 # 1. 设置集群信息（指向API Server，信任CA）
kubectl config set-cluster kubernetes \
  --server=https://192.168.190.102:6443 \  # 替换为API Server地址
  --certificate-authority=/etc/kubernetes/pki/ca.crt \
  --embed-certs=true  # 将CA证书嵌入kubeconfig（避免依赖本地文件）
​
# 2. 设置用户信息（关联证书和私钥）
kubectl config set-credentials dev-user \
  --client-certificate=./dev-user.crt \
  --client-key=./dev-user.key \
  --embed-certs=true  # 嵌入用户证书和私钥
​
# 3. 设置上下文（绑定集群和用户）
kubectl config set-context dev-user-context \
  --cluster=kubernetes \
  --user=dev-user
​
# 4. 切换到该上下文
kubectl config use-context dev-user-context
# 5. 切换回管理员用户
kubectl config use-context kubernetes-admin@kubernetes
 
 openssl x509 -req -in dev-user.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out dev-user.crt  -days 365

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-ops-binding  # 自定义名称
  namespace: default  # 必须和Role在同一个命名空间
subjects:  # 权限接收者（主体）
- kind: User  # 主体类型：用户账户
  name: dev-user  # 服务账户名称（需提前创建：kubectl create sa my-app-sa -n default）
  namespace: default  # 服务账户所在命名空间
roleRef:  # 引用要分配的Role（固定格式，不能改）
  apiGroup: rbac.authorization.k8s.io
  kind: Role  # 引用的是Role类型
  name:  pod-role-test  # 引用的Role名称