Docker容器迁移到Kubernetes指南

随着云原生技术的普及，Kubernetes（K8s）已成为容器编排的事实标准。许多企业从Docker单机部署转向K8s集群管理，以实现高可用、弹性伸缩和自动化运维。本文将系统梳理迁移过程中的关键步骤、技术差异和实战经验，帮助开发者和企业高效完成迁移。

一、迁移前的核心差异分析

1.1 架构差异：从单机到集群的思维转变

Docker原生环境以单机容器为核心，依赖docker-compose管理多容器服务；而K8s采用主从架构，通过Master节点（API Server、Scheduler、Controller Manager）和Worker节点（Kubelet、容器运行时）协同工作。迁移需重新设计服务拓扑，例如将单节点上的多个容器拆解为K8s的Pod（最小部署单元），并通过Service实现内部通信。

关键点：

• Pod设计：一个Pod可包含多个紧密耦合的容器（如主应用+日志收集器），共享网络命名空间和存储卷。
• Service类型：根据需求选择ClusterIP（内部访问）、NodePort（节点端口暴露）或LoadBalancer（云厂商负载均衡）。

1.2 资源管理：从静态到动态的分配模式

Docker通过--memory和--cpus参数静态限制资源，而K8s使用Requests/Limits机制动态分配资源。例如：

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "1"
    memory: "1Gi"

迁移建议：

• 评估应用实际资源占用，避免过度分配导致节点资源耗尽。
• 使用Vertical Pod Autoscaler（VPA）自动调整资源请求。

1.3 网络与存储：从本地到分布式的适配

• 网络：Docker默认使用桥接网络，K8s通过CNI插件（如Calico、Flannel）实现跨节点Pod通信。需确保应用能处理动态IP分配（如通过Service DNS名访问）。
• 存储：Docker依赖本地卷或docker volume，K8s需配置PersistentVolume（PV）和PersistentVolumeClaim（PVC）。例如，将MySQL数据卷迁移为：

  apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
  name: mysql-pvc
  spec:
  accessModes: [ "ReadWriteOnce" ]
  resources:
    requests:
      storage: 10Gi

二、迁移实施步骤

2.1 容器镜像适配

• 镜像标签：K8s推荐使用不可变标签（如app:v1.2.0而非latest），避免版本混乱。
• 多阶段构建：优化镜像大小，例如：
  ```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”]

### 2.2 编排文件转换
将`docker-compose.yml`转换为K8s的`Deployment`和`Service`。例如：
```yaml
# docker-compose.yml片段
services:
  web:
    image: nginx:latest
    ports:
      - "80:80"
# 转换为K8s Deployment和Service
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:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

2.3 配置与密钥管理

• ConfigMap：存储非敏感配置（如环境变量）：

  apiVersion: v1
  kind: ConfigMap
  metadata:
  name: app-config
  data:
  LOG_LEVEL: "debug"

• Secret：加密存储密码、API密钥：

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

2.4 迁移工具推荐

• Kompose：自动将docker-compose转换为K8s资源文件（kompose convert）。
• Velero：备份和迁移持久化数据。
• Argo CD：实现GitOps持续部署。

三、迁移后优化

3.1 监控与日志

• Prometheus+Grafana：监控Pod资源使用、API调用延迟等指标。
• EFK栈（Elasticsearch+Fluentd+Kibana）：集中收集和分析日志。

3.2 高可用设计

• Pod反亲和性：避免同一服务的Pod调度到同一节点：

  affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values: [ "nginx" ]
      topologyKey: "kubernetes.io/hostname"

• 健康检查：配置livenessProbe和readinessProbe：

  livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10

3.3 成本优化

• 节点自动伸缩（Cluster Autoscaler）：根据负载动态调整Worker节点数量。
• 资源配额：限制Namespace的资源使用，避免单个团队占用过多资源。

四、常见问题与解决方案

4.1 迁移后服务不可用

• 原因：Service的selector未匹配Pod标签，或targetPort配置错误。
• 排查：执行kubectl get pods -o wide确认Pod IP，kubectl describe service <name>检查Selector。

4.2 存储卷挂载失败

• 原因：PV的accessModes与PVC不匹配，或存储类（StorageClass）未正确配置。
• 解决：确保PV和PVC的accessModes一致（如均为ReadWriteOnce）。

4.3 性能下降

• 原因：K8s默认网络插件（如Flannel）性能低于Docker本地网络。
• 优化：切换至高性能CNI插件（如Calico的BGP模式）。

五、总结与展望

迁移至K8s不仅是技术栈的升级，更是运维模式的变革。企业需逐步建立云原生能力中心，涵盖容器化改造、CI/CD流水线、混沌工程等实践。未来，随着eBPF、Wasm等技术的融合，K8s将进一步简化应用部署，推动企业向自动化、智能化演进。

行动建议：

1. 从小规模试点开始，逐步扩大迁移范围。
2. 制定详细的回滚方案，应对迁移中可能出现的问题。
3. 培训团队掌握K8s核心概念和调试技巧。

通过系统化的迁移策略，企业可充分释放K8s的潜力，构建更具弹性和效率的云原生基础设施。