/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}
K8s 生产实录周总结：滚动发布、优雅停机与 GPU 调度最佳实践
在过去一周的“K8s 生产实录”专栏中，我们从应用开发与运维实践者的视角出发，深入拆解了 Kubernetes 在大规模生产落地过程中最容易踩坑的四个核心领域：
- 滚动发布的步进容量计算（maxSurge 与 maxUnavailable）；
- 容器生命周期与网络规则下发的异步竞态（preStop 与优雅停机）；
- 滚动更新卡死的快速排障 SOP（describe pod 与探针避坑）；
- 异构 GPU 节点的专用隔离调度（Taints、Tolerations 与 NodeAffinity）。
在第一周结束之际，我们把这一整套 Kubernetes 生产治理经验整理成一张“高可用交付避坑矩阵与标准模板”。
K8s 生产核心参数调校避坑矩阵
| 滚动策略 Strategy | maxSurge: 25%, maxUnavailable: 0 | 保证发布期间系统服务总容量永不缩容，先起新 Pod 再销旧 Pod | 误设 maxUnavailable: 50% 导致发布时吞吐减半、瞬间被打崩 |
| 优雅停机 preStop | lifecycle.preStop.exec: ["sleep", "10"] | 错开容器进程退出与 Ingress / Kube-proxy 路由摘除的时间差 | 漏配 preStop 导致正在传输的长连接直接被 RST，引发 502 |
| 停机宽限期 GracePeriod | terminationGracePeriodSeconds: 60 | 给进程充足的时间处理完存量请求并释放 DB 连接池 | 设置过短（默认 30s 在慢业务下）导致容器被 SIGKILL 强杀 |
| 超时保护 Deadline | progressDeadlineSeconds: 300 | 滚动发布卡死 5 分钟后自动标记为 Failed 并通知告警 | 未配此项导致 CI/CD 流水线永久挂起卡死 |
| 节点污点隔离 Taint | dedicated=gpu:NoSchedule | 锁死高价值硬件，严禁普通 CPU 微服务抢占 GPU 物理资源 | 误打 NoExecute 污点导致节点上正在运行的 Pod 全部被秒杀驱逐 |
经过生产压测检验的通用 Deployment YAML 黄金模版
apiVersion: apps/v1
kind: Deployment
metadata:
name: production-core-service
namespace: production
labels:
app.kubernetes.io/name: core-service
spec:
replicas: 4
progressDeadlineSeconds: 300
minReadySeconds: 10
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 0
template:
metadata:
labels:
app.kubernetes.io/name: core-service
spec:
terminationGracePeriodSeconds: 60
# 节点调度与污点容忍
tolerations:
– key: "node-role.kubernetes.io/app"
operator: "Exists"
effect: "NoSchedule"
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
– weight: 100
podAffinityTerm:
labelSelector:
matchLabels:
app.kubernetes.io/name: core-service
topologyKey: "kubernetes.io/hostname"
containers:
– name: app
image: registry.internal.net/prod/core-service:v3.1.0
imagePullPolicy: IfNotPresent
lifecycle:
preStop:
exec:
command: ["/bin/sh", "-c", "sleep 10"]
ports:
– containerPort: 8080
resources:
requests:
cpu: "1000m"
memory: "2Gi"
limits:
cpu: "2000m"
memory: "4Gi"
readinessProbe:
httpGet:
path: /health/ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 2
failureThreshold: 3
livenessProbe:
httpGet:
path: /health/live
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 3
failureThreshold: 3
实践心得：把云原生当成精密的物理钟表
Kubernetes 的强大之处在于其纯粹的声明式 API 与最终一致性控制循环。但想要在生产环境中实现“零抖动、零宕机”，开发者就必须深刻理解每一个 Controller 背后的异步时序。
配置好探针、留足缓冲、明确资源边界，K8s 就会成为支撑业务高歌猛进的最坚实后盾。
下周，我们将开启第二周的进阶探索——“HPA 弹性伸缩基于自定义 Prometheus 指标与扩缩容冷却调优”，带大家玩转云原生的智能弹性！
