这一章节主要涉及如何持久化应用数据、管理配置、保护敏感信息以及定义安全和访问控制策略。以下是干货总结：

一、存储（Storage）

1.1、Volume

• Pod 内部的临时存储，生命周期与 Pod 绑定。

• 为集群中的 Pods 提供长期和临时存储的方法。

Container（容器）中的磁盘文件是短暂的，当容器崩溃时，kubelet会重新启动容器，但最初的文件将丢失，Container会以最干净的状态启动。另外，当一个Pod运行多个Container时，各个容器可能需要共享一些文件。Kubernetes Volume可以解决这两个问题。
一些需要持久化数据的程序才会用到Volumes，或者一些需要共享数据的容器需要volumes。

• 常见类型：emptyDir、hostPath、configMap、secret、persistentVolumeClaim。

1.2、PersistentVolume (PV)

由集群管理员提供的持久化存储资源（如 NFS、Ceph、云盘）。

1.3、PersistentVolumeClaim (PVC)

用户申请存储的请求（声明自己需要多大的存储）。

Pod 通过 PVC 来挂载 PV，实现数据持久化。

1.4、StorageClass

定义存储类型（SSD、HDD、云存储等），支持动态创建 PV。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:name: low-latencyannotations:storageclass.kubernetes.io/is-default-class: "false"
provisioner: csi-driver.example-vendor.example
reclaimPolicy: Retain # 默认值是 Delete
allowVolumeExpansion: true
mountOptions:- discard # 这可能会在块存储层启用 UNMAP/TRIM
volumeBindingMode: WaitForFirstConsumer
parameters:guaranteedReadWriteLatency: "true" # 这是服务提供商特定的

1.5、PVC 和 PV 的绑定过程？

用户创建 PVC → 调度器寻找匹配的 PV → 绑定成功 → Pod 使用 PVC 挂载。

二、配置管理（Configuration）

2.1、ConfigMap

存放非敏感配置信息（环境变量、配置文件）；可以挂载为文件或注入环境变量。

一般用ConfigMap去管理一些配置文件、或者一些大量的环境变量信息。

ConfigMap将配置和Pod分开，有一个nginx，nginx.conf -> configmap,nginx
更易于配置文件的更改和管理。

这是一个 ConfigMap 的示例，它的一些键只有一个值，其他键的值看起来像是 配置的片段格式。

apiVersion: v1
kind: ConfigMap
metadata:name: game-demo
data:# 类属性键；每一个键都映射到一个简单的值player_initial_lives: "3"ui_properties_file_name: "user-interface.properties"# 类文件键game.properties: |enemy.types=aliens,monstersplayer.maximum-lives=5    user-interface.properties: |color.good=purplecolor.bad=yellowallow.textmode=true    

2.2、Secret

存放敏感信息（密码、证书、密钥）。

Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。 这样的信息可能会被放在 Pod 规约中或者镜像中。 使用 Secret 意味着你不需要在应用程序代码中包含机密数据。

由于创建 Secret 可以独立于使用它们的 Pod， 因此在创建、查看和编辑 Pod 的工作流程中暴露 Secret（及其数据）的风险较小。 Kubernetes 和在集群中运行的应用程序也可以对 Secret 采取额外的预防措施， 例如避免将敏感数据写入非易失性存储。

Secret 类似于 ConfigMap 但专门用于保存机密数据。

Base64 编码存储，建议结合 KMS 或外部密钥管理服务。Secret更倾向于存储和共享敏感、加密的配置信息。

使用方式

• 挂载到 Pod 中（文件/环境变量）。

• 动态更新：Pod 内应用可监听挂载的配置变化。

2.3、存活、就绪和启动探针

Kubernetes 提供了多种探针：

• 存活探针
• 就绪探针
• 启动探针

1. 存活探针

存活探针决定何时重启容器。 例如，当应用在运行但无法取得进展时，存活探针可以捕获这类死锁。

如果一个容器的存活探针失败多次，kubelet 将重启该容器。

存活探针不会等待就绪探针成功。 如果你想在执行存活探针前等待，你可以定义 initialDelaySeconds，或者使用启动探针。

2. 就绪探针
   就绪探针决定容器何时准备好接受流量。 这种探针在等待应用执行耗时的初始任务时非常有用； 例如：建立网络连接、加载文件和预热缓存。在容器的生命周期后期， 就绪探针也很有用，例如，从临时故障或过载中恢复时。

如果就绪探针返回的状态为失败，Kubernetes 会将该 Pod 从所有对应服务的端点中移除。

就绪探针在容器的整个生命期内持续运行。

3. 启动探针
   启动探针检查容器内的应用是否已启动。 启动探针可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被 kubelet 杀掉。

如果配置了这类探针，它会禁用存活检测和就绪检测，直到启动探针成功为止。

这类探针仅在启动时执行，不像存活探针和就绪探针那样周期性地运行。

三、安全（Security）

1. ServiceAccount

   • Pod 与 API Server 交互的身份。

   • 每个 Pod 默认分配一个 ServiceAccount。

2. RBAC (Role-Based Access Control)

   • Role：命名空间级别的权限。

   • ClusterRole：跨命名空间的全局权限。

   • RoleBinding/ClusterRoleBinding：将用户/组绑定到角色。

3. Pod Security Context

   • 定义运行时安全策略（UID/GID、只读文件系统、是否允许特权模式）。

4. NetworkPolicy

   • 控制 Pod 之间、Pod 与外部的网络访问。

   • 类似“防火墙规则”。

四、策略与最佳实践

1. 资源限制（ResourceQuota & LimitRange）

   • 为 Pod/命名空间设置 CPU、内存上限。

   • 避免“资源被少数应用吃光”。

2. PodDisruptionBudget (PDB)

   • 控制在节点维护或升级时，至少有多少 Pod 副本存活。

3. 安全加固

   • 使用 Pod Security Admission（PSA） 替代 PodSecurityPolicy。

   • 常见模式：privileged、baseline、restricted。

五、总结

• 存储：PV 提供，PVC 申请，SC 动态化。

• 配置：ConfigMap 普通配置，Secret 存密码。

• 安全：ServiceAccount 身份，RBAC 控权限，NetworkPolicy 限流量。

• 策略：资源配额防滥用，PDB 保障高可用。

---

“人的一生会经历很多痛苦，但回头想想，都是传奇”。

---