【Kubernetes专项】K8s 控制器 Deployment 从入门到企业实战应用

Cyber4K

1019人浏览 · 2026-01-25 09:37:02

Cyber4K · 2026-01-25 09:37:02 发布

十一、K8s 控制器 Deployment 从入门到企业实战应用

Deployment 官方文档：https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

11.1 Deployment 概述、原理及作用

11.1.1 Deployment 概述

Deployment是kubernetes中最常用的资源对象，为ReplicaSet和Pod的创建提供了一种声明式的定义方法，在Deployment对象中描述一个期望的状态，Deployment控制器就会按照一定的控制速率把实际状态改成期望状态，通过定义一个Deployment控制器会创建一个新的ReplicaSet控制器，通过ReplicaSet创建pod，删除Deployment控制器，也会删除Deployment控制器下对应的ReplicaSet控制器和pod资源。

使用Deployment而不直接创建ReplicaSet是因为Deployment对象拥有许多ReplicaSet没有的特性，例如滚动升级、金丝雀发布、蓝绿部署和回滚。

Deployment控制器是建立在rs之上的一个控制器，可以管理多个rs，每次更新镜像版本，都会生成一个新的rs，把旧的rs替换掉，多个rs同时存在，但是只有一个rs运行。

11.1.2 Deployment 工作原理：如何管理 rs 和 pod ？

Deployment可以使用声明式定义，**直接在命令行通过纯命令的方式完成对应资源版本的内容的修改，也就是通过打补丁的方式进行修改；**Deployment能提供滚动式自定义自控制的更新；对Deployment来讲，我们在实现更新时还可以实现控制更新节奏和更新逻辑。

互动：什么叫做更新节奏和更新逻辑呢？

比如说Deployment控制5个pod副本，pod的期望值是5个，但是升级的时候需要额外多几个pod，那我们控制器可以控制在5个pod副本之外还能再增加几个pod副本；比方说能多一个，但是不能少，那么升级的时候就是先增加一个，再删除一个，增加一个删除一个，始终保持pod副本数是5个；还有一种情况，最多允许多一个，最少允许少一个，也就是最多6个，最少4个，第一次加一个，删除两个，第二次加两个，删除两个，依次类推，可以自己控制更新方式，这种滚动更新需要加readinessProbe和livenessProbe探测，确保pod中容器里的应用都正常启动了才删除之前的pod。

11.1.3 Deployment 对象的作用

创建ReplicaSet和Pod
滚动更新
回滚版本
自动且平滑扩缩容
暂停和继续Deployment

滚动更新：不停止就服务的状态下升级

回滚版本：将应用回滚到之前的版本

11.2 Deployment 资源清单文件编写技巧

11.2.1 `spec`字段定义

[root@k8s-master1 ~]# kubectl explain deploy.spec
  minReadySeconds       <integer>
  # k8s在这个时间后在进行升级
  # 如果没有设置，k8s回家设该容器启动起来之后就提供服务
  
  paused        		<boolean>
  # 暂停状态设置，当设置为 true 时：
  # 1.暂停 Deployment 的滚动更新过程
  # 2.即使修改了 Pod 模板（如镜像版本），也不会触发新的滚动更新
  # 3.当前正在进行的滚动更新也会暂停

  progressDeadlineSeconds   <integer>
  #  k8s 在升级过程中有可能由于各种原因升级卡住（这个时候还没有明确的升级失败），比如在拉取被墙的镜像，权限不够等错误。那么这个时候就需要有个 deadline ，在 deadline 之内如果还卡着，那么就上报这个情况，这个时候这个 Deployment 状态就被标记为 False，并且注明原因。但是它并不会阻止 Deployment 继续进行卡住后面的操作。完全由用户进行控制。
  
  replicas      	<integer>
  # 副本数设置
  
  revisionHistoryLimit  	<integer>
  # 保留的历史版本，默认为10个
  
  selector      	<LabelSelector> -required-
  # 标签选择器，选择匹配设定标签的pod
  
  strategy      	<DeploymentStrategy>
  # 更新策略
  
  template      	<PodTemplateSpec> -required-
  # 定义pod模版

11.2.2 `spec.strategy`字段定义

[root@k8s-master1 ~]# kubectl explain deploy.spec.strategy
  rollingUpdate <RollingUpdateDeployment>
  # 滚动更新
  
  type  <string>
  # 类型：
  # 1."Recreate"` --> 重建式更新，定义滚动更新方式，删除一个，更新一个
  # 2."RollingUpdate"` --> 默认策略，滚动更新，定义滚动更新方式，也就是pod能多几个，还是能少几个

11.2.3 `spec.strategy.rollingUpdate`字段定义

[root@k8s-master1 ~]# kubectl explain deploy.spec.strategy.rollingUpdate
  maxSurge      	<IntOrString>（理解为扩增）
  # 更新时，最多允许超过指定副本数有几个
  # 第一种：数值方式
  # 第二种：百分比方式（默认25%，向上取整，5*25%=1.25个 --> 2个）
  
  maxUnavailable    <IntOrString>（理解为缩减）
  # 最多允许几个不可用
  # 第一种：数值方式
  # 第二种：百分比方式（默认25%，向下取整，5*25%=1.25个 --> 1个）
  
# 5个副本数量
replicas： 5
	maxSurge: 25%          5*25%=1.25  -> 5+2=7		# 最多 7 个pod
	maxUnavailable: 25%    5%25%=1.25  -> 5-1=4		# 最少 4 个pod
	
	maxUnavailable =< replicas =< maxSurge

11.2.4 `spec.template`字段定义

[root@k8s-master1 ~]# kubectl explain deploy.spec.template
  metadata      <ObjectMeta>
  # 定义模版的名字
  spec  <PodSpec>
  
# deployment.spec.template为Pod定义的模板，和Pod定义不太一样；
# template中不包含apiVersion和Kind属性，要求必须有metadata
# deployment.spec.template.spec 为容器的属性信息，其他定义内容和Pod一致。

11.2.5 Deployment 使用案例：创建一个web站点

deployment是一个三级结构，deployment管理replicaset，replicaset管理pod

n1 && n2 ]# ctr -n k8s.io images import myapp-blue-v1.tar.gz
n1 && n2 ]# ctr -n=k8s.io images import myapp-blue-v2.tar.gz

# 编写yaml资源文件
[root@k8s-master1 ~]# vim deployment-demo.yaml
apiVersion: apps/v1
kind: Deployment		# 资源类型
metadata:
  name: myapp-v1		# deploy资源的名字
spec:
  replicas: 2			# deploy管理的pod副本数
  selector:				# 标签选择器
    matchLabels:		# matchLabels下定义的标签需要跟template.metadata.labels定义的标签一致
      app: myapp
      version: v1
  template:				# pod资源模版
    metadata:
      labels:
        app: myapp
        version: v1
    spec:
      containers:
      - name: myapp
        image: docker.io/janakiramm/myapp:v1
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        startupProbe:
          httpGet:
            scheme: HTTP
            port: 80
            path: /
          initialDelaySeconds: 20
          periodSeconds: 5
          timeoutSeconds: 10
        livenessProbe:
          httpGet:
            scheme: HTTP
            port: 80
            path: /
          initialDelaySeconds: 20
          periodSeconds: 5
          timeoutSeconds: 10
        readinessProbe:
          httpGet:
            scheme: HTTP
            port: 80
            path: /
          initialDelaySeconds: 20
          periodSeconds: 5
          timeoutSeconds: 10

[root@k8s-master1 ~]# kubectl apply -f deployment-demo.yaml

# 查看deployment资源的状态（这会等一会由于探测的存在）
[root@k8s-master1 ~]# kubectl get deploy
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
myapp-v1   2/2     2            2           26s

1.NAME		# 列出名称空间中deployment的名称。
2.READY		# 显示deployment有多少副本数。它遵循ready/desired的模式。
3.UP-TO-DATE	# 显示已更新到所需状态的副本数。
4.AVAILABLE		# 显示你的可以使用多少个应用程序副本。
5.AGE		# 显示应用程序已运行的时间。

# 由于创建deploy资源自然而然就会创建rs资源，查看一下状态
[root@k8s-master1 ~]# kubectl get rs
NAME                  DESIRED   CURRENT   READY   AGE
myapp-v1-7b4647c584   2         2         2       39s

# 查看pod资源并测试
[root@k8s-master1 ~]# kubectl get pods -owide
[root@k8s-master1 ~]# curl 10.244.147.215:80/	# 进行测试
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Sample Deployment</title>
  <style>
    body {
      color: #ffffff;
      background-color: blue;
      font-family: Arial, sans-serif;
      font-size: 14px;
    }

    h1 {
      font-size: 500%;
      font-weight: normal;
      margin-bottom: 0;
    }

    h2 {
      font-size: 200%;
      font-weight: normal;
      margin-bottom: 0;
    }
  </style>
</head>
<body>
  <div align="center">
    <h1>Welcome to V1 of the web application</h1>
    <h2>This application will be deployed on Kubernetes.</h2>
  </div>
</body>
</html>

请注意，ReplicaSet的名称始终设置为[DEPLOYMENT-NAME]-[RANDOM-STRING]。RANDOM-STRING是随机生成的

11.3 Deployment 实现 pod 扩缩容

11.3.1 实现扩容

[root@k8s-master1 ~]# vim deployment-demo.yaml
...
spec:
  replicas: 6		# 2 -> 6
...

[root@k8s-master1 ~]# kubectl apply -f deployment-demo.yaml
[root@k8s-master1 ~]# kubectl get deploy
[root@k8s-master1 ~]# kubectl get rs
[root@k8s-master1 ~]# kubectl get pods

11.3.2 实现缩容

[root@k8s-master1 ~]# vim deployment-demo.yaml
...
spec:
  replicas: 2		# 6 -> 2
...

[root@k8s-master1 ~]# kubectl apply -f deployment-demo.yaml
[root@k8s-master1 ~]# kubectl get deploy
[root@k8s-master1 ~]# kubectl get rs
[root@k8s-master1 ~]# kubectl get pods

11.4 Deployment 实现滚动更新

11.4.1 滚动更新概述

滚动更新是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式，一次滚动发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义），例如第一批1台，第二批10%，第三批50%，第四批100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的。

11.4.2 实现滚动更新

[root@k8s-master1 ~]# kubectl explain deploy.spec.strategy
  rollingUpdate <RollingUpdateDeployment>
  # 滚动更新
  
  type  <string>
  # 类型：
  # 1."Recreate"` --> 重建式更新，定义滚动更新方式，删除一个，更新一个
  # 2."RollingUpdate"` --> 默认策略，滚动更新，定义滚动更新方式，也就是pod能多几个，还是能少几个
  
[root@k8s-master1 ~]# kubectl explain deploy.spec.strategy.rollingUpdate
  maxSurge      	<IntOrString>（理解为扩增）
  # 更新时，最多允许超过指定副本数有几个
  # 第一种：数值方式
  # 第二种：百分比方式（默认25%，向上取整，5*25%=1.25个 --> 2个）
  
  maxUnavailable    <IntOrString>（理解为缩减）
  # 最多允许几个不可用
  # 第一种：数值方式
  # 第二种：百分比方式（默认25%，向下取整，5*25%=1.25个 --> 1个）
  
# 5个副本数量
replicas： 5
	maxSurge: 25%          5*25%=1.25  -> 5+2=7		# 最多 7 个pod
	maxUnavailable: 25%    5%25%=1.25  -> 5-1=4		# 最少 4 个pod
	
	maxUnavailable =< replicas =< maxSurge

11.4.3 示例演示

# 准备yaml文件并查看describe描述
[root@k8s-master1 ~]# vim deployment-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    apps: deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: v1
  template:
    metadata:
      labels:
        app: myapp
        version: v1
    spec:
      containers:
      - name: myapp
        image: docker.io/janakiramm/myapp:v1
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        startupProbe:
          httpGet:
            scheme: HTTP
            port: 80
            path: /
          initialDelaySeconds: 20
          periodSeconds: 5
          timeoutSeconds: 10
        livenessProbe:
          httpGet:
            scheme: HTTP
            port: 80
            path: /
          initialDelaySeconds: 20
          periodSeconds: 5
          timeoutSeconds: 10
        readinessProbe:
          httpGet:
            scheme: HTTP
            port: 80
            path: /
          initialDelaySeconds: 20
          periodSeconds: 5
          timeoutSeconds: 10
          
[root@k8s-master1 ~]# kubectl apply -f deployment-demo.yaml
[root@k8s-master1 ~]# kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
myapp-7b4647c584-c72rv   1/1     Running   0          33s
myapp-7b4647c584-jsbxg   1/1     Running   0          33s
myapp-7b4647c584-qns66   1/1     Running   0          33s

# 查看详细信息
[root@k8s-master1 ~]# kubectl describe deploy myapp

# 更改replicas的数目
[root@k8s-master1 ~]# vim deployment-demo.yaml
...
  template:
    metadata:
      labels:
        app: myapp
        version: v1
    spec:
      containers:
      - name: myapp
        image: docker.io/janakiramm/myapp:v2	# v1 --> v2
...

[root@k8s-master1 ~]# kubectl apply -f deployment-demo.yaml

# 那么，什么是滚动更新呢，可以启动监控命令查看
[root@k8s-master1 ~]# kubectl get pods -w
1.pending表示正在进行调度
2.ContainerCreating表示正在创建一个pod
3.running表示运行一个pod
4.running起来一个pod之后再Terminating（停掉）一个pod，以此类推，直到所有pod完成滚动升级

# 可以看到rs有两个，上面那个是升级之前的，已经被停掉，但是可以随时回滚 
[root@k8s-master1 ~]# kubectl get rs
NAME               DESIRED   CURRENT   READY   AGE
myapp-7b4647c584   0         0         0       11m
myapp-8479994f8c   3         3         3       4m25s

# 查看控制器的历史滚动版本
[root@k8s-master1 ~]# kubectl rollout history deploy myapp
deployment.apps/myapp
REVISION  CHANGE-CAUSE
1         <none>		# v1
2         <none>		# v2

# 回滚到之前的v1版本
[root@k8s-master1 ~]# kubectl rollout undo deploy/myapp --to-revision=1

11.4.4 回滚命令介绍

# 回滚 Deployment 到上一个版本
kubectl rollout undo deployment/<deployment-name>

# 先查看历史版本
kubectl rollout history deployment/<deployment-name>

# 回滚到指定版本
kubectl rollout undo deployment/<deployment-name> --to-revision=<revision-number>

# 查看更新历史（详细信息）
kubectl rollout history deployment/<deployment-name> --revision=<revision-number>

# 查看当前更新状态
kubectl rollout status deployment/<deployment-name>

# 查看所有版本历史（包括变更内容）
kubectl rollout history deployment/<deployment-name> --revision=<revision-number>

11.5 自定义滚动更新策略

11.5.1 两个参数`maxSurge`和`maxUnavailable`字段定义

maxSurge和maxUnavailable用来控制滚动更新的更新策略

取值范围：[0,副本数] 但是注意：两个参数不能同时为0

]# kubectl explain deploy.spec.strategy.rollingUpdate
  maxSurge      	<IntOrString>（理解为扩增）
  # 更新时，最多允许超过指定副本数有几个
  # 第一种：数值方式
  # 第二种：百分比方式（默认25%，向上取整，5*25%=1.25个 --> 2个）
  
  maxUnavailable    <IntOrString>（理解为缩减）
  # 最多允许几个不可用
  # 第一种：数值方式
  # 第二种：百分比方式（默认25%，向下取整，5*25%=1.25个 --> 1个）
  
# 5个副本数量
replicas： 5
	maxSurge: 25%          5*25%=1.25  -> 5+2=7		# 最多 7 个pod
	maxUnavailable: 25%    5%25%=1.25  -> 5-1=4		# 最少 4 个pod
	
	maxUnavailable =< replicas =< maxSurge
	# 这两个选项不能同时为零

11.5.2 生产建议配置

# 生产建议默认配置：
	maxSurge: 1
	maxUnavailable: 0

即**“一上一下，先上后下”最平滑原则**：

1个新版本pod ready（结合readiness）后，才销毁旧版本pod。此配置适用场景是平滑更新、保证服务平稳，但也有缺点，就是**“太慢”了**。

maxSurge:
	和期望的副本数比，超过期望副本数最大比例（或最大值），这个值调的越大，副本更新速度越快。

maxUnavailable:
	和期望的副本数比，不可用副本数最大比例（或最大值），这个值越小，越能保证服务稳定，更新越平滑；

11.5.3 `spec.strategy.type`字段

[root@k8s-master1 ~]# kubectl explain deploy.spec.strategy.type
     - `"Recreate"`			# 重建（非常危险！！！）
     - `"RollingUpdate"`	# 根据策略滚动更新

11.5.3.1 `spec.strategy.type.RollingUpdate`示例

修改更新策略：maxSurge=1，maxUnavailable=1

]# kubectl patch deployment myapp-v1 -p '{"spec":{"strategy":{"rollingUpdate": {"maxSurge":1,"maxUnavailable":0}}}}' 

# 这种太过于繁琐且易错

# 推荐还是编写yaml文件还是更好！
# vim deployment-demo.yaml
...
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: v1
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate			# 选择类型
...
    spec:
      containers:
      - name: myapp
        image: docker.io/janakiramm/myapp:v2	# 更改一下镜像版本 v1 --> v2
  

]# vim deployment-demo.yaml
]# kubectl apply -f deployment-demo.yaml

# 打开另外一个终端去观察
]# kubectl get pods -owide -w

11.5.3.2 `spec.strategy.type.Recrate`示例

# vim deployment-demo.yaml
...
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: v1
  strategy:
    type: Recreate		# 选择类型
...
    spec:
      containers:
      - name: myapp
        image: docker.io/janakiramm/myapp:v1	# 更改一下镜像版本 v2 --> v1
  

]# vim deployment-demo.yaml
]# kubectl apply -f deployment-demo.yaml

# 打开另外一个终端去观察
]# kubectl get pods -owide -w
recreate这种更新策略，会把之前的所有pod都删除，再创建新的pod，风险很大

11.6 蓝绿部署

11.6.1 什么是蓝绿部署？

蓝绿部署中，一共有两套系统：**一套是正在提供服务系统，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的、正在运行的系统，只是系统版本和对外服务情况不同。**开发新版本，要用新版本替换线上的旧版本，在线上的系统之外，搭建了一个使用新版本代码的全新系统。

蓝色系统不对外提供服务，用来做什么呢？

用来做发布前测试，测试过程中发现任何问题，可以直接在蓝色系统上修改，不干扰用户正在使用的系统。（注意，两套系统没有耦合的时候才能百分百保证不干扰）

蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统：切换后的一段时间内，依旧是蓝绿两套系统并存，但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统（新系统）工作状态，如果出现问题，直接切换回绿色系统。

当确信对外提供服务的蓝色系统工作正常，不对外提供服务的绿色系统已经不再需要的时候，蓝色系统正式成为对外提供服务系统，成为新的绿色系统。原先的绿色系统可以销毁，将资源释放出来，用于部署下一个蓝色系统。

11.6.2 蓝绿部署优缺点

优点：

更新过程无需停机，风险较少；
回滚方便，只需要更改路由或者切换DNS服务器，效率较高；

缺点：

成本较高，需要部署两套环境。如果新版本中基础服务出现问题，会瞬间影响全网用户；如果新版本有问题也会影响全网用户。
需要部署两套机器，费用开销大
在非隔离的机器（Docker、VM）上操作时，可能会导致蓝绿环境被摧毁风险
负载均衡器/反向代理/路由/DNS处理不当，将导致流量没有切换过来情况出现

11.6.3 K8s 实现线上业务的蓝绿部署

Kubernetes不支持内置的蓝绿部署。目前最好的方式是创建新的deployment，然后更新应用程序的service以指向新的deployment部署的应用

# 
n1 && n2 ]# ctr -n k8s.io images import myapp-lan.tar.gz
n1 && n2 ]# ctr -n k8s.io images import myapp-lv.tar.gz

[root@k8s-master1 ~]# kubectl create ns blue-green
[root@k8s-master1 ~]# vim lv.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v1
  namespace: blue-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: v2
  template:
    metadata:
      labels:
        app: myapp
        version: v2			# 这里原本应该是v1，但是资源包镜像封装错误
    spec:
      containers:
      - name: myapp
        image: janakiramm/myapp:v2	# 这里原本应该是v1，但是资源包镜像封装错误
        imagePullPolicy: IfNotPresent
        ports:
          - containerPort: 80

[root@k8s-master1 ~]# kubectl apply -f lv.yml

# 查看ip地址并测试
[root@k8s-master1 ~]# kubectl get pods -n blue-green -owide
[root@k8s-master1 ~]# curl -s 10.244.90.170 | grep back
      background-color: green;

# 写入svc资源文件（实现ip转移到主机MasterIP）
[root@k8s-master1 ~]# vim service_lanlv.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp-lan-lv
  namespace: blue-green
  labels:
    app: myapp
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30062
    name: http
  selector:
    app: :myapp
    version: v2

[root@k8s-master1 ~]# kubectl apply -f service_lanlv.yaml

# 查看端口号，并进行测试
[root@k8s-master1 ~]# kubectl get svc -n blue-green
NAME           TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
myapp-lan-lv   NodePort   10.103.223.205   <none>        80:30062/TCP   65s

# http://k8s-master的ip:30062
# http://172.25.254.10:30062

# 寻找特征标签
[root@k8s-master1 ~]# kubectl get pods -n blue-green --show-labels

[root@k8s-master1 ~]# vim lan.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v2
  namespace: blue-green
spec:
  replicas: 3
  selector:
   matchLabels:
    app: myapp
    version: v1
  template:
   metadata:
    labels:
     app: myapp
     version: v1
   spec:
    containers:
    - name: myapp
      image: janakiramm/myapp:v1
      imagePullPolicy: IfNotPresent
      ports:
      - containerPort: 80

[root@k8s-master1 ~]# kubectl apply -f lan.yaml
[root@k8s-master1 ~]# kubectl get pods -n blue-green
NAME                        READY   STATUS    RESTARTS   AGE
myapp-v1-855f7f85-dqrc2     1/1     Running   0          16m
myapp-v1-855f7f85-kqp5c     1/1     Running   0          16m
myapp-v1-855f7f85-vnsr4     1/1     Running   0          16m
myapp-v2-55dc586597-2sgp5   1/1     Running   0          23s
myapp-v2-55dc586597-jj9rl   1/1     Running   0          23s
myapp-v2-55dc586597-rz6rp   1/1     Running   0          23s


[root@k8s-master1 ~]# kubectl get pods -n blue-green --show-labels
[root@k8s-master1 ~]# vim service_lanlv.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp-lan-lv
  namespace: blue-green
  labels:
    app: myapp
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30062
    name: http
  selector:
    app: myapp
    version: v1

[root@k8s-master1 ~]# kubectl apply -f service_lanlv.yaml
[root@k8s-master1 ~]# kubectl get svc -n blue-green
NAME           TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
myapp-lan-lv   NodePort   10.103.223.205   <none>        80:30062/TCP   13m

# 上面那个，如果页面还在的话，可以点击刷新按钮，查看效果
# http://172.25.254.10:30062

[root@k8s-master1 ~]# kubectl describe svc -n blue-green
Name:                     myapp-lan-lv
Namespace:                blue-green
Labels:                   app=myapp
Annotations:              <none>
Selector:                 app=myapp,version=v1
Type:                     NodePort
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.103.223.205
IPs:                      10.103.223.205
Port:                     http  80/TCP
TargetPort:               80/TCP
NodePort:                 http  30062/TCP
Endpoints:                10.244.90.173:80,10.244.90.172:80,10.244.147.229:80	# 查看这里，跟下面对应
Session Affinity:         None
External Traffic Policy:  Cluster
Internal Traffic Policy:  Cluster
Events:                   <none>

[root@k8s-master1 ~]# kubectl get pods -owide -n blue-green

# 删除所有资源，以免影响后面实验

11.7 浅谈金丝雀发布

11.7.1 金丝雀发布由来及概述

金丝雀发布的由来：17 世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；当瓦斯含量超过一定限度时，虽然人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为瓦斯检测指标，以便在危险状况下紧急撤离。

金丝雀发布（又称灰度发布、灰度更新）：金丝雀发布一般先发1台，或者一个小比例，例如2%的服务器，主要做流量验证用，也称为金丝雀 (Canary) 测试（国内常称灰度测试）。

简单的金丝雀测试一般通过手工测试验证，复杂的金丝雀测试需要比较完善的监控基础设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或回退的依据。如果金丝测试通过，则把剩余的V1版本全部升级为V2版本。如果金丝雀测试失败，则直接回退金丝雀，发布失败。

**优点：**灵活，策略自定义，可以按照流量或具体的内容进行灰度(比如不同账号，不同参数)，出现问题不会影响全网用户；

**缺点：**没有覆盖到所有的用户导致出现问题不好排查

11.7.2 K8s 实现线上业务的金丝雀发布

[root@k8s-master1 ~]# kubectl apply -f lv.yml
# 打开一个终端进行监控
[root@k8s-master1 ~]# kubectl get pods -l app=myapp -n blue-green -w
NAME                      READY   STATUS    RESTARTS   AGE
myapp-v1-855f7f85-8d877   1/1     Running   0          10s
myapp-v1-855f7f85-cx9ld   1/1     Running   0          10s
myapp-v1-855f7f85-ln62p   1/1     Running   0          10s
......


[root@k8s-master1 ~]# vim lv.yml
...
    spec:
      containers:
      - name: myapp
        image: docker.io/library/nginx:latest	# 更改镜像
...

# 更新yaml文件及停止滚动
[root@k8s-master1 ~]# kubectl apply -f lv.yml && kubectl rollout pause deploy myapp-v1 -n blue-green

[root@k8s-master1 ~]# kubectl get pods -l app=myapp -n blue-green -owide -w

# 上面的解释说明把myapp这个容器的镜像更新到docker.io/library/nginx:v1版本
# 更新镜像之后，创建一个新的pod就立即暂停，这就是我们说的金丝雀发布；如果暂停几个小时之后没有问题，那么取消暂停，就会依次执行后面步骤，把所有pod都升级。

# 解除暂停并查看状态
]# kubectl rollout resume deployment myapp-v1 -n blue-green
]# kubectl get pods -l app=myapp -n blue-green -owide -w

[root@k8s-master1 ~]# kubectl get rs -n blue-green
NAME                  DESIRED   CURRENT   READY   AGE
myapp-v1-5c764776d5   0         0         0       8m7s
myapp-v1-7f4fdb8844   3         3         3       7m6s

# 这里已经可以看到有两个ReplicaSet控制器了