发布策略【K8S （三）】

[1 金丝雀发布（Canary Release）](#1 金丝雀发布（Canary Release）)

2.蓝绿发布

2.1核心定义

2.2工作原理

2.3优缺点

[3.滚动发布（Rolling Update）](#3.滚动发布（Rolling Update）)

[3.2 工作原理](#3.2 工作原理)

3.3优缺点

[4 声明式资源管理方法](#4 声明式资源管理方法)

[4.1 基本原理](#4.1 基本原理)

[4.2 查看与解释配置清单](#4.2 查看与解释配置清单)

[4.3 修改资源配置清单并应用](#4.3 修改资源配置清单并应用)

[4.4 在线修改](#4.4 在线修改)

[4.5 删除资源配置清单](#4.5 删除资源配置清单)

5.yaml文件

1.YAML语法格式：

1 金丝雀发布（Canary Release）

Deployment控制器支持自定义控制更新过程中的滚动节奏，如"暂停(pause)"或"继续(resume)"更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作，这就是所谓的金丝雀发布。

步骤：

bash 复制代码

（1）更新deployment的版本，并配置暂停deployment
kubectl set image deployment/nginx nginx=nginx:1.14 && kubectl rollout pause 
deployment/nginx
kubectl rollout status deployment/nginx    #观察更新状态

（2）监控更新的过程，可以看到已经新增了一个资源，但是并未按照预期的状态去删除一个旧的资源，就是因
为使用了pause暂停命令
kubectl get pods -w 
curl [-I] 10.0.0.189
curl [-I] 192.168.10.20:44847

（3）确保更新的pod没问题了，继续更新
kubectl rollout resume deployment/nginx

（4）查看最后的更新情况
kubectl get pods -w 
curl [-I] 10.0.0.189
curl [-I] 192.168.80.11:44847

2.蓝绿发布

2.1核心定义

同时运行两个完全相同的环境：

蓝环境：旧版本（生产中正在提供服务的环境）
绿环境 ：新版本（部署完成后，经过测试再切换流量）流量通过负载均衡器一次性全部切换到绿环境，若出现问题，可快速切回蓝环境。

2.2工作原理

生产环境运行蓝环境（旧版本 v1）。
部署绿环境（新版本 v2），与蓝环境共享相同的数据库、缓存等依赖（或使用独立副本，确保数据兼容）。
对绿环境进行冒烟测试、集成测试，确认功能正常。
通过 Service 或 Ingress 将所有流量从蓝环境切换到绿环境。
观察一段时间，若稳定则下线蓝环境；若出现问题，立即将流量切回蓝环境。

2.3优缺点

|-----------------|-----------------------------------|
| 优点 | 缺点 |
| 流量切换瞬间完成，用户无感知 | 需要双倍的成本（两个完整环境） |
| 回滚极其快速（只需要切换流量） | 数据库等状态同步复杂（若新版本修改了数据结构，蓝绿环境数据需兼容） |
| 发布过程简单 | 不适合大型应用（资源占用过高） |

3.滚动发布（Rolling Update）

3.2 工作原理

生产环境运行旧版本 Deployment（如 5 个 Pod）。
触发滚动更新，K8s 会先终止一个旧 Pod，再创建一个新 Pod。
新 Pod 就绪后，再终止下一个旧 Pod，重复此过程。
直到所有旧 Pod 都被替换为新 Pod，发布完成。
若出现问题，可通过 kubectl rollout undo 回滚到旧版本。

3.3优缺点

|---------------------------------|------------------------------|
| 优点 | 缺点 |
| 资源成本低（无需额外环境，逐步替换） | 回滚速度较慢（需重新替换Pod） |
| 发布过程平滑，用户无感知 | 新旧版本同时运行，需要确保兼容（如API版本，消息格式） |
| 适合有状态应用（可通过 StatefulSet 实现有序更新） | 无法快速切换全部流量，问题发现后仍有部分用户受影响 |

4 声明式资源管理方法

4.1 基本原理

1.适合于对资源的修改操作

2.声明式资源管理方法依赖于资源配置清单文件对资源进行管理

资源配置清单文件有两种格式：yaml（人性化，易读），json（易于api接口解析）

3.对资源的管理，是通过事先定义在统一资源配置清单内，再通过陈述式命令应用到k8s集群里

4.语法格式：kubectl create/apply/delete -f xxxx.yaml

4.2 查看与解释配置清单

//查看资源配置清单

kubectl get deployment nginx -o yaml

//解释资源配置清单

kubectl explain deployment.metadata

kubectl get service nginx -o yaml

kubectl explain service.metadata

4.3 修改资源配置清单并应用

bash 复制代码

离线修改：
修改yaml文件，并用 kubectl apply -f xxxx.yaml 文件使之生效
注意：当apply不生效时，先使用delete清除资源，再apply创建资源

kubectl get service nginx -o yaml > nginx-svc.yaml
vim nginx-svc.yaml              #修改port: 8080

kubectl delete -f nginx-svc.yaml
kubectl apply -f nginx-svc.yaml
kubectl get svc

4.4 在线修改

直接使用 kubectl edit service nginx 在线编辑资源配置清单并保存退出即时生效（如port: 888）

PS：此修改方式不会对yaml文件内容修改

4.5 删除资源配置清单

陈述式删除：

kubectl delete service nginx

声明式删除：

kubectl delete -f nginx-svc.yaml

5.yaml文件

1.YAML语法格式：

大小写敏感
使用缩进表示层级关系
不支持Tab键制表符缩进，只使用空格缩进
缩进的空格数目不重要，只要相同层级的元素左侧对齐即可，通常开头缩进两个空格
符号字符后缩进一个空格，如冒号，逗号，短横杆（-）等
"---"表示YAML格式，一个文件的开始，用于分隔文件间
"#"表示注释

bash 复制代码

deployment文件 
apiVersion: apps/v1    # API版本：apps/v1（Deployment的稳定版，k8s 1.9+推荐使用）
kind: Deployment       # 资源类型：Deployment（用于管理Pod的创建、更新、扩缩容）
metadata:
  labels:               # 给Deployment自身打标签（用于筛选/关联其他资源，如Service）
    app: nginx-abc      # 标签键值对：app=nginx-abc
  name: nginx-deployment    # Deployment的名称（在dev命名空间下唯一）
  namespace: dev     # 命名空间：dev（将该Deployment部署到dev命名空间，隔离资源）
spec:    
  replicas: 2       # 期望的Pod副本数：2个（K8s会确保始终有2个nginx Pod运行）
  selector:         # 标签选择器：Deployment通过该配置找到要管理的Pod
    matchLabels:     # 匹配标签：只管理带有app=nginx-abc标签的Pod
      app: nginx-abc
  strategy:       # 更新策略：定义Pod版本更新时的行为
    rollingUpdate:    # 滚动更新（默认策略）：逐步替换旧Pod，避免服务中断
      maxSurge: 25%   # 最大超额数：更新时最多可超出期望副本数的25%（2*25%=0.5，向上取整为1）
      maxUnavailable: 25%  # 最大不可用数：更新时最多允许25%的Pod不可用（2*25%=0.5，向下取整为0）
    type: RollingUpdate # 策略类型：RollingUpdate（滚动更新），另一种是Recreate（先删所有旧Pod再建新的）
  template:    # Pod模板：Deployment根据该模板创建Pod
    metadata:   # Pod的标签：必须和上面selector.matchLabels一致
      labels:
        app: nginx-abc
    spec:
      containers:    # 容器配置（一个Pod可包含多个容器，这里只有nginx）
      - image: nginx:1.15   # 容器镜像：nginx 1.15版本
        imagePullPolicy: IfNotPresent   # 镜像拉取策略：IfNotPresent（本地有则用本地，无则从仓库拉）
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP


service文件

apiVersion: v1    # API版本：v1（Service资源的稳定版，所有K8s版本均支持，无版本迭代差异）
kind: Service     # 资源类型：Service（K8s中用于为Pod提供稳定访问入口、负载均衡、服务发现的核心资源）
metadata:        # 给Service自身打标签（用于筛选、关联其他资源，如Ingress、HPA）
  labels:        # 标签键值对：app=nginx-svc（用于标识该Service的用途）
    app: nginx-svc    # 标签键值对：app=nginx-svc（用于标识该Service的用途）
  name: nginx-svc   # Service的名称（在dev命名空间下唯一，用于集群内服务发现）
  namespace: dev   # 命名空间：dev（和之前的nginx Deployment保持一致，确保能关联到同命名空间的Pod）
spec:  
  ports:       # 端口映射配置列表（一个Service可配置多个端口映射，满足多端口服务需求）
  - port: 80    # Service自身的「集群内部访问端口」
    protocol: TCP  # 通信协议：TCP（默认值，还支持UDP、SCTP，nginx的HTTP服务基于TCP）
    targetPort: 80   # 后端Pod的「容器端口」（nginx容器实际监听的端口）
  selector:   # 标签选择器：Service的核心关联配置，用于找到要转发流量的后端Pod
    app: nginx-abc   # 匹配标签：只将流量转发到带有「app=nginx-abc」标签的Pod
  sessionAffinity: None  # 会话亲和性（会话保持）：关闭会话保持（默认值）
  type: NodePort  # Service类型：NodePort（用于对外暴露服务，支持集群外部访问）

发布策略 【K8S （三）】

1 金丝雀发布（Canary Release）

2.蓝绿发布

2.1核心定义

2.2工作原理

2.3优缺点

3.滚动发布 （Rolling Update）

3.2 工作原理

3.3优缺点

4 声明式资源管理方法

4.1 基本原理

4.2 查看与解释配置清单

4.3 修改资源配置清单并应用

4.4 在线修改

4.5 删除资源配置清单

5.yaml文件

1.YAML语法格式：

发布策略【K8S （三）】

3.滚动发布（Rolling Update）