创建#

• 用文件创建configmap对象

kubectl create configmap game-config —from-file=hongfu.file

• 直接用key value创建configmap对象, 适合值比较少的创建

kubectl create configmap literal-config —from-literal=name=dave —from-literal==password=pass

热更新#

ConfigMap 热更新，指的是在不重启、不重建 Pod 的前提下，让容器内的应用程序自动感知并加载 ConfigMap 的配置变更，实现配置的「无停机生效」，是生产环境中非常核心的运维能力。有文件链接

• 以 Volume 卷挂载方式注入 → 支持热更新（集群侧自动同步）

• 以环境变量方式注入 → 完全不支持热更新

1.PV（PersistentVolume，持久卷）#

PV 是集群级别的存储资源，由集群管理员预先配置、管理，代表了集群中的一块实际存储（如云盘、NAS、本地磁盘、分布式存储等）。

• 生命周期：独立于 Pod，是集群的底层存储资源，不会随 Pod 或 PVC 的删除而自动销毁（取决于回收策略）
• 作用：对底层存储进行抽象，向上提供统一的存储接口，屏蔽不同存储厂商的底层实现差异
• 归属：集群级别资源，不属于任何 Namespace

2. PVC（PersistentVolumeClaim，持久卷声明）#

PVC 是用户 / 租户级别的存储申请，由应用开发者创建，代表 Pod 对存储资源的需求（比如需要多大空间、什么访问模式）。

• 生命周期：与 Pod 绑定，属于 Namespace 级别的资源
• 作用：作为用户对存储的「申请单」，向集群申请符合要求的 PV 资源
• 归属：Namespace 级别资源，必须和 Pod 在同一个 Namespace

3.PV/PVC - 关联条件#

◆ 容量: PV 的值不小于 PVC 要求，可以大于最好一致

◆ 读写策略：完全匹配

□ 单节点读写 - ReadWriteOnce - RWO

□ 多节点只读 - ReadOnlyMany - ROX

□ 多节点读写 - ReadWriteMany - RWX

◆ 存储类: PV 的类与 PVC 的类必须一致，不存在包容降级关系

PV/PVC - 回收策略#

➢ Retain（保留）：手动回收

➢ Recycle（回收）：基本擦除（rm -rf /thevolume/*）

➢ Delete（删除）：关联的存储资产（例如 AWS EBS、GCE PD、Azure Disk 和 OpenStack Cinder 卷）将被删除

当前，只有 NFS 和 HostPath 支持回收策略。AWS EBS、GCE PD、Azure Disk 和 Cinder 卷支持删除策略

专业补充说明

1. Retain（保留）

   这是默认策略，PVC 删除后 PV 会被保留，数据不会被自动清除，需要管理员手动清理 PV 与底层存储数据，适用于数据敏感、需长期留存的场景。

2. Recycle（回收）

   会自动清空卷内的所有数据，清空后 PV 重新变为可用状态，可被新的 PVC 绑定，Kubernetes 1.25 版本后已被废弃，推荐改用动态供给实现。

3. Delete（删除）

   PVC 删除后，PV 与对应的底层存储资产会被同步自动删除，适合云厂商块存储等支持自动销毁的存储类型，需注意数据会被永久删除，不可恢复。

节点亲和性#

1. preferredDuringSchedulingIgnoredDuringExecution：软性亲和策略

• 核心逻辑：优先调度到满足规则的节点，若没有符合条件的节点，Pod 也可以调度到其他节点，不会出现 Pending 无法启动的情况。
• 适用场景：非强制的资源偏好、业务就近调度、性能优先级匹配等场景，不影响集群整体调度可用性。
• 权重机制：可通过 weight 字段给不同规则设置优先级，权重越高的规则，调度时优先级越高。

2. requiredDuringSchedulingIgnoredDuringExecution：硬性亲和策略

• 核心逻辑：强制要求 Pod 必须调度到完全满足规则的节点上，若集群中没有符合条件的节点，Pod 会一直处于 Pending 状态，无法启动。
• 适用场景：强业务隔离、专属资源绑定、合规要求、硬件专属匹配（如 GPU 节点）等强约束场景。

pod亲和性#

podAffinity（Pod 亲和性）让 Pod和指定的 Pod 部署在同一拓扑域（同一节点 / 同一机房 / 同一可用区）业务强依赖 Pod 就近部署、降低跨节点网络延迟、同业务 Pod 聚合管理

podAntiAffinity（Pod 反亲和性）让 Pod和指定的 Pod 部署在不同拓扑域（不同节点 / 不同机房 / 不同可用区）高可用部署（多副本 Pod 分散到不同节点，避免单节点故障导致服务全挂）、业务实例隔离、避免资源争抢

然后也分软硬

1. preferredDuringSchedulingIgnoredDuringExecution：软性策略

• 核心逻辑：优先让 Pod 满足规则，若集群中没有符合条件的节点，Pod 依然可以正常调度，不会出现 Pending。
• 适用场景：非强制的业务就近部署、高可用的弱约束场景，不影响集群整体调度可用性。
• 支持通过weight字段给规则设置权重，权重越高的规则，调度优先级越高。

2. requiredDuringSchedulingIgnoredDuringExecution：硬性策略

• 核心逻辑：强制要求Pod 必须满足规则，若集群中没有符合条件的节点，Pod 会一直处于 Pending 状态，无法启动。
• 适用场景：强高可用约束、合规要求、业务强隔离等必须严格遵守的调度规则。