基于Kubernetes构建企业Jenkins CI/CD平台

1.蓝绿发布

项目逻辑上分为AB组，在项目升级时，首先把A组从负 载均衡中摘除，进行新版本的部署。

B组仍然继续提供 服务。A组升级完成上线，B组从负载均衡中摘除。

 

特点：

• 策略简单
• 升级/回滚速度快
• 用户无感知，平滑过渡

 

缺点：

• 需要两倍以上服务器资源
• 短时间内浪费一定资源成本

 

2.灰度发布

灰度发布：只升级部分服务，即让一部分用户继续用 老版本，一部分用户开始用新版本，如果用户对新版 本没有什么意见，那么逐步扩大范围，把所有用户都 迁移到新版本上面来。

特点：

• 保证整体系统稳定性
• 用户无感知，平滑过渡

 

缺点：

• 自动化要求高

 

3.滚动发布

滚动发布：

每次只升级一个或多个服务，升级完成 后加入生产环境，不断执行这个过程，直到集群中 的全部旧版升级新版本。 特点：

• 用户无感知，平滑过渡

缺点：

• 部署周期长
• 发布策略较复杂
• 不易回滚

 

4.发布流程

 

5在Kubernetes中部署Jenkins

https://github.com/jenkinsci/kubernetes-plugin/tree/fc40c869edfd9e3904a9a56b0f80c5a25e988fa1/src/main/kubernetes

 

mkdir k8s-ci/jenkins -p && cd k8s-cli/jenkins

rabc.yml

---
# 创建名为jenkins的ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins

---
# 创建名为jenkins的Role，授予允许管理API组的资源Pod
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: jenkins
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create","delete","get","list","patch","update","watch"]
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create","delete","get","list","patch","update","watch"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get","list","watch"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get"]

---
# 将名为jenkins的Role绑定到名为jenkins的ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: jenkins
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role