1. Kubernetes作业解析从入门到进阶实战刚接触Kubernetes时那些抽象的概念和复杂的YAML配置总让人望而生畏。直到真正动手完成几个作业项目才发现这套容器编排系统远比想象中简单。最近在整理学习笔记时发现k8s作业45这个练习组合特别能体现Kubernetes的核心价值——它用Deployment实现无状态应用的滚动更新用StatefulSet处理有状态服务再配合Service和Ingress构建完整的访问链路。下面我就拆解这两个作业的技术要点分享一些从入门到进阶的实操心得。2. 作业环境准备与基础架构设计2.1 实验环境搭建要点推荐使用Minikube作为本地开发环境它比直接配置多节点集群更轻量。安装时注意minikube start --driverdocker --cpus2 --memory4096这个配置给足了资源空间避免后续部署时因资源不足报错。我曾尝试用默认的2GB内存运行MySQL结果Pod反复崩溃增加内存后问题立即解决。2.2 应用架构设计思路两个作业共同构建了一个经典的三层架构前端Nginx作为静态资源服务器中间层Node.js处理业务逻辑数据层MySQL持久化数据这种分离设计让每个组件都可以独立扩展。比如当访问量激增时只需增加Node.js的Pod副本数而不必动数据库层。3. 无状态服务部署实战作业43.1 Deployment控制器详解作业4要求用Deployment部署Web应用其核心优势在于apiVersion: apps/v1 kind: Deployment metadata: name: web-app spec: replicas: 3 strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 0 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: nginx image: nginx:1.19 ports: - containerPort: 80关键参数说明maxSurge:1表示更新时最多新增1个PodmaxUnavailable:0确保服务始终可用经验生产环境建议maxUnavailable设为25%这样更新速度更快且风险可控3.2 Service暴露技巧ClusterIP类型的Service适合内部通信apiVersion: v1 kind: Service metadata: name: web-service spec: selector: app: web ports: - protocol: TCP port: 80 targetPort: 80测试时发现如果selector标签与Pod不匹配Service会一直处于pending状态。建议用kubectl get endpoints命令检查关联情况。4. 有状态服务部署进阶作业54.1 StatefulSet的特殊设计MySQL这类有状态服务需要稳定的网络标识持久化存储有序部署/扩展StatefulSet的典型配置apiVersion: apps/v1 kind: StatefulSet metadata: name: mysql spec: serviceName: mysql replicas: 1 selector: matchLabels: app: mysql template: metadata: labels: app: mysql spec: containers: - name: mysql image: mysql:5.7 env: - name: MYSQL_ROOT_PASSWORD value: password ports: - containerPort: 3306 volumeMounts: - name: mysql-persistent-storage mountPath: /var/lib/mysql volumeClaimTemplates: - metadata: name: mysql-persistent-storage spec: accessModes: [ ReadWriteOnce ] resources: requests: storage: 1Gi4.2 数据持久化方案对比作业中使用了volumeClaimTemplates动态创建PVC实际生产还需考虑本地存储性能好但无法迁移网络存储如NFS适合多节点读写云厂商块存储AWS EBS或Azure Disk测试时发现MySQL容器首次启动较慢因为要初始化数据库。建议在livenessProbe中增加初始延迟livenessProbe: exec: command: - mysqladmin - ping initialDelaySeconds: 30 periodSeconds: 105. 网络连通性实战测试5.1 集群内通信验证Node.js应用需要连接MySQL通过Service的DNS名称即可访问const pool mysql.createPool({ host: mysql.default.svc.cluster.local, user: root, password: password, database: app_db });关键点Service全称格式 . .svc.cluster.local同一命名空间可省略后缀5.2 Ingress对外暴露Nginx Ingress的配置示例apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: web-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: myapp.local http: paths: - path: / pathType: Prefix backend: service: name: web-service port: number: 80测试前需在本地hosts文件添加解析127.0.0.1 myapp.local6. 常见问题排查手册6.1 Pod启动失败排查流程查看详细事件kubectl describe pod pod-name检查镜像拉取私有镜像需要配置imagePullSecrets镜像tag是否存在拼写错误资源配额kubectl top pod查看资源使用调整requests/limits6.2 网络连接问题典型症状应用能启动但无法访问其他服务检查Service的selector标签测试集群DNS解析kubectl run -it --rm --imagebusybox:1.28 test -- nslookup mysql验证网络策略是否阻止通信7. 性能调优实战建议7.1 资源限制配置避免单个Pod耗尽节点资源resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 512Mi建议Java应用堆内存设为limits的70-80%CPU limits可能导致 throttling生产环境慎用7.2 HPA自动扩缩容基于CPU利用率自动扩展DeploymentapiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web-autoscaler spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web-app minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50测试时用kubectl run -it --rm --imagebusybox:1.28 --restartNever -- sh -c while true; do wget -q -O- http://web-service; done模拟负载8. 安全加固关键步骤8.1 最小权限原则为Pod配置专用ServiceAccount使用NetworkPolicy限制流量避免使用root用户运行容器8.2 敏感信息管理用Secret存储密码kubectl create secret generic mysql-pass --from-literalpasswordsecret在Deployment中引用env: - name: MYSQL_ROOT_PASSWORD valueFrom: secretKeyRef: name: mysql-pass key: password9. 监控与日志方案9.1 基础监控搭建安装Metrics Serverminikube addons enable metrics-server查看资源使用kubectl top pods --sort-bycpu9.2 日志收集实践多容器日志查看技巧kubectl logs -f pod-name -c container-name对于生产环境建议部署LokiPromtailGrafana栈10. 从作业到生产的差距完成这两个作业后要部署真实生产系统还需考虑CI/CD流水线设计多环境配置管理ConfigMap/Secret差异化灾备方案Pod反亲和性、多可用区部署金丝雀发布策略比如更复杂的更新策略strategy: type: RollingUpdate rollingUpdate: maxSurge: 25% maxUnavailable: 25% minReadySeconds: 30