一、为何必须升级到Kubernetes？
1.1 单机Docker的瓶颈
单机环境痛点：
├─ 资源利用率不均衡（CPU飙高 vs 内存闲置）
├─ 服务扩容需手动操作
├─ 零宕机更新难以实现
└─ 网络配置复杂（跨主机通信困难） 企业级需求：
┌───────────┬───────────────┐
| 场景 | Kubernetes方案 |
|───────────|───────────────|
| 滚动更新 | Deployment策略 |
| 服务发现 | Service+Ingress |
| 自动扩缩容 | HPA控制器 |
└───────────┴───────────────┘
1.2 迁移收益预估
# 某电商平台迁移前后对比 | 单机Docker | Kubernetes集群
-----------|-----------|-------------
部署效率 | 30min/次 | 2min/次 # 提升15倍
故障恢复 | 人工介入 | 自愈机制 # MTTR减少80%
资源成本 | ￥5万/月 | ￥3.2万/月 # 节省36%
二、迁移前准备：环境与数据双保险
2.1 环境兼容性检查
# 检测Docker与Kubernetes版本兼容性
$ docker version | grep 'API version' # 需≥1.41
$ kubectl version --short | grep Server # 推荐v1.24+ # 检查Linux内核配置
$ grep -E 'vm.swappiness|overcommit' /etc/sysctl.conf
vm.swappiness=0 # 必须调优项
vm.overcommit_memory=1 # 避免OOM Killer误杀
2.2 数据备份方案
# 持久化数据备份（以PostgreSQL为例）
$ docker exec -t pg_container pg_dump -U postgres dbname > backup.sql # 容器配置导出
$ docker inspect <container_id> > config.json
$ docker save -o app-image.tar <image_name>
三、五步完成平滑迁移
3.1 步骤1：搭建Kubernetes集群
# 使用kubeadm初始化控制平面
$ kubeadm init --pod-network-cidr=10.244.0.0/16 # 安装Calico网络插件
$ kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml # 节点加入集群（在工作节点执行）
$ kubeadm join 192.168.0.100:6443 --token <token> \ --discovery-token-ca-cert-hash sha256:<hash>
3.2 步骤2：容器镜像迁移
# 搭建私有镜像仓库（Harbor）
$ helm install harbor bitnami/harbor --set service.type=LoadBalancer # 推送镜像到新仓库
$ docker tag local-image:1.0 harbor.domain.com/prod/app:v1
$ docker push harbor.domain.com/prod/app:v1
3.3 步骤3：服务编排转换
# 将docker-compose.yml转换为Deployment
apiVersion: apps/v1
kind: Deployment
metadata: name: web-app
spec: replicas: 3 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: web image: harbor.domain.com/prod/app:v1 ports: - containerPort: 8080 envFrom: - configMapRef: name: app-config
3.4 步骤4：流量切换方案
蓝绿发布策略：
1. 旧Docker服务保持运行（v1.0）
2. Kubernetes集群部署新版本（v1.1）
3. 修改Nginx配置将10%流量导至集群
4. 监控无异常后逐步切流
3.5 步骤5：监控体系构建
# 安装Prometheus Operator
$ helm install prometheus prometheus-community/kube-prometheus-stack # 配置容器日志收集（EFK方案）
$ kubectl apply -f https://raw.githubusercontent.com/fluent/fluentd-kubernetes-daemonset/master/fluentd-daemonset-elasticsearch-rbac.yaml
四、四大避坑指南
4.1 网络配置陷阱
常见故障：
◼ 跨节点容器无法互通 → 检查Calico的MTU设置
◼ Service ClusterIP不通 → 确认kube-proxy模式（推荐iptables）
解决方案：
$ kubectl get endpoints <service-name> # 验证Endpoint状态
$ iptables-save | grep KUBE-SVC- # 查看iptables规则
4.2 存储卷迁移
# 将本地卷迁移到CSI驱动（以Rook-Ceph为例）
$ kubectl apply -f https://raw.githubusercontent.com/rook/rook/master/deploy/examples/csi/rbd/storageclass.yaml # PVC数据迁移命令
$ kubectl cp /local/path my-pod:/remote/path
4.3 容器时区同步
# 在Deployment中挂载主机时区
spec: containers: - name: app volumeMounts: - name: timezone mountPath: /etc/localtime volumes: - name: timezone hostPath: path: /usr/share/zoneinfo/Asia/Shanghai
4.4 资源限制优化
resources: requests: memory: "512Mi" cpu: "500m" limits: memory: "1Gi" cpu: "1"
# 通过监控数据调整：
$ kubectl top pod # 查看实际资源消耗
五、迁移后性能调优
5.1 节点亲和性配置
affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: node-type operator: In values: - high-memory
5.2 自动水平扩缩容
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: name: app-hpa
spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web-app minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60
结语：迁移不是终点而是起点
完成Docker到Kubernetes的迁移只是云原生旅程的第一步，接下来需要：
- 建立完善的CI/CD流水线
- 实施Service Mesh服务治理
- 探索Serverless架构转型
迁移成功标志：当团队不再关注“容器在哪里运行”，而是聚焦业务价值交付时，说明转型真正成功。
新时代农民工
)
)
