容器化部署：从手动到自动

📅 2026-02-28 📁 技术分享 ⏱️ 12 分钟

系列七：基础设施篇 · 第6篇

还记得"半夜两点起来回滚"的噩梦吗？手动部署一台服务器，要从安装依赖、配置环境、上传代码、重启服务……每一步都可能出错。更要命的是，开发环境能跑，测试环境能跑，一上生产就崩——"我这边明明是好的"成了最无力的辩解。

容器化改变了这一切。它让部署从"手工作坊"进化到"流水线工厂"，让"一次构建，到处运行"成为现实。

今天我们来聊聊容器化部署的演进历程，看看从手动到自动，我们经历了什么。

一、部署方式的演进

1.1 物理机时代

最早的时候，应用直接部署在物理服务器上。

采购服务器，等待到货
安装操作系统，配置网络
安装运行时环境（Java、Python 等）
部署应用，配置启动脚本
配置监控、日志收集

资源浪费：一台物理机只跑一个应用，CPU 利用率可能只有 10%
部署缓慢：从采购到上线，周期以周计
环境不一致：每台服务器的配置可能有细微差异
扩展困难：流量突增时，很难快速扩容

那时候，运维是一个高度依赖经验的岗位。谁更熟悉系统，谁就能更快地排查问题。但这也意味着知识难以传承，一旦老员工离职，新人往往无从下手。

1.2 虚拟机时代

虚拟化技术的出现，让一台物理机可以运行多个虚拟机。

资源利用率提升，一台物理机跑多个应用
虚拟机镜像可以复制，环境一致性有所改善
扩容时可以快速创建新的虚拟机
快照功能让回滚变得可行

重量级：每个虚拟机都要跑完整的操作系统，启动分钟级
资源开销：虚拟化层本身消耗 10-20% 的资源
镜像臃肿：虚拟机镜像动辄几个 GB，传输和存储都是负担
仍然不够灵活：创建虚拟机还是太慢，跟不上业务变化

虚拟机时代，我们学会了用配置管理工具（如 Ansible、Puppet）来标准化环境。但"配置漂移"的问题依然存在：时间一长，各台机器的配置又开始不一致。

1.3 容器时代

容器的核心理念：应用 + 环境 = 可移植单元。

容器不是虚拟机，它不模拟完整的硬件和操作系统，而是共享宿主机的内核，只是通过隔离技术让每个容器"看起来"像独占系统。

轻量：容器镜像通常只有几十到几百 MB
快速：容器启动秒级，而非分钟级
一致：开发、测试、生产环境完全一致
可移植：在任何支持容器的系统上运行
版本化：镜像有明确的版本，可以追溯和回滚

容器化让"环境"成为代码的一部分，随代码一起版本管理。这从根本上解决了"我这边是好的"问题——如果容器在你那边能跑，在别人那边也一定能跑。

这就是为什么容器成为现代部署的事实标准。

二、容器化的技术原理

要真正理解容器，我们需要深入到底层，看看它究竟是如何工作的。

2.1 容器 vs 虚拟机：本质区别

很多人把容器理解为"轻量级虚拟机"，这是一个常见的误区。实际上，两者的实现原理完全不同：

┌─────────────────────────────────────┐
│         应用程序 A                   │
├─────────────────────────────────────┤
│         Guest OS（完整操作系统）       │
├─────────────────────────────────────┤
│            Hypervisor               │  ← 硬件虚拟化层
├─────────────────────────────────────┤
│            Host OS                  │
├─────────────────────────────────────┤
│          物理服务器硬件               │
└─────────────────────────────────────┘

┌──────────┬──────────┬──────────┐
│  应用 A   │  应用 B   │  应用 C   │
├──────────┼──────────┼──────────┤
│Container │Container │Container │
│ Runtime  │ Runtime  │ Runtime  │  ← 容器运行时
├──────────┴──────────┴──────────┤
│          Host OS Kernel         │  ← 共享内核
├─────────────────────────────────┤
│         物理服务器硬件            │
└─────────────────────────────────┘

关键区别：

虚拟机：每个虚拟机运行完整的 Guest OS，通过 Hypervisor 模拟硬件
容器：所有容器共享宿主机内核，没有独立的操作系统

打个比方：虚拟机像是每家都盖独立的房子，有自己的地基、墙壁、屋顶；容器则像是一栋大楼里的公寓，共享地基和主体结构，但每户有独立的房间和门锁。

2.2 Namespace：资源隔离的魔法

Linux Namespace 是容器隔离的核心技术，它让容器"以为自己独占系统"。

Namespace 类型	隔离内容	效果
PID	进程 ID	容器内进程从 PID 1 开始，看不到宿主机进程
Network	网络栈	容器有独立的网卡、IP、路由表、端口
Mount	文件系统	容器有独立的文件系统挂载点
UTS	主机名	容器可以有自己的 hostname
IPC	进程间通信	容器内进程通信与外界隔离
User	用户 ID	容器内的 root 可以映射到宿主机的普通用户

在宿主机上执行：

# 查看当前进程
ps aux
# 输出：看到成百上千个进程

# 启动一个容器
docker run -it alpine sh

# 在容器内查看进程
ps aux
# 输出：只看到 1 个进程（PID 1 就是 sh）

这就是 PID Namespace 的魔力——容器内的进程看不到宿主机的其他进程，以为自己就是系统的"老大"。

每个容器都有自己的网络栈：

# 在宿主机上
ip addr
# 看到 eth0、docker0 等网卡

# 进入容器
docker run -it alpine sh
ip addr
# 看到 eth0@ifxx，这是容器独有的虚拟网卡

容器间的网络通信，通过 Linux 的虚拟网卡对（veth pair）和网桥（bridge）实现，就像给每户公寓拉了独立的电话线。

2.3 Cgroups：资源限制的紧箍咒

如果说 Namespace 是让容器"以为自己独占系统"，那 Cgroups 就是"限制容器能用多少资源"。

CPU：限制 CPU 使用率、绑定到特定 CPU 核心
内存：限制内存使用量，超出则 OOM Kill
磁盘 I/O：限制读写速率
网络带宽：限制网络流量
进程数：限制可创建的进程数量

# 限制容器最多使用 512MB 内存，1 个 CPU 核心
docker run -d \
  --memory="512m" \
  --cpus="1.0" \
  --name myapp \
  nginx

# 验证限制生效
docker stats myapp

如果不加限制，一个失控的容器可能吃掉宿主机所有内存，导致其他容器被连带杀死——这叫"吵闹邻居问题"（Noisy Neighbor）。Cgroups 就是防止这种情况的"紧箍咒"。

Cgroups 本质上是 Linux 内核的一个文件系统接口：

# 查看某个进程的 CPU 限制
cat /sys/fs/cgroup/cpu/docker/<container_id>/cpu.cfs_quota_us

# 查看内存限制
cat /sys/fs/cgroup/memory/docker/<container_id>/memory.limit_in_bytes

Docker 只是在创建容器时，向这些文件写入相应的数值，内核会自动执行限制。

2.4 UnionFS：镜像分层的秘密

Docker 镜像为什么能做到"增量更新"？答案在于 Union File System（联合文件系统）。

Docker 镜像由多个只读层组成，容器运行时在最上层添加一个可写层：

┌─────────────────────────────────┐
│  Container Layer（可写）         │  ← 容器运行时的修改写到这里
├─────────────────────────────────┤
│  Image Layer 3（应用代码）        │  ← 只读
├─────────────────────────────────┤
│  Image Layer 2（依赖库）         │  ← 只读
├─────────────────────────────────┤
│  Image Layer 1（基础 OS）        │  ← 只读
└─────────────────────────────────┘

当容器需要修改某个文件时：

从只读层复制文件到可写层
在可写层进行修改
后续读取时，可写层的文件"覆盖"只读层的原文件

这样做的好处：

存储高效：多个镜像共享相同的基础层，节省磁盘空间
构建快速：利用缓存，只重建变化的层
传输高效：拉取镜像时，只需下载本地没有的层

# 拉取一个镜像
docker pull nginx:latest

# 查看镜像分层
docker history nginx:latest

# 输出示例：
# IMAGE          CREATED        SIZE
# 605c77e624dd   2 weeks ago    141MB   ← 应用层
# <missing>      2 weeks ago    1.04kB  ← 配置层
# <missing>      2 weeks ago    1.89kB  ← 脚本层
# <missing>      2 weeks ago    62.5MB  ← 依赖层
# <missing>      2 weeks ago    33.3MB  ← 基础层

2.5 容器运行时：从 Docker 到 containerd

Docker 不是唯一的容器运行时，实际上，容器技术栈已经标准化和模块化：

runtime-spec：容器运行时标准，定义如何运行容器
image-spec：镜像格式标准，定义镜像结构
distribution-spec：镜像分发标准，定义如何推送/拉取镜像

Docker（单体）→ Docker Engine → containerd + runc（模块化）

┌─────────────────────────────────┐
│   Kubernetes / Docker CLI       │  ← 用户接口
├─────────────────────────────────┤
│   CRI（容器运行时接口）           │  ← 标准接口
├─────────────────────────────────┤
│   containerd / CRI-O           │  ← 高层运行时
├─────────────────────────────────┤
│   runc / kata-containers       │  ← 低层运行时
├─────────────────────────────────┤
│   Linux Kernel（Namespace/Cgroups）│  ← 内核能力
└─────────────────────────────────┘

containerd：高层运行时，管理镜像、容器生命周期
runc：底层运行时，真正创建和运行容器进程

打个比方：containerd 是餐厅经理（管理订单、调度），runc 是厨师（真正做菜）。

三、Docker 实践：从零开始

3.0 Docker 架构与工作原理

在深入实践之前，先理解 Docker 的架构：

┌─────────────────────────────────────────────────────────┐
│                      Docker 架构                         │
│                                                         │
│  ┌──────────────┐       ┌──────────────────────────┐   │
│  │ Docker CLI   │       │     Docker Daemon        │   │
│  │ (客户端)      │──────▶│     (dockerd)            │   │
│  │ docker run   │ REST  │  ┌────────────────────┐  │   │
│  │ docker build │  API  │  │   containerd       │  │   │
│  └──────────────┘       │  │   ┌──────────────┐ │  │   │
│                         │  │   │    runc      │ │  │   │
│                         │  │   └──────────────┘ │  │   │
│                         │  └────────────────────┘  │   │
│                         │  ┌────────────────────┐  │   │
│                         │  │  镜像存储 (OverlayFS)│  │   │
│                         │  └────────────────────┘  │   │
│                         └──────────────────────────┘   │
│                                   │                     │
│                                   ▼                     │
│                         ┌──────────────────────────┐   │
│                         │   Linux Kernel           │   │
│                         │   (Namespaces + Cgroups) │   │
│                         └──────────────────────────┘   │
└─────────────────────────────────────────────────────────┘

当你执行 docker run nginx 时，发生了什么？

CLI 解析命令：docker 客户端解析参数
API 调用：通过 REST API 调用 dockerd
镜像检查：本地是否有 nginx 镜像？没有则从 Registry 拉取
镜像拉取：从 Docker Hub 下载镜像层（利用分层缓存）
容器创建：containerd 调用 runc 创建容器
Namespace 隔离：创建独立的进程、网络、文件系统命名空间
Cgroups 限制：应用资源限制
容器启动：执行 nginx 进程

# 拉取镜像时可以看到分层下载
docker pull nginx:latest

# 输出示例：
# latest: Pulling from library/nginx
# a2abf6c4d29d: Pull complete   ← 基础层
# a9edb18cadd1: Pull complete   ← 依赖层
# 589b7251471a: Pull complete   ← 应用层
# ...

如果本地已有某些层（来自其他镜像），Docker 会复用它们，大大节省下载时间和存储空间。

3.1 Dockerfile 最佳实践

理解原理后，我们来看看 Docker 的实际使用。

3.1 Dockerfile 最佳实践

Dockerfile 是构建镜像的"配方"，写好 Dockerfile 是容器化的第一步。

# 第一阶段：构建
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

# 第二阶段：运行
FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
EXPOSE 3000
USER node
CMD ["node", "dist/main.js"]

使用多阶段构建：构建和运行分离，最终镜像不包含编译工具
选择合适的基础镜像：alpine 只有 5MB，比完整 Ubuntu 小几十倍
利用缓存：把 package*.json 单独复制并安装依赖，放在 COPY . . 前面
不使用 root 运行：USER node 提升安全性
明确暴露端口：EXPOSE 3000 作为文档说明

# ❌ 错误示范
FROM ubuntu:latest
RUN apt-get update
COPY . /app
RUN cd /app && npm install
CMD ["npm", "start"]

问题：

使用 ubuntu:latest（镜像 100MB+，且版本不确定）
没有利用缓存（每次都重新 npm install）
使用 root 运行（安全风险）
没有清理 apt 缓存（镜像臃肿）

3.2 镜像优化技巧

# 使用 alpine 基础镜像
FROM alpine:3.18

# 在同一层安装和清理
RUN apk add --no-cache nodejs npm && \
    npm install -g pnpm

# 清理缓存
RUN rm -rf /var/cache/apk/*

Docker 会按顺序执行 Dockerfile 的每条指令，如果某层没有变化，就使用缓存：

# ✅ 好的顺序：依赖放前面
COPY package.json package-lock.json ./
RUN npm ci
COPY . .

# ❌ 坏的顺序：代码放前面
COPY . .
RUN npm ci  # 代码变了，这一层就要重新跑

node_modules
npm-debug.log
Dockerfile
.dockerignore
.git
.gitignore
README.md
.env
coverage
.nyc_output

3.3 Docker Compose：多容器编排

单机多容器场景，Docker Compose 是最佳选择。

version: '3.8'

services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=production
      - DATABASE_URL=postgres://db:5432/mydb
    depends_on:
      - db
      - redis
    networks:
      - backend
    restart: unless-stopped
    
  db:
    image: postgres:15-alpine
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=mydb
      - POSTGRES_PASSWORD=secret
    networks:
      - backend
    restart: unless-stopped
    
  redis:
    image: redis:7-alpine
    volumes:
      - redis_data:/data
    networks:
      - backend
    restart: unless-stopped

  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - app
    networks:
      - backend
    restart: unless-stopped

networks:
  backend:
    driver: bridge

volumes:
  postgres_data:
  redis_data:

# 启动所有服务
docker-compose up -d

# 查看服务状态
docker-compose ps

# 查看日志
docker-compose logs -f app

# 扩容某个服务
docker-compose up -d --scale app=3

# 停止并清理
docker-compose down -v

四、Kubernetes：容器编排之王

单机容器管理很简单，但当容器数量达到成百上千，跨多台服务器部署时，就需要一个"容器编排系统"。Kubernetes（K8s）就是这个领域的王者。

4.1 为什么需要 Kubernetes

容器挂了怎么办？需要人工介入重启
如何在多台机器上均匀分布容器？手动调度效率低
如何实现容器的自动扩缩容？需要写脚本监控和调整
如何管理容器之间的网络通信？配置复杂
如何滚动更新而不中断服务？步骤繁琐，容易出错

Kubernetes 把这些问题都解决了。它不仅是一个容器调度器，更是一个分布式系统操作系统。

4.2 Kubernetes 架构详解

Kubernetes 的设计遵循几个核心原则：

声明式 API：你告诉系统"我想要什么"，而不是"怎么做"
控制器模式：持续对比期望状态和实际状态，自动调和
微服务架构：每个组件独立运行，通过 API 通信
可扩展性：通过 CRD（自定义资源定义）扩展能力

**Master 节点（控制平面）

┌────────────────────────────────────────────────────┐
│                   Master Node                       │
│  ┌──────────────┐  ┌──────────────┐               │
│  │ API Server   │  │   Scheduler  │               │
│  │ (入口+认证)   │  │  (调度决策)   │               │
│  └──────────────┘  └──────────────┘               │
│  ┌──────────────┐  ┌──────────────┐               │
│  │ Controller   │  │     etcd     │               │
│  │  Manager     │  │  (数据存储)   │               │
│  │ (状态维护)    │  └──────────────┘               │
│  └──────────────┘                                  │
└────────────────────────────────────────────────────┘

API Server：集群入口，所有请求都通过它
Scheduler：决定 Pod 运行在哪个 Node 上
Controller Manager：维护集群状态（如副本数）
etcd：分布式键值存储，保存集群所有数据

┌────────────────────────────────────────────────────┐
│                   Worker Node                       │
│  ┌──────────────┐  ┌──────────────┐               │
│  │   kubelet    │  │ kube-proxy   │               │
│  │ (节点代理)    │  │ (网络代理)    │               │
│  └──────────────┘  └──────────────┘               │
│  ┌────────────────────────────────────────────┐   │
│  │           Container Runtime                │   │
│  │     (containerd / CRI-O / Docker)          │   │
│  └────────────────────────────────────────────┘   │
│  ┌──────────┬──────────┬──────────┐              │
│  │   Pod 1  │   Pod 2  │   Pod 3  │              │
│  └──────────┴──────────┴──────────┘              │
└────────────────────────────────────────────────────┘

kubelet：与 Master 通信，管理本机 Pod
kube-proxy：维护网络规则，实现 Service 负载均衡
Container Runtime：运行容器的底层软件

4.3 核心概念详解

Pod 是 Kubernetes 中最小的部署单元，一个 Pod 可以包含一个或多个容器：

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: app
    image: myapp:1.0.0
    ports:
    - containerPort: 8080
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "256Mi"
        cpu: "500m"
  - name: sidecar  # 边车容器
    image: log-collector:1.0
    volumeMounts:
    - name: logs
      mountPath: /var/log/app
  volumes:
  - name: logs
    emptyDir: {}

同一 Pod 内的容器共享网络命名空间（同一 IP）
共享存储卷
总是被一起调度到同一节点
生命周期：Pending → Running → Succeeded/Failed

Deployment 管理 Pod 的副本和更新策略：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # 更新时最多多 1 个 Pod
      maxUnavailable: 0  # 更新时最少保持 3 个 Pod
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:2.0.0
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

维护指定数量的 Pod 副本
滚动更新和回滚
暂停和恢复更新
扩容和缩容

Service 为一组 Pod 提供稳定的访问入口：

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP  # 集群内部访问

类型	访问范围	使用场景
ClusterIP	集群内部	内部服务通信
NodePort	集群外部（节点端口）	开发测试环境
LoadBalancer	集群外部（云负载均衡）	生产环境
ExternalName	外部服务别名	访问外部服务

# ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database_host: "postgres.default.svc.cluster.local"
  database_port: "5432"
  log_level: "info"
---
# Secret
apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  database_password: c2VjcmV0cGFzc3dvcmQ=  # base64 编码

4.4 实践案例：完整的应用部署

# 1. 数据库部署
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:15-alpine
        ports:
        - containerPort: 5432
        env:
        - name: POSTGRES_DB
          value: myapp
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: app-secret
              key: database_password
        volumeMounts:
        - name: postgres-data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: postgres-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi
---
# 2. API 服务部署
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: myapp-api:2.0.0
        ports:
        - containerPort: 8080
        env:
        - name: DATABASE_URL
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: database_url
        - name: DATABASE_PASSWORD
          valueFrom:
            secretKeyRef:
              name: app-secret
              key: database_password
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
---
# 3. API Service
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  selector:
    app: api
  ports:
  - port: 80
    targetPort: 8080
---
# 4. 前端部署
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 2
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: nginx
        image: myapp-frontend:2.0.0
        ports:
        - containerPort: 80
---
# 5. Ingress 配置
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80

4.5 容器编排策略

Kubernetes 提供了丰富的调度和编排能力：

spec:
  nodeSelector:
    disktype: ssd           # 调度到有 SSD 的节点
    zone: us-west-1a        # 调度到特定可用区

spec:
  affinity:
    # Pod 亲和性：与某个 Pod 靠近
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: cache
        topologyKey: kubernetes.io/hostname
    
    # Pod 反亲和性：与某个 Pod 分开
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchLabels:
              app: api
          topologyKey: kubernetes.io/hostname

# 节点打污点（在节点上执行）
kubectl taint nodes node1 dedicated=gpu:NoSchedule

# Pod 容忍污点
spec:
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: development
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    pods: "50"

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

五、CI/CD 流水线集成

容器化解决了"环境一致性"问题，但代码如何变成可部署的镜像？如何自动化地部署到生产环境？这就需要 CI/CD 流水线。

5.1 CI/CD 是什么

代码提交后自动触发
自动构建、自动测试
尽早发现问题，降低修复成本
目标：让代码始终处于可部署状态

持续交付：代码通过测试后，随时可以部署到生产（手动触发）
持续部署：代码通过测试后，自动部署到生产（全自动）
目标：让部署成为日常、低风险的操作

CI/CD 的本质是将软件交付流程标准化、自动化，减少人为干预，提高发布效率和质量。

5.2 完整流水线示例

# .gitlab-ci.yml
stages:
  - test
  - build
  - deploy-staging
  - deploy-production

variables:
  IMAGE_NAME: registry.example.com/myapp
  IMAGE_TAG: ${CI_COMMIT_SHA}

# 测试阶段
test:
  stage: test
  image: node:18-alpine
  script:
    - npm ci
    - npm run lint
    - npm run test:unit
    - npm run test:integration
  coverage: '/Lines\s*:\s*(\d+.\d+)%/'
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml

# 构建镜像
build:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker login -u $REGISTRY_USER -p $REGISTRY_PASSWORD registry.example.com
    - docker build -t $IMAGE_NAME:$IMAGE_TAG .
    - docker push $IMAGE_NAME:$IMAGE_TAG
    # 也打上 latest 标签
    - docker tag $IMAGE_NAME:$IMAGE_TAG $IMAGE_NAME:latest
    - docker push $IMAGE_NAME:latest
  only:
    - main
    - develop

# 部署到 staging
deploy-staging:
  stage: deploy-staging
  image: bitnami/kubectl:latest
  script:
    - kubectl config use-context staging-cluster
    - kubectl set image deployment/myapp myapp=$IMAGE_NAME:$IMAGE_TAG -n staging
    - kubectl rollout status deployment/myapp -n staging
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - develop

# 部署到生产（需要手动触发）
deploy-production:
  stage: deploy-production
  image: bitnami/kubectl:latest
  script:
    - kubectl config use-context production-cluster
    # 使用金丝雀发布策略
    - kubectl apply -f k8s/canary.yaml
    - sleep 300  # 等待 5 分钟观察
    - kubectl apply -f k8s/production.yaml
    - kubectl rollout status deployment/myapp -n production
  environment:
    name: production
    url: https://www.example.com
  when: manual  # 手动触发
  only:
    - main

5.3 GitHub Actions 示例

# .github/workflows/ci-cd.yml
name: CI/CD Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    
    - name: Setup Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '18'
        cache: 'npm'
    
    - name: Install dependencies
      run: npm ci
    
    - name: Run linter
      run: npm run lint
    
    - name: Run tests
      run: npm run test:coverage
    
    - name: Upload coverage
      uses: codecov/codecov-action@v3
      with:
        files: ./coverage/lcov.info

  build:
    needs: test
    runs-on: ubuntu-latest
    outputs:
      image_tag: ${{ steps.meta.outputs.tags }}
    
    steps:
    - uses: actions/checkout@v4
    
    - name: Set up Docker Buildx
      uses: docker/setup-buildx-action@v3
    
    - name: Log in to Container Registry
      uses: docker/login-action@v3
      with:
        registry: ${{ env.REGISTRY }}
        username: ${{ github.actor }}
        password: ${{ secrets.GITHUB_TOKEN }}
    
    - name: Extract metadata
      id: meta
      uses: docker/metadata-action@v5
      with:
        images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
        tags: |
          type=sha,prefix=
          type=ref,event=branch
          type=semver,pattern={{version}}
    
    - name: Build and push
      uses: docker/build-push-action@v5
      with:
        context: .
        push: true
        tags: ${{ steps.meta.outputs.tags }}
        labels: ${{ steps.meta.outputs.labels }}
        cache-from: type=gha
        cache-to: type=gha,mode=max

  deploy-staging:
    needs: build
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/develop'
    environment:
      name: staging
      url: https://staging.example.com
    
    steps:
    - uses: actions/checkout@v4
    
    - name: Deploy to staging
      run: |
        echo "Deploying ${{ needs.build.outputs.image_tag }} to staging"
        # 这里可以添加实际的部署命令

  deploy-production:
    needs: build
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    environment:
      name: production
      url: https://www.example.com
    
    steps:
    - uses: actions/checkout@v4
    
    - name: Deploy to production
      run: |
        echo "Deploying ${{ needs.build.outputs.image_tag }} to production"

5.4 GitOps 实践

GitOps 是 CI/CD 的进一步演进，核心理念是：Git 是单一事实来源。

应用代码仓库                    配置仓库（K8s manifests）
     │                               │
     ▼                               ▼
  开发提交                      更新镜像版本
     │                               │
     ▼                               ▼
  CI 流水线                    GitOps Operator
     │                          （ArgoCD/Flux）
     ▼                               │
 构建镜像并推送                       ▼
     │                         自动同步到集群
     └───────────────────────────────┘

# ArgoCD Application 定义
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/k8s-configs.git
    targetRevision: HEAD
    path: apps/myapp/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true       # 自动清理已删除的资源
      selfHeal: true    # 自动修复漂移
    syncOptions:
    - CreateNamespace=true

GitOps 的优势：

版本控制：所有变更都有记录，可追溯、可审计
自动同步：集群状态自动与 Git 保持一致
漂移检测：手动修改集群会被检测并自动恢复
多环境管理：通过不同分支/目录管理多套环境

六、部署策略详解

代码准备好后，如何部署到生产环境？这涉及到部署策略的选择。不同的策略适用于不同的场景，核心目标是在降低风险的同时保证服务可用性。

6.1 滚动更新（Rolling Update）

逐步用新版本替换旧版本
始终保持一定数量的实例在线
平滑过渡，用户无感知

[ v1 v1 v1 v1 ] → [ v1 v1 v1 v2 ] → [ v1 v1 v2 v2 ] → [ v1 v2 v2 v2 ] → [ v2 v2 v2 v2 ]

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1         # 更新过程中最多多 1 个 Pod
      maxUnavailable: 0   # 更新过程中最少保持所有 Pod 可用

零停机，服务持续可用
资源利用率高，不需要额外机器
出问题可快速回滚

更新期间新旧版本共存，需要考虑兼容性
回滚需要时间，不是瞬间完成

6.2 蓝绿部署（Blue-Green）

维护两套完整的环境：蓝环境和绿环境
新版本部署到空闲环境，充分验证
流量切换到新环境，瞬间完成

蓝环境(v1) ←── 流量 ──→ 绿环境(空闲)
                        部署新版本 v2
蓝环境(v1)      流量切换      绿环境(v2)

# 蓝色版本
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
---
# 绿色版本
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
---
# Service 通过切换 selector 实现流量切换
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
    version: blue  # 切换到 green 即可完成蓝绿切换
  ports:
  - port: 80

切换瞬间完成，用户无感知
回滚只需切换流量，秒级完成
新旧版本完全隔离，便于对比验证

需要双倍资源，成本较高
数据库迁移需要额外处理

6.3 金丝雀发布（Canary）

先将新版本部署到小部分用户（如 5%）
观察关键指标（错误率、延迟、业务指标）
确认无问题后逐步扩大范围
出问题立即回滚，影响范围有限

[ v1 v1 v1 v1 ] → [ v1 v1 v1 v2 ] → 观察 → [ v1 v1 v2 v2 ] → [ v2 v2 v2 v2 ]
                        ↑ 5%流量              ↑ 50%流量

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp
  http:
  - route:
    - destination:
        host: myapp
        subset: stable
      weight: 95    # 95% 流量到稳定版本
    - destination:
        host: myapp
        subset: canary
      weight: 5     # 5% 流量到金丝雀版本

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp-rollout
spec:
  replicas: 10
  strategy:
    canary:
      steps:
      - setWeight: 5      # 5% 流量
      - pause: {duration: 10m}  # 暂停 10 分钟观察
      - setWeight: 20     # 20% 流量
      - pause: {duration: 10m}
      - setWeight: 50     # 50% 流量
      - pause: {duration: 10m}
      - setWeight: 80     # 80% 流量
      - pause: {duration: 10m}
  selector:
    matchLabels:
      app: myapp
  template:
    # ... Pod 模板

风险可控，问题影响范围小
真实环境验证，比测试环境更可靠
可以结合 A/B 测试，收集用户反馈

需要精细的流量控制能力
监控和告警要足够完善
持续时间较长

6.4 策略选择指南

策略	资源消耗	风险程度	回滚速度	适用场景
滚动更新	低	中	中	日常发布
蓝绿部署	高	低	快	关键服务、大版本
金丝雀	中	最低	快	大流量、高风险变更

常规发布 → 滚动更新
重要版本 → 蓝绿 + 金丝雀（先蓝绿部署，再逐步切流量）
紧急修复 → 滚动更新 + 快速回滚
高风险变更 → 金丝雀 + 自动化回滚（基于监控指标）

选择策略时，需要在资源成本、风险承受能力、团队能力之间找到平衡。

七、容器网络与服务发现

容器网络是容器化中最复杂的领域之一，让我们深入理解它。

7.1 容器网络模型

Docker 采用的网络模型包含三个概念：

Sandbox（沙箱）：包含容器的网络栈配置（接口、路由表、DNS）
Endpoint（端点）：沙箱连接到网络的接口
Network（网络）：一组可相互通信的端点

Kubernetes 采用的标准，更简单：

容器创建时调用 CNI 插件配置网络
容器销毁时调用 CNI 插件清理网络
插件负责分配 IP、创建网络设备、配置路由

7.2 Docker 网络模式

# 每个容器有独立 IP，通过网桥通信
docker run -d --name web1 nginx
docker run -d --name web2 nginx

# 查看网络
docker network inspect bridge

网络拓扑：

┌─────────────────────────────────────┐
│           宿主机                     │
│  ┌──────────┐    ┌──────────┐      │
│  │  web1    │    │  web2    │      │
│  │172.17.0.2│    │172.17.0.3│      │
│  └────┬─────┘    └────┬─────┘      │
│       │               │            │
│       └───────┬───────┘            │
│               │                    │
│        ┌──────▼──────┐             │
│        │  docker0    │ 172.17.0.1  │
│        │  (网桥)      │             │
│        └──────┬──────┘             │
│               │                    │
│        ┌──────▼──────┐             │
│        │    eth0     │             │
│        └─────────────┘             │
└─────────────────────────────────────┘

# 容器直接使用宿主机网络
docker run -d --network host nginx

# 此时容器没有独立 IP，直接使用宿主机端口

# 完全隔离，没有网络
docker run -d --network none alpine

7.3 Kubernetes 网络

所有 Pod 不经 NAT 就能相互通信
所有 Node 都能与所有 Pod 通信
Pod 看到的自己 IP 和别人看到的它的 IP 是一样的

同一个 Pod 内的容器共享网络命名空间：

# Pod 内的两个容器
spec:
  containers:
  - name: app
    image: myapp
    ports:
    - containerPort: 8080
  - name: sidecar
    image: log-collector
    # 可以直接访问 localhost:8080

Service 通过 kube-proxy 实现，有三种模式：

userspace：kube-proxy 在用户空间代理流量（已废弃）
iptables：通过 iptables 规则做 DNAT（默认）
IPVS：通过 IPVS 做负载均衡（高性能）

iptables 模式的流量路径：

Client → ClusterIP:Port
         ↓
    iptables DNAT
         ↓
    Pod IP:Port

                    ┌─────────────────┐
    外部流量 ────────▶│  Ingress        │
                    │  Controller     │
                    └────────┬────────┘
                             │
              ┌──────────────┼──────────────┐
              ▼              ▼              ▼
        ┌─────────┐   ┌─────────┐   ┌─────────┐
        │ Service │   │ Service │   │ Service │
        │  (api)  │   │ (web)   │   │ (admin) │
        └────┬────┘   └────┬────┘   └────┬────┘
             │             │             │
        ┌────▼────┐   ┌────▼────┐   ┌────▼────┐
        │   Pods  │   │   Pods  │   │   Pods  │
        └─────────┘   └─────────┘   └─────────┘

7.4 Service Mesh（服务网格）

当服务数量增多，服务间通信变得复杂，Service Mesh 应运而生。

┌────────────────────────────────────────────────────┐
│                    Istio 控制平面                   │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐         │
│  │  Pilot   │  │  Citadel │  │ Galley   │         │
│  │ (流量管理)│  │ (安全)    │  │ (配置)   │         │
│  └──────────┘  └──────────┘  └──────────┘         │
└─────────────────────┬──────────────────────────────┘
                      │ 下发配置
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
   ┌─────────┐   ┌─────────┐   ┌─────────┐
   │ Pod A   │   │ Pod B   │   │ Pod C   │
   │┌───────┐│   │┌───────┐│   │┌───────┐│
   ││Envoy  ││   ││Envoy  ││   ││Envoy  ││
   ││Proxy  ││   ││Proxy  ││   ││Proxy  ││
   │└───┬───┘│   │└───┬───┘│   │└───┬───┘│
   │    │    │   │    │    │   │    │    │
   │┌───▼───┐│   │┌───▼───┐│   │┌───▼───┐│
   ││ App   ││   ││ App   ││   ││ App   ││
   │└───────┘│   │└───────┘│   │└───────┘│
   └─────────┘   └─────────┘   └─────────┘

流量管理：金丝雀发布、故障注入、流量镜像
安全：mTLS 加密、身份认证、授权策略
可观测性：分布式追踪、指标收集、访问日志

# Istio 流量管理示例
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

八、存储与数据持久化

容器是临时的，如何持久化数据？

8.1 Docker 存储机制

Docker 使用存储驱动管理镜像层和容器层：

Overlay2：现代默认驱动，性能最佳
Device Mapper：早期驱动，性能较差
Btrfs/ZFS：文件系统级支持

# 创建命名卷
docker volume create mydata

# 挂载到容器
docker run -v mydata:/app/data myapp

# 查看卷信息
docker volume inspect mydata

# 挂载宿主机目录
docker run -v /host/path:/container/path myapp

# 挂载到内存（临时数据）
docker run --tmpfs /tmp myapp

8.2 Kubernetes 存储体系

用户/开发者              集群管理员
     │                       │
     ▼                       ▼
┌─────────┐            ┌──────────┐
│   PVC   │  请求      │    PV    │  提供
│ (声明)  │ ─────────▶ │  (资源)  │
└─────────┘            └──────────┘
                             │
                             ▼
                      ┌──────────────┐
                      │ StorageClass │
                      │  (存储类)     │
                      └──────────────┘

# StorageClass 定义
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
---
# PVC 自动创建 PV
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-claim
spec:
  storageClassName: fast-ssd
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

有状态应用需要稳定的存储和网络标识：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: database
spec:
  serviceName: database
  replicas: 3
  template:
    spec:
      containers:
      - name: postgres
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:  # 每个 Pod 自动创建 PVC
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi

StatefulSet 保证：

Pod 有稳定的网络标识：database-0, database-1, database-2
每个 Pod 有独立的 PVC，数据不丢失
按顺序创建和删除（0 → 1 → 2）

九、容器安全最佳实践

容器化带来了便利，但也引入了新的安全挑战。

7.1 镜像安全

# ✅ 使用官方镜像，指定版本
FROM node:18.19.0-alpine3.19

# ❌ 不要使用 latest
FROM node:latest

# 使用 distroless 或 alpine
FROM gcr.io/distroless/nodejs18-debian11
# 或
FROM alpine:3.19

# 使用 Trivy 扫描漏洞
trivy image myapp:1.0.0

# CI 中集成
trivy image --exit-code 1 --severity HIGH,CRITICAL myapp:1.0.0

7.2 运行时安全

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    readOnlyRootFilesystem: true
    allowPrivilegeEscalation: false
    capabilities:
      drop:
      - ALL

resources:
  limits:
    memory: "512Mi"
    cpu: "500m"
  requests:
    memory: "256Mi"
    cpu: "250m"

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-network-policy
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
    ports:
    - protocol: TCP
      port: 5432

7.3 密钥管理

# ✅ 使用 Kubernetes Secret
env:
- name: DATABASE_PASSWORD
  valueFrom:
    secretKeyRef:
      name: app-secret
      key: password

# 或使用外部密钥管理系统（Vault、AWS Secrets Manager）

十、容器化实践案例

10.1 微服务架构迁移案例

┌─────────────────────────────────────┐
│          单体应用                    │
│  ┌───────────────────────────────┐  │
│  │ 用户 │ 商品 │ 订单 │ 支付 │ 库存 │  │
│  └───────────────────────────────┘  │
│  ┌───────────────────────────────┐  │
│  │        MySQL 数据库            │  │
│  └───────────────────────────────┘  │
└─────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│                     Kubernetes 集群                      │
│                                                         │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐   │
│  │ 用户服务 │  │ 商品服务 │  │ 订单服务 │  │ 支付服务 │   │
│  │ (3 pods)│  │ (5 pods)│  │ (5 pods)│  │ (3 pods)│   │
│  └────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘   │
│       │            │            │            │         │
│  ┌────▼────────────▼────────────▼────────────▼────┐   │
│  │              Service Mesh (Istio)               │   │
│  └─────────────────────┬───────────────────────────┘   │
│                        │                               │
│  ┌─────────────────────▼───────────────────────────┐   │
│  │               Ingress Controller                │   │
│  └─────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘

阶段一：容器化

- 为每个模块编写 Dockerfile

- 建立私有镜像仓库 - 本地测试容器化应用

阶段二：Kubernetes 部署

- 编写 Deployment、Service 配置

- 配置 ConfigMap、Secret - 设置资源限制和健康检查

阶段三：服务拆分

- 逐步拆分数据库（每个服务独立数据库）

- 引入消息队列解耦 - 实现服务间通信（gRPC/HTTP）

阶段四：完善基础设施

- 部署 Service Mesh

- 配置分布式追踪 - 实现自动化 CI/CD

指标	迁移前	迁移后	提升
部署频率	每周 1 次	每天 5+ 次	35x
故障恢复时间	2 小时	5 分钟	24x
资源利用率	15%	60%	4x
新功能上线周期	2 个月	1 周	8x

10.2 CI/CD 完整案例

myapp/
├── src/                 # 源代码
├── Dockerfile           # 构建配置
├── docker-compose.yml   # 本地开发
├── k8s/                 # Kubernetes 配置
│   ├── base/           # 基础配置
│   └── overlays/       # 环境差异化配置
│       ├── staging/
│       └── production/
├── .gitlab-ci.yml      # CI/CD 配置
└── scripts/
    └── deploy.sh       # 部署脚本

stages:
  - lint
  - test
  - build
  - security
  - deploy-staging
  - integration-test
  - deploy-production

variables:
  IMAGE_NAME: registry.company.com/myapp
  HELM_CHART: charts/myapp

# 代码检查
lint:
  stage: lint
  image: node:18-alpine
  script:
    - npm ci
    - npm run lint
    - npm run type-check

# 单元测试
unit-test:
  stage: test
  image: node:18-alpine
  script:
    - npm ci
    - npm run test:unit -- --coverage
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml
  coverage: '/Lines\s*:\s*(\d+.\d+)%/'

# 集成测试
integration-test:
  stage: test
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker-compose -f docker-compose.test.yml up -d
    - docker wait test-runner
    - docker logs test-runner
  after_script:
    - docker-compose -f docker-compose.test.yml down -v

# 构建镜像
build:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker login -u $REGISTRY_USER -p $REGISTRY_PASSWORD registry.company.com
    - docker build 
        --build-arg BUILD_DATE=$(date -u +'%Y-%m-%dT%H:%M:%SZ')
        --build-arg VERSION=$CI_COMMIT_TAG
        -t $IMAGE_NAME:$CI_COMMIT_SHA .
    - docker push $IMAGE_NAME:$CI_COMMIT_SHA
  only:
    - main
    - tags

# 安全扫描
security-scan:
  stage: security
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --severity HIGH,CRITICAL $IMAGE_NAME:$CI_COMMIT_SHA
  allow_failure: true  # 不阻断流水线，但记录问题

# 部署到 staging
deploy-staging:
  stage: deploy-staging
  image: alpine/k8s:latest
  script:
    - kubectl config use-context staging-cluster
    - helm upgrade --install myapp $HELM_CHART
        --namespace staging
        --set image.tag=$CI_COMMIT_SHA
        --values k8s/overlays/staging/values.yaml
    - kubectl rollout status deployment/myapp -n staging --timeout=300s
  environment:
    name: staging
    url: https://staging.company.com
  only:
    - main

# E2E 测试
e2e-test:
  stage: integration-test
  image: cypress/included:latest
  script:
    - npm ci
    - npm run e2e -- --config baseUrl=https://staging.company.com
  artifacts:
    when: always
    paths:
      - cypress/videos/
      - cypress/screenshots/
  only:
    - main

# 部署到生产
deploy-production:
  stage: deploy-production
  image: alpine/k8s:latest
  script:
    - kubectl config use-context production-cluster
    # 金丝雀发布：先部署 10% 流量
    - helm upgrade --install myapp-canary $HELM_CHART
        --namespace production
        --set image.tag=$CI_COMMIT_SHA
        --set replicaCount=1
        --set canary.enabled=true
        --values k8s/overlays/production/values.yaml
    # 等待 10 分钟观察
    - sleep 600
    # 检查错误率
    - ./scripts/check-error-rate.sh || exit 1
    # 全量发布
    - helm upgrade --install myapp $HELM_CHART
        --namespace production
        --set image.tag=$CI_COMMIT_SHA
        --values k8s/overlays/production/values.yaml
    # 清理金丝雀
    - helm uninstall myapp-canary -n production
  environment:
    name: production
    url: https://www.company.com
  when: manual
  only:
    - tags

10.3 故障排查案例

查看 Pod 状态

kubectl describe pod myapp-xxx
# 发现：Last State: Terminated with exit code 137
# exit code 137 = 128 + 9 = 被 SIGKILL 杀死

检查资源使用

kubectl top pod myapp-xxx
# 内存使用接近 limit

查看事件

kubectl get events --field-selector involvedObject.name=myapp-xxx
# OOMKilled

resources:
  requests:
    memory: "256Mi"
  limits:
    memory: "512Mi"  # 增加限制

查看网络策略

kubectl get networkpolicy

检查 Service Mesh 日志

kubectl logs -l app=myapp -c istio-proxy

使用分布式追踪

jaeger-ui 查看调用链

添加超时和重试
优化数据库查询
添加熔断器

# Istio 超时和重试配置
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
  http:
  - route:
    - destination:
        host: service-b
    timeout: 5s
    retries:
      attempts: 3
      perTryTimeout: 2s

十一、常见问题与解决方案

容器化环境需要更强大的监控能力。

8.1 三大支柱

# Fluent Bit 收集容器日志
apiVersion: fluentbit.fluent.io/v1alpha2
kind: FluentBit
metadata:
  name: fluent-bit
spec:
  image: kubesphere/fluent-bit:v2.0.8
  positionDB:
    hostPath:
      path: /var/log/flb-db
  fluentBitConfigSelector:
    matchLabels:
      config: fluent-bit-config

# Prometheus ServiceMonitor
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: myapp-monitor
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: metrics
    interval: 30s

# OpenTelemetry Collector
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: otel-collector
spec:
  config: |
    receivers:
      otlp:
        protocols:
          grpc:
          http:
    exporters:
      jaeger:
        endpoint: jaeger-collector:14250
        tls:
          insecure: true
    service:
      pipelines:
        traces:
          receivers: [otlp]
          exporters: [jaeger]

8.2 告警规则

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: myapp-alerts
spec:
  groups:
  - name: myapp.rules
    rules:
    - alert: HighErrorRate
      expr: |
        sum(rate(http_requests_total{status=~"5.."}[5m])) 
        / sum(rate(http_requests_total[5m])) > 0.05
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: High error rate detected
        description: Error rate is {{ $value | humanizePercentage }}

十二、总结与展望

容器化部署的演进，本质上是运维的标准化和自动化过程。从手动操作到自动化流水线，我们经历了三个关键跨越：

标准化：容器镜像让环境定义标准化，告别"我这边是好的"
编排化：Kubernetes 让集群管理标准化，实现自愈和自动调度
流水线化：CI/CD 让发布流程标准化，从代码到部署全自动

效率：部署从小时级到分钟级，甚至秒级
稳定：环境一致，减少因环境差异导致的诡异问题
灵活：快速扩缩容，从容应对流量变化
可靠：多种部署策略，降低发布风险，支持快速回滚

入门：Docker 基础 → Docker Compose
进阶：Kubernetes 核心概念 → 实践部署
高级：CI/CD 流水线 → GitOps
专家：Service Mesh → Platform Engineering

容器化不是终点，而是现代基础设施的起点：

Serverless：进一步抽象基础设施，按需运行，按使用付费
GitOps：以 Git 为单一事实来源，声明式管理一切
Service Mesh：服务间通信下沉到基础设施层，更精细的流量控制
Platform Engineering：构建内部开发者平台，提升开发体验
eBPF：内核级可观测性和网络，更高效、更安全

理解这些原理，才能在技术演进中保持清醒，做出正确的架构决策。技术会变，但核心理念——标准化、自动化、可观测——始终不变。

系列七 · 第1篇：服务注册与发现
系列七 · 第2篇：负载均衡
系列七 · 第3篇：配置中心
系列七 · 第4篇：服务网关
系列七 · 第5篇：日志与监控
系列七 · 第6篇：容器化部署（本文）

返回文章列表返回首页

💬 评论 (0)

0/500

排序：

容器化部署：从手动到自动

一、部署方式的演进

1.1 物理机时代

1.2 虚拟机时代

1.3 容器时代

二、容器化的技术原理

2.1 容器 vs 虚拟机：本质区别

2.2 Namespace：资源隔离的魔法

2.3 Cgroups：资源限制的紧箍咒

2.4 UnionFS：镜像分层的秘密

2.5 容器运行时：从 Docker 到 containerd

三、Docker 实践：从零开始

3.0 Docker 架构与工作原理

3.1 Dockerfile 最佳实践

3.1 Dockerfile 最佳实践

3.2 镜像优化技巧

3.3 Docker Compose：多容器编排

四、Kubernetes：容器编排之王

4.1 为什么需要 Kubernetes

4.2 Kubernetes 架构详解

4.3 核心概念详解

4.4 实践案例：完整的应用部署

4.5 容器编排策略

五、CI/CD 流水线集成

5.1 CI/CD 是什么

5.2 完整流水线示例

5.3 GitHub Actions 示例

5.4 GitOps 实践

六、部署策略详解

6.1 滚动更新（Rolling Update）

6.2 蓝绿部署（Blue-Green）

6.3 金丝雀发布（Canary）

6.4 策略选择指南

七、容器网络与服务发现

7.1 容器网络模型

7.2 Docker 网络模式

7.3 Kubernetes 网络

7.4 Service Mesh（服务网格）

八、存储与数据持久化

8.1 Docker 存储机制

8.2 Kubernetes 存储体系

九、容器安全最佳实践

7.1 镜像安全

7.2 运行时安全

7.3 密钥管理

十、容器化实践案例

10.1 微服务架构迁移案例

10.2 CI/CD 完整案例

10.3 故障排查案例

十一、常见问题与解决方案

8.1 三大支柱

8.2 告警规则

十二、总结与展望

💬 评论 (0)

觉得有帮助？分享给更多人！