从零到一：Kubernetes 集群应用部署全流程指南

一、部署前的环境准备与集群验证

在正式部署应用前，需确保 Kubernetes 集群处于健康状态。首先通过 kubectl version 验证客户端与服务端版本兼容性，避免因 API 版本不匹配导致部署失败。接着执行 kubectl cluster-info 检查集群核心组件（如 API Server、etcd）的运行状态，若发现组件异常，需通过 kubectl get pods -n kube-system 定位具体故障 Pod 并排查日志。

资源配额管理是部署前的关键环节。通过 kubectl describe nodes 查看节点资源（CPU、内存）的分配情况，结合应用需求调整 ResourceQuota 对象。例如，为命名空间 prod 设置 CPU 限制：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: cpu-quota
  namespace: prod
spec:
  hard:
    requests.cpu: "2"
    limits.cpu: "4"

此配置确保该命名空间下的应用总 CPU 请求量不超过 2 核，总限制量不超过 4 核，防止资源过载。

二、应用资源定义与最佳实践

1. Deployment 资源详解

Deployment 是部署无状态应用的核心资源，通过 replicas 字段控制 Pod 副本数。以下是一个 Nginx 应用的 Deployment 示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25.3
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

• 资源请求与限制：requests 定义 Pod 运行所需的最小资源，调度器据此选择节点；limits 防止单个 Pod 占用过多资源。
• 标签选择器：selector.matchLabels 必须与 template.metadata.labels 一致，否则 Deployment 无法关联 Pod。

2. Service 与 Ingress 配置

Service 为 Pod 提供稳定的访问入口，ClusterIP 类型适用于集群内部通信：

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

若需对外暴露服务，需结合 Ingress 控制器（如 Nginx Ingress）：

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

此配置将域名 example.com 的流量路由至 nginx-service。

三、部署策略与滚动更新

1. 滚动更新机制

Kubernetes 默认采用滚动更新策略，通过 maxUnavailable 和 maxSurge 控制更新过程：

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

• maxUnavailable: 1 表示更新时最多允许 1 个 Pod 不可用。
• maxSurge: 1 表示更新时最多可创建 1 个超出 replicas 数量的 Pod。

2. 回滚操作

若更新后应用异常，可通过 kubectl rollout undo 快速回滚：

kubectl rollout undo deployment/nginx-deployment

查看历史版本：

kubectl rollout history deployment/nginx-deployment

回滚至指定版本：

kubectl rollout undo deployment/nginx-deployment --to-revision=2

四、监控与日志管理

1. Prometheus 与 Grafana 监控

通过 Prometheus 采集 Pod 指标，Grafana 可视化数据。示例配置：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: nginx-monitor
spec:
  selector:
    matchLabels:
      app: nginx
  endpoints:
  - port: web
    interval: 30s

此配置监控标签为 app: nginx 的 Service 的 web 端口，每 30 秒采集一次数据。

2. 日志收集方案

EFK（Elasticsearch-Fluentd-Kibana）是常用日志方案。Fluentd DaemonSet 配置示例：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
spec:
  template:
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

此配置将节点日志目录挂载至 Fluentd 容器，实现日志集中收集。

五、高可用部署优化

1. 多节点调度策略

通过 nodeSelector 和 affinity 控制 Pod 分布。示例：

spec:
  template:
    spec:
      nodeSelector:
        disktype: ssd
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx
            topologyKey: "kubernetes.io/hostname"

• nodeSelector 将 Pod 调度至标签为 disktype: ssd 的节点。
• podAntiAffinity 确保同一节点的不同 Pod 标签为 app: nginx，避免单节点故障导致服务中断。

2. HPA 自动扩缩容

基于 CPU 使用率的自动扩缩容配置：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

当 CPU 平均利用率超过 50% 时，HPA 自动增加副本数至最多 10 个。

六、安全与权限管理

1. RBAC 权限控制

通过 Role 和 RoleBinding 限制用户权限。示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: prod
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: prod
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

此配置允许用户 jane 在 prod 命名空间下读取 Pod 信息。

2. Secret 管理

敏感信息（如数据库密码）应通过 Secret 存储：

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  password: eW91cnBhc3N3b3Jk # base64 编码的密码

在 Pod 中引用：

env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db-secret
      key: password

七、故障排查与常见问题

1. Pod 一直处于 Pending 状态

通过 kubectl describe pod <pod-name> 查看事件，常见原因包括：

• 资源不足：节点无足够 CPU/内存，需调整资源请求或扩容节点。
• 持久卷绑定失败：PVC 未绑定 PV，检查 StorageClass 配置。
• 节点选择器不匹配：Pod 调度策略与节点标签不一致。

2. ImagePullBackOff 错误

表示镜像拉取失败，可能原因：

• 镜像地址错误：检查 image 字段是否正确。
• 镜像仓库认证失败：配置 imagePullSecrets：

  spec:
  template:
    spec:
      imagePullSecrets:
      - name: regcred

八、总结与进阶建议

在 Kubernetes 上部署应用需遵循“资源定义→策略配置→监控优化”的完整流程。对于生产环境，建议：

1. 使用 Helm 或 Kustomize：简化复杂应用的部署与管理。
2. 实施 GitOps：通过 ArgoCD 等工具实现声明式部署与版本控制。
3. 定期演练故障恢复：验证集群高可用性与数据备份策略。

通过系统化的部署实践与持续优化，可充分发挥 Kubernetes 的弹性与自动化优势，为业务提供稳定可靠的应用运行环境。