一、为什么选择Kubernetes来搭建CI/CD流水线
现在很多团队都在用Kubernetes管理容器化应用，它就像个智能管家，能自动帮我们处理应用的部署、扩容和故障恢复。把CI/CD流水线建在Kubernetes上特别合适，主要有三个好处：
首先，环境一致性特别好。开发、测试、生产环境都用同样的容器镜像，再也不会出现"在我机器上是好的"这种问题。比如我们用同一个Docker镜像打包应用，在任何环境运行效果都一样。
其次，资源利用率高。Kubernetes可以动态分配资源，构建任务来了就自动扩容，没任务时就释放资源。比如我们公司之前用的物理机，现在改用Kubernetes后，服务器成本直接降了60%。
最后，故障恢复能力强。如果构建节点出问题，Kubernetes会自动把任务迁移到健康节点。上周我们有个构建节点突然宕机，系统自动在其他节点重新运行任务，开发团队甚至都没察觉到异常。
二、搭建基础CI/CD流水线的具体步骤
让我们用一个实际项目来演示。假设我们有个用Node.js写的Web应用，现在要给它搭建CI/CD流水线。
技术栈说明：全部示例基于Kubernetes + GitLab CI + Docker技术栈
首先准备一个简单的Kubernetes部署文件：
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp
spec:
replicas: 2
selector:
matchLabels:
app: webapp
template:
metadata:
labels:
app: webapp
spec:
containers:
- name: webapp
image: registry.example.com/webapp:latest # 使用私有镜像仓库
ports:
- containerPort: 3000
resources:
limits:
memory: "512Mi"
cpu: "500m" # 限制CPU使用量
然后在项目根目录创建.gitlab-ci.yml文件：
# .gitlab-ci.yml
stages:
- build
- test
- deploy
build_image:
stage: build
script:
- docker build -t registry.example.com/webapp:$CI_COMMIT_SHA . # 用commit哈希作为镜像标签
- docker push registry.example.com/webapp:$CI_COMMIT_SHA
only:
- master # 只在master分支触发
run_tests:
stage: test
script:
- docker run --rm registry.example.com/webapp:$CI_COMMIT_SHA npm test # 运行测试
needs: ["build_image"]
deploy_prod:
stage: deploy
script:
- kubectl apply -f deployment.yaml # 部署到Kubernetes
- kubectl rollout status deployment/webapp # 等待部署完成
when: manual # 需要手动触发生产环境部署
needs: ["run_tests"]
这个流水线已经包含了构建、测试、部署三个基本阶段。每次代码推送到master分支时，会自动构建Docker镜像并运行测试。测试通过后，需要人工确认才会部署到生产环境。
三、常见问题排查指南
在实际使用中，经常会遇到各种问题。下面分享几个我们踩过的坑和解决方法。
问题1：构建镜像时拉取基础镜像失败
错误信息通常是"Error response from daemon: pull access denied"。这是因为Kubernetes节点没有权限拉取私有镜像。解决方法是在Kubernetes中创建docker-registry secret：
kubectl create secret docker-registry regcred \
--docker-server=registry.example.com \
--docker-username=yourname \
--docker-password=yourpassword \
--docker-email=youremail@example.com
然后在deployment.yaml中引用这个secret：
spec:
containers:
- name: webapp
image: registry.example.com/webapp:latest
imagePullSecrets: # 添加这行
- name: regcred
问题2：部署后应用无法访问
首先检查Pod状态：
kubectl get pods -l app=webapp
如果Pod是Running状态但无法访问，可能是Service配置问题。确保有对应的Service：
# service.yaml
apiVersion: v1
kind: Service
metadata:
name: webapp-service
spec:
selector:
app: webapp
ports:
- protocol: TCP
port: 80
targetPort: 3000 # 对应容器端口
type: LoadBalancer # 如果是云环境会自动创建负载均衡器
问题3：资源不足导致构建失败
在GitLab Runner的config.toml中添加资源限制：
[[runners]]
executor = "kubernetes"
[runners.kubernetes]
cpu_limit = "1" # 限制CPU
memory_limit = "2Gi" # 限制内存
service_cpu_limit = "500m"
service_memory_limit = "512Mi"
四、高级技巧与优化建议
基础流水线搭建好后，可以考虑以下优化方案：
- 使用Kaniko构建镜像：不需要Docker daemon，更安全
build_image:
stage: build
image: gcr.io/kaniko-project/executor:latest
script:
- /kaniko/executor
--context $CI_PROJECT_DIR
--destination registry.example.com/webapp:$CI_COMMIT_SHA
--cache=true # 启用缓存加速构建
- 添加HPA自动伸缩：根据CPU使用率自动调整Pod数量
# hpa.yaml
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: webapp-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: webapp
minReplicas: 2
maxReplicas: 10
targetCPUUtilizationPercentage: 50 # CPU超过50%就扩容
- 实现蓝绿部署：通过Service切换流量，实现零停机部署
# 先部署新版本
kubectl apply -f deployment-green.yaml
# 测试新版本
kubectl exec -it <green-pod> -- curl localhost:3000/health
# 切换Service指向新版本
kubectl patch svc webapp-service -p '{"spec":{"selector":{"version":"green"}}}'
五、实际应用场景分析
这种基于Kubernetes的CI/CD方案特别适合以下场景：
微服务架构：可以同时管理数十个服务的构建和部署。我们有个客户有50多个微服务，用这套方案后部署时间从2小时缩短到15分钟。
需要频繁发布的项目：电商大促期间，有些团队每天要发布几十次。使用自动伸缩后，既保证了构建速度，又节省了成本。
混合云环境：开发测试用本地Kubernetes集群，生产环境用公有云。通过统一的CI/CD流程，确保环境一致性。
六、技术方案优缺点
优点：
- 环境一致性极高，从开发到生产使用相同的容器镜像
- 资源利用率高，构建节点可以动态伸缩
- 故障自愈能力强，节点故障不影响整体流程
- 扩展性好，可以轻松支持大规模并行构建
缺点：
- 初期学习曲线较陡，需要掌握Kubernetes和CI/CD工具
- 调试复杂，问题可能涉及多个组件
- 对网络要求较高，需要稳定的镜像仓库访问
注意事项：
- 一定要做好资源限制，避免某个构建任务耗尽集群资源
- 生产环境部署建议设置手动批准环节
- 定期清理旧的镜像和构建缓存，避免磁盘爆满
- 为不同项目设置不同的命名空间，实现逻辑隔离
七、总结与展望
基于Kubernetes的CI/CD流水线确实能给研发团队带来很大便利，但也要根据团队实际情况逐步推进。建议从小项目开始试点，积累经验后再推广到核心业务系统。
未来可以探索的方向包括：
- 结合服务网格实现更精细的流量控制
- 使用Argo CD等工具实现GitOps工作流
- 引入机器学习自动优化构建参数
无论采用什么方案，记住CI/CD的最终目标是让团队能够快速、可靠地交付价值。Kubernetes只是帮助我们实现这个目标的工具之一。
评论