把 k8s经典蘑菇理解为一套面向 Kubernetes 集群的部署范式：将容器镜像、工作负载、服务入口、伸缩策略和运行观测组织成可重复执行的路径。下面以一个无状态库存查询 API 为例，说明开发人员如何准备模板、平台运维人员如何发布，以及值班人员怎样检查故障。先让 API 稳定接流量，再逐步加入弹性伸缩、持久化和服务网格能力。示例使用 kubectl 创建和调整资源，不预设集群采用哪套 API 资源版本；若改用 YAML 清单，应按目标集群支持的资源定义补齐相应字段。

先拆清模板里要解决的问题

编写资源清单或准备 kubectl 命令前，先明确库存查询 API 如何启动、读取哪些配置、监听什么端口，以及实例异常时怎样判断恢复。典型组合是由 Deployment 管理无状态副本，由 Service 提供集群内稳定地址；需要集群外访问时，再配置 Ingress 和入口控制器。应用配置与镜像分开管理，数据库凭据放入 Secret；需要保留的业务数据交给持久卷，不依赖容器文件系统。

同时确定命名空间、标签和资源边界。例如，将同一业务的 Deployment 与 Service 放在同一命名空间，并统一使用 app: api 标签。Service 选择器必须与 Pod 模板标签匹配，否则 Service 找不到后端，Pod 即使显示运行也无法接收请求。

• 镜像：由构建流程产出，并使用可核验的镜像摘要发布。
• 工作负载：Deployment 管理无状态 API 副本和滚动更新。
• 网络：Service 负责集群内访问，Ingress 按需承接集群外请求。
• 运行保障：探针、资源请求、伸缩策略和日志指标共同用于判断服务状态。

按部署顺序搭建基础工作负载

先将应用打包为容器镜像，在镜像中明确启动命令和监听端口，并准备能反映应用状态的健康检查接口。以下命令创建命名空间和 Deployment。镜像摘要、端口及探针路径都要替换或核对为库存查询 API 实际使用的值；占位摘要不能直接用于发布。

kubectl create namespace demo

kubectl create deployment api \
  --image=registry.example.com/team/api@sha256:REPLACE_WITH_DIGEST \
  --replicas=3 \
  -n demo

接着为容器设置资源请求和上限。CPU 请求值为 200m、内存请求值为 256Mi；CPU 上限为 1 核、内存上限为 512Mi。这些是演练参数，不是所有应用的通用标准。实际配置应结合压测结果和运行曲线调整，避免请求值过低导致节点超载，也避免上限设置不当影响服务响应。

kubectl set resources deployment/api -n demo \
  --requests=cpu=200m,memory=256Mi \
  --limits=cpu=1,memory=512Mi

为新 Pod 设置滚动更新策略，并加入就绪探针和存活探针。更新时允许额外启动 1 个 Pod，同时将不可用副本数设为 0，以减少发布期间的容量波动。就绪探针访问 /ready，存活探针访问 /live；请确认应用确实提供这两个端点。

kubectl patch deployment api -n demo --type=strategic \
  -p '{"spec":{"strategy":{"type":"RollingUpdate","rollingUpdate":{"maxSurge":1,"maxUnavailable":0}},"template":{"spec":{"containers":[{"name":"api","readinessProbe":{"httpGet":{"path":"/ready","port":8080},"periodSeconds":10},"livenessProbe":{"httpGet":{"path":"/live","port":8080},"periodSeconds":20}}]}}}}'

若应用启动较慢，可加入 startupProbe，让启动检查先完成，避免存活探针在初始化期间过早判定进程失败。探针接口应真实反映服务状态，不能只返回成功，却忽略关键依赖已经不可用。配置完成后检查 Deployment 与 Pod 的实际状态，而不是只根据命令返回成功就认定服务已经可用。

接通服务，并让发布过程可控

为 Deployment 配置 Service，使用同一组标签选择后端 Pod。下面的命令把集群内的 80 端口转发到容器的 8080 端口；集群内部的调用方通过 Service 名称访问，不直接依赖可能随 Pod 重建而变化的 IP。

kubectl expose deployment api \
  --name=api \
  --port=80 \
  --target-port=8080 \
  --type=ClusterIP \
  -n demo

需要对外访问时，再配置 Ingress 和对应的入口控制器，明确主机名、路径和后端 Service，避免把每个业务端口直接暴露到集群外。readinessProbe 判断实例是否可以接收流量，livenessProbe 判断进程是否需要重启。Service 选择器要与 Deployment 创建的 Pod 标签一致；若 Service 没有可用端点，先检查标签、Pod 就绪状态和目标端口。

发布时使用构建流程生成的镜像摘要，先在测试环境验证，再更新 Deployment 中的镜像地址。观察滚动更新状态、Pod 事件和应用日志；若新 Pod 无法就绪，先检查镜像拉取、配置挂载、端口和探针，再考虑回退到上一个健康的 ReplicaSet。环境差异放入 ConfigMap 或 Secret，避免临时修改镜像来切换配置。

kubectl set image deployment/api \
  api=registry.example.com/team/api@sha256:REPLACE_WITH_NEW_DIGEST \
  -n demo

kubectl rollout status deployment/api -n demo --timeout=180s

不要把数据库密码直接写入镜像或明文配置文件。可以由受控的密钥管理流程创建 Secret，再通过环境变量或卷挂载交给应用；访问凭据时要限制命名空间和服务账号权限。ConfigMap 适合存放非敏感配置，例如下游服务地址和功能开关。

补齐伸缩、容量与故障恢复

当 API 请求量变化明显时，可以为 Deployment 配置 HPA。伸缩依赖集群能提供指标数据，也依赖容器设置合理的 CPU requests。下面将副本范围设为 2 到 10，并把平均 CPU 使用率 65% 作为目标；应用高峰、启动耗时和下游数据库承载能力也要一并评估。

kubectl autoscale deployment api \
  --min=2 \
  --max=10 \
  --cpu=65 \
  -n demo

应用 HPA 前，确认集群指标组件正常，并检查 Deployment 已声明 CPU requests。伸缩不能代替容量规划：数据库连接池上限、消息队列配额和节点可用资源都要同步评估，否则 API 副本增加后，压力可能转移到下游依赖。若 CPU 使用率长期不反映真实瓶颈，还应根据请求量、队列长度或业务延迟补充合适的指标与告警。

对需要保存用户数据的组件，使用 PVC 与合适的存储类，并做好备份和恢复演练。PodDisruptionBudget 可限制自愿中断时同时不可用的副本数；配合多副本和合理的节点分布，可降低维护操作对服务的影响。对于有严格启动顺序或稳定网络标识的服务，应评估 StatefulSet，而不是把有状态组件一概放进 Deployment。

服务网格适合需要统一处理服务间加密、流量治理或细粒度调用观测的场景，但会增加代理资源消耗和运维复杂度。先用 Kubernetes 原生 Service、探针和伸缩能力跑通库存查询主链路，再针对明确需求引入网格策略，避免一开始就把复杂度堆进基础模板。

以运行结果校验整条路径

完成命名空间、Deployment、Service 和 HPA 的配置后，按顺序检查资源状态、后端端点和发布结果：

kubectl get deployment,pods,svc,hpa -n demo
kubectl rollout status deployment/api -n demo --timeout=180s
kubectl get endpointslice -n demo
kubectl describe deployment api -n demo
kubectl logs deployment/api -n demo

执行前确认 demo 命名空间已创建，且镜像摘要已替换为构建流程产出的实际值。依次检查 Pod 是否就绪、Service 是否关联到可用端点、入口是否能访问，以及日志和指标是否持续产生。再演练一次滚动发布，确认新副本就绪后旧副本退出；模拟实例异常，检查流量是否转向健康副本；最后验证回退、扩缩容和数据恢复流程。

kubectl rollout undo deployment/api -n demo
kubectl get pods,svc,hpa -n demo
kubectl get endpointslice -n demo

若发布后出现故障，先结合 Deployment 事件、Pod 状态和应用日志定位原因；确认新镜像或配置有问题时，再执行回退并检查旧副本是否恢复就绪。这样，k8s经典蘑菇就从一组可重复执行的部署步骤变成可复用的运行方法：先标准化工作负载，再接通服务，最后用伸缩、观测和恢复机制巩固稳定性。