容器化部署

K8s 存储体系：三层抽象 Kubernetes 存储体系通过三层抽象解耦了存储使用方与提供方，这是理解容器持久化存储的核心。根据 K8s 存储文档，三层结构如下： ┌──────────────────────────────────────────────────────┐ │ Pod (使用方) │ │ volumeMounts → volumes │ ├──────────────────────────────────────────────────────┤ │ PVC (声明) — 用户申请存储 │ │ "我需要 10Gi RWO 的存储" │ ├──────────────────────────────────────────────────────┤ │ StorageClass (动态供给) — 存储模板 │ │ "使用 ceph-rbd 驱动，reclaim: Retain" │ ├──────────────────────────────────────────────────────┤ │ PV (物理资源) — 实际存储 │ │ "10.0.0.5:/data/pvc-xxx (NFS)" │ └──────────────────────────────────────────────────────┘ PV（PersistentVolume） PV 是集群级资源，代表物理存储的抽象。PV 可以由管理员手动创建，也可通过 StorageClass 自动供给： apiVersion: v1 kind: PersistentVolume metadata: name: pv-nfs-data spec: capacity: storage: 50Gi accessModes: - ReadWriteMany # 多节点读写 persistentVolumeReclaimPolicy: Retain nfs: server: 10....

Requests 与 Limits 的语义 Kubernetes 中每个容器可以配置 CPU 和 Memory 的 requests 与 limits。很多开发者分不清二者的区别，导致 Pod 频繁被驱逐或 OOMKilled。 apiVersion: v1 kind: Pod metadata: name: api-server spec: containers: - name: app image: myapp:latest resources: requests: cpu: "250m" # 0.25 核 memory: "256Mi" limits: cpu: "500m" # 0.5 核 memory: "512Mi" 核心区别 维度 Requests Limits 作用阶段 调度时 运行时 含义 Pod 需要的最小资源保证 Pod 能使用的最大资源上限 调度器行为 调度器根据 requests 判断节点是否有足够资源 调度器不关心 limits 运行时行为 cgroups 中的保障份额 CPU 被节流（throttle），Memory 触发 OOMKilled 是否可超卖 可以（节点上所有 Pod 的 limits 之和可超过节点容量） 不建议超卖 Memory 简单理解：...