【Linux&Kubernetes】必学知识点合集四

自动创建，初始为空：Pod 被分派到某个 Node 上时，emptyDir 卷会在该节点本地自动创建，初始状态为空白目录，无需提前准备存储；
多容器共享读写：Pod 中不同容器可将 emptyDir 卷挂载到自身不同路径，所有容器均可读写卷中的相同文件，实现容器间文件交互；
生命周期与 Pod 强绑定：仅当 Pod 在节点上运行时，emptyDir 卷存在；若 Pod 因节点故障、调度驱逐、手动删除等原因被从节点移除，emptyDir 卷中的数据会永久删除；
容器崩溃不丢数据：容器崩溃仅会触发容器重启，不会导致 Pod 从节点移除，因此容器崩溃期间 emptyDir 卷中的数据完全安全。

核心 YAML 示例

yaml

apiVersion: v1
kind: Pod
metadata:
  name: emptyDir-demo
spec:
  containers:
  - name: container-1
    image: nginx
    volumeMounts:
    - name: shared-volume
      mountPath: /usr/share/nginx/html  # 容器1挂载路径
  - name: container-2
    image: busybox
    command: ["sh", "-c", "echo 'Hello emptyDir' > /data/index.html && sleep 3600"]
    volumeMounts:
    - name: shared-volume
      mountPath: /data  # 容器2挂载路径
  volumes:
  - name: shared-volume
    emptyDir: {}  # 定义emptyDir卷

3. 解释 hostPath 卷类型的特征

hostPath 卷是将Pod 所在节点的本地文件系统目录 / 文件，挂载到 Pod 内部的卷类型，实现 Pod 与节点主机的文件系统互通。

核心特征

节点本地存储：卷的实际存储位置为 Pod 调度到的节点主机本地，而非集群共享存储；
数据跨 Pod 保留：若多个 Pod 被调度到同一节点，且挂载该节点相同的 hostPath 路径，可实现跨 Pod 共享数据；
核心缺陷：强绑定节点，限制 Pod 的迁移性 —— 若 Pod 因节点故障被调度到其他节点，原 hostPath 中的数据无法被新 Pod 访问；
需注意权限问题：Pod 内容器的运行用户可能无节点主机目录的读写权限，需手动配置节点目录权限。

核心注意点

尽可能避免在生产环境使用 hostPath 卷，其会降低 Pod 的可用性和集群的扩展性，仅适用于节点本地的临时场景（如 Pod 需读取节点主机的系统配置、日志文件）。

核心 YAML 示例

yaml

apiVersion: v1
kind: Pod
metadata:
  name: hostPath-demo
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: host-log
      mountPath: /var/log/nginx  # Pod内挂载路径
  volumes:
  - name: host-log
    hostPath:
      path: /var/log/nginx-node  # 节点主机的实际路径
      type: DirectoryOrCreate    # 路径不存在则自动创建

4. 解释 PV 卷类型的特征

PV（PersistentVolume，持久卷）是集群级别的持久化存储资源，由集群管理员提前创建或通过StorageClass 动态供应，独立于 Pod 存在，为集群提供可共享的持久化存储能力。

核心特征

集群级资源：PV 与节点、Pod 同级，是集群的独立资源，可被命名空间内的任意 PVC 申领使用；
生命周期独立于 Pod：PV 的创建、删除由管理员或 StorageClass 管理，即使使用该 PV 的所有 Pod 被删除，PV 依然存在，数据长期保留；
兼容多种存储后端：基于卷插件实现，支持 NFS、Ceph、AWS EBS、GCE PD、本地存储等多种底层存储；
自带核心属性：创建 PV 时需指定存储容量、访问模式、回收策略、存储类等属性，为 PVC 提供标准化的存储资源。

核心 YAML 示例（NFS 类型 PV）

yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 1Gi  # 存储容量
  accessModes:
    - ReadWriteMany  # 访问模式
  persistentVolumeReclaimPolicy: Retain  # 回收策略
  storageClassName: nfs-storage  # 存储类
  nfs:
    path: /data/nfs  # NFS 服务端共享路径
    server: 192.168.1.100  # NFS 服务端IP

5. 什么是 PVC，如何使用它

PVC（PersistentVolumeClaim，持久卷申领）是用户对 PV 存储资源的请求，由业务开发人员创建，用于声明所需的存储容量、访问模式、存储类等属性，K8s 会自动为 PVC 匹配符合条件的 PV 并完成绑定。

PVC 核心特性

与 Pod 关联：PVC 需在 Pod 中挂载使用，一个 Pod 可使用一个或多个 PVC；
按需申领：用户无需关心底层 PV 的具体实现（如 NFS/Ceph），只需声明存储需求，实现存储与业务解耦；
命名空间隔离：PVC 是命名空间级资源，仅能申领同一集群中未被绑定的 PV，且只能被同一命名空间的 Pod 使用；
资源耗用：使用 PVC 会耗用 PV 资源，PVC 与 PV 绑定后，该 PV 无法被其他 PVC 重复使用。

PVC 核心使用步骤

步骤 1：创建 PVC，声明存储需求

yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
  namespace: default
spec:
  accessModes:
    - ReadWriteMany  # 与PV的访问模式匹配
  resources:
    requests:
      storage: 1Gi   # 申领的存储容量（≤PV容量）
  storageClassName: nfs-storage  # 与PV的存储类匹配

步骤 2：在 Pod 中挂载并使用 PVC

yaml

apiVersion: v1
kind: Pod
metadata:
  name: pvc-demo
  namespace: default
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: pvc-volume
      mountPath: /usr/share/nginx/html  # Pod内挂载路径
  volumes:
  - name: pvc-volume
    persistentVolumeClaim:
      claimName: nfs-pvc  # 关联已创建的PVC名称

步骤 3：验证绑定状态

bash

运行

# 查看PVC状态，STATUS为Bound表示绑定成功
kubectl get pvc nfs-pvc
# 查看PV状态，STATUS为Bound表示已被PVC绑定
kubectl get pv nfs-pv

6. PV 有哪几种访问模式，详细说明

PV 的访问模式（Access Modes）定义了PV 存储资源可被挂载和使用的方式，创建 PV 时需指定，PVC 申领时需声明与 PV 匹配的访问模式，否则无法完成绑定。K8s 支持 4 种核心访问模式，一个 PV 可同时支持多种访问模式，PVC 只需匹配其中一种即可。

4 种核心访问模式详解

ReadWriteOnce（RWO）
- 核心含义：卷可以被一个节点以读写方式挂载；
- 扩展说明：该模式允许运行在同一节点上的多个 Pod 同时访问该卷，是最常用的访问模式；
- 适用场景：单节点的有状态应用，如单机 MySQL、Redis 等；
- 支持存储：几乎所有存储类型（NFS、Ceph、EBS、本地存储等）。
ReadOnlyMany（ROX）
- 核心含义：卷可以被多个节点以只读方式挂载；
- 扩展说明：所有节点上的 Pod 仅能读取卷中数据，无法写入，适合共享只读数据的场景；
- 适用场景：静态资源共享，如前端静态页面、配置文件、日志只读查询等；
- 支持存储：NFS、Ceph、GlusterFS 等共享存储。
ReadWriteMany（RWX）
- 核心含义：卷可以被多个节点以读写方式挂载；
- 扩展说明：所有节点上的 Pod 均可对卷进行读写操作，是共享存储的核心模式；
- 适用场景：多节点的有状态应用，如分布式数据库、微服务配置共享、日志集中收集等；
- 支持存储：NFS、Ceph、GlusterFS 等分布式共享存储（本地存储、EBS 不支持）。
ReadWriteOncePod（RWOP）
- 核心含义：卷可以被单个 Pod以读写方式挂载；
- 扩展说明：是 K8s 1.22 版本新增的模式，严格限制整个集群中只有一个 Pod能读写该卷，比 RWO 限制更严格；
- 适用场景：对数据一致性要求极高的单 Pod 应用，如单机数据库主节点，避免多 Pod 同时读写导致数据冲突；
- 支持存储：本地存储、EBS、NFS 等（需存储后端支持）。

访问模式核心注意点

访问模式是PV 的属性，由底层存储后端决定，并非所有存储类型都支持所有访问模式；
实际使用能力以底层存储后端为准，例如 NFS 声明 RWX 模式才真正具备多节点读写能力；
PVC 申领时的访问模式只需是 PV 支持的模式之一，无需完全一致。

7. 解释 PV 的回收策略

PV 的回收策略（PersistentVolumeReclaimPolicy）定义了当 PVC 与 PV 解除绑定后，PV 及其存储的数据该如何处理，创建 PV 时可手动指定，未指定则使用集群默认策略（通常为 Delete）。K8s 支持 3 种核心回收策略，回收策略仅对已被绑定过的 PV 生效。

3 种核心回收策略详解

Retain（保留）
- 核心行为：PVC 与 PV 解除绑定后，PV 的状态会变为 Released，PV 及其存储中的数据会被完整保留，不会被自动清理或删除；
- 后续操作：需管理员手动处理—— 手动清理 PV 中的数据，然后将 PV 的状态修改为 Available，方可被其他 PVC 重新申领；
- 适用场景：对数据安全性要求极高的场景，如生产环境的数据库数据、核心业务日志，避免数据被误删；
- 支持所有存储类型。
Recycle（回收）
- 核心行为：PVC 与 PV 解除绑定后，K8s 会自动执行基础的数据清理操作（本质是执行 rm -rf /thevolume/* 命令），清理完成后 PV 状态变为 Available，可被其他 PVC 重新申领；
- 核心特点：仅清理卷内数据，不删除 PV 本身和底层存储资源；
- 适用场景：开发 / 测试环境，无需保留历史数据，追求存储资源的复用性；
- 支持有限：目前仅 NFS 和 HostPath 两种存储类型支持该策略，主流分布式存储（Ceph）、云厂商存储（EBS）均不支持。
Delete（删除）
- 核心行为：PVC 与 PV 解除绑定后，K8s 会自动删除 PV 资源，同时会删除与 PV 关联的底层存储资源（如 AWS EBS 磁盘、GCE PD 磁盘、Azure Disk 磁盘）；
- 核心特点：彻底清理，PV 和底层存储资源均被删除，数据也会被永久删除；
- 适用场景：开发 / 测试环境的临时存储，无需保留数据和存储资源，追求集群资源的自动清理；
- 支持存储：云厂商块存储（AWS EBS、GCE PD、Azure Disk）、OpenStack Cinder 等，NFS 不支持（仅能清理数据，无法删除 NFS 共享目录）。

核心注意点

PV 创建后可手动修改回收策略，命令：kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'；
生产环境推荐使用 Retain 策略，避免数据因误操作被永久删除；
动态供应的 PV（由 StorageClass 创建），其回收策略由 StorageClass 的 reclaimPolicy 字段指定。

8. 如何将特定 Pod 调度到指定的节点？

K8s 中将特定 Pod 调度到指定节点的核心方式有 2 种，均通过在 Pod 配置中添加调度规则实现，适用于不同的调度需求，操作简单、直接，是最基础的节点调度方式。

方式 1：nodeName（精准调度到指定名称的节点）

nodeName 是 Pod 最基础的调度字段，直接指定 Pod 要运行的节点名称，K8s 调度器会跳过所有调度算法，直接将 Pod 调度到该节点，精准度最高。

核心特点

强制调度：无视节点的资源状态、污点、亲和性等所有规则，直接调度；
无调度器参与：kubelet 直接在指定节点创建 Pod，无需 kube-scheduler 调度；
节点不存在则失败：若指定的节点名称不存在或节点不可用，Pod 会处于 Pending 状态。

YAML 配置示例

yaml

apiVersion: v1
kind: Pod
metadata:
  name: nodeName-demo
spec:
  nodeName: cka-worker1  # 直接指定节点名称
  containers:
  - name: nginx
    image: nginx

方式 2：nodeSelector（调度到带有指定标签的节点）

nodeSelector 是通过节点标签实现调度的方式，需先为节点添加自定义标签，再在 Pod 中声明要匹配的标签，K8s 调度器会将 Pod 调度到带有该标签且资源充足的节点上。

核心特点

标签匹配调度：仅调度到带有指定标签的节点，支持为多个节点添加同一标签，实现 Pod 调度到一组节点；
需提前配置节点标签：节点默认无自定义标签，需管理员手动添加；
强制匹配：无匹配标签的节点，不会被调度器选中。

核心使用步骤

步骤 1：为节点添加自定义标签

bash

运行

# 为节点cka-worker1添加标签：node-type=app
kubectl label nodes cka-worker1 node-type=app
# 验证节点标签
kubectl get nodes cka-worker1 --show-labels

步骤 2：在 Pod 中配置 nodeSelector，匹配节点标签

yaml

apiVersion: v1
kind: Pod
metadata:
  name: nodeSelector-demo
spec:
  nodeSelector:
    node-type: app  # 匹配节点的自定义标签
  containers:
  - name: nginx
    image: nginx

步骤 3：验证调度结果

bash

运行

# 查看Pod所在节点，确认调度到目标节点
kubectl get pod nodeSelector-demo -o wide

9. 什么是节点的亲和性？

节点亲和性（Node Affinity）是 Pod 的一种高级调度属性，用于将 Pod 吸引到一类特定的节点，本质是通过节点标签实现更灵活、更精细的节点调度，是 nodeSelector 的增强版，解决了 nodeSelector 仅能实现精确标签匹配的局限性。

节点亲和性核心特性

支持更丰富的匹配规则：不仅支持精确匹配，还支持模糊匹配（如包含、不包含、存在、不存在），满足复杂的调度需求；
支持调度优先级：分为硬亲和性和软亲和性，分别对应强制调度和优先调度，提高调度的灵活性和容错性；
与节点标签绑定：基于节点标签实现匹配，需先为节点添加自定义标签；
调度器参与：由 kube-scheduler 按照亲和性规则进行调度，需节点满足资源充足、无冲突污点等条件。

两种核心节点亲和性类型

硬亲和性（requiredDuringSchedulingIgnoredDuringExecution）
- 核心规则：强制要求节点满足所有亲和性匹配规则，若集群中无满足条件的节点，Pod 会一直处于 Pending 状态，无法被调度；
- 适用场景：Pod 必须运行在特定类型的节点上，如核心业务 Pod 需运行在高性能节点（标签 performance=high）。
软亲和性（preferredDuringSchedulingIgnoredDuringExecution）
- 核心规则：优先选择满足亲和性匹配规则的节点，若集群中无满足条件的节点，调度器会忽略该规则，将 Pod 调度到其他可用节点；
- 适用场景：非强制的调度需求，如普通业务 Pod 优先运行在华北节点（标签 region=huabei），无华北节点则调度到其他区域。

核心 YAML 配置示例（硬 + 软亲和性）

yaml

apiVersion: v1
kind: Pod
metadata:
  name: node-affinity-demo
spec:
  affinity:
    nodeAffinity:
      # 硬亲和性：必须匹配标签node-type=app
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: node-type
            operator: In
            values: ["app"]
      # 软亲和性：优先匹配标签performance=high
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100  # 权重（0-100），权重越高优先级越高
        preference:
          matchExpressions:
          - key: performance
            operator: In
            values: ["high"]
  containers:
  - name: nginx
    image: nginx

常用匹配运算符（operator）

In：节点标签值在指定的 values 列表中；
NotIn：节点标签值不在指定的 values 列表中；
Exists：节点存在该标签（无需指定值）；
DoesNotExist：节点不存在该标签；
Gt：节点标签值大于指定值（数值类型）；
Lt：节点标签值小于指定值（数值类型）。

10. 什么是污点，它的主要用途是什么？

污点（Taint）

污点是节点的一种属性，由管理员为节点添加，用于使节点排斥一类特定的 Pod，即带有污点的节点，会拒绝所有未配置对应容忍度的 Pod 调度到自身，实现节点的访问控制。

污点的格式为：key=value:effect，包含三个核心部分：

key：污点的键（自定义字符串）；
value：污点的值（自定义字符串，可选）；
effect：污点的作用效果，决定节点如何排斥 Pod，支持 3 种效果：
1. NoSchedule：拒绝新的未容忍 Pod 调度，已运行在节点上的未容忍 Pod 不会被驱逐；
2. PreferNoSchedule：优先拒绝未容忍 Pod 调度，若集群中无其他可用节点，可调度；
3. NoExecute：拒绝新的未容忍 Pod 调度，并立即驱逐已运行在节点上的未容忍 Pod。

容忍度（Toleration）

容忍度是Pod 的一种属性，与污点配合使用，用于允许 Pod 调度到带有对应污点的节点上。Pod 配置了容忍度后，可忽略节点的对应污点，被调度到该节点。

污点的主要用途

污点是 K8s 中节点调度管控的核心手段，主要用于以下场景，实现集群节点的精细化管理：

隔离专用节点：为核心业务的专用节点添加污点，仅让配置了对应容忍度的核心业务 Pod 调度到该节点，避免普通业务 Pod 占用专用节点资源；
隔离故障节点：当节点出现故障（如磁盘满、网络异常）时，为节点添加 NoExecute 污点，立即驱逐节点上的所有 Pod，避免故障节点影响业务运行；
节点维护：节点需要停机维护（如重启、升级）时，为节点添加 NoExecute 污点，优雅驱逐所有 Pod，再进行维护操作；
资源分级：为不同性能的节点添加不同污点（如 performance=high:NoSchedule），仅让高优先级业务 Pod 配置对应容忍度，调度到高性能节点；
避免单节点负载过高：为负载过高的节点添加 NoSchedule 污点，拒绝新的 Pod 调度，实现负载均衡。

核心实操示例

步骤 1：为节点添加污点

bash

运行

# 为节点cka-worker1添加污点：key=node-type, value=dev, effect=NoSchedule
kubectl taint nodes cka-worker1 node-type=dev:NoSchedule
# 验证节点污点
kubectl describe node cka-worker1 | grep Taints

步骤 2：为 Pod 配置容忍度，允许调度到带污点的节点

yaml

apiVersion: v1
kind: Pod
metadata:
  name: toleration-demo
spec:
  tolerations:
  - key: "node-type"    # 匹配污点的key
    operator: "Equal"   # 匹配方式
    value: "dev"        # 匹配污点的value
    effect: "NoSchedule"# 匹配污点的effect
  containers:
  - name: nginx
    image: nginx

步骤 3：移除节点污点

bash

运行

# 移除节点的指定污点
kubectl taint nodes cka-worker1 node-type=dev:NoSchedule-

核心注意点

容忍度仅允许Pod 调度到带污点的节点，不保证一定能调度：调度器还会评估节点的资源状态、亲和性等其他规则；
一个节点可添加多个污点，一个 Pod 可配置多个容忍度，只需匹配其中一个污点即可；
污点是节点级属性，无命名空间限制；容忍度是 Pod 级属性，需与 Pod 一起创建。

https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

一个 API 入口调用多个大模型：AiiOnly客户端 + CC Switch 打通 Codex AI编程流程

AI编程社区

VSCode Claude Code + MiMo 中转免登录完整配置教程（解决原生登录弹窗 + 模型报错）

AI编程社区

从零开始做一个属于自己的 Skill（保姆级教程）

AI编程社区

所有评论(0)

查看更多评论

qq_43064223

@qq_43064223

已为社区贡献11条内容

【Linux&Kubernetes】 必学知识点合集四

qq_43064223

1. 解释什么是 Kubernetes 的 Volume

Volume 核心特性

2. 解释 emptyDir 卷类型的特征

核心特征

核心 YAML 示例

3. 解释 hostPath 卷类型的特征

核心特征

核心注意点

核心 YAML 示例

4. 解释 PV 卷类型的特征

核心特征

核心 YAML 示例（NFS 类型 PV）

5. 什么是 PVC，如何使用它

PVC 核心特性

PVC 核心使用步骤

步骤 1：创建 PVC，声明存储需求

步骤 2：在 Pod 中挂载并使用 PVC

步骤 3：验证绑定状态

6. PV 有哪几种访问模式，详细说明

4 种核心访问模式详解

访问模式核心注意点

7. 解释 PV 的回收策略

3 种核心回收策略详解

核心注意点

8. 如何将特定 Pod 调度到指定的节点？

方式 1：nodeName（精准调度到指定名称的节点）

核心特点

YAML 配置示例

方式 2：nodeSelector（调度到带有指定标签的节点）

核心特点

核心使用步骤

步骤 1：为节点添加自定义标签

步骤 2：在 Pod 中配置 nodeSelector，匹配节点标签

步骤 3：验证调度结果

9. 什么是节点的亲和性？

节点亲和性核心特性

两种核心节点亲和性类型

核心 YAML 配置示例（硬 + 软亲和性）

常用匹配运算符（operator）

10. 什么是污点，它的主要用途是什么？

污点（Taint）

容忍度（Toleration）

污点的主要用途

核心实操示例

步骤 1：为节点添加污点

步骤 2：为 Pod 配置容忍度，允许调度到带污点的节点

步骤 3：移除节点污点

核心注意点

所有评论(0)

温馨提示：您尚未绑定手机号

qq_43064223

【Linux&Kubernetes】必学知识点合集四