一、部署前的核心准备工作

1.1 容器化应用构建

应用容器化是Kubernetes部署的基础，需通过Dockerfile定义构建规范。关键要素包括：

• 基础镜像选择：优先使用Alpine等轻量级镜像（如python:3.9-alpine），减少安全风险与存储开销
• 依赖管理优化：采用多阶段构建（Multi-stage Build）分离编译环境与运行环境，示例：
  ```dockerfile

  编译阶段

  FROM golang:1.20 AS builder
  WORKDIR /app
  COPY . .
  RUN go build -o myapp

运行阶段

FROM alpine:3.18
COPY —from=builder /app/myapp /usr/local/bin/
CMD [“myapp”]

- **镜像安全加固**：使用Trivy等工具扫描漏洞，通过`docker scan`命令检测已知CVE
## 1.2 集群环境验证
部署前需确认集群状态：
- **节点资源检查**：`kubectl top nodes`查看CPU/内存使用率，确保剩余资源≥应用需求2倍
- **存储类配置**：验证StorageClass是否存在（`kubectl get sc`），SSD类型存储适合数据库类应用
- **网络策略测试**：通过`kubectl run -it --rm debug --image=busybox --restart=Never -- sh`创建临时Pod测试跨节点通信
# 二、核心资源对象定义
## 2.1 Deployment资源详解
Deployment是应用部署的核心控制器，关键配置项：
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        resources:
          limits:
            cpu: "500m"
            memory: "512Mi"
          requests:
            cpu: "250m"
            memory: "256Mi"
        livenessProbe:
          httpGet:
            path: /health
            port: 80
          initialDelaySeconds: 30
          periodSeconds: 10

• 滚动更新策略：maxSurge控制新增Pod数量，maxUnavailable限制不可用Pod比例
• 资源限制：通过requests/limits保障QoS等级，Burstable类型适合大多数Web应用
• 健康检查：结合livenessProbe与readinessProbe实现自动化故障恢复

2.2 Service与Ingress配置

服务暴露方案选择：

• ClusterIP：内部服务通信（默认类型）
• NodePort：开发环境快速测试（端口范围30000-32767）
• LoadBalancer：云环境自动创建负载均衡器
• Ingress：基于路径/域名的路由（需安装Ingress Controller）

Nginx Ingress示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

三、高级部署策略

3.1 金丝雀发布实现

通过流量分片实现渐进式发布：

# 原始Deployment（v1）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-v1
...
# 新版本Deployment（v2）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-v2
...
# Service选择器调整
apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
    version: v1  # 初始指向v1

通过修改Service的selector.version标签实现流量切换，或使用Istio等Service Mesh实现更精细的流量管理。

3.2 蓝绿部署实践

完整切换方案：

1. 创建v2版本Deployment（replicas: 3）
2. 将Service指向v2版本
3. 监控指标（错误率、延迟）
4. 回滚时只需切换Service指向

四、运维监控体系

4.1 日志收集方案

• EFK堆栈：Elasticsearch+Fluentd+Kibana
• Loki+Promtail：轻量级日志方案
• Sidecar模式：为每个Pod添加日志收集容器

Fluentd配置示例：

<match **>
  @type elasticsearch
  host "elasticsearch"
  port 9200
  index_name "k8s-#{ENV['KUBE_NAMESPACE']}"
</match>

4.2 指标监控体系

Prometheus监控关键指标：

• Pod状态：kube_pod_status_phase
• 资源使用：container_cpu_usage_seconds_total
• API调用：apiserver_request_total

Grafana仪表盘建议：

• 集群资源使用率（按Namespace分组）
• 部署版本分布热力图
• 错误率趋势分析

五、常见问题解决方案

5.1 ImagePullBackOff错误

• 检查镜像地址是否正确（包括tag）
• 验证镜像仓库认证配置（imagePullSecrets）
• 确认节点网络可访问仓库（docker pull测试）

5.2 CrashLoopBackOff错误

• 查看Pod日志：kubectl logs <pod-name> --previous
• 检查资源限制是否不足
• 验证健康检查配置是否合理

5.3 调度失败问题

• 使用kubectl describe pod <pod-name>查看事件
• 检查节点污点（Taints）与容忍度（Tolerations）
• 验证资源请求是否超过节点可用量

六、自动化部署实践

6.1 GitOps工作流

采用ArgoCD实现声明式部署：

1. 在Git仓库维护K8s清单文件
2. ArgoCD同步仓库与集群状态
3. 通过Webhook触发自动同步

6.2 Helm Chart开发

标准化应用部署模板：

# Chart.yaml
apiVersion: v2
name: web-app
version: 1.0.0
appVersion: "1.0"
# values.yaml
replicaCount: 3
image:
  repository: nginx
  tag: 1.25
resources:
  limits:
    cpu: 500m
    memory: 512Mi

通过helm install web-app ./chart完成部署，支持环境变量覆盖（--set参数）。

七、最佳实践总结

1. 基础设施即代码：所有资源通过YAML/Helm管理
2. 渐进式发布：优先采用滚动更新，复杂场景使用金丝雀
3. 可观测性建设：日志、指标、追踪三管齐下
4. 安全基线：镜像扫描、RBAC权限控制、网络策略
5. 灾备设计：多区域部署、定期备份Etcd数据

通过系统化的部署流程与自动化工具链，可实现Kubernetes应用的高效、稳定运行。实际部署中需根据业务特点调整参数，持续优化部署策略。