草庐IT

详解kubernetes的发布方式

大妖史莱姆 2023-03-28 原文

项目的发布方式

  1. 蓝绿发布：不停止旧版本，直接部署新版本
  2. 灰度发布：旧版本和新版本共存
  3. 滚动更新：平滑地将服务更新

蓝绿发布

蓝绿部署就是不停止旧版本，直接部署新版本

部署过程：

  1. 部署v1的应用（初始状态） ：所有外部请求都会进入此版本
  2. 部署版本2的应用：新版的应用
  3. 如果版本2测试正常，就可以将流量切换到版本2
  4. 稳定运行一段时间，没问题就删除版本1正在使用的资源（例如实例），从此正式使用版本2

优点: 无需停机，风险较小

缺点: 切换是全量的，如果版本2有问题，则对用户体验有直接影响, 需要双倍机器资源。

部署服务

创建目录

mkdir /root/bluegreen

部署版本V1的Deployment

cat > /root/bluegreen/blue.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: blue
spec:
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  selector:
    matchLabels:
      app: bluegreen
  replicas: 4
  template:
    metadata:
      labels:
        app: bluegreen
        version: v1.0
    spec:
      containers:
      - name: bluegreen
        image: registry.cn-hangzhou.aliyuncs.com/ray-docker/ray-demo-docker:v1
        ports:
        - containerPort: 80
EOF

[root@kubemaster ~]# kubectl apply -f /root/bluegreen/blue.yaml

部署Service

cat > /root/bluegreen/bluegreenservice.yaml <<EOF
apiVersion: v1
kind: Service
metadata:
  name: bluegreen
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: bluegreen
    version: v1.0
  type: ClusterIP
EOF

[root@kubemaster ~]# kubectl apply -f /root/bluegreen/bluegreenservice.yaml

部署版本V2的Deployment

cat > /root/bluegreen/green.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: green
spec:
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  selector:
    matchLabels:
      app: bluegreen
  replicas: 4
  template:
    metadata:
      labels:
        app: bluegreen
        version: v2.0
    spec:
      containers:
      - name: bluegreen
        image: registry.cn-hangzhou.aliyuncs.com/ray-docker/ray-demo-docker:v2
        ports:
        - containerPort: 80
EOF

[root@kubemaster ~]# kubectl apply -f /root/bluegreen/green.yaml

查看pod和service

[root@kubemaster ~]# kubectl get pod,svc
NAME                        READY   STATUS    RESTARTS   AGE
pod/blue-599dd97cf7-74fqm   1/1     Running   0          95m
pod/blue-599dd97cf7-cs6mc   1/1     Running   0          95m
pod/blue-599dd97cf7-ddcf5   1/1     Running   0          95m
pod/blue-599dd97cf7-z47hv   1/1     Running   0          95m
pod/green-9fd69c4bc-c6jcd   1/1     Running   0          94m
pod/green-9fd69c4bc-grt7x   1/1     Running   0          94m
pod/green-9fd69c4bc-w7tkj   1/1     Running   0          94m
pod/green-9fd69c4bc-zx6pz   1/1     Running   0          94m

NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/bluegreen    ClusterIP   10.97.172.131   <none>        80/TCP    95m
service/kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   3d17h

验证

检查当前版本

查看到的是V1版本

[root@kubemaster ~]# curl http://10.97.172.131/api/home
Webapplication - V1

修改bluegreenservice.yaml

version: v1.0改为version: v2.0，并重新发布

[root@kubemaster ~]# kubectl apply -f /root/bluegreen/bluegreenservice.yaml

查看是否为V2版本

查看到的是V2版本

[root@kubemaster ~]# curl http://10.97.172.131:80/api/home
Webapplication - V2

灰度发布(金丝雀)

灰度发布，就是将一部分新版服务部署到线上环境，有些用户的请求会进入新版的服务，这会出现两种情况

  1. 如果用户反馈不好，会将新版服务停止或者重做
  2. 如果代码质量有问题，也只会影响部分的用户

部署过程:

  1. 准备好部署各个阶段的工件

  2. 从负载均衡列表中移除掉“金丝雀”服务器

  3. 升级“金丝雀”应用（排掉原有流量并进行部署）

  4. 对应用进行自动化测试

  5. 将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）

    如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）

优点: 用户体验影响小，灰度发布过程出现问题只影响部分用户

部署

cat > /root/canary/canary.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: blue
spec:
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  selector:
    matchLabels:
      app: bluegreen
  replicas: 6
  template:
    metadata:
      labels:
        app: bluegreen
        version: v1.0
    spec:
      containers:
      - name: bluegreen
        image: registry.cn-hangzhou.aliyuncs.com/ray-docker/ray-demo-docker:v1
        ports:
        - containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: green
spec:
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  selector:
    matchLabels:
      app: bluegreen
  replicas: 4
  template:
    metadata:
      labels:
        app: bluegreen
        version: v2.0
    spec:
      containers:
      - name: bluegreen
        image: registry.cn-hangzhou.aliyuncs.com/ray-docker/ray-demo-docker:v2
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: bluegreen
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: bluegreen
    version: v1.0
  type: ClusterIP
EOF

[root@kubemaster ~]# kubectl apply -f /root/canary/canary.yaml

验证

[root@kubemaster ~]# curl http://10.97.172.131:80/api/home
Webapplication - V2
[root@kubemaster ~]# curl http://10.97.172.131:80/api/home
Webapplication - V2
[root@kubemaster ~]# curl http://10.97.172.131:80/api/home
Webapplication - V1

滚动更新

取出部分服务器停止服务，更新后重新投入使用。直到集群中所有实例都是最新版本。默认maxUnavailable和surge都是25%

  • maxUnavailable：和期望ready的副本数比，不可用副本数最大比例（或最大值），这个值越小，越能保证服务稳定，更新越平滑；
  • maxSurge：和期望ready的副本数比，超过期望副本数最大比例（或最大值），这个值调的越大，副本更新速度越快。

这种部署方式相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数。可以部分部署，例如每次只取出集群的25%进行升级

部署

创建Deployment

mkdir /root/rollingUpdate

cat > /root/rollingUpdate/rollingUpdate.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling-update
  labels:
    app: rolling-update-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: rolling-update-pod
  template:
    metadata:
      labels:
        app: rolling-update-pod
    spec:
      containers:
      - name: rolling-update-container
        image: registry.cn-hangzhou.aliyuncs.com/ray-docker/ray-demo-docker:v1
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: bluegreen
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: rolling-update-pod
    version: v1.0
  type: ClusterIP
EOF

[root@kubemaster ~]# kubectl apply -f /root/rollingUpdate/rollingUpdate.yaml

监控Deployment的状态

新启一个bash窗口

[root@kubemaster ~]# kubectl get deployment rolling-update -w

开始滚动更新

[root@kubemaster ~]# kubectl set image deployment/rolling-update rolling-update-container=registry.cn-hangzhou.aliyuncs.com/ray-docker/ray-demo-docker:v2 --record

验证

Deployment状态

[root@kubemaster ~]# kubectl get deployment rolling-update -w
NAME             READY   UP-TO-DATE   AVAILABLE   AGE
rolling-update   3/3     3            3           41m
rolling-update   3/3     3            3           41m
rolling-update   3/3     3            3           41m
rolling-update   3/3     0            3           41m
rolling-update   3/3     1            3           41m
rolling-update   4/3     1            4           41m
rolling-update   3/3     1            3           41m
rolling-update   3/3     2            3           41m
rolling-update   4/3     2            4           41m
rolling-update   3/3     2            3           41m
rolling-update   3/3     3            3           41m
rolling-update   4/3     3            4           41m
rolling-update   3/3     3            3           41m

其他命令

查看Deployment滚动配置

kubectl describe deployment rolling-update

检查 Deployment 修订历史

kubectl rollout history deployment rolling-update

回滚到之前的修订版本

## 回滚到上一个版本
kubectl rollout undo deployment rolling-update
##回滚到指定版本
kubectl rollout undo deployment rolling-update --to-revision=1

取值范围

数值

  1. maxUnavailable: [0, 副本数]
  2. maxSurge: [0, 副本数]

注意：两者不能同时为0。

比例

  1. maxUnavailable: [0%, 100%] 向下取整，比如10个副本，5%的话==0.5个，但计算按照0个；
  2. maxSurge: [0%, 100%] 向上取整，比如10个副本，5%的话==0.5个，但计算按照1个；

注意：两者不能同时为0。

建议配置

  1. maxUnavailable == 0
  2. maxSurge == 1

这是我们生产环境提供给用户的默认配置。即“一上一下，先上后下”最平滑原则：1个新版本pod ready（结合readiness）后，才销毁旧版本pod。此配置适用场景是平滑更新、保证服务平稳，但也有缺点，就是“太慢”了

自定义策略

DeploymentController调整replicaset数量时，严格通过以下公式来控制发布节奏

(目标副本数-maxUnavailable) <= 线上实际Ready副本数 <= (目标副本数+maxSurge)

举例：

如果期望副本数为10，且至少80%的副本能够正常工作。且建议maxSurge 与maxUnavailable 一致。

由此可以设定目标副本数为10，线上实际Ready副本数为8，从此可以得出maxUnavailable = 10 - 2 = 8，即8 ≤ 线上实际Ready副本数 ≤ 12

详解kubernetescodebluegreenrolling-update.NET技术

有关详解kubernetes的发布方式的更多相关文章

  1. ruby - 如何以所有可能的方式将字符串拆分为长度最多为 3 的连续子字符串？ - 2

    我试图获取一个长度在1到10之间的字符串，并输出将字符串分解为大小为1、2或3的连续子字符串的所有可能方式。例如:输入:123456将整数分割成单个字符，然后继续查找组合。该代码将返回以下所有数组。[1,2,3,4,5,6][12,3,4,5,6][1,23,4,5,6][1,2,34,5,6][1,2,3,45,6][1,2,3,4,56][12,34,5,6][12,3,45,6][12,3,4,56][1,23,45,6][1,2,34,56][1,23,4,56][12,34,56][123,4,5,6][1,234,5,6][1,2,345,6][1,2,3,456][123

  2. ruby - 解析 RDFa、微数据等的最佳方式是什么，使用统一的模式/词汇(例如 schema.org)存储和显示信息 - 2

    我主要使用Ruby来执行此操作，但到目前为止我的攻击计划如下:使用gemsrdf、rdf-rdfa和rdf-microdata或mida来解析给定任何URI的数据。我认为最好映射到像schema.org这样的统一模式，例如使用这个yaml文件，它试图描述数据词汇表和opengraph到schema.org之间的转换:#SchemaXtoschema.orgconversion#data-vocabularyDV:name:namestreet-address:streetAddressregion:addressRegionlocality:addressLocalityphoto:i

  3. ruby-on-rails - 正确的 Rails 2.1 做事方式 - 2

    question的一些答案关于redirect_to让我想到了其他一些问题。基本上，我正在使用Rails2.1编写博客应用程序。我一直在尝试自己完成大部分工作(因为我对Rails有所了解)，但在需要时会引用Internet上的教程和引用资料。我设法让一个简单的博客正常运行，然后我尝试添加评论。靠我自己，我设法让它进入了可以从script/console添加评论的阶段，但我无法让表单正常工作。我遵循的其中一个教程建议在帖子Controller中创建一个“评论”操作，以添加评论。我的问题是:这是“标准”方式吗？我的另一个问题的答案之一似乎暗示应该有一个CommentsController参

  4. 世界前沿3D开发引擎HOOPS全面讲解——集3D数据读取、3D图形渲染、3D数据发布于一体的全新3D应用开发工具 - 2

    无论您是想搭建桌面端、WEB端或者移动端APP应用，HOOPSPlatform组件都可以为您提供弹性的3D集成架构，同时，由工业领域3D技术专家组成的HOOPS技术团队也能为您提供技术支持服务。如果您的客户期望有一种在多个平台（桌面/WEB/APP，而且某些客户端是“瘦”客户端）快速、方便地将数据接入到3D应用系统的解决方案，并且当访问数据时，在各个平台上的性能和用户体验保持一致，HOOPSPlatform将帮助您完成。利用HOOPSPlatform，您可以开发在任何环境下的3D基础应用架构。HOOPSPlatform可以帮您打造3D创新型产品，HOOPSSDK包含的技术有：快速且准确的CAD

  5. ruby-on-rails - 如何在发布新的 Ruby 或 Rails 版本时收到通知？ - 2

    有人知道在发布新版本的Ruby和Rails时收到电子邮件的方法吗？他们有邮件列表，RubyonRails有一个推特，但我不想听到那些随之而来的喧嚣，我只想知道什么时候发布新版本，尤其是那些有安全修复的版本。 最佳答案 从therailsblog获取提要.http://weblog.rubyonrails.org/feed/atom.xml 关于ruby-on-rails-如何在发布新的Ruby或Rails版本时收到通知？，我们在StackOverflow上找到一个类似的问题：

  6. 【鸿蒙应用开发系列】- 获取系统设备信息以及版本API兼容调用方式 - 2

    在应用开发中，有时候我们需要获取系统的设备信息，用于数据上报和行为分析。那在鸿蒙系统中，我们应该怎么去获取设备的系统信息呢，比如说获取手机的系统版本号、手机的制造商、手机型号等数据。1、获取方式这里分为两种情况，一种是设备信息的获取，一种是系统信息的获取。1.1、获取设备信息获取设备信息，鸿蒙的SDK包为我们提供了DeviceInfo类，通过该类的一些静态方法，可以获取设备信息，DeviceInfo类的包路径为：ohos.system.DeviceInfo.具体的方法如下：ModifierandTypeMethodDescriptionstatic StringgetAbiList​()Obt

  7. ruby - 鸭子输入字符串、符号和数组的优雅方式？ - 2

    这是针对我无法破坏的现有公共(public)API，但我确实希望对其进行扩展。目前，该方法采用字符串或符号或任何其他在作为第一个参数传递给send时有意义的内容我想添加发送字符串、符号等列表的功能。我可以只使用is_a吗？数组，但还有其他发送列表的方法，这不是很像ruby​​。我将调用列表中的map，所以第一个倾向是使用respond_to?:map。但是字符串也会响应:map，所以这行不通。 最佳答案 如何将它们全部视为数组？String的行为与仅包含String的Array相同:deffoo(obj,arg)[*arg].eac

  8. ruby - 如何以编程方式删除实例上的 "singleton information"以使其编码(marshal)？ - 2

    我创建了一个由于“在运行时执行的单例元类定义”而无法编码的对象(这段代码的描述是否正确？)。这是通过以下代码执行的:#defineclassXthatmyusesingletonclassmetaprogrammingfeatures#throughcallofmethod:break_marshalling!classXdefbreak_marshalling!meta_class=class我该怎么做才能使对象编码正确？是否可以从对象instance_of_x的classX中“移除”单例组件？我真的需要一个建议，因为我们的一些对象需要通过Marshal.dump序列化机制进行缓存。

  9. ruby - Paperclip:以编程方式分配图像并设置其名称 - 2

    使用Paperclip，我想从这样的URL抓取图像:require'open-uri'user.photo=open(url)问题是我最后得到一个像“open-uri20110915-4852-1o7k5uw”这样的文件名。有什么方法可以更改user.photo上的文件名？作为一个额外的变化，Paperclip将我的文件存储在S3上，所以如果我可以在初始分配中设置我想要的文件名就更好了，这样图像就会上传到正确的S3key。像这样:user.photo=open(url),:filename=>URI.parse(url).path 最佳答案

  10. ruby - 如何以编程方式检查证书是否已被吊销？ - 2

    我正在开发一个xcode自动构建系统。在执行一些预构建验证时，我想检查指定的证书文件是否已被撤销。我了解securityverify-cert验证其他证书属性但不验证吊销。我如何检查撤销？我正在用Ruby编写构建系统，但我对任何语言的想法都持开放态度。我阅读了这个答案(Openssl-Howtocheckifacertificateisrevokedornot)，但指向底部的链接(DoesOpenSSLautomaticallyhandleCRLs(CertificateRevocationLists)now?)进入的Material对我的目的来说有点过于复杂(用户上传已撤销的证书是一

随机推荐