当前位置： 首页 > news >正文

今晚比分足球预测东莞网站制作十年乐云seo

news 2025/8/8 10:16:23
今晚比分足球预测,东莞网站制作十年乐云seo,浙江同安建设有限公司网站,工商公示系统查询入口概述 Deployment 是最常用的用于部署无状态服务的方式。Deployment 控制器使得您能够以声明的方式更新 Pod（容器组）和 ReplicaSet（副本集）。该控制器并不直接管理pod，而是通过管理ReplicaSet来间接管理Pod&#xff0c…

概述

Deployment 是最常用的用于部署无状态服务的方式。Deployment 控制器使得您能够以声明的方式更新 Pod（容器组）和 ReplicaSet（副本集）。该控制器并不直接管理pod，而是通过管理ReplicaSet来间接管理Pod，即：Deployment管 理ReplicaSet，ReplicaSet管理Pod。所以Deployment比ReplicaSet功能更加强大。

Deployment 为我们确定了如下几种运维场景：

  • 创建 Deployment : 创建 Deployment 后，Deployment 控制器将立刻创建一个 ReplicaSet 副本集，并由 ReplicaSet 创建所需要的 Pod。

  • 更新 Deployment: 更新 Deployment 中 Pod 的定义（例如，发布新版本的容器镜像）。此时 Deployment 控制器将为该 Deployment 创建一个新的 ReplicaSet 副本集，并且逐步在新的副本集中创建 Pod，在旧的副本集中删除 Pod，以达到滚动更新的效果。

  • 回滚Deployment: 回滚到一个早期 Deployment 版本。

  • 伸缩Deployment: 水平扩展 Deployment，以便支持更大的负载，或者水平收缩 Deployment，以便节省服务器资源。

  • 暂停和继续Deployment

  •  查看Deployment状态

  • 清理策略

  • 金丝雀发布

Deployment配置详情

apiVersion: apps/v1 # 版本号
kind: Deployment # 类型       
metadata: # 元数据name: # rs名称 namespace: # 所属命名空间 labels: #标签controller: deploy
spec: # 详情描述replicas: 3 # 副本数量revisionHistoryLimit: 3 # 保留历史版本paused: false # 暂停部署，默认是falseprogressDeadlineSeconds: 600 # 部署超时时间（s），默认是600strategy: # 策略type: RollingUpdate # 滚动更新策略rollingUpdate: # 滚动更新maxSurge: 30% # 最大额外可以存在的副本数，可以为百分比，也可以为整数maxUnavailable: 30% # 最大不可用状态的 Pod 的最大值，可以为百分比，也可以为整数selector: # 选择器，通过它指定该控制器管理哪些podmatchLabels:      # Labels匹配规则app: nginx-podmatchExpressions: # Expressions匹配规则- {key: app, operator: In, values: [nginx-pod]}template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1ports:- containerPort: 80

创建Deployment

下面的 yaml 文件定义了一个 Deployment，该 Deployment 将创建一个有 3 个 nginx Pod 副本的 ReplicaSet（副本集）：

apiVersion: apps/v1
kind: Deployment
metadata:name: deploymentnamespace: dev
spec:replicas: 3selector:matchLabels:app: nginx-podtemplate:metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1

 

在这个例子中：

  • 将创建一个名为 deployment 的 Deployment（部署），名称由 .metadata.name 字段指定
  • 该 Deployment 将创建 3 个 Pod 副本，副本数量由 .spec.replicas 字段指定
  • .spec.selector 字段指定了 Deployment 如何找到由它管理的 Pod。此案例中，我们使用了 Pod template 中定义的一个标签（app: nginx-pod）。对于极少数的情况，这个字段也可以定义更加复杂的规则
  • .template 字段包含了如下字段：
    • .template.metadata.labels 字段，指定了 Pod 的标签（app: nginx-pod）
    • .template.spec.containers[].image 字段，表明该 Pod 运行一个容器 nginx:1.17.1
    • .template.spec.containers[].name 字段，表明该容器的名字是 nginx

# 创建deployment
[root@k8s-master01 dev]# kubectl create -f deployment.yaml
deployment.apps/deployment created# 查看deployment
[root@k8s-master01 dev]# kubectl get deployments.apps  -n dev
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
deployment   3/3     3            3           6m37s#查看rs
[root@k8s-master01 dev]# kubectl get rs -n dev
NAME                    DESIRED   CURRENT   READY   AGE
deployment-7cffcbf558   3         3         3       8m36s# 发现rs的名称是在原来deployment的名字后面添加了一个10位数的随机串# 查看pod
[root@k8s-master01 dev]# kubectl get pod -n dev
NAME                          READY   STATUS    RESTARTS   AGE
deployment-7cffcbf558-m8qw7   1/1     Running   0          10m
deployment-7cffcbf558-nhhth   1/1     Running   0          10m
deployment-7cffcbf558-xwxhw   1/1     Running   0          10m

伸缩 Deployment

# 变更副本数量为5个
[root@k8s-master01 dev]# kubectl scale deployment deployment-test --replicas 5 -n dev
deployment.apps/deployment-test scaled# 查看deployment
[root@k8s-master01 dev]# kubectl get deployments.apps deployment-test -n dev
NAME              READY   UP-TO-DATE   AVAILABLE   AGE
deployment-test   5/5     5            5           5m26s# 查看pod
[root@k8s-master01 dev]# kubectl get pod -n dev
NAME                               READY   STATUS    RESTARTS   AGE
deployment-test-7cffcbf558-46hg7   1/1     Running   0          6m16s
deployment-test-7cffcbf558-5vjqw   1/1     Running   0          6m16s
deployment-test-7cffcbf558-fj846   1/1     Running   0          114s
deployment-test-7cffcbf558-mdz8q   1/1     Running   0          114s
deployment-test-7cffcbf558-ws965   1/1     Running   0          6m16s# 编辑deployment的副本数量，修改spec:replicas: 3
[root@k8s-master01 dev]# kubectl edit deployments.apps deployment-test -n dev
deployment.apps/deployment-test edited# 查看pod
[root@k8s-master01 dev]# kubectl get pod -n dev
NAME                               READY   STATUS    RESTARTS   AGE
deployment-test-7cffcbf558-46hg7   1/1     Running   0          8m37s
deployment-test-7cffcbf558-5vjqw   1/1     Running   0          8m37s
deployment-test-7cffcbf558-mdz8q   1/1     Running   0          4m15s

更新 Deployment

deployment支持两种更新策略: 重建更新 和 滚动更新 ,可以通过 strategy 指定策略类型,支持两个属性:

strategy：指定新的Pod替换旧的Pod的策略， 支持两个属性：
 type：指定策略类型，支持两种策略

  •     Recreate：在创建出新的Pod之前会先杀掉所有已存在的Pod
  •     RollingUpdate：滚动更新，就是杀死一部分，就启动一部分，在更新过程中，存在两个版本Pod

 rollingUpdate：当type为RollingUpdate时生效，用于为RollingUpdate设置参数，支持两个属
性：

  •     maxUnavailable：用来指定在升级过程中不可用Pod的最大数量，默认为25%。
  •     maxSurge： 用来指定在升级过程中可以超过期望的Pod的最大数量，默认为25%
     

 

重建更新

重建部署策略是先把旧的pod全部停掉，然后新建pod。由于部署期间出现服务中断，这种部署策略很少用。

在spec节点下添加更新策略

spec:strategy: # 策略type: Recreate # 重建更新

创建deploy进行验证

#修改镜像
[root@k8s-master01 dev]# kubectl set image deployment deployment-test nginx=nginx:1.17.2 -n dev
deployment.apps/deployment-test image updated#查看更新后的 Deployment 的详情[root@k8s-master01 dev]# kubectl  get deployments.apps -n dev -o wide
NAME              READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES         SELECTOR
deployment-test   3/3     3            3           39m   nginx        nginx:1.17.2   app=nginx-pod

滚动更新

在spec节点下添加更新策略

spec:strategy: # 策略type: RollingUpdate # 滚动更新策略rollingUpdate:maxSurge: 25% maxUnavailable: 25%

创建deploy进行验证

#修改镜像
[root@k8s-master01 dev]# kubectl set image deployment deployment-test nginx=nginx:1.17.3 -n dev
deployment.apps/deployment-test image updated[root@k8s-master01 dev]# kubectl get deployments.apps -n dev -o wide
NAME              READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES         SELECTOR
deployment-test   3/3     3            3           55m   nginx        nginx:1.17.3   app=nginx-pod#滚动更新是通过创建一个新的 3 个副本数的 ReplicaSet 并同时将旧的 Replicaset 的副本数缩容到 0 个副本 来达成的。
[root@k8s-master01 dev]# kubectl get rs -n dev
NAME                         DESIRED   CURRENT   READY   AGE
deployment-test-5b6ffdcd8d   3         3         3       5m37s
deployment-test-79dbdc995f   0         0         0       30m
deployment-test-7cffcbf558   0         0         0       56mDeployment 将确保更新过程中，任意时刻只有一定数量的 Pod 被关闭。默认情况下，Deployment 确保至少 .spec.replicas 的 75% 的 Pod 保持可用（25% max unavailable）
Deployment 将确保更新过程中，任意时刻只有一定数量的 Pod 被创建。默认情况下，Deployment 确保最多 .spec.replicas 的 25% 的 Pod 被创建（25% max surge）Deployment Controller 先创建一个新 Pod，然后删除一个旧 Pod，然后再创建新的，如此循环，直到全部更新。Deployment Controller 不会 kill 旧的 Pod，除非足够数量的新 Pod 已经就绪，Deployment Controller 也不会创新新 Pod 直到足够数量的旧 Pod 已经被 kill。#查看 Deployment 详情
[root@k8s-master01 dev]# kubectl describe deployments.apps
Name:                   deployment-test
Namespace:              dev
CreationTimestamp:      Sat, 05 Apr 2025 19:28:48 +0800
Labels:                 <none>
Annotations:            deployment.kubernetes.io/revision: 3
Selector:               app=nginx-pod
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:Labels:  app=nginx-podContainers:nginx:Image:         nginx:1.17.3Port:          <none>Host Port:     <none>Environment:   <none>Mounts:        <none>Volumes:         <none>Node-Selectors:  <none>Tolerations:     <none>
Conditions:Type           Status  Reason----           ------  ------Available      True    MinimumReplicasAvailableProgressing    True    NewReplicaSetAvailable
OldReplicaSets:  deployment-test-7cffcbf558 (0/0 replicas created), deployment-test-79dbdc995f (0/0 replicas created)
NewReplicaSet:   deployment-test-5b6ffdcd8d (3/3 replicas created)
Events:Type    Reason             Age    From                   Message----    ------             ----   ----                   -------Normal  ScalingReplicaSet  60m    deployment-controller  Scaled up replica set deployment-test-7cffcbf558 to 3Normal  ScalingReplicaSet  55m    deployment-controller  Scaled up replica set deployment-test-7cffcbf558 to 5 from 3Normal  ScalingReplicaSet  52m    deployment-controller  Scaled down replica set deployment-test-7cffcbf558 to 3 from 5Normal  ScalingReplicaSet  34m    deployment-controller  Scaled down replica set deployment-test-7cffcbf558 to 0 from 3Normal  ScalingReplicaSet  34m    deployment-controller  Scaled up replica set deployment-test-79dbdc995f to 3Normal  ScalingReplicaSet  9m5s   deployment-controller  Scaled up replica set deployment-test-5b6ffdcd8d to 1Normal  ScalingReplicaSet  7m37s  deployment-controller  Scaled down replica set deployment-test-79dbdc995f to 2 from 3Normal  ScalingReplicaSet  7m37s  deployment-controller  Scaled up replica set deployment-test-5b6ffdcd8d to 2 from 1Normal  ScalingReplicaSet  6m8s   deployment-controller  Scaled down replica set deployment-test-79dbdc995f to 1 from 2Normal  ScalingReplicaSet  6m8s   deployment-controller  Scaled up replica set deployment-test-5b6ffdcd8d to 3 from 2Normal  ScalingReplicaSet  6m6s   deployment-controller  Scaled down replica set deployment-test-79dbdc995f to 0 from 1在 Events 中，可以看到：创建 Deployment 时，Deployment Controller 创建了一个 ReplicaSet并直接将其scale up 到 3 个副本。
当更新 Deployment 时，Deployment Controller 先创建一个新的 ReplicaSet并将其 scale up 到 1 个副本，然后 scale down 旧的 ReplicaSet 到 2。
Deployment Controller 继续 scale up 新的 ReplicaSet 并 scale down 旧的 ReplicaSet，直到最后，新旧两个 ReplicaSet，一个副本数为 3，另一个副本数为 0。

回滚 Deployment

当想要回滚（rollback）Deployment，例如：Deployment 不稳定（可能是不断地崩溃）。默认情况下，kubernetes 将保存 Deployment 的所有更新（rollout）历史。

kubectl rollout： 版本升级相关功能，支持下面的选项：

  • status 显示当前升级状态
  • history 显示 升级历史记录
  • pause 暂停版本升级过程
  • resume 继续已经暂停的版本升级过程
  • restart 重启版本升级过程
  • undo 回滚到上一级版本（可以使用--to-revision回滚到指定版本）

# 查看当前升级版本的状态
[root@k8s-master01 dev]#  kubectl rollout status deploy deployment-test -n dev
deployment "deployment-test" successfully rolled out# 查看升级历史记录
[root@k8s-master01 dev]# kubectl rollout history deploy deployment-test -n dev
deployment.apps/deployment-test
REVISION  CHANGE-CAUSE
1         kubectl create --filename=deployment.yaml --record=true
2         kubectl create --filename=deployment.yaml --record=true
3         kubectl create --filename=deployment.yaml --record=true
# 可以发现有三次版本记录，说明完成过两次升级#使用--to-revision=1回滚到了1版本， 如果省略这个选项，就是回退到上个版本，就是2版本
[root@k8s-master01 dev]# kubectl rollout undo deployment deployment-test --to-revision=1 -n dev
deployment.apps/deployment-test rolled back# 查看，nginx镜像版本到了第一版
[root@k8s-master01 dev]# kubectl get deployments.apps -n dev -o wide
NAME              READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS   IMAGES         SELECTOR
deployment-test   3/3     3            3           7m31s   nginx        nginx:1.17.1   app=nginx-pod# 查看rs，发现第3个rs中有3个pod运行，前面两个版本的rs中pod为运行
[root@k8s-master01 dev]# kubectl get rs -n dev
NAME                         DESIRED   CURRENT   READY   AGE
deployment-test-5b6ffdcd8d   0         0         0       6m20s
deployment-test-79dbdc995f   0         0         0       6m39s
deployment-test-7cffcbf558   3         3         3       9m33s
  •   其实deployment之所以可是实现版本的回滚，就是通过记录下历史rs来实现的
  • 一旦想回滚到哪个版本，只需要将当前版本pod数量降为0，然后将回滚版本的pod提升为目标数量就可以了  

金丝雀发布（灰度发布）

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

# 更新deployment的版本，并配置暂停deployment
[root@k8s-master01 dev]# kubectl set image deploy deployment-test nginx=nginx:1.17.5 -n dev && kubectl rollout pause deployment deployment-test -n devdeployment.apps/deployment-test image updated
deployment.apps/deployment-test paused#观察更新状态
[root@k8s-master01 dev]# kubectl rollout status deploy deployment-test -n dev
Waiting for deployment "deployment-test" rollout to finish: 0 out of 3 new replicas have been updated...# 监控更新的过程，可以看到已经新增了一个资源，但是并未按照预期的状态去删除一个旧的资源，就是因为使用了pause暂停命令
[root@k8s-master01 dev]# kubectl get rs -n dev -o wide
NAME                         DESIRED   CURRENT   READY   AGE     CONTAINERS   IMAGES         SELECTOR
deployment-test-5b6ffdcd8d   0         0         0       20m     nginx        nginx:1.17.3   app=nginx-pod,pod-template-hash=5b6ffdcd8d
deployment-test-79dbdc995f   0         0         0       20m     nginx        nginx:1.17.2   app=nginx-pod,pod-template-hash=79dbdc995f
deployment-test-7cffcbf558   2         2         2       23m     nginx        nginx:1.17.1   app=nginx-pod,pod-template-hash=7cffcbf558
deployment-test-845cbff7c8   1         1         0       60s     nginx        nginx:1.17.5   app=nginx-pod,pod-template-hash=845cbff7c8
deployment-test-f5b4bdd49    1         1         1       6m53s   nginx        nginx:1.17.4   app=nginx-pod,pod-template-hash=f5b4bdd49[root@k8s-master01 dev]# kubectl get pod -n dev
NAME                               READY   STATUS    RESTARTS   AGE
deployment-test-7cffcbf558-6xj55   1/1     Running   0          15m
deployment-test-7cffcbf558-mg8dm   1/1     Running   0          15m
deployment-test-7cffcbf558-nd6ld   1/1     Running   0          15m
deployment-test-f5b4bdd49-r2f5m    1/1     Running   0          4m55s# 确保更新的pod没问题了，继续更新
[root@k8s-master01 dev]# kubectl rollout resume deploy deployment-test -n dev
deployment.apps/deployment-test resumed# 查看更新情况
[root@k8s-master01 dev]# kubectl get rs -n dev -o wide
NAME                         DESIRED   CURRENT   READY   AGE     CONTAINERS   IMAGES         SELECTOR
deployment-test-5b6ffdcd8d   0         0         0       22m     nginx        nginx:1.17.3   app=nginx-pod,pod-template-hash=5b6ffdcd8d
deployment-test-79dbdc995f   0         0         0       23m     nginx        nginx:1.17.2   app=nginx-pod,pod-template-hash=79dbdc995f
deployment-test-7cffcbf558   0         0         0       26m     nginx        nginx:1.17.1   app=nginx-pod,pod-template-hash=7cffcbf558
deployment-test-845cbff7c8   3         3         3       3m39s   nginx        nginx:1.17.5   app=nginx-pod,pod-template-hash=845cbff7c8
deployment-test-f5b4bdd49    0         0         0       9m32s   nginx        nginx:1.17.4   app=nginx-pod,pod-template-hash=f5b4bdd49[root@k8s-master01 dev]# kubectl get pod -n dev
NAME                               READY   STATUS    RESTARTS   AGE
deployment-test-845cbff7c8-2fm7r   1/1     Running   0          4m23s
deployment-test-845cbff7c8-8fbvx   1/1     Running   0          4m57s
deployment-test-845cbff7c8-wb62j   1/1     Running   0          6m6s

局限性

按照 Kubernetes 默认支持的这种方式进行金丝雀发布，有一定的局限性：

  • 不能根据用户注册时间、地区等请求中的内容属性进行流量分配
  • 同一个用户如果多次调用该 Service，有可能第一次请求到了旧版本的 Pod，第二次请求到了新版本的 Pod

TIP

在 Kubernetes 中不能解决上述局限性的原因是：Kubernetes Service 只在 TCP 层面解决负载均衡的问题，并不对请求响应的消息内容做任何解析和识别。如果想要更完善地实现金丝雀发布，可以考虑如下三种选择：

  • 业务代码编码实现
  • Spring Cloud 灰度发布
  • Istio 灰度发布

删除Deployment

# 删除deployment，其下的rs和pod也将被删除
[root@k8s-master01 dev]# kubectl delete -f deployment.yaml
deployment.apps "deployment-test" deleted

http://www.cadmedia.cn/news/2807.html

相关文章：

  • 石家庄网站建设公司哪个好免费制作详情页的网站
  • 临沂网站建设哪家公司好百度通用网址
  • 福田网页设计优化关键词首页排行榜
  • 做网站的心得体会搜狗搜索引擎推广
  • 沈阳建站武汉今日新闻头条
  • 创客联盟网站建设建立个人网站
  • 服务器建设网站推广代理平台登录
  • 南宁疫情最新消息今天封城了厦门百度seo
  • 温州市住房和城乡建设网站杭州网站排名seo
  • 建设银行北海分行网站企业网站建设制作
  • 网站开发方法有哪些广告关键词有哪些
  • 网站开发软件有外贸网站免费建站
  • 电商购物网站开发近期舆情热点事件
  • 开一个网站需要什么百度指数批量查询工具
  • 中国纪检监察报多久一期网络优化工作内容
  • 北京建设工程网站域名站长工具
  • 成都微信网站建设推seo推广要多少钱
  • 室内设计公司的名字网络优化主要做什么
  • 网站建设开发五行属性软件推广怎么做
  • 网站建设时设置语言选项免费大数据查询
  • 深圳疫情今天最新消息seo搜索引擎优化方案
  • 顺德做网站b2b电子商务网站
  • 重庆服装网站建设费用网络营销常见术语
  • 齐齐哈尔网站开发百度指数网页版
  • 网站建设用的工具sem营销是什么意思
  • 现在外国有哪个网站可以做卖东西网站为什么要seo?
  • 闸北区网站建设网页制google登录入口
  • 专门查大学的网站hyein seo官网
  • 江西专业南昌网站建设百度推广上班怎么样
  • 济南网站建设开发公司哪家好杭州网络推广外包