京公网安备11010502063487号在 kind 集群里实测 StatefulSet 的三个“稳定”:Pod 按 web-0、web-1、web-2 有序创建(前一个 Ready 才创建下一个,各 7 秒)并从大序号往小序号逐个终止;重建后名字和 DNS(web-0.web.<ns>.svc)不变但 Pod IP 会变;volumeClaimTemplates 给每个 Pod 一个 PVC,Pod 重建和缩容扩容后数据仍在,persistentVolumeClaimRetentionPolicy 可让 PVC 随缩容/删除一起删除;OrderedReady 会被一个不就绪的 Pod 卡住,Parallel 不会。
在 5 节点 kind 集群里实测 StatefulSet 更新:RollingUpdate 从最大序号开始一次换一个(web-3 +6.7 秒、web-2 +11.7 秒、web-1 +16.1 秒、web-0 +21.7 秒);partition=2 只更新 web-2、web-3,currentRevision 与 updateRevision 不同,改成 0 后其余更新;OnDelete 改模板后 Pod 全不动,删一个才换一个;更新到坏模板后卡在 web-3,即使把模板改回好的,不健康的 web-3 也不会被自动替换,必须手动删除。
在 kind 集群里实测 Deployment 滚动更新:6 个副本下默认 25%/25% 峰值 8 个 Pod、最低 5 个 Ready(maxSurge 向上取整、maxUnavailable 向下取整),用时 7.9 秒;maxSurge 1 / maxUnavailable 0 与 maxSurge 0 / maxUnavailable 1 都要约 24 秒,maxSurge 100% 只要 4.0 秒但峰值 12 个;Recreate 有约 6 秒完全不可用;minReadySeconds=5 让 4 个副本的更新从 15.9 秒变成 31.9 秒。
在 kind 集群里实测 Deployment 的发布历史:每个 Pod 模板版本对应一个 ReplicaSet(revision 记在注解里,旧的缩到 0 保留);rollout undo --to-revision=2 把 revision 2 的 ReplicaSet 重新启用并改号为 5,不带参数再 undo 回到 revision 4(变成 6);revisionHistoryLimit=2 时只保留当前加最近 2 个,回滚已被删除的 revision 报 unable to find specified revision;change-cause 注解显示在 history 里;pause/resume 把多次修改合成一次发布。
在 kind 集群里实测 ReplicaSet 的收养:先有标签匹配的裸 Pod 再创建 replicas=2 的 ReplicaSet,裸 Pod 被收养(ownerReferences、uid 不变)只再新建 1 个;改标签的 Pod 脱离 ReplicaSet、ReplicaSet 补新的,标签改回后又被收养并删掉多余的;--cascade=orphan 删除后同 selector 的新 ReplicaSet 接管全部 Pod(uid 不变);两个 selector 相同的 ReplicaSet 各管各的,新来的匹配裸 Pod 被收养后立刻作为多余的删掉。
在 kind 集群里实测 Job:completions=6、parallelism=2 的 Job 最多同时 2 个 Pod、分 3 批共 18 秒完成,Indexed 模式给每个 Pod 序号;总是失败的 Job 在 backoffLimit=2 时 restartPolicy: Never 新建 3 个 Pod(创建时刻 0/10/30 秒的指数退避)、OnFailure 原地重启容器(restartCount 2),都以 BackoffLimitExceeded 失败;activeDeadlineSeconds=8 在 8.8 秒后以 DeadlineExceeded 失败并删掉 Pod;suspend 暂停时不创建 Pod,ttlSecondsAfterFinished=8 在完成后约 7.8 秒自动删除 Job 与 Pod。
在 kind 集群里让 CronJob 真实跑 5 分钟:每个 Job 睡 75 秒、每分钟一次,Allow 每个整分创建一个互相重叠的 Job,Forbid 在上一个跑完后才补建被跳过的调度(+4.0、+81.0、+160.0、+238.0 秒,越拖越晚,事件 JobAlreadyActive ×10),Replace 每个整分先删掉上一个再创建新的;suspend 150 秒后恢复只补最近那一次;startingDeadlineSeconds=10 时错过 31 秒的调度不补,等下一个整分;默认保留成功 3 个、失败 1 个历史 Job。
在 kind 集群里实测 PV 与 PVC 的配对:3Gi 的 PVC 在 2Gi/5Gi/10Gi 三个 PV 里选最小够用的 5Gi;20Gi、RWX 或存储类不同的 PVC 保持 Pending,新增匹配的 PV 后 7.4 秒自动绑定;selector 选标签、claimRef 预留给指定 PVC;Retain 的 PV 在删除 PVC 后变 Released 且不会被别人拿走,去掉 claimRef 后 4.5 秒可再次绑定;动态供给的 standard 是 WaitForFirstConsumer、reclaimPolicy Delete,PV 随 PVC 一起被删除。
在 kind 集群里实测 StorageClass 的动态供给:local-path 在 Immediate 模式下因不知道节点而 ProvisioningFailed,在 WaitForFirstConsumer 模式下等 Pod 调度后 2.2 秒 Bound 且 PV 带该节点的亲和;一次供给的事件序列 WaitForFirstConsumer → ExternalProvisioning → Provisioning → ProvisioningSucceeded(3.2 秒);不写 storageClassName 会被补成默认类,空字符串表示不动态供给,多个默认类时选最新的;存储类的 reclaimPolicy 被供给出的 PV 继承,Retain 时删 PVC 后数据仍在。
在 kind 集群里实测 PVC 扩容的规则:存储类 allowVolumeExpansion 为 false 时改 requests.storage 被 Forbidden,事后改成 true 立刻生效;受理后 spec 变大但 status.capacity、PV 和 Pod 里的文件系统都不变,PVC 上出现 ExternalExpanding 事件,在等外部控制器;缩小不能低于 status.capacity;没绑定的 PVC spec 整个不可变,绑定后只有 requests 能改。
在 kind 集群里装 metrics-server 实测 HPA 的算法:CPU 利用率 200% 对目标 50% 时副本数按 ceil(当前副本×当前值÷目标值) 从 1 一步到 4、再到 maxReplicas=6;负载消失后缩容要等稳定窗口,6→2→1 约 89 秒;利用率比目标高 4% 落在默认 ±10% 容忍区内不扩容,高 40% 则 2→3→5;没写 requests.cpu 时 HPA 报 missing request,TARGETS 显示 <unknown>。
在 kind 集群里实测 emptyDir:容器重启后文件还在、删除 Pod 后节点上的目录 2.3 秒内消失;medium: Memory 是 tmpfs,默认大小等于节点内存,写 50 MiB 在 memory.stat 里变成 shmem;tmpfs 的页算在容器内存里,limit 64Mi 写 100 MiB 会 OOMKilled 并陷入 CrashLoopBackOff;sizeLimit 对 Memory 卷是立刻 ENOSPC,对磁盘卷则是 kubelet 周期检查后的驱逐。