2026/9/14 1:34:36
FEATURED · 精选文章 
简介这套实战资料面向需要系统掌握Kubernetes容器编排与微服务部署的运维、云计算工程师围绕k8s 1.13.3版本在电商微服务场景下的落地展开提供从镜像打包、Java环境配置到Ingress接入的完整链路。包体共6个文件包含tar与gz格式的JDK、Maven、Nginx Ingress Controller等镜像安装包yaml编排文件以及docx格式的部署文档笔记压缩包约950.8MB。已有222人学习下载内容按实际部署顺序组织非常适合作为生产环境前的模拟练习案例。文档详细记录了基于simple-microservice的电商应用部署细节、mandatory原版配置用法与版本兼容性注意事项读者可参照笔记逐步复现一套可运行的电商微服务集群理解镜像导入、环境变量配置与Ingress流量接入等关键操作。同时打包齐全的基础组件省去另找安装包的麻烦配套笔记让部署过程有据可依适合边学边练快速积累Kubernetes实战经验。1. 为什么是k8s 1.13.3电商微服务稳定优先把 K8s 版本锁在 1.13.3不是因为它新而是因为它旧得刚刚好。这个版本没有后来频繁的 API 组迁移和运行时变更很多电商系统在生产环境一跑就是两三年稳定压倒一切。用 k8s 1.13.3 部署电商微服务你需要关心的不是新特性而是如何把注册中心、配置中心、消息队列和业务服务合理地放进同一个集群。这篇记录从安装包整理到微服务上线的完整路径适合手里有内网机器、想复现一套电商微服务案例的运维或开发。2. 集群与资源规划先给 k8s 1.13.3 一个能跑微服务的底座2.1 硬件与操作系统选型别让 Master 成为瓶颈电商微服务至少包含用户、商品、订单、支付和网关五个应用再加上 MySQL、Redis、Nacos、RabbitMQ 这些中间件一台机器根本扛不住。我习惯准备 1 台 Master 和 3 台 Node硬件规格如下表。节点角色CPU内存系统盘数据盘用途Master4 核8 GB100 GB SSD无需etcd、kube-apiserver、schedulerNode18 核16 GB100 GB SSD200 GB SSD业务 Pod 与部分中间件Node28 核16 GB100 GB SSD200 GB SSD业务 Pod 与部分中间件Node34 核8 GB80 GB SSD100 GB SSDNacos、RabbitMQ 等有状态服务操作系统建议 CentOS 7.6 或 Ubuntu 18.04内核版本至少 3.10。安装前必须关闭交换分区否则 kubelet 在内存压力下会拒绝调度 Pod表现为节点反复 NotReady。此外 etcd 对磁盘 IO 很敏感Master 千万不要用机械盘否则 etcd 的 fsync 延迟会拖垮整个集群的写入性能。2.2 安装包与离线镜像整理从 bin 到 images 的固定套路标题里的“安装包”并不是指某个现成的压缩包而是把 kubeadm、kubelet、kubectl 三个二进制和对应镜像按照固定的目录结构整理好。1.13.3 的三个二进制版本必须完全一致镜像版本也要锁定。我的习惯是k8s-1.13.3-installer/ ├── bin/ │ ├── kubeadm │ ├── kubelet │ └── kubectl ├── images/ │ ├── kube-apiserver-v1.13.3.tar │ ├── kube-controller-manager-v1.13.3.tar │ ├── kube-scheduler-v1.13.3.tar │ ├── kube-proxy-v1.13.3.tar │ ├── pause-3.1.tar │ ├── etcd-3.2.24.tar │ └── coredns-1.2.6.tar └── yaml/ └── kubeadm-init.yaml内网环境用docker save把镜像导出再在目标机器上docker load。注意 1.13.3 的 pause 镜像版本是 3.1etcd 是 3.2.24这两个版本号是强绑定关系随意替换会导致 kubelet 启动后反复 crash。整理好目录后第一时间用md5sum生成校验文件防止内网拷贝造成文件损坏。2.3 命名空间与节点标签划分电商微服务的调度边界把中间件和业务服务混在 default 命名空间里是一种短期省事、长期痛苦的写法。我先创建两个命名空间再给节点打上调度标签。kubectl create namespace middleware kubectl create namespace mall kubectl label nodes node1 middlewaretrue kubectl label nodes node2 middlewaretrue kubectl label nodes node3 apptrue这样中间件只会调度到 node1 和 node2业务服务只会调度到 node3。1.13.3 的调度器还没有后来版本中完善拓扑分布约束用 nodeSelector 是最直接可用的方案。另外命名空间隔离也方便配合 Kubernetes 的 RBAC后续给不同团队分配权限时不需要重新划分整个集群。2.4 网络组件与网段规划flannel 和 calico 怎么选1.13.3 里网络插件通常二选一flannel 和 calico。如果电商微服务规模不大且没有 NetworkPolicy 需求flannel 的 VXLAN 模式最省心如果以后要做多租户隔离或网络策略一开始就装 calico省得后面迁移。kubeadm 初始化时要把 Pod 网段和 Service 网段规划好# kubeadm-init.yaml apiVersion: kubeadm.k8s.io/v1beta1 kind: ClusterConfiguration networking: podSubnet: 10.244.0.0/16 serviceSubnet: 10.96.0.0/12这里的podSubnet要与 flannel 的配置保持一致flannel 默认使用 10.244.0.0/16。Service 网段建议避开公司内网段和 Pod 网段否则会出现访问冲突最常见的问题是 DNS 解析到错误的地址。初始化命令为kubeadm init --configkubeadm-init.yaml初始化完成后 kubelet 才能正常启动。3. 在 K8s 1.13.3 部署电商微服务公共依赖MySQL、Nacos、Redis、RabbitMQ3.1 MySQL用 StatefulSet 固定数据和网络身份MySQL 是有状态服务不能像无状态 Pod 一样动不动重建。1.13.3 上部署 MySQL 首选 StatefulSet因为它能保证 Pod 名称和网络标识稳定且每个副本有独立的 PVC。下面是一个简化但可用的 StatefulSetapiVersion: apps/v1 kind: StatefulSet metadata: name: mysql namespace: middleware spec: serviceName: mysql replicas: 1 selector: matchLabels: app: mysql template: metadata: labels: app: mysql spec: nodeSelector: middleware: true containers: - name: mysql image: mysql:5.7 ports: - containerPort: 3306 env: - name: MYSQL_ROOT_PASSWORD valueFrom: secretKeyRef: name: mysql-secret key: root-password volumeMounts: - name: data mountPath: /var/lib/mysql volumes: - name: data hostPath: path: /data/mysql type: DirectoryOrCreate注意 1.13.3 中 StatefulSet 的 API 版本是apps/v1不是更早的apps/v1beta1。这里用 hostPath 是为了演示生产环境建议先创建 Local PV 再绑定。hostPath 的path如果不存在DirectoryOrCreate会帮你创建但权限要提前处理好否则 MySQL 会因为没有写权限而启动失败。提示如果 MySQL 需要对外提供管理访问可以额外创建一个独立 Service类型为 NodePort避免直接暴露 3306 端口给集群外。3.2 Nacos注册中心必须让业务稳定地找到它电商微服务的服务发现我用 Nacos 的场景远多于 Eureka因为 Nacos 同时承担配置中心。在 1.13.3 上Nacos 可以直接使用 Deployment 加 ServiceapiVersion: apps/v1 kind: Deployment metadata: name: nacos namespace: middleware spec: replicas: 1 selector: matchLabels: app: nacos template: metadata: labels: app: nacos spec: nodeSelector: middleware: true containers: - name: nacos image: nacos/nacos-server:v2.2.0 env: - name: MODE value: standalone - name: NACOS_SERVER_IP valueFrom: fieldRef: fieldPath: status.podIP ports: - containerPort: 8848 - containerPort: 9848这里用MODEstandalone是为了在资源有限时快速跑通案例。如果要做高可用需要把 replicas 设为 3并配置NACOS_SERVERS指向彼此。Nacos 2.x 的 gRPC 端口 9848 必须暴露在 Service 里否则 Spring Cloud 服务在注册后会因为无法建立 gRPC 连接而频繁报错。对应 Service 定义apiVersion: v1 kind: Service metadata: name: nacos namespace: middleware spec: selector: app: nacos ports: - name: http port: 8848 targetPort: 8848 - name: grpc port: 9848 targetPort: 9848 type: ClusterIP业务服务注册时地址写nacos.middleware.svc.cluster.local:8848即可不需要关心 Nacos Pod 的 IP 变化。这样微服务架构图中的注册中心节点才真正稳定。3.3 Redis 与 RabbitMQ削峰填谷的最小却完整的部署Redis 和 MQ 是电商在大促时兜底的关键但在部署案例里不需要一开始就上集群。我会用 Deployment 快速跑起来先保证功能链路完整。Redis 的命令kubectl run redis --imageredis:5.0 --replicas1 --port6379 -n middleware这样创建的 Deployment 默认不会持久化数据。如果只是演示可以接受但为了笔记里能说明白持久化问题我一般会补一条 PVC 挂载。RabbitMQ 用管理镜像kubectl run rabbitmq --imagerabbitmq:3.8-management --port5672 --port15672 -n middleware然后手动创建一个 Service把 15672 暴露为 NodePort方便在浏览器里看队列积压情况。RabbitMQ 的数据目录默认在容器内应用重启就丢失所以这个方案只适合“先跑通”阶段。真正上线前需要换成 StatefulSet 并配置 PVC。3.4 私有镜像仓库与 imagePullSecret微服务镜像的交付前提电商微服务的镜像不能都放在 Docker Hub内网需要一套私有仓库。常见做法是部署 Harbor也可以直接用带 TLS 的 Docker Registry。镜像上传完成后K8s 节点拉取私有镜像需要认证。kubectl create secret docker-registry registry-secret \ --docker-serverregistry.internal \ --docker-usernameadmin \ --docker-passwordyour-password \ -n mall在业务 Deployment 里通过imagePullSecrets引用spec: imagePullSecrets: - name: registry-secret这里很容易踩坑如果业务服务在多个命名空间每个命名空间都要单独创建一份 Secret因为 K8s 的 Secret 默认只属于单个命名空间。没有这个配置Pod 状态会一直卡在ImagePullBackOff日志里的错误是unauthorized: authentication required。4. 电商微服务编排从 Deployment、Service 到 Ingress 的实战参数4.1 微服务核心清单资源配额、探针和 Nacos 连接配置电商微服务中的每个应用都需要一份规范的 Deployment。以下单服务为例apiVersion: apps/v1 kind: Deployment metadata: name: order-service namespace: mall labels: app: order-service spec: replicas: 2 selector: matchLabels: app: order-service template: metadata: labels: app: order-service spec: nodeSelector: app: true containers: - name: order-service image: registry.internal/mall/order-service:1.3.3 imagePullPolicy: IfNotPresent ports: - containerPort: 8080 resources: requests: cpu: 200m memory: 512Mi limits: cpu: 1 memory: 1Gi env: - name: SPRING_PROFILES_ACTIVE value: k8s - name: NACOS_ADDR value: nacos.middleware.svc.cluster.local:8848 readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 20 periodSeconds: 10 timeoutSeconds: 3 livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 initialDelaySeconds: 30 periodSeconds: 20initialDelaySeconds必须大于 Spring Boot 的完整启动时间否则容器刚启动还在初始化探针就开始探测连续失败几次就会被 kubelet 杀死进入CrashLoopBackOff。requests和limits的差距不要太大这里设置 requests 200m CPU、limits 1 CPU是为了让 HPA 在流量上涨时有扩容空间。另外如果整合了 knife4j 做 API 文档实际上只需要确保网关服务能访问到订单服务的/v3/api-docs路径即可。Knife4j 在 K8s 环境里最常见的坑是文档地址写死了本机 localhost导致网关聚合文档时拿到错误地址。解决办法是在 Nacos 配置中注册实例时显式指定ip为 Pod IP不要依赖自动探测。4.2 Service 与 Ingress网关如何暴露给外部调用内部服务之间使用 ClusterIP 足够但外部请求必须经过网关。网关的 Service 类型可以选择 NodePort然后再由 Ingress 根据域名和路径转发apiVersion: v1 kind: Service metadata: name: gateway-service namespace: mall spec: selector: app: gateway-service ports: - name: http port: 8080 targetPort: 8080 type: NodePort nodePort: 30880Ingress 配置apiVersion: extensions/v1beta1 kind: Ingress metadata: name: mall-gateway namespace: mall annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: mall.example.com http: paths: - path: /api backend: serviceName: gateway-service servicePort: 80801.13.3 中 Ingress 的 API 版本是extensions/v1beta1如果拿到新版本的 YAML 直接 apply 会报no matches for kind Ingress。注意rewrite-target注释如果你希望访问https://mall.example.com/api/order时实际转发到网关的/order就需要这个重写规则。网关内部再通过 Nacos 找到具体服务这样整条链路就是客户端 → Ingress → 网关 → 微服务。4.3 优雅上下线与配置热更新大促前必须做的两件事发版时如果直接删 Pod正在处理的订单请求会瞬间失败。K8s 默认发送 SIGTERM但 Spring Boot 需要时间完成事务和连接池清理。在容器里加 preStop 钩子lifecycle: preStop: exec: command: [/bin/sh, -c, sleep 10]这个等待时间最好与 readinessProbe 的periodSeconds配合。我的习惯是 readiness 每 10 秒探测一次preStop 睡眠 10 秒这样可以保证在 Endpoint 更新后流入旧 Pod 的流量完全耗尽。配置热更新方面不建议把应用配置写死在镜像里。用 ConfigMap 挂载配置文件修改 ConfigMap 后可以通过kubectl rollout restart deployment/order-service -n mall让 Pod 重新加载。1.13.3 还不支持kubectl set env直接触发生成新 ReplicaSet所以最稳妥的方式就是 rollout restart。4.4 用 HPA 应对流量峰值autoscaling/v1 在 1.13.3 的边界电商大促时流量是平时的几十倍提前扩容不如自动扩容。1.13.3 的 HPA 只支持autoscaling/v1也就是只有 CPU 指标不包含自定义指标。创建一个基于 CPU 的 HPAapiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: order-service-hpa namespace: mall spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: order-service minReplicas: 2 maxReplicas: 10 targetCPUUtilizationPercentage: 60这里 targetCPUUtilizationPercentage 指的是所有 Pod 的平均 CPU 使用率。如果订单服务的单个 Pod 在 200m requests 下已经跑满HPA 会自动增加副本数。但注意 1.13.3 无法根据 QPS 或消息队列积压量扩容只能依赖 CPU。如果业务对响应时间敏感建议把 requests 设低一点让 HPA 有更充裕的扩容空间。提示HPA 扩容不是瞬时的默认每 30 秒评估一次新 Pod 拉起还需要镜像拉取和启动时间。大促前可以先手动把 minReplicas 调高降低冷启动风险。5. 部署后的验证与笔记整理k8s 1.13.3 案例可复制的关键5.1 安装包版本锁定与校验文件案例部署完成第一件事就是把安装包目录重新固化。把二进制文件名带上版本号避免以后多个版本混在一起。然后生成校验文件cd k8s-1.13.3-installer find . -type f -exec md5sum {} \; checksum.md5checksum.md5可以交给所有后续接触这套环境的人。每次更新二进制或镜像后重新生成一遍并在 docs/change-log.md 里记录变更原因。这样即便过去半年再回来看也能快速确认当时部署的精确版本组合。5.2 导出运行时 YAML 并与原始清单做 diff部署完不要只保留 src 目录下的 YAML。K8s 会为资源补充很多默认字段只有导出运行时的 YAML才能反映系统真实状态kubectl get deploy order-service -n mall -o yaml deployed/order-service.deployed.yaml kubectl get statefulset mysql -n middleware -o yaml deployed/mysql.deployed.yaml kubectl get hpa order-service-hpa -n mall -o yaml deployed/order-service-hpa.deployed.yaml导出后与原始清单做 diff能发现很多隐蔽问题比如镜像 tag 被替换、副本数被 HPA 修改、默认添加了revisionHistoryLimit等。把 diff 的关键行写进 notes.md这就是最有价值的排错笔记。5.3 一条命令定位“服务注册不上 Nacos”问题最后留一个压箱底的检查手段。电商微服务最常见的故障是“服务已经启动但 Nacos 控制台看不到实例”。不要急着翻业务日志先检查网络kubectl exec -it order-service-xxx -n mall -- /bin/sh \ -c telnet nacos.middleware.svc.cluster.local 8848如果 telnet 不通再检查 Service 的 Endpointskubectl get endpoints nacos -n middlewareEndpoints 列表为空说明 Service 的 selector 和 Pod 标签不匹配列表有 IP 但 telnet 不通则需要检查网络插件或安全组规则。这个排查顺序比直接看应用日志快得多因为“注册不上”八成是网络问题而不是代码问题。把这组命令连同典型输出写进笔记最前面下次遇到同类故障时30 秒就能定位到根因。本文还有配套的精品资源点击获取
K8s 1.13.3部署电商微服务：从安装包到上线的完整实践
简介这套实战资料面向需要系统掌握Kubernetes容器编排与微服务部署的运维、云计算工程师围绕k8s 1.13.3版本在电商微服务场景下的落地展开提供从镜像打包、Java环境配置到Ingress接入的完整链路。包体共6个文件包含tar与gz格式的JDK、Maven、Nginx Ingress Controller等镜像安装包yaml编排文件以及docx格式的部署文档笔记压缩包约950.8MB。已有222人学习下载内容按实际部署顺序组织非常适合作为生产环境前的模拟练习案例。文档详细记录了基于simple-microservice的电商应用部署细节、mandatory原版配置用法与版本兼容性注意事项读者可参照笔记逐步复现一套可运行的电商微服务集群理解镜像导入、环境变量配置与Ingress流量接入等关键操作。同时打包齐全的基础组件省去另找安装包的麻烦配套笔记让部署过程有据可依适合边学边练快速积累Kubernetes实战经验。1. 为什么是k8s 1.13.3电商微服务稳定优先把 K8s 版本锁在 1.13.3不是因为它新而是因为它旧得刚刚好。这个版本没有后来频繁的 API 组迁移和运行时变更很多电商系统在生产环境一跑就是两三年稳定压倒一切。用 k8s 1.13.3 部署电商微服务你需要关心的不是新特性而是如何把注册中心、配置中心、消息队列和业务服务合理地放进同一个集群。这篇记录从安装包整理到微服务上线的完整路径适合手里有内网机器、想复现一套电商微服务案例的运维或开发。2. 集群与资源规划先给 k8s 1.13.3 一个能跑微服务的底座2.1 硬件与操作系统选型别让 Master 成为瓶颈电商微服务至少包含用户、商品、订单、支付和网关五个应用再加上 MySQL、Redis、Nacos、RabbitMQ 这些中间件一台机器根本扛不住。我习惯准备 1 台 Master 和 3 台 Node硬件规格如下表。节点角色CPU内存系统盘数据盘用途Master4 核8 GB100 GB SSD无需etcd、kube-apiserver、schedulerNode18 核16 GB100 GB SSD200 GB SSD业务 Pod 与部分中间件Node28 核16 GB100 GB SSD200 GB SSD业务 Pod 与部分中间件Node34 核8 GB80 GB SSD100 GB SSDNacos、RabbitMQ 等有状态服务操作系统建议 CentOS 7.6 或 Ubuntu 18.04内核版本至少 3.10。安装前必须关闭交换分区否则 kubelet 在内存压力下会拒绝调度 Pod表现为节点反复 NotReady。此外 etcd 对磁盘 IO 很敏感Master 千万不要用机械盘否则 etcd 的 fsync 延迟会拖垮整个集群的写入性能。2.2 安装包与离线镜像整理从 bin 到 images 的固定套路标题里的“安装包”并不是指某个现成的压缩包而是把 kubeadm、kubelet、kubectl 三个二进制和对应镜像按照固定的目录结构整理好。1.13.3 的三个二进制版本必须完全一致镜像版本也要锁定。我的习惯是k8s-1.13.3-installer/ ├── bin/ │ ├── kubeadm │ ├── kubelet │ └── kubectl ├── images/ │ ├── kube-apiserver-v1.13.3.tar │ ├── kube-controller-manager-v1.13.3.tar │ ├── kube-scheduler-v1.13.3.tar │ ├── kube-proxy-v1.13.3.tar │ ├── pause-3.1.tar │ ├── etcd-3.2.24.tar │ └── coredns-1.2.6.tar └── yaml/ └── kubeadm-init.yaml内网环境用docker save把镜像导出再在目标机器上docker load。注意 1.13.3 的 pause 镜像版本是 3.1etcd 是 3.2.24这两个版本号是强绑定关系随意替换会导致 kubelet 启动后反复 crash。整理好目录后第一时间用md5sum生成校验文件防止内网拷贝造成文件损坏。2.3 命名空间与节点标签划分电商微服务的调度边界把中间件和业务服务混在 default 命名空间里是一种短期省事、长期痛苦的写法。我先创建两个命名空间再给节点打上调度标签。kubectl create namespace middleware kubectl create namespace mall kubectl label nodes node1 middlewaretrue kubectl label nodes node2 middlewaretrue kubectl label nodes node3 apptrue这样中间件只会调度到 node1 和 node2业务服务只会调度到 node3。1.13.3 的调度器还没有后来版本中完善拓扑分布约束用 nodeSelector 是最直接可用的方案。另外命名空间隔离也方便配合 Kubernetes 的 RBAC后续给不同团队分配权限时不需要重新划分整个集群。2.4 网络组件与网段规划flannel 和 calico 怎么选1.13.3 里网络插件通常二选一flannel 和 calico。如果电商微服务规模不大且没有 NetworkPolicy 需求flannel 的 VXLAN 模式最省心如果以后要做多租户隔离或网络策略一开始就装 calico省得后面迁移。kubeadm 初始化时要把 Pod 网段和 Service 网段规划好# kubeadm-init.yaml apiVersion: kubeadm.k8s.io/v1beta1 kind: ClusterConfiguration networking: podSubnet: 10.244.0.0/16 serviceSubnet: 10.96.0.0/12这里的podSubnet要与 flannel 的配置保持一致flannel 默认使用 10.244.0.0/16。Service 网段建议避开公司内网段和 Pod 网段否则会出现访问冲突最常见的问题是 DNS 解析到错误的地址。初始化命令为kubeadm init --configkubeadm-init.yaml初始化完成后 kubelet 才能正常启动。3. 在 K8s 1.13.3 部署电商微服务公共依赖MySQL、Nacos、Redis、RabbitMQ3.1 MySQL用 StatefulSet 固定数据和网络身份MySQL 是有状态服务不能像无状态 Pod 一样动不动重建。1.13.3 上部署 MySQL 首选 StatefulSet因为它能保证 Pod 名称和网络标识稳定且每个副本有独立的 PVC。下面是一个简化但可用的 StatefulSetapiVersion: apps/v1 kind: StatefulSet metadata: name: mysql namespace: middleware spec: serviceName: mysql replicas: 1 selector: matchLabels: app: mysql template: metadata: labels: app: mysql spec: nodeSelector: middleware: true containers: - name: mysql image: mysql:5.7 ports: - containerPort: 3306 env: - name: MYSQL_ROOT_PASSWORD valueFrom: secretKeyRef: name: mysql-secret key: root-password volumeMounts: - name: data mountPath: /var/lib/mysql volumes: - name: data hostPath: path: /data/mysql type: DirectoryOrCreate注意 1.13.3 中 StatefulSet 的 API 版本是apps/v1不是更早的apps/v1beta1。这里用 hostPath 是为了演示生产环境建议先创建 Local PV 再绑定。hostPath 的path如果不存在DirectoryOrCreate会帮你创建但权限要提前处理好否则 MySQL 会因为没有写权限而启动失败。提示如果 MySQL 需要对外提供管理访问可以额外创建一个独立 Service类型为 NodePort避免直接暴露 3306 端口给集群外。3.2 Nacos注册中心必须让业务稳定地找到它电商微服务的服务发现我用 Nacos 的场景远多于 Eureka因为 Nacos 同时承担配置中心。在 1.13.3 上Nacos 可以直接使用 Deployment 加 ServiceapiVersion: apps/v1 kind: Deployment metadata: name: nacos namespace: middleware spec: replicas: 1 selector: matchLabels: app: nacos template: metadata: labels: app: nacos spec: nodeSelector: middleware: true containers: - name: nacos image: nacos/nacos-server:v2.2.0 env: - name: MODE value: standalone - name: NACOS_SERVER_IP valueFrom: fieldRef: fieldPath: status.podIP ports: - containerPort: 8848 - containerPort: 9848这里用MODEstandalone是为了在资源有限时快速跑通案例。如果要做高可用需要把 replicas 设为 3并配置NACOS_SERVERS指向彼此。Nacos 2.x 的 gRPC 端口 9848 必须暴露在 Service 里否则 Spring Cloud 服务在注册后会因为无法建立 gRPC 连接而频繁报错。对应 Service 定义apiVersion: v1 kind: Service metadata: name: nacos namespace: middleware spec: selector: app: nacos ports: - name: http port: 8848 targetPort: 8848 - name: grpc port: 9848 targetPort: 9848 type: ClusterIP业务服务注册时地址写nacos.middleware.svc.cluster.local:8848即可不需要关心 Nacos Pod 的 IP 变化。这样微服务架构图中的注册中心节点才真正稳定。3.3 Redis 与 RabbitMQ削峰填谷的最小却完整的部署Redis 和 MQ 是电商在大促时兜底的关键但在部署案例里不需要一开始就上集群。我会用 Deployment 快速跑起来先保证功能链路完整。Redis 的命令kubectl run redis --imageredis:5.0 --replicas1 --port6379 -n middleware这样创建的 Deployment 默认不会持久化数据。如果只是演示可以接受但为了笔记里能说明白持久化问题我一般会补一条 PVC 挂载。RabbitMQ 用管理镜像kubectl run rabbitmq --imagerabbitmq:3.8-management --port5672 --port15672 -n middleware然后手动创建一个 Service把 15672 暴露为 NodePort方便在浏览器里看队列积压情况。RabbitMQ 的数据目录默认在容器内应用重启就丢失所以这个方案只适合“先跑通”阶段。真正上线前需要换成 StatefulSet 并配置 PVC。3.4 私有镜像仓库与 imagePullSecret微服务镜像的交付前提电商微服务的镜像不能都放在 Docker Hub内网需要一套私有仓库。常见做法是部署 Harbor也可以直接用带 TLS 的 Docker Registry。镜像上传完成后K8s 节点拉取私有镜像需要认证。kubectl create secret docker-registry registry-secret \ --docker-serverregistry.internal \ --docker-usernameadmin \ --docker-passwordyour-password \ -n mall在业务 Deployment 里通过imagePullSecrets引用spec: imagePullSecrets: - name: registry-secret这里很容易踩坑如果业务服务在多个命名空间每个命名空间都要单独创建一份 Secret因为 K8s 的 Secret 默认只属于单个命名空间。没有这个配置Pod 状态会一直卡在ImagePullBackOff日志里的错误是unauthorized: authentication required。4. 电商微服务编排从 Deployment、Service 到 Ingress 的实战参数4.1 微服务核心清单资源配额、探针和 Nacos 连接配置电商微服务中的每个应用都需要一份规范的 Deployment。以下单服务为例apiVersion: apps/v1 kind: Deployment metadata: name: order-service namespace: mall labels: app: order-service spec: replicas: 2 selector: matchLabels: app: order-service template: metadata: labels: app: order-service spec: nodeSelector: app: true containers: - name: order-service image: registry.internal/mall/order-service:1.3.3 imagePullPolicy: IfNotPresent ports: - containerPort: 8080 resources: requests: cpu: 200m memory: 512Mi limits: cpu: 1 memory: 1Gi env: - name: SPRING_PROFILES_ACTIVE value: k8s - name: NACOS_ADDR value: nacos.middleware.svc.cluster.local:8848 readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 20 periodSeconds: 10 timeoutSeconds: 3 livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 initialDelaySeconds: 30 periodSeconds: 20initialDelaySeconds必须大于 Spring Boot 的完整启动时间否则容器刚启动还在初始化探针就开始探测连续失败几次就会被 kubelet 杀死进入CrashLoopBackOff。requests和limits的差距不要太大这里设置 requests 200m CPU、limits 1 CPU是为了让 HPA 在流量上涨时有扩容空间。另外如果整合了 knife4j 做 API 文档实际上只需要确保网关服务能访问到订单服务的/v3/api-docs路径即可。Knife4j 在 K8s 环境里最常见的坑是文档地址写死了本机 localhost导致网关聚合文档时拿到错误地址。解决办法是在 Nacos 配置中注册实例时显式指定ip为 Pod IP不要依赖自动探测。4.2 Service 与 Ingress网关如何暴露给外部调用内部服务之间使用 ClusterIP 足够但外部请求必须经过网关。网关的 Service 类型可以选择 NodePort然后再由 Ingress 根据域名和路径转发apiVersion: v1 kind: Service metadata: name: gateway-service namespace: mall spec: selector: app: gateway-service ports: - name: http port: 8080 targetPort: 8080 type: NodePort nodePort: 30880Ingress 配置apiVersion: extensions/v1beta1 kind: Ingress metadata: name: mall-gateway namespace: mall annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: mall.example.com http: paths: - path: /api backend: serviceName: gateway-service servicePort: 80801.13.3 中 Ingress 的 API 版本是extensions/v1beta1如果拿到新版本的 YAML 直接 apply 会报no matches for kind Ingress。注意rewrite-target注释如果你希望访问https://mall.example.com/api/order时实际转发到网关的/order就需要这个重写规则。网关内部再通过 Nacos 找到具体服务这样整条链路就是客户端 → Ingress → 网关 → 微服务。4.3 优雅上下线与配置热更新大促前必须做的两件事发版时如果直接删 Pod正在处理的订单请求会瞬间失败。K8s 默认发送 SIGTERM但 Spring Boot 需要时间完成事务和连接池清理。在容器里加 preStop 钩子lifecycle: preStop: exec: command: [/bin/sh, -c, sleep 10]这个等待时间最好与 readinessProbe 的periodSeconds配合。我的习惯是 readiness 每 10 秒探测一次preStop 睡眠 10 秒这样可以保证在 Endpoint 更新后流入旧 Pod 的流量完全耗尽。配置热更新方面不建议把应用配置写死在镜像里。用 ConfigMap 挂载配置文件修改 ConfigMap 后可以通过kubectl rollout restart deployment/order-service -n mall让 Pod 重新加载。1.13.3 还不支持kubectl set env直接触发生成新 ReplicaSet所以最稳妥的方式就是 rollout restart。4.4 用 HPA 应对流量峰值autoscaling/v1 在 1.13.3 的边界电商大促时流量是平时的几十倍提前扩容不如自动扩容。1.13.3 的 HPA 只支持autoscaling/v1也就是只有 CPU 指标不包含自定义指标。创建一个基于 CPU 的 HPAapiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: order-service-hpa namespace: mall spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: order-service minReplicas: 2 maxReplicas: 10 targetCPUUtilizationPercentage: 60这里 targetCPUUtilizationPercentage 指的是所有 Pod 的平均 CPU 使用率。如果订单服务的单个 Pod 在 200m requests 下已经跑满HPA 会自动增加副本数。但注意 1.13.3 无法根据 QPS 或消息队列积压量扩容只能依赖 CPU。如果业务对响应时间敏感建议把 requests 设低一点让 HPA 有更充裕的扩容空间。提示HPA 扩容不是瞬时的默认每 30 秒评估一次新 Pod 拉起还需要镜像拉取和启动时间。大促前可以先手动把 minReplicas 调高降低冷启动风险。5. 部署后的验证与笔记整理k8s 1.13.3 案例可复制的关键5.1 安装包版本锁定与校验文件案例部署完成第一件事就是把安装包目录重新固化。把二进制文件名带上版本号避免以后多个版本混在一起。然后生成校验文件cd k8s-1.13.3-installer find . -type f -exec md5sum {} \; checksum.md5checksum.md5可以交给所有后续接触这套环境的人。每次更新二进制或镜像后重新生成一遍并在 docs/change-log.md 里记录变更原因。这样即便过去半年再回来看也能快速确认当时部署的精确版本组合。5.2 导出运行时 YAML 并与原始清单做 diff部署完不要只保留 src 目录下的 YAML。K8s 会为资源补充很多默认字段只有导出运行时的 YAML才能反映系统真实状态kubectl get deploy order-service -n mall -o yaml deployed/order-service.deployed.yaml kubectl get statefulset mysql -n middleware -o yaml deployed/mysql.deployed.yaml kubectl get hpa order-service-hpa -n mall -o yaml deployed/order-service-hpa.deployed.yaml导出后与原始清单做 diff能发现很多隐蔽问题比如镜像 tag 被替换、副本数被 HPA 修改、默认添加了revisionHistoryLimit等。把 diff 的关键行写进 notes.md这就是最有价值的排错笔记。5.3 一条命令定位“服务注册不上 Nacos”问题最后留一个压箱底的检查手段。电商微服务最常见的故障是“服务已经启动但 Nacos 控制台看不到实例”。不要急着翻业务日志先检查网络kubectl exec -it order-service-xxx -n mall -- /bin/sh \ -c telnet nacos.middleware.svc.cluster.local 8848如果 telnet 不通再检查 Service 的 Endpointskubectl get endpoints nacos -n middlewareEndpoints 列表为空说明 Service 的 selector 和 Pod 标签不匹配列表有 IP 但 telnet 不通则需要检查网络插件或安全组规则。这个排查顺序比直接看应用日志快得多因为“注册不上”八成是网络问题而不是代码问题。把这组命令连同典型输出写进笔记最前面下次遇到同类故障时30 秒就能定位到根因。本文还有配套的精品资源点击获取 
