1. Kubernetes项目部署实战从零到生产级落地作为容器编排领域的事实标准Kubernetesk8s已成为现代应用部署的核心基础设施。我在过去三年主导过二十余次企业级k8s部署发现大多数团队在初次接触时会陷入概念明白但落地困难的困境。本文将分享一个电商系统在k8s上的完整部署过程涵盖集群搭建、应用容器化、服务暴露等关键环节特别会重点讲解生产环境中那些文档里不会写的细节问题。2. 环境准备与集群搭建2.1 基础设施规划对于中小规模部署我推荐使用kubeadm工具搭建集群。以下是经过验证的硬件配置方案节点类型CPU内存磁盘数量备注Master节点4核8GB100GB3生产环境必须奇数个Worker节点8核16GB200GB2根据业务负载动态扩展重要提示所有节点必须禁用swap分区否则kubelet会无法正常启动。通过swapoff -a命令临时关闭并注释掉/etc/fstab中的swap挂载项永久生效。2.2 容器运行时选择虽然Docker仍是常见选择但根据Kubernetes官方建议我们采用containerd作为运行时# 在所有节点安装containerd cat EOF | sudo tee /etc/modules-load.d/containerd.conf overlay br_netfilter EOF sudo modprobe overlay sudo modprobe br_netfilter # 安装containerd sudo apt-get update sudo apt-get install -y containerd sudo mkdir -p /etc/containerd containerd config default | sudo tee /etc/containerd/config.toml sudo systemctl restart containerdcontainerd相比Docker减少了约30%的内存开销特别适合资源受限的环境。但要注意其日志管理方式与Docker不同需要额外配置日志轮转。3. 应用容器化实践3.1 SpringBoot应用Dockerfile优化以典型的Java应用为例这是经过生产验证的多阶段构建方案# 构建阶段 FROM maven:3.8.4-openjdk-17 as builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline COPY src/ ./src/ RUN mvn package -DskipTests # 运行时镜像 FROM eclipse-temurin:17-jre-jammy WORKDIR /app COPY --frombuilder /app/target/*.jar ./app.jar RUN mkdir -p /app/config \ chown -R 1001:0 /app \ chmod -R grw /app USER 1001 EXPOSE 8080 ENTRYPOINT [java,-jar,/app.jar]关键优化点使用非root用户运行UID 1001分离依赖下载与构建阶段加快CI/CD流程精确控制文件权限符合安全合规要求3.2 配置管理方案对比对于配置管理我们评估了三种主流方案方案优点缺点适用场景ConfigMap原生支持简单易用修改需要重启Pod非敏感配置变更不频繁Secret支持base64编码实际仍是明文存储非高敏感数据外部配置中心动态生效权限控制完善增加架构复杂度大规模生产环境最终采用分层策略基础配置使用ConfigMap数据库密码等通过Secret存储业务开关接入Apollo配置中心4. 部署编排与流量管理4.1 Deployment控制器详解这是电商订单服务的部署定义包含多个关键生产配置apiVersion: apps/v1 kind: Deployment metadata: name: order-service labels: app: order-service spec: replicas: 3 revisionHistoryLimit: 5 # 保留5个旧版本用于回滚 strategy: rollingUpdate: maxSurge: 1 # 滚动更新时最大额外Pod数 maxUnavailable: 0 # 保证始终有可用实例 selector: matchLabels: app: order-service template: metadata: labels: app: order-service spec: affinity: podAntiAffinity: # 反亲和性确保Pod分散在不同节点 preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: - order-service topologyKey: kubernetes.io/hostname containers: - name: order-service image: registry.example.com/order-service:v1.2.0 ports: - containerPort: 8080 resources: requests: cpu: 500m memory: 1Gi limits: cpu: 2 memory: 2Gi livenessProbe: httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 5 periodSeconds: 5关键配置解析maxUnavailable: 0确保滚动更新时不中断服务Pod反亲和性预防单节点故障导致服务不可用资源限制避免单个应用耗尽节点资源就绪探针(Readiness Probe)控制流量接入时机4.2 Ingress高级配置使用Nginx Ingress实现基于路径的路由和灰度发布apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ecommerce-ingress annotations: nginx.ingress.kubernetes.io/canary: true nginx.ingress.kubernetes.io/canary-weight: 20 spec: ingressClassName: nginx rules: - host: shop.example.com http: paths: - path: /api/order pathType: Prefix backend: service: name: order-service-canary port: number: 8080 - path: /api pathType: Prefix backend: service: name: main-service port: number: 8080这个配置实现了将/api/order路径的20%流量导向金丝雀版本其余API请求路由到稳定版本基于路径的灵活路由策略5. 生产环境问题排查实录5.1 典型故障场景与解决方案案例1Pod频繁重启现象Pod每10-15分钟重启一次日志显示OOMKilled排查kubectl describe pod [pod-name] | grep -A 10 Last State发现内存限制设置为1Gi但实际使用经常达到1.2Gi解决调整内存limits为1.5Gi添加JVM参数-XX:UseContainerSupport -XX:MaxRAMPercentage75.0案例2服务间调用超时现象A服务调用B服务出现3秒延迟排查工具kubectl get endpoints [service-name] # 检查Endpoint是否正常 kubectl run -it --rm debug-tool --imagenicolaka/netshoot --restartNever # 在debug容器内执行 dig [service-name].[namespace].svc.cluster.local发现CoreDNS解析延迟高解决增加CoreDNS副本数配置Pod的dnsConfigdnsConfig: options: - name: ndots value: 25.2 监控与日志收集方案推荐的生产级监控栈组合指标监控Prometheus Operator Grafana日志收集Fluent Bit Elasticsearch分布式追踪Jaeger关键配置示例Fluent Bit输出到ESapiVersion: v1 kind: ConfigMap metadata: name: fluent-bit-config data: fluent-bit.conf: | [SERVICE] Parsers_File parsers.conf [INPUT] Name tail Path /var/log/containers/*.log Parser docker Tag kube.* Refresh_Interval 5 [OUTPUT] Name es Match * Host elasticsearch Port 9200 Logstash_Format On Replace_Dots On Retry_Limit False6. 集群维护与优化技巧6.1 节点资源回收长期运行的集群容易出现资源碎片定期执行# 清理终止状态的Pod kubectl get pods --all-namespaces --field-selectorstatus.phaseFailed -o json | kubectl delete -f - # 清理Evicted Pods kubectl get pods --all-namespaces -o json | jq .items[] | select(.status.reason!null) | select(.status.reason | contains(Evicted)) | \(.metadata.namespace) \(.metadata.name) | xargs -n2 kubectl delete pod -n6.2 镜像垃圾清理在每个节点设置定时任务crontab0 3 * * * /usr/bin/docker image prune -a --filter until240h -f 0 4 * * * /usr/bin/crictl rmi --prune这个组合可以清理超过10天的旧镜像节省约40%的磁盘空间。注意Docker和containerd需要使用不同的清理命令。6.3 HPA自动扩缩容配置为订单服务配置基于CPU的自动扩缩apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: order-service-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: order-service minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60实际使用中发现单纯基于CPU的扩缩容有时不够灵敏后来我们增加了自定义指标metrics: - type: Pods pods: metric: name: http_requests_per_second target: type: AverageValue averageValue: 100这使系统能在流量突增时更快响应将扩容触发时间从原来的3分钟缩短到30秒左右。