尧图网页设计 
这几天刚好在一个内部项目里把一套SpringBoot微服务迁到了Kubernetes上整个过程走完最大的感受是很多人不是不会写Dockerfile也不是不懂K8s的概念而是卡在了“怎么把SpringBoot、Kubernetes、Helm这三样东西真正串成一条能用的交付链路”上。这篇文章就把我这次实操里踩过的坑、验证过的方案、调过的参数全部摊开讲从集群搭建讲到HPA弹性扩缩容再从裸YAML讲到Helm打包适合准备把SpringBoot微服务迁到云原生体系里的开发同学也适合刚接触Kubernetes、想找个完整项目练手的运维或后端工程师。1. 整体设计与技术选型思路1.1 为什么偏偏是Kubernetes而不是Docker Compose或者Swarm先说一个很多人会问的问题团队规模不大、服务也就五六个直接上Docker Compose不行吗非要上Kubernetes我的回答是如果你的服务数量不再增长、流量也非常稳定那Docker Compose确实够用。但一旦你开始拆微服务以下需求会迅速冒出来服务实例需要根据流量自动增减某个节点宕掉后Pod要能自动在其他机器上拉起来发布新版本时不能中断线上请求整个集群要能容忍单机故障。Kubernetes解决的就是这一整套分布式应用的编排问题。它把若干台服务器抽象成一个资源池你的SpringBoot服务只是池子里的一个个Pod调度、自愈、滚动更新、扩缩容都交给控制面处理。Docker Compose会在单机范围内管理容器Swarm则是“多了一个管理入口”但生态和扩展性完全不在一个量级。Kubernetes胜出的既有API设计得完整这个因素也有活跃的社区和Helm这种配套工具链。说白了Kubernetes不是一个容器工具而是一套面向“大规模分布式系统”的编排标准。1.2 Helm到底解决什么问题为什么不能只写YAML用Kubernetes裸YAML部署一两个服务没什么问题服务一多就不对劲了。每个服务至少是一份Deployment、一份Service再加上Ingress、ConfigMap、Secret、HPA动辄五六份文件而且每份里面都有镜像地址、副本数、资源限制这些随时可能改的字段。你让开发改一个镜像Tag就得在十个文件里搜索替换稍不留神就漏改一处。更麻烦的是不同环境测试、预发、生产之间的差异用裸YAML基本只能靠复制目录再手工改改到最后连谁是最新版本都说不清。Helm把一组相关的Kubernetes资源打包成一个Chart所有可变参数抽到values.yaml里模板文件负责渲染这就相当于给Kubernetes YAML加了一层“配置中心”和“版本管理”。你要升级服务改一下values.yaml然后执行helm upgrade就能完成一次可追踪、可回滚的发布。我这里强烈建议即便团队只有三四个人只要计划用Kubernetes托管三个以上微服务就直接上Helm别等到二十个服务的时候再迁移那时候改造成本要高好几倍。1.3 云原生微服务的整体蓝图从代码到弹性伸缩我这次搭建的完整链路是这样一个闭环SpringBoot服务通过Maven构建成Jar包再用Dockerfile打包成镜像镜像推到私有Registry后Helm负责渲染生成Kubernetes资源并执行部署服务以Deployment形式跑在集群里通过Service做负载均衡靠Ingress暴露到集群外部Controller Manager里的HPA根据CPU或自定义指标自动调整副本数。如果我给这套体系画一张逻辑图它会分成四层接入层Ingress、服务层Deployment/Pod/Service、调度与自愈层Kubelet/Controller Manager、配置与发布层Helm/ConfigMap/Secret。很多人听到“云原生”以为一定要上什么高深的Service Mesh其实对大多数中小团队来说先把Kubernetes加Helm这套底座打扎实就已经拿到云原生交付能力的大头了。微服务框架本身选择SpringBoot还是其他语言并不关键关键在于你怎样把服务打成镜像、怎样声明它的运行状态、怎样让平台按需调度。只要这层想明白了后续再引入配置中心、链路追踪、消息队列都是顺手的事。2. 环境准备与工具链选型2.1 本地Kubernetes集群到底选k3s、kind还是minikube写这本书的开头我先得承认一个现实如果你手头的机器只有8G内存硬上完整版kubeadm部署的Kubernetes集群会非常痛苦光系统组件就能吃掉两个G。所以我强烈建议根据机器配置和用途选型k3sRancher出品的轻量发行版把很多组件做成了进程内集成默认使用SQLite存储而非etcd内存占用小得多单机装k3s之后跑SpringBoot微服务毫无压力。这是我最推荐的方案也是我这次实战用的环境。k3s自带Traefik和flannel装完开机即用。kind以Docker容器作为“节点”来模拟整个集群创建速度快适合做CI流水线里的集成测试环境但网络模型绕了一层Docker桥接调试Ingress和NodePort时会有额外心智负担。minikube老牌本地集群工具功能全对初学者友好但默认虚拟机驱动在部分环境下需要装额外组件资源消耗比k3s高。这里有一张针对本地开发的对比表可以直接参考维度k3skindminikube安装耗时约1分钟约2分钟约3分钟取决于虚拟机内存占用约500MB约1GB以上约1GB以上生产一致性中高组件基本一致中节点是容器中单节点模拟适合场景日常开发/小团队生产CI集成测试入门学习我推荐本地开发用k3s还有一个重要原因是它支持的一等公民K3s Server Agent模式可以直接把多台树莓派或旧笔记本组成轻量集群体验和生产环境的分界线非常模糊。我这次直接用单节点k3s后面所有YAML和Helm Chart同样可以平滑适配完整Kubernetes集群。2.2 Helm安装与常用命令速览Helm的安装不像Kubernetes组件那么复杂本质上就是下载一个二进制文件放到PATH里。以Linux环境为例可以到GitHub Releases页面拿最新稳定版安装包解压后把helm放到/usr/local/bin下。也可以直接用它提供的一键脚本curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh装好之后验证版本helm version # version.BuildInfo{Version:v3.10.0, GitCommit:...}有些同学对helm 3.x的版本号很敏感因为3.10左右开始对Chart依赖的处理有一些变化。我这次用的其实是v3.10.0如果你本地已经装了更高的3.14或3.15大部分命令语法完全一样不用担心。日常用得最多的命令无非是这几个# 创建新Chart helm create order-service # 本地模板渲染不实际部署用于排查YAML渲染问题 helm template order-service ./order-service # 语法和格式检查 helm lint ./order-service # 首次安装 helm install order-service ./order-service -f values-prod.yaml # 升级存在则更新不存在则安装 helm upgrade --install order-service ./order-service -f values-prod.yaml # 回滚到上一个版本 helm rollback order-service 12.3 Ingress Controller与镜像加速的实用配置k3s默认自带Traefik作为Ingress Controller这对我们来说是好事少装一个组件。但如果你用kind或minikube可能需要手动部署ingress-nginx。这里我提醒一个容易踩的坑Ingress Controller本身是一个运行在集群内的Deployment它负责监听Ingress资源并动态生成负载均衡配置如果你的集群没有Ingress Controller就算创建了Ingress对象也不会生效访问Service的域名会一直超时。镜像加速这边不管是minikube还是kind默认都会去Docker Hub拉镜像在国内网络环境下经常超时。我的做法是给Docker配置镜像加速地址然后让k3s通过读取host的Docker镜像。k3s本身内置了containerd它不直接用Docker镜像缓存所以在单节点开发环境下我建议这样处理让k3s启动时加上docker作为镜像源或者直接把用到的镜像提前用docker pull拉好再通过k3s ctr导入。实操中我更推荐直接配置私有镜像仓库比如部署一个Harbor或者简单的Registry开发机和集群都从那里拉彻底摆脱对公共网络的依赖。3. SpringBoot服务准备与镜像构建细节3.1 微服务拆到什么粒度才算合理先把镜子摆正Kubernetes和微服务是两码事。你可以把所有功能写在一个SpringBoot单体应用里然后部署到Kubernetes也可以拆十个微服务部署到Docker Compose。但在实践里Kubernetes会倒逼你认真考虑服务边界因为每个Deployment的副本数、资源限制、HPA阈值都是独立的。我这次拿来做示例的是典型的订单链路网关服务、用户服务、订单服务、支付服务外加一个公共服务包放通用的工具类。拆分的判断标准我总结成三条一是能不能独立上线改一个服务不影响其他服务二是数据能不能隔离每个服务都有自己的存储不允许直接读别人库三是团队职责是否清晰谁负责哪个服务边界清楚。如果一条都不满足那你拆出来的所谓“微服务”其实就是分布式的单体维护成本只会更高。3.2 Dockerfile的演进之路从粗放到精细化先看一个新手常写的DockerfileFROM maven:3.8-jdk-11 AS build COPY . . RUN mvn clean package -DskipTests FROM openjdk:11-jre-slim COPY --frombuild /target/order-service.jar /app/app.jar ENTRYPOINT [java, -jar, /app/app.jar]这是一版能工作的Dockerfile但它有一个很明显的痛点每次代码变更Maven都要重新下载依赖、重新编译构建时间从几十秒变成几分钟开发迭代要疯。解决办法是分层利用Docker的Build Cache先把pom.xml拷进去让依赖下载这一层能被缓存住FROM maven:3.8-jdk-11 AS build WORKDIR /workspace COPY pom.xml . RUN mvn dependency:go-offline -B COPY src ./src RUN mvn clean package -DskipTests这样只要pom.xml不变依赖层的缓存就一直有效通常能把镜像构建时间缩短60%以上。再进一步还可以用Jib或者Buildpacks这些工具能自动分析SpringBoot项目的构建方式甚至不需要在本地装Docker就能推送镜像。不过我建议还是先手写Dockerfile理解原理再上工具。3.3 JVM内存、健康检查与优雅停机这些细节不能省SpringBoot应用跑在容器里最常犯的错误就是把JVM当物理机跑。默认情况下JVM会根据机器总内存计算堆大小而Pod里的容器看到的/proc/meminfo是宿主机或虚拟机的信息如果requests设置得低节点可能超卖OOM Killer随时会把你的进程杀掉。我这次SpringBoot用的是JDK 11在容器里直接显式指定内存参数ENV JAVA_OPTS-Xms256m -Xmx512m -XX:MaxMetaspaceSize128m ENTRYPOINT [sh, -c, java $JAVA_OPTS -jar /app/app.jar]从SpringBoot 2.3开始内置了graceful shutdown支持配置一下就能在Pod被终止时先把正在处理的请求完成再退出server: shutdown: graceful spring: lifecycle: timeout-per-shutdown-phase: 30sKubernetes在滚动更新时会先给旧Pod发SIGTERM如果应用没处理优雅停机连接就会被直接掐断。我自己就遇到过这种情况发布的时候总有几个请求报Connect Reset排查了很久才意识到是JVM没有等请求处理完就退出了。健康检查方面SpringBoot Actuator暴露的/actuator/health接口要配置成无需鉴权同时Kubernetes的readinessProbe和livenessProbe要区分清楚。readiness探针决定流量是否打到这个Pod上liveness探针决定Pod是否还活着配置错误会导致滚动更新卡死或者Pod被无限重启。具体YAML我会在下一章专门讲。4. Kubernetes部署编排与弹性扩缩容实战4.1 一份地道的Deployment YAML该长什么样把SpringBoot应用跑到Kubernetes里第一个核心资源是Deployment它负责任务声明、滚动更新和副本管理。下面这份YAML是我这个实战项目里一份比较完整的order-service注释都标在关键行apiVersion: apps/v1 kind: Deployment metadata: name: order-service namespace: mall labels: app: order-service spec: replicas: 2 selector: matchLabels: app: order-service strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: metadata: labels: app: order-service spec: containers: - name: order-service image: harbor.example.com/mall/order-service:1.4.0 imagePullPolicy: IfNotPresent ports: - containerPort: 8080 resources: requests: cpu: 250m memory: 512Mi limits: cpu: 1 memory: 768Mi readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 20 periodSeconds: 10 failureThreshold: 3 livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 initialDelaySeconds: 50 periodSeconds: 20 failureThreshold: 3 env: - name: SPRING_PROFILES_ACTIVE value: k8s - name: SPRING_CONFIG_LOCATION value: optional:classpath:/,optional:configmap:/etc/mall-config/ volumeMounts: - name: config mountPath: /etc/mall-config volumes: - name: config configMap: name: mall-config有几个坑我特意标出来。maxSurge设为1、maxUnavailable设为0意思是滚动更新时先拉起一个新Pod等它ready再终止一个旧Pod发布期间服务始终有全部副本在跑适合对可用性敏感的场景。如果你设置maxUnavailable为1发布时会先杀掉一个旧Pod如果新Pod起不来服务容量就会少一半。资源requests和limits的差别我用一句话解释requests是Kubernetes调度器用来决定把Pod放在哪台节点上的凭证limits是运行时强制限制超过就会触发容器重启。不建议把limits和requests设成一样大尤其内存JVM的堆外内存、Metaspace、线程栈很容易把内存顶上去一旦超过limitPod会被OOMKilled而你还以为是代码泄漏。4.2 HPA弹性扩缩容的数学逻辑与配置细节弹性扩缩容是整个Kubernetes最吸引人的能力之一但它依赖一等公民指标来源默认一般是metrics-server提供的CPU和内存。注意Kubernetes本身不采集指标需要单独部署metrics-serverk3s默认没有启用它我是手动安装的kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml装完验证一下kubectl top nodes kubectl top pods -n mall能分别显示出CPU和内存使用量才说明指标链路通了。接下来创建HPA。以下是给order-service配置的HPA目标CPU平均使用率保持60%副本数浮动范围是2到8apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: order-service-hpa namespace: mall spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: order-service minReplicas: 2 maxReplicas: 8 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 behavior: scaleDown: stabilizationWindowSeconds: 300HPA的原理其实是一个控制循环每隔一段时间一般30秒左右从metrics-server拉取当前Pod的指标然后拿实际利用率和目标利用率做比较用下面这个公式计算期望副本数期望副本数 ceil(当前副本数 x (当前指标值 / 目标指标值))我用具体数字解释一下当前有2个Pod每个Pod的CPU使用率是90%目标利用率是60%那么期望副本数就是ceil(2 x (90 / 60)) ceil(3) 3。HPA会立刻把副本数调到3。如果指标变成一直120%期望副本数就是ceil(2 x 2) 4。如果当前指标低于目标值它还会按同样的公式缩容只是受缩容稳定窗口限制不会因为一两分钟的抖动就疯狂地一缩一扩。这里有个关键的“机制陷阱”需要提醒averageUtilization是基于requests来计算的不是基于Pod的真实核数。比如一个Pod的cpu request配了500m即使这个Pod跑到1000m指标也是200%。所以建议把HPA的评估目标直接与requests关联比如request设250m目标利用率设70%这样你就知道核心CPU最多用不到200m上下整机的压力是可预估的。4.3 压测现场从2个Pod一路顶到8个Pod配置说完直接看实操。我用部署在集群外的压测机向Ingress发起并发请求工具是abApache Bench虽然简单但看趋势已经足够ab -n 100000 -c 200 http://mall.example.com/order-service/api/order/list刚开始HPA还未介入order-service只有2个Podab一压Kubernetes Dashboard里立刻能看到CPU使用率飙升到接近250%HPA控制器在30秒内触发扩容Pod数量从2变为4再过了大约两分钟变为8CPU利用率被拉回到60%左右。整个压测过程用kubectl命令观察得清清楚楚kubectl get hpa -n mall -w # NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE # order-service-hpa Deployment/order-service 90%/60% 2 8 2 15h # order-service-hpa Deployment/order-service 130%/60% 2 8 4 15h # order-service-hpa Deployment/order-service 75%/60% 2 8 6 15h # order-service-hpa Deployment/order-service 60%/60% 2 8 8 15h压测结束后我没有马上看到缩容这是正常的因为我在HPA里把scaleDown的稳定窗口设成了300秒。设计上这是刻意为之缩容太重会引发“抖动”流量一小就缩下一次流量一来又得重新创建PodPod创建到Ready最少几十秒期间的请求全部超时。稳定窗口相当于一个阻尼器逼着系统观测一段时间再决定要不要缩。要加深对HPA的理解最好把这些参数整理成一张表放在手里参数作用建议值averageUtilization目标平均CPU利用率60%-70%比较合理stabilizationWindowSeconds缩容缩容前的观察等待期300秒起步minReplicas最低副本数至少2避免单点maxReplicas最大副本数根据峰值流量评估不是越大越好评估周期HPA默认评估间隔默认15秒左右不需要改4.4 使用Helm把服务部署做成标准化交付到了Helm这里整个交付流程就算打通了。我的做法是每个服务建一个Chart目录把Kubernetes清单作为模板放进去order-service/ ├── Chart.yaml ├── values.yaml ├── values-dev.yaml ├── values-prod.yaml └── templates/ ├── deployment.yaml ├── service.yaml ├── ingress.yaml ├── hpa.yaml └── _helpers.tplChart.yaml元信息apiVersion: v2 name: order-service description: A Helm chart for order service of mall type: application version: 0.1.0 appVersion: 1.4.0values.yaml的核心参数replicaCount: 2 image: repository: harbor.example.com/mall/order-service tag: 1.4.0 pullPolicy: IfNotPresent service: type: ClusterIP port: 80 targetPort: 8080 ingress: enabled: true className: traefik host: mall.example.com path: /order-service(/|$)(.*) resources: requests: cpu: 250m memory: 512Mi limits: cpu: 1 memory: 768Mi hpa: enabled: true minReplicas: 2 maxReplicas: 8 targetCPUUtilizationPercentage: 60模板文件里面通过{{ .Values.xxx }}引用这些字段部署时指定不同环境values文件helm upgrade --install order-service ./order-service -n mall -f values-dev.yaml helm upgrade --install order-service ./order-service -n mall -f values-prod.yaml我极力建议团队统一用helm upgrade --install来发布不要先helm install再分步改。这样每一次发布都会生成一个版本记录出问题可以一秒回滚到上一个版本helm history order-service -n mall helm rollback order-service 3 -n mall这里有一个从我实际项目里带出来的经验不要把密码、数据库连接串写进values.yaml哪怕你只是放在私有Git仓库。正确做法是把Secret存到Vault或者外部Secrets Operator让Helm只管部署编排。否则一旦Chart泄露等于把整个环境的钥匙交出去了。5. 常见问题与排查技巧实录5.1 镜像拉取失败与CreateContainerConfigError镜像拉取失败是Kubernetes新手遇到最多的拦路虎常见报错有两种ImagePullBackOff和ErrImagePull。排查思路先看事件kubectl describe pod order-service-xxxxx -n mall如果事件里出现“pull access denied”说明镜像不存在或权限不对。我在实践里吃过一个暗亏镜像的Tag用latest本地Docker明明有这个镜像但k3s的containerd还是去远程仓库拉由于私有仓库地址配置略有问题一直超时。从那以后我就不再使用latest而是把版本号写死既保证可复现也避免上面的策略误会。CreateContainerConfigError则说明Pod启动前的配置解析失败了最常见的根源是ConfigMap里缺少某个key或者Secret引用的键不存在。遇到这类报错优先执行kubectl get configmap、kubectl describe secret检查不要一上来就怀疑代码。5.2 就绪探针配置不当导致滚动更新卡死这是我踩过最隐蔽的坑readinessProbe配置了/actuator/health/readiness但SpringBoot 2.3之前这个端点默认不暴露返回404新Pod始终不Ready滚动更新就卡在Waiting旧Pod被maxUnavailable0锁住不能删整个发布流程直接停滞。解决方案是确保有暴露相关endpoint的依赖和配置。再提醒一点readiness和liveness千万别共用同一个接口否则当应用因为依赖的数据库不可用而失去就绪状态时liveness也会跟着失败Kubernetes会认为Pod不健康并把它重启造成服务反复重启但一直起不来的假象。正确做法是readiness检查依赖项liveness只检查进程是否活着。5.3 HPA拿不到指标TARGETS一直显示UnavailableHPA配置完成后如果kubectl get hpa里TARGETS列显示Unavailable大概率不是HPA自身的问题而是metrics-server没有正常工作。先看metrics-server的Pod日志kubectl logs -n kube-system deployment/metrics-server常见原因包括证书未适配导致Kubelet拒绝连接或者metrics-server缺了kubelet-preferred-address-types参数。在自签证书环境下需要给metrics-server增加--kubelet-insecure-tls参数。另外Pods的requests没有配置或者所有请求为0也会导致计算不出利用率所以配置HPA前先确认kubectl top pods有数据。5.4 弹性伸缩目标设置太高或太低怎么权衡把HPA目标设成90%意味着Pod要快跑满了才会扩容好处是省机器坏处是延迟会飙升因为CPU到达90%的时候请求已经在排队了。把目标设成30%倒是反应快但机器成本可能翻好几倍。我给绝大多数无状态SpringBoot服务推荐60%-70%这个区间理由是大部分服务对延迟的敏感度都在这个范围内能找到平衡点给流量波峰预留了40%空间又不至于让机器闲置。缩容稳定窗口也别拍脑袋设。我这里有个经验公式如果你的服务启动到Ready需要40秒那么缩容稳定窗口至少应该大于这个时间的两倍否则缩下来的Pod还没走完回调又重建永远是无效缩容。压测后我特意把300秒稳定窗口保留实测流量撤掉后约5分钟才缩到2个副本刚好符合预期。5.5 团队协作里最容易被忽略的版本与配置管理问题Helm虽然帮你解决了资源编排的版本管理但实际交付链路里还有一个容易被忽略的环节镜像Tag和Chart版本怎么联动。我的建议是把镜像Tag写死在values-prod.yaml里每次发布前先更新appVersion和image.tag提交后走CI/CD流水线Helm Chart本身也打标签归档。千万别在服务器上手动改values.yaml否则很容易出现“环境里跑着的镜像和Git仓库里记录的对不上”的灾难。这一套组合拳打下来我最大的收获倒不是学会了几个命令而是建立了一种从“代码到运行平台”的全局视角SpringBoot决定了我能提供什么服务Kubernetes决定了我能怎样调度和管理这些服务Helm则在中间充当了胶水把发布流程固化下来。以后不管服务数量怎么涨我只要往Chart里加模板、往values里加参数就能在相同规则下无限复制。哪怕你暂时只有一两个SpringBoot服务我也建议试试这套链路因为把基础设施当作代码来管省下的是未来每一次发布时的焦虑。 SpringBoot微服务迁移Kubernetes与Helm实战指南
这几天刚好在一个内部项目里把一套SpringBoot微服务迁到了Kubernetes上整个过程走完最大的感受是很多人不是不会写Dockerfile也不是不懂K8s的概念而是卡在了“怎么把SpringBoot、Kubernetes、Helm这三样东西真正串成一条能用的交付链路”上。这篇文章就把我这次实操里踩过的坑、验证过的方案、调过的参数全部摊开讲从集群搭建讲到HPA弹性扩缩容再从裸YAML讲到Helm打包适合准备把SpringBoot微服务迁到云原生体系里的开发同学也适合刚接触Kubernetes、想找个完整项目练手的运维或后端工程师。1. 整体设计与技术选型思路1.1 为什么偏偏是Kubernetes而不是Docker Compose或者Swarm先说一个很多人会问的问题团队规模不大、服务也就五六个直接上Docker Compose不行吗非要上Kubernetes我的回答是如果你的服务数量不再增长、流量也非常稳定那Docker Compose确实够用。但一旦你开始拆微服务以下需求会迅速冒出来服务实例需要根据流量自动增减某个节点宕掉后Pod要能自动在其他机器上拉起来发布新版本时不能中断线上请求整个集群要能容忍单机故障。Kubernetes解决的就是这一整套分布式应用的编排问题。它把若干台服务器抽象成一个资源池你的SpringBoot服务只是池子里的一个个Pod调度、自愈、滚动更新、扩缩容都交给控制面处理。Docker Compose会在单机范围内管理容器Swarm则是“多了一个管理入口”但生态和扩展性完全不在一个量级。Kubernetes胜出的既有API设计得完整这个因素也有活跃的社区和Helm这种配套工具链。说白了Kubernetes不是一个容器工具而是一套面向“大规模分布式系统”的编排标准。1.2 Helm到底解决什么问题为什么不能只写YAML用Kubernetes裸YAML部署一两个服务没什么问题服务一多就不对劲了。每个服务至少是一份Deployment、一份Service再加上Ingress、ConfigMap、Secret、HPA动辄五六份文件而且每份里面都有镜像地址、副本数、资源限制这些随时可能改的字段。你让开发改一个镜像Tag就得在十个文件里搜索替换稍不留神就漏改一处。更麻烦的是不同环境测试、预发、生产之间的差异用裸YAML基本只能靠复制目录再手工改改到最后连谁是最新版本都说不清。Helm把一组相关的Kubernetes资源打包成一个Chart所有可变参数抽到values.yaml里模板文件负责渲染这就相当于给Kubernetes YAML加了一层“配置中心”和“版本管理”。你要升级服务改一下values.yaml然后执行helm upgrade就能完成一次可追踪、可回滚的发布。我这里强烈建议即便团队只有三四个人只要计划用Kubernetes托管三个以上微服务就直接上Helm别等到二十个服务的时候再迁移那时候改造成本要高好几倍。1.3 云原生微服务的整体蓝图从代码到弹性伸缩我这次搭建的完整链路是这样一个闭环SpringBoot服务通过Maven构建成Jar包再用Dockerfile打包成镜像镜像推到私有Registry后Helm负责渲染生成Kubernetes资源并执行部署服务以Deployment形式跑在集群里通过Service做负载均衡靠Ingress暴露到集群外部Controller Manager里的HPA根据CPU或自定义指标自动调整副本数。如果我给这套体系画一张逻辑图它会分成四层接入层Ingress、服务层Deployment/Pod/Service、调度与自愈层Kubelet/Controller Manager、配置与发布层Helm/ConfigMap/Secret。很多人听到“云原生”以为一定要上什么高深的Service Mesh其实对大多数中小团队来说先把Kubernetes加Helm这套底座打扎实就已经拿到云原生交付能力的大头了。微服务框架本身选择SpringBoot还是其他语言并不关键关键在于你怎样把服务打成镜像、怎样声明它的运行状态、怎样让平台按需调度。只要这层想明白了后续再引入配置中心、链路追踪、消息队列都是顺手的事。2. 环境准备与工具链选型2.1 本地Kubernetes集群到底选k3s、kind还是minikube写这本书的开头我先得承认一个现实如果你手头的机器只有8G内存硬上完整版kubeadm部署的Kubernetes集群会非常痛苦光系统组件就能吃掉两个G。所以我强烈建议根据机器配置和用途选型k3sRancher出品的轻量发行版把很多组件做成了进程内集成默认使用SQLite存储而非etcd内存占用小得多单机装k3s之后跑SpringBoot微服务毫无压力。这是我最推荐的方案也是我这次实战用的环境。k3s自带Traefik和flannel装完开机即用。kind以Docker容器作为“节点”来模拟整个集群创建速度快适合做CI流水线里的集成测试环境但网络模型绕了一层Docker桥接调试Ingress和NodePort时会有额外心智负担。minikube老牌本地集群工具功能全对初学者友好但默认虚拟机驱动在部分环境下需要装额外组件资源消耗比k3s高。这里有一张针对本地开发的对比表可以直接参考维度k3skindminikube安装耗时约1分钟约2分钟约3分钟取决于虚拟机内存占用约500MB约1GB以上约1GB以上生产一致性中高组件基本一致中节点是容器中单节点模拟适合场景日常开发/小团队生产CI集成测试入门学习我推荐本地开发用k3s还有一个重要原因是它支持的一等公民K3s Server Agent模式可以直接把多台树莓派或旧笔记本组成轻量集群体验和生产环境的分界线非常模糊。我这次直接用单节点k3s后面所有YAML和Helm Chart同样可以平滑适配完整Kubernetes集群。2.2 Helm安装与常用命令速览Helm的安装不像Kubernetes组件那么复杂本质上就是下载一个二进制文件放到PATH里。以Linux环境为例可以到GitHub Releases页面拿最新稳定版安装包解压后把helm放到/usr/local/bin下。也可以直接用它提供的一键脚本curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh装好之后验证版本helm version # version.BuildInfo{Version:v3.10.0, GitCommit:...}有些同学对helm 3.x的版本号很敏感因为3.10左右开始对Chart依赖的处理有一些变化。我这次用的其实是v3.10.0如果你本地已经装了更高的3.14或3.15大部分命令语法完全一样不用担心。日常用得最多的命令无非是这几个# 创建新Chart helm create order-service # 本地模板渲染不实际部署用于排查YAML渲染问题 helm template order-service ./order-service # 语法和格式检查 helm lint ./order-service # 首次安装 helm install order-service ./order-service -f values-prod.yaml # 升级存在则更新不存在则安装 helm upgrade --install order-service ./order-service -f values-prod.yaml # 回滚到上一个版本 helm rollback order-service 12.3 Ingress Controller与镜像加速的实用配置k3s默认自带Traefik作为Ingress Controller这对我们来说是好事少装一个组件。但如果你用kind或minikube可能需要手动部署ingress-nginx。这里我提醒一个容易踩的坑Ingress Controller本身是一个运行在集群内的Deployment它负责监听Ingress资源并动态生成负载均衡配置如果你的集群没有Ingress Controller就算创建了Ingress对象也不会生效访问Service的域名会一直超时。镜像加速这边不管是minikube还是kind默认都会去Docker Hub拉镜像在国内网络环境下经常超时。我的做法是给Docker配置镜像加速地址然后让k3s通过读取host的Docker镜像。k3s本身内置了containerd它不直接用Docker镜像缓存所以在单节点开发环境下我建议这样处理让k3s启动时加上docker作为镜像源或者直接把用到的镜像提前用docker pull拉好再通过k3s ctr导入。实操中我更推荐直接配置私有镜像仓库比如部署一个Harbor或者简单的Registry开发机和集群都从那里拉彻底摆脱对公共网络的依赖。3. SpringBoot服务准备与镜像构建细节3.1 微服务拆到什么粒度才算合理先把镜子摆正Kubernetes和微服务是两码事。你可以把所有功能写在一个SpringBoot单体应用里然后部署到Kubernetes也可以拆十个微服务部署到Docker Compose。但在实践里Kubernetes会倒逼你认真考虑服务边界因为每个Deployment的副本数、资源限制、HPA阈值都是独立的。我这次拿来做示例的是典型的订单链路网关服务、用户服务、订单服务、支付服务外加一个公共服务包放通用的工具类。拆分的判断标准我总结成三条一是能不能独立上线改一个服务不影响其他服务二是数据能不能隔离每个服务都有自己的存储不允许直接读别人库三是团队职责是否清晰谁负责哪个服务边界清楚。如果一条都不满足那你拆出来的所谓“微服务”其实就是分布式的单体维护成本只会更高。3.2 Dockerfile的演进之路从粗放到精细化先看一个新手常写的DockerfileFROM maven:3.8-jdk-11 AS build COPY . . RUN mvn clean package -DskipTests FROM openjdk:11-jre-slim COPY --frombuild /target/order-service.jar /app/app.jar ENTRYPOINT [java, -jar, /app/app.jar]这是一版能工作的Dockerfile但它有一个很明显的痛点每次代码变更Maven都要重新下载依赖、重新编译构建时间从几十秒变成几分钟开发迭代要疯。解决办法是分层利用Docker的Build Cache先把pom.xml拷进去让依赖下载这一层能被缓存住FROM maven:3.8-jdk-11 AS build WORKDIR /workspace COPY pom.xml . RUN mvn dependency:go-offline -B COPY src ./src RUN mvn clean package -DskipTests这样只要pom.xml不变依赖层的缓存就一直有效通常能把镜像构建时间缩短60%以上。再进一步还可以用Jib或者Buildpacks这些工具能自动分析SpringBoot项目的构建方式甚至不需要在本地装Docker就能推送镜像。不过我建议还是先手写Dockerfile理解原理再上工具。3.3 JVM内存、健康检查与优雅停机这些细节不能省SpringBoot应用跑在容器里最常犯的错误就是把JVM当物理机跑。默认情况下JVM会根据机器总内存计算堆大小而Pod里的容器看到的/proc/meminfo是宿主机或虚拟机的信息如果requests设置得低节点可能超卖OOM Killer随时会把你的进程杀掉。我这次SpringBoot用的是JDK 11在容器里直接显式指定内存参数ENV JAVA_OPTS-Xms256m -Xmx512m -XX:MaxMetaspaceSize128m ENTRYPOINT [sh, -c, java $JAVA_OPTS -jar /app/app.jar]从SpringBoot 2.3开始内置了graceful shutdown支持配置一下就能在Pod被终止时先把正在处理的请求完成再退出server: shutdown: graceful spring: lifecycle: timeout-per-shutdown-phase: 30sKubernetes在滚动更新时会先给旧Pod发SIGTERM如果应用没处理优雅停机连接就会被直接掐断。我自己就遇到过这种情况发布的时候总有几个请求报Connect Reset排查了很久才意识到是JVM没有等请求处理完就退出了。健康检查方面SpringBoot Actuator暴露的/actuator/health接口要配置成无需鉴权同时Kubernetes的readinessProbe和livenessProbe要区分清楚。readiness探针决定流量是否打到这个Pod上liveness探针决定Pod是否还活着配置错误会导致滚动更新卡死或者Pod被无限重启。具体YAML我会在下一章专门讲。4. Kubernetes部署编排与弹性扩缩容实战4.1 一份地道的Deployment YAML该长什么样把SpringBoot应用跑到Kubernetes里第一个核心资源是Deployment它负责任务声明、滚动更新和副本管理。下面这份YAML是我这个实战项目里一份比较完整的order-service注释都标在关键行apiVersion: apps/v1 kind: Deployment metadata: name: order-service namespace: mall labels: app: order-service spec: replicas: 2 selector: matchLabels: app: order-service strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: metadata: labels: app: order-service spec: containers: - name: order-service image: harbor.example.com/mall/order-service:1.4.0 imagePullPolicy: IfNotPresent ports: - containerPort: 8080 resources: requests: cpu: 250m memory: 512Mi limits: cpu: 1 memory: 768Mi readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 20 periodSeconds: 10 failureThreshold: 3 livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 initialDelaySeconds: 50 periodSeconds: 20 failureThreshold: 3 env: - name: SPRING_PROFILES_ACTIVE value: k8s - name: SPRING_CONFIG_LOCATION value: optional:classpath:/,optional:configmap:/etc/mall-config/ volumeMounts: - name: config mountPath: /etc/mall-config volumes: - name: config configMap: name: mall-config有几个坑我特意标出来。maxSurge设为1、maxUnavailable设为0意思是滚动更新时先拉起一个新Pod等它ready再终止一个旧Pod发布期间服务始终有全部副本在跑适合对可用性敏感的场景。如果你设置maxUnavailable为1发布时会先杀掉一个旧Pod如果新Pod起不来服务容量就会少一半。资源requests和limits的差别我用一句话解释requests是Kubernetes调度器用来决定把Pod放在哪台节点上的凭证limits是运行时强制限制超过就会触发容器重启。不建议把limits和requests设成一样大尤其内存JVM的堆外内存、Metaspace、线程栈很容易把内存顶上去一旦超过limitPod会被OOMKilled而你还以为是代码泄漏。4.2 HPA弹性扩缩容的数学逻辑与配置细节弹性扩缩容是整个Kubernetes最吸引人的能力之一但它依赖一等公民指标来源默认一般是metrics-server提供的CPU和内存。注意Kubernetes本身不采集指标需要单独部署metrics-serverk3s默认没有启用它我是手动安装的kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml装完验证一下kubectl top nodes kubectl top pods -n mall能分别显示出CPU和内存使用量才说明指标链路通了。接下来创建HPA。以下是给order-service配置的HPA目标CPU平均使用率保持60%副本数浮动范围是2到8apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: order-service-hpa namespace: mall spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: order-service minReplicas: 2 maxReplicas: 8 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 behavior: scaleDown: stabilizationWindowSeconds: 300HPA的原理其实是一个控制循环每隔一段时间一般30秒左右从metrics-server拉取当前Pod的指标然后拿实际利用率和目标利用率做比较用下面这个公式计算期望副本数期望副本数 ceil(当前副本数 x (当前指标值 / 目标指标值))我用具体数字解释一下当前有2个Pod每个Pod的CPU使用率是90%目标利用率是60%那么期望副本数就是ceil(2 x (90 / 60)) ceil(3) 3。HPA会立刻把副本数调到3。如果指标变成一直120%期望副本数就是ceil(2 x 2) 4。如果当前指标低于目标值它还会按同样的公式缩容只是受缩容稳定窗口限制不会因为一两分钟的抖动就疯狂地一缩一扩。这里有个关键的“机制陷阱”需要提醒averageUtilization是基于requests来计算的不是基于Pod的真实核数。比如一个Pod的cpu request配了500m即使这个Pod跑到1000m指标也是200%。所以建议把HPA的评估目标直接与requests关联比如request设250m目标利用率设70%这样你就知道核心CPU最多用不到200m上下整机的压力是可预估的。4.3 压测现场从2个Pod一路顶到8个Pod配置说完直接看实操。我用部署在集群外的压测机向Ingress发起并发请求工具是abApache Bench虽然简单但看趋势已经足够ab -n 100000 -c 200 http://mall.example.com/order-service/api/order/list刚开始HPA还未介入order-service只有2个Podab一压Kubernetes Dashboard里立刻能看到CPU使用率飙升到接近250%HPA控制器在30秒内触发扩容Pod数量从2变为4再过了大约两分钟变为8CPU利用率被拉回到60%左右。整个压测过程用kubectl命令观察得清清楚楚kubectl get hpa -n mall -w # NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE # order-service-hpa Deployment/order-service 90%/60% 2 8 2 15h # order-service-hpa Deployment/order-service 130%/60% 2 8 4 15h # order-service-hpa Deployment/order-service 75%/60% 2 8 6 15h # order-service-hpa Deployment/order-service 60%/60% 2 8 8 15h压测结束后我没有马上看到缩容这是正常的因为我在HPA里把scaleDown的稳定窗口设成了300秒。设计上这是刻意为之缩容太重会引发“抖动”流量一小就缩下一次流量一来又得重新创建PodPod创建到Ready最少几十秒期间的请求全部超时。稳定窗口相当于一个阻尼器逼着系统观测一段时间再决定要不要缩。要加深对HPA的理解最好把这些参数整理成一张表放在手里参数作用建议值averageUtilization目标平均CPU利用率60%-70%比较合理stabilizationWindowSeconds缩容缩容前的观察等待期300秒起步minReplicas最低副本数至少2避免单点maxReplicas最大副本数根据峰值流量评估不是越大越好评估周期HPA默认评估间隔默认15秒左右不需要改4.4 使用Helm把服务部署做成标准化交付到了Helm这里整个交付流程就算打通了。我的做法是每个服务建一个Chart目录把Kubernetes清单作为模板放进去order-service/ ├── Chart.yaml ├── values.yaml ├── values-dev.yaml ├── values-prod.yaml └── templates/ ├── deployment.yaml ├── service.yaml ├── ingress.yaml ├── hpa.yaml └── _helpers.tplChart.yaml元信息apiVersion: v2 name: order-service description: A Helm chart for order service of mall type: application version: 0.1.0 appVersion: 1.4.0values.yaml的核心参数replicaCount: 2 image: repository: harbor.example.com/mall/order-service tag: 1.4.0 pullPolicy: IfNotPresent service: type: ClusterIP port: 80 targetPort: 8080 ingress: enabled: true className: traefik host: mall.example.com path: /order-service(/|$)(.*) resources: requests: cpu: 250m memory: 512Mi limits: cpu: 1 memory: 768Mi hpa: enabled: true minReplicas: 2 maxReplicas: 8 targetCPUUtilizationPercentage: 60模板文件里面通过{{ .Values.xxx }}引用这些字段部署时指定不同环境values文件helm upgrade --install order-service ./order-service -n mall -f values-dev.yaml helm upgrade --install order-service ./order-service -n mall -f values-prod.yaml我极力建议团队统一用helm upgrade --install来发布不要先helm install再分步改。这样每一次发布都会生成一个版本记录出问题可以一秒回滚到上一个版本helm history order-service -n mall helm rollback order-service 3 -n mall这里有一个从我实际项目里带出来的经验不要把密码、数据库连接串写进values.yaml哪怕你只是放在私有Git仓库。正确做法是把Secret存到Vault或者外部Secrets Operator让Helm只管部署编排。否则一旦Chart泄露等于把整个环境的钥匙交出去了。5. 常见问题与排查技巧实录5.1 镜像拉取失败与CreateContainerConfigError镜像拉取失败是Kubernetes新手遇到最多的拦路虎常见报错有两种ImagePullBackOff和ErrImagePull。排查思路先看事件kubectl describe pod order-service-xxxxx -n mall如果事件里出现“pull access denied”说明镜像不存在或权限不对。我在实践里吃过一个暗亏镜像的Tag用latest本地Docker明明有这个镜像但k3s的containerd还是去远程仓库拉由于私有仓库地址配置略有问题一直超时。从那以后我就不再使用latest而是把版本号写死既保证可复现也避免上面的策略误会。CreateContainerConfigError则说明Pod启动前的配置解析失败了最常见的根源是ConfigMap里缺少某个key或者Secret引用的键不存在。遇到这类报错优先执行kubectl get configmap、kubectl describe secret检查不要一上来就怀疑代码。5.2 就绪探针配置不当导致滚动更新卡死这是我踩过最隐蔽的坑readinessProbe配置了/actuator/health/readiness但SpringBoot 2.3之前这个端点默认不暴露返回404新Pod始终不Ready滚动更新就卡在Waiting旧Pod被maxUnavailable0锁住不能删整个发布流程直接停滞。解决方案是确保有暴露相关endpoint的依赖和配置。再提醒一点readiness和liveness千万别共用同一个接口否则当应用因为依赖的数据库不可用而失去就绪状态时liveness也会跟着失败Kubernetes会认为Pod不健康并把它重启造成服务反复重启但一直起不来的假象。正确做法是readiness检查依赖项liveness只检查进程是否活着。5.3 HPA拿不到指标TARGETS一直显示UnavailableHPA配置完成后如果kubectl get hpa里TARGETS列显示Unavailable大概率不是HPA自身的问题而是metrics-server没有正常工作。先看metrics-server的Pod日志kubectl logs -n kube-system deployment/metrics-server常见原因包括证书未适配导致Kubelet拒绝连接或者metrics-server缺了kubelet-preferred-address-types参数。在自签证书环境下需要给metrics-server增加--kubelet-insecure-tls参数。另外Pods的requests没有配置或者所有请求为0也会导致计算不出利用率所以配置HPA前先确认kubectl top pods有数据。5.4 弹性伸缩目标设置太高或太低怎么权衡把HPA目标设成90%意味着Pod要快跑满了才会扩容好处是省机器坏处是延迟会飙升因为CPU到达90%的时候请求已经在排队了。把目标设成30%倒是反应快但机器成本可能翻好几倍。我给绝大多数无状态SpringBoot服务推荐60%-70%这个区间理由是大部分服务对延迟的敏感度都在这个范围内能找到平衡点给流量波峰预留了40%空间又不至于让机器闲置。缩容稳定窗口也别拍脑袋设。我这里有个经验公式如果你的服务启动到Ready需要40秒那么缩容稳定窗口至少应该大于这个时间的两倍否则缩下来的Pod还没走完回调又重建永远是无效缩容。压测后我特意把300秒稳定窗口保留实测流量撤掉后约5分钟才缩到2个副本刚好符合预期。5.5 团队协作里最容易被忽略的版本与配置管理问题Helm虽然帮你解决了资源编排的版本管理但实际交付链路里还有一个容易被忽略的环节镜像Tag和Chart版本怎么联动。我的建议是把镜像Tag写死在values-prod.yaml里每次发布前先更新appVersion和image.tag提交后走CI/CD流水线Helm Chart本身也打标签归档。千万别在服务器上手动改values.yaml否则很容易出现“环境里跑着的镜像和Git仓库里记录的对不上”的灾难。这一套组合拳打下来我最大的收获倒不是学会了几个命令而是建立了一种从“代码到运行平台”的全局视角SpringBoot决定了我能提供什么服务Kubernetes决定了我能怎样调度和管理这些服务Helm则在中间充当了胶水把发布流程固化下来。以后不管服务数量怎么涨我只要往Chart里加模板、往values里加参数就能在相同规则下无限复制。哪怕你暂时只有一两个SpringBoot服务我也建议试试这套链路因为把基础设施当作代码来管省下的是未来每一次发布时的焦虑。