最小可行部署需包含Deployment与Service两个YAML文件,但必须配置readinessProbe和livenessProbe(均建议用/actuator/health)、多阶段构建镜像(JRE运行时)、合理JVM参数、Service类型按环境选择、ConfigMap/Secret解耦配置,否则易导致滚动更新卡住、OOMKilled、503错误或安全风险。

能直接跑通的最小可行部署,只需要 Deployment + Service 两个 YAML 文件,但跳过健康探针、资源限制、非 root 用户这些环节,上线后大概率会出问题——比如滚动更新卡住、OOM 被 kill、或被安全扫描标为高危。
Deployment 必须配 readinessProbe 和 livenessProbe
Spring Boot 默认启动快,但实际依赖(DB 连接池、Redis 初始化、配置中心拉取)可能耗时几十秒。Kubernetes 若没探针,会把还没 ready 的 Pod 加入 Service 的 endpoint,导致请求 503 或超时。
-
readinessProbe建议用 Actuator 的/actuator/health,initialDelaySeconds: 30,periodSeconds: 10 -
livenessProbe同样用/actuator/health,但可设更宽松的failureThreshold: 5,避免因短暂 GC 暂停误杀 - 别用
httpGet直接打/—— Spring Boot 首页不带健康语义,且可能被 Spring Security 拦截返回 401
容器镜像必须用多阶段构建 + JRE 而非 JDK
本地 mvn package 打出的 jar 可以直接运行,但放进容器里,基础镜像选错会导致镜像体积翻倍、攻击面扩大、启动变慢。
评估 Kubernetes 集群安全态势,覆盖 RBAC、工作负载安全、网络策略、基础设施即代码(IaC)、运行时监控和密钥管理等 30 项控制项……
- 构建阶段用
eclipse-temurin:21-jdk-alpine,运行阶段必须切到eclipse-temurin:21-jre-alpine - 别用
openjdk:8-jdk-slim这类已 EOL 的镜像,Java 8 官方支持早在 2023 年终止 - ENTRYPOINT 中加
-XX:+UseContainerSupport和-XX:MaxRAMPercentage=75.0,否则 JVM 无视 cgroup 限制,内存超限直接被 OOMKilled
Service 类型选 ClusterIP 还是 LoadBalancer 看环境
本地测试(Kind / Minikube)和云上生产环境,type 字段行为完全不同,硬写死会卡在 pending 状态。
- 开发/测试:用
type: ClusterIP+kubectl port-forward,避免暴露公网 IP - 云厂商(AWS/Azure/GCP):用
type: LoadBalancer,会自动创建 ELB/NLB - 裸金属或私有云:改用
type: NodePort,并确认防火墙放行对应端口(默认 30000–32767) - 千万别在
Service里漏写selector,它必须和Deployment的matchLabels完全一致,否则 endpoint 为空
ConfigMap 和 Secret 必须和代码解耦
把数据库密码写进 application.yml 再打包进镜像,等于把密钥硬编码——每次改密码都要重构建、重部署,审计也过不了。
- 敏感字段(
spring.datasource.password、API keys)必须走Secret,且用stringData字段明文定义,由 kubectl 自动 base64 编码 - 非敏感配置(
server.port、logging.level)用ConfigMap,挂载为文件或环境变量均可 - 在
Deployment的env下用valueFrom: configMapKeyRef或secretKeyRef引用,别用envFrom全量注入——容易污染环境变量命名空间
真正卡住人的不是 YAML 语法,而是 JVM 参数没对齐 cgroup、探针路径被 Actuator 版本改名、或者 Secret 没加 type: Opaque 导致挂载失败——这些细节不会报错,只会让 Pod 一直 Pending 或 CrashLoopBackOff。

















