简介这份资源面向具备一定容器与 Linux 基础的运维、云计算及后端开发人员聚焦 Kubernetes 1.13.3 环境下电商微服务的落地部署帮助读者打通从集群搭建到微服务上线的完整链路解决理论理解与生产实践脱节的问题。压缩包共 6 个文件约 950.8MB包含 gz、tar 等安装包与镜像归档、一份 yaml 编排清单以及一份 docx 详细文档笔记覆盖 JDK、Maven、微服务镜像与 Nginx Ingress 控制器等关键组件便于按需取用。目前已有 223 人学习下载。资源价值在于提供了一套可复现的电商微服务实战案例文档笔记梳理了部署流程与配置要点yaml 清单给出编排参考安装包与镜像归档省去繁琐的下载准备读者可据此搭建实验环境、理解服务暴露与流量入口配置并对照笔记排查常见问题适合作为 k8s 微服务部署的练手与查阅资料。1. k8s 1.13.3 部署电商微服务一套老版本集群的完整落地路径2019 年前后大量电商团队把 Spring Cloud 微服务往 Kubernetes 上迁而当时生产环境里跑得最稳的版本之一就是 k8s 1.13.3。今天回头看这个版本确实老但它对应的部署思路——二进制包安装、手动签发证书、逐节点配置 kubelet——恰恰是理解 k8s 集群搭建最好的教材。现在很多教程一上来就是 kubeadm 一键拉起出了问题完全不知道从哪查黑匣子一样。这套方案的价值在于每一步你都能看到配置文件、证书、systemd 单元出问题有据可查。它适合两类人一是想彻底搞懂 k8s 集群搭建原理的工程师二是手上还有老版本集群需要维护、扩容、排障的运维。电商微服务场景对集群的要求很具体——订单、商品、库存、支付这些服务要能滚动更新、要能扛住大促流量、要能快速回滚下面就从集群搭建一路讲到微服务怎么跑上去。2. 集群搭建从二进制包到三节点就绪2.1 为什么这套方案选二进制包而不是 kubeadmk8s 1.13.3 这个版本kubeadm 已经可用但生产环境里很多团队仍然选二进制包部署原因有三个。第一kubeadm 把证书、etcd、apiserver 的配置都封装在/etc/kubernetes下定制化困难比如你想把 etcd 单独部署到三台机器上做高可用kubeadm 的默认行为会跟你打架。第二二进制包部署让你对每个组件的启动参数一清二楚电商大促前要调 apiserver 的--max-requests-inflight、kubelet 的--max-pods这些在 kubeadm 里要改配置文件再 reload二进制方案直接改 systemd unit 就行。第三老版本 kubeadm 的证书有效期只有一年到期后集群直接不可用而二进制方案你可以自己控制证书签发周期。常见做法是etcd 用三节点独立部署master 组件apiserver、controller-manager、scheduler在三台 master 上以静态 Pod 或 systemd 方式运行node 上跑 kubelet 和 kube-proxy。下面按这个结构走。2.2 安装包准备与基础环境配置先在三台 master 和三台 node 上做统一的基础配置。关闭 swap、设置内核参数、加载模块这些是 k8s 集群搭建的固定动作。# 关闭 swapk8s 1.13.3 的 kubelet 默认不允许 swap 开启 swapoff -a sed -i /swap/s/^/#/ /etc/fstab # 加载内核模块 cat /etc/modules-load.d/k8s.conf EOF br_netfilter ip_vs ip_vs_rr ip_vs_wrr ip_vs_sh nf_conntrack_ipv4 EOF # 设置内核参数 cat /etc/sysctl.d/k8s.conf EOF net.bridge.bridge-nf-call-ip6tables 1 net.bridge.bridge-nf-call-iptables 1 net.ipv4.ip_forward 1 net.ipv4.tcp_tw_recycle 0 EOF sysctl --system这几条命令里br_netfilter和bridge-nf-call-iptables是让 iptables 能处理桥接流量的关键不设置的话 Service 的 ClusterIP 根本不通。ip_vs系列模块是 kube-proxy 用 ipvs 模式的前提1.13.3 默认还是 iptables 模式但生产环境建议开 ipvs后面会讲怎么切。tcp_tw_recycle必须关掉它在 NAT 环境下会导致连接随机失败这个坑在电商场景里尤其致命——用户下单请求时通时不通排查起来非常费劲。安装包方面需要准备这些kubernetes-server-linux-amd64.tar.gz包含 apiserver、controller-manager、scheduler、kubelet、kube-proxy、kubectl 二进制、etcd-v3.3.x 的二进制包、CFSSL 用于证书签发。把二进制文件解压后放到/usr/local/binetcd 放到/usr/local/etcd。2.3 证书签发与 etcd 集群启动k8s 组件之间全部走 TLS证书这块是新手最容易翻车的地方。用 CFSSL 生成一套证书包括 CA、apiserver、kubelet 客户端、kube-proxy 客户端、etcd 相关证书。# 生成 CA cfssl gencert -initca ca-csr.json | cfssljson -bare ca # 签发 apiserver 证书注意 hosts 字段要包含所有 master IP 和 Service 网段第一个 IP cat apiserver-csr.json EOF { CN: kube-apiserver, hosts: [ 10.0.0.1,10.0.0.2,10.0.0.3, 127.0.0.1, kubernetes,kubernetes.default,kubernetes.default.svc, 10.254.0.1 ], key: {algo: rsa,size: 2048}, names: [{C: CN,ST: Beijing,L: Beijing,O: k8s,OU: System}] } EOF cfssl gencert -caca.pem -ca-keyca-key.pem -configca-config.json -profilekubernetes apiserver-csr.json | cfssljson -bare apiserverhosts字段里的10.254.0.1是 Service 网段的第一个 IPapiserver 证书必须包含它否则集群内部通过 Service 访问 apiserver 会报证书不匹配。这个细节很多教程漏掉导致kubectl get svc在 Pod 里执行时直接 TLS 握手失败。etcd 三节点启动时每个节点用各自的配置文件关键参数是--initial-cluster要列出所有节点--listen-peer-urls和--listen-client-urls要区分开。# etcd 启动命令示例节点1 /usr/local/etcd/etcd \ --name etcd-1 \ --data-dir /var/lib/etcd \ --listen-client-urls https://10.0.0.1:2379 \ --advertise-client-urls https://10.0.0.1:2379 \ --listen-peer-urls https://10.0.0.1:2380 \ --initial-advertise-peer-urls https://10.0.0.1:2380 \ --initial-cluster etcd-1https://10.0.0.1:2380,etcd-2https://10.0.0.2:2380,etcd-3https://10.0.0.3:2380 \ --initial-cluster-token etcd-cluster \ --initial-cluster-state new \ --cert-file/etc/etcd/ssl/etcd.pem \ --key-file/etc/etcd/ssl/etcd-key.pem \ --peer-cert-file/etc/etcd/ssl/etcd.pem \ --peer-key-file/etc/etcd/ssl/etcd-key.pem \ --trusted-ca-file/etc/etcd/ssl/ca.pem \ --peer-trusted-ca-file/etc/etcd/ssl/ca.pem启动后验证ETCDCTL_API3 etcdctl --endpointshttps://10.0.0.1:2379 --cacertca.pem --certetcd.pem --keyetcd-key.pem endpoint health三个节点都返回 healthy 才算过。如果某个节点起不来先看日志里是不是--initial-cluster里的地址写错了或者证书 CN 和--name不匹配。2.4 master 组件与 node 接入apiserver 启动时关键参数包括--etcd-servers、--service-cluster-ip-range、--client-ca-file、--tls-cert-file。controller-manager 和 scheduler 通过--kubeconfig连 apiserver这个 kubeconfig 里用的证书 CN 必须是system:kube-controller-manager和system:kube-scheduler否则 RBAC 会拒绝。node 上 kubelet 启动后需要手动批准 CSR 才能加入集群。1.13.3 里用kubectl get csr看到 Pending 的请求kubectl certificate approve name批准。kube-proxy 建议直接开 ipvs 模式# kube-proxy 配置片段 --proxy-modeipvs --ipvs-schedulerrr --ipvs-min-sync-period5s --ipvs-sync-period30sipvs 模式下Service 的负载均衡由内核直接处理比 iptables 的链式匹配快很多电商场景下几千个 Service 时差距明显。但要注意ipvs 模式需要 node 上加载ip_vs相关模块且kube-proxy启动前要确保ipvsadm已安装否则它会静默回退到 iptables。三台 master 的高可用靠一个 VIP 加 keepalived 实现apiserver 的--advertise-address指向各自 IPkubeconfig 里 server 地址写 VIP。这样任何一个 master 挂了kubectl 和 kubelet 仍然能通过 VIP 访问到存活的 apiserver。3. 电商微服务在 k8s 上的部署编排3.1 微服务拆分与镜像构建策略电商系统典型拆分用户服务、商品服务、订单服务、库存服务、支付服务、网关。每个服务独立镜像、独立 Deployment。镜像构建建议用多阶段构建基础镜像选openjdk:8-jre-alpine这类小体积的减少拉取时间。镜像 tag 不要用latest用 git commit hash 或构建号否则滚动更新时 k8s 无法判断镜像是否变化。# 多阶段构建示例 FROM maven:3.6-jdk-8 AS builder WORKDIR /build COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package -DskipTests FROM openjdk:8-jre-alpine WORKDIR /app COPY --frombuilder /build/target/order-service.jar app.jar EXPOSE 8080 ENTRYPOINT [java,-jar,app.jar]这个 Dockerfile 的关键在于先 copy pom.xml 再 go-offline利用 Docker 层缓存改代码时不用重新下载依赖。电商项目依赖多这一步能省好几分钟。3.2 Deployment 与 Service 的关键参数订单服务的 Deployment 要配 readinessProbe 和 livenessProbereadinessProbe 决定 Pod 什么时候接入流量livenessProbe 决定什么时候重启。电商场景下readinessProbe 的initialDelaySeconds要给够Spring Boot 启动慢设 30 秒比较稳。apiVersion: apps/v1 kind: Deployment metadata: name: order-service spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 selector: matchLabels: app: order-service template: metadata: labels: app: order-service spec: containers: - name: order-service image: registry.internal/order-service:20240101-abc123 ports: - containerPort: 8080 readinessProbe: httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 30 periodSeconds: 10 livenessProbe: httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 60 periodSeconds: 20 resources: requests: memory: 1Gi cpu: 500m limits: memory: 2Gi cpu: 1000mmaxUnavailable: 0配合maxSurge: 1表示滚动更新时先起一个新 Pod就绪后再杀一个旧 Pod全程可用 Pod 数不低于期望值。电商大促期间这个配置能保证更新不断流。resources 的 requests 和 limits 必须设不设的话调度器无法合理分配且 Pod 可能被 OOM kill。Service 用 ClusterIP 给内部服务互调网关用 NodePort 或 LoadBalancer 暴露。1.13.3 里 LoadBalancer 需要云厂商支持自建集群一般用 NodePort 加外部 nginx 转发。apiVersion: v1 kind: Service metadata: name: order-service spec: selector: app: order-service ports: - port: 8080 targetPort: 8080 type: ClusterIP3.3 配置管理与服务发现配置用 ConfigMap 挂载敏感信息用 Secret。Spring Cloud 微服务原来用 Eureka 或 Nacos 做服务发现迁到 k8s 后可以直接用 Service 名做 DNS 解析省掉一个注册中心。但要注意k8s 的 DNS 解析在 Pod 的/etc/resolv.conf里配了search域跨 namespace 访问要写全order-service.prod.svc.cluster.local。apiVersion: v1 kind: ConfigMap metadata: name: order-service-config data: application.yml: | spring: datasource: url: jdbc:mysql://mysql.prod.svc.cluster.local:3306/order redis: host: redis.prod.svc.cluster.localConfigMap 更新后挂载为 volume 的文件会自动更新但环境变量方式注入的不会。Spring Boot 读取配置的时机是启动时所以改完 ConfigMap 要重启 Pod 才生效。这个点经常被忽略改完配置发现没生效排查半天。4. 避坑与排查老版本集群的五个血泪教训4.1 Pod 一直 Pending事件里报 Insufficient cpu现象Deployment 创建后 Pod 卡在 Pendingkubectl describe pod看到Insufficient cpu。原因node 上可分配 CPU 被 requests 占满或者 kubelet 的--max-pods到了上限。解决先kubectl describe node看 Allocated resources如果 requests 接近 capacity要么加 node要么调低 requests。注意 1.13.3 的调度器不考虑 limits只看 requests所以 requests 设太大是常见误用。4.2 Service 能 ping 通但端口不通现象Pod 之间用 Service 名能解析出 ClusterIPping 也通但 curl 端口超时。原因kube-proxy 的 iptables 规则没生效或者 ipvs 模式下ip_vs模块没加载。解决iptables -t nat -L KUBE-SERVICES -n看有没有对应规则ipvs 模式用ipvsadm -Ln看虚拟服务列表。如果规则为空重启 kube-proxy 并检查日志里有没有Failed to load ip_vs之类的报错。4.3 证书过期导致集群不可用现象某天早上所有 kubectl 命令报Unable to connect to the server: x509: certificate has expired。原因apiserver 证书或 kubelet 客户端证书到期。1.13.3 的 kubelet 证书默认不自动轮换。解决重新签发证书并重启对应组件。预防措施是写个脚本每月检查证书有效期openssl x509 -in apiserver.pem -noout -dates。4.4 滚动更新卡住新 Pod 一直不就绪现象kubectl rollout status一直不返回新 Pod 的 readinessProbe 失败。原因readinessProbe 的 path 写错或者initialDelaySeconds太短应用还没启动完就被判定失败。解决先kubectl exec进 Pod 手动 curl 那个 path确认应用真的起来了。Spring Boot 的 actuator health 端点要确保依赖的数据库、Redis 都连上了才返回 UP如果数据库连不上health 会一直 DOWN。4.5 etcd 磁盘慢导致 apiserver 超时现象kubectl 操作偶尔超时apiserver 日志里出现etcdserver: request timed out。原因etcd 对磁盘 IO 敏感如果和别的 IO 密集服务混部fsync 延迟高。解决etcd 用 SSD且--heartbeat-interval和--election-timeout适当调大。电商场景下 etcd 写操作频繁Pod 状态更新、Event 写入磁盘不行整个集群都卡。5. 进阶用 HPA 和自定义指标扛住大促流量集群跑起来只是开始电商真正考验的是流量突增时的弹性。1.13.3 的 HPA 支持 CPU 和内存指标但电商更关心 QPS 和队列长度这就需要 custom metrics。常见做法是部署 Prometheus Adapter把 Prometheus 里的指标通过 custom metrics API 暴露给 HPA。apiVersion: autoscaling/v2beta1 kind: HorizontalPodAutoscaler metadata: name: order-service-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: order-service minReplicas: 3 maxReplicas: 20 metrics: - type: Pods pods: metricName: http_requests_per_second targetAverageValue: 500这个 HPA 表示每个 Pod 每秒处理 500 请求时触发扩容最多扩到 20 个。v2beta1是 1.13.3 支持的版本autoscaling/v2要 1.23 才有。Prometheus Adapter 的配置里要写 rule把 Prometheus 的rate(http_requests_total[1m])映射成http_requests_per_second。验证 HPA 是否生效用kubectl get hpa -w持续观察同时用压测工具打流量。如果 HPA 显示unknown说明 custom metrics API 没通检查kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1能不能返回数据。一个我踩过的坑HPA 扩容后新 Pod 启动慢导致扩容速度跟不上流量上涨速度。后来把initialDelaySeconds调小并在应用启动脚本里加了预热逻辑先把本地缓存加载完再注册到 readiness。这个改动让扩容生效时间从 90 秒降到 30 秒。大促前一定要做全链路压测别等流量来了才发现 HPA 是摆设。希望帮到你。本文还有配套的精品资源点击获取