侧边栏壁纸
博主头像
落叶人生博主等级

走进秋风,寻找秋天的落叶

  • 累计撰写 130562 篇文章
  • 累计创建 28 个标签
  • 累计收到 9 条评论
标签搜索

目 录CONTENT

文章目录

kubernetes资源--deployment

2023-09-27 星期三 / 0 评论 / 0 点赞 / 58 阅读 / 9645 字

Deployment(中文意思为部署、调度)提供了一种更加简单的更新RC和Pod的机制,K8S版本1.2实现的。通过在Deployment中描述所期望的集群状态,Deployment Controll

Deployment(中文意思为部署、调度)提供了一种更加简单的更新RC和Pod的机制,K8S版本1.2实现的。通过在Deployment中描述所期望的集群状态,Deployment Controller会将现在的集群状态在一个可控的速度下逐步更新成所期望的集群状态。Deployment主要职责同样是为了保证pod的数量和健康,90%的功能与RC完全一样,可以看做新一代的RC。

功能

Deployment集成了上线部署、滚动升级、创建副本、暂停上线任务,恢复上线任务,回滚到以前某一版本(成功/稳定)的Deployment等功能,在某种程度上,Deployment可以实现无人值守的上线,大大降低上线过程的复杂沟通、操作风险。

RC全部功能:Deployment继承了上面描述的RC全部功能。

事件和状态查看:可以查看Deployment的升级详细进度和状态。

回滚:当升级pod镜像或者相关参数时发现问题,可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。

版本记录:每次对Deployment的操作,都能保存下来,给予后续可能的回滚使用。

暂停和启动:对于每一次升级,都能够随时暂停和启动。

多种升级方案:Recreate--删除所有已存在的pod,重新创建新的; RollingUpdate--滚动升级,逐步替换的策略,同时滚动升级时,支持更多的附加参数,例如设置最大不可用pod数量,最小升级间隔时间等等。

使用场景

使用Deployment来启动(上线/部署)一个Pod或者RS

检查一个Deployment是否成功执行

更新Deployment来重新创建相应的Pods(例如,需要使用一个新的Image)

如果现有的Deployment不稳定,那么回滚到一个早期的稳定的Deployment版本

暂停或者恢复一个Deployment

与RC比较,deployment的优势

Deployment使用了RS,它是更高一层的概念。

RC只支持基于等式的selector(env=dev或environment!=qa),但RS还支持新的,基于集合的selector(version in (v1.0, v2.0)或env notin (dev, qa)),这对复杂的运维管理很方便。

使用Deployment升级Pod,只需要定义Pod的最终状态,K8S会为你执行必要的操作,虽然能够使用命令kubectl rolling-update完成升级,但它是在客户端与服务端多次交互控制RC完成的,所以REST API中并没有rolling-update的接口,这为定制自己的管理系统带来了一些麻烦。

Deployment拥有更加灵活强大的升级、回滚功能。

常用命令

创建

使用子命令create,创建Deployment

kubectl create-f test-dpm.yaml --record

注意--record参数,使用此参数将记录后续创建对象的操作,方便管理与问题追溯

使用子命令edit,编辑spec.replicas/spec.template.spec.container.image字段,完成deployment的扩缩容与滚动升级(这要比子命令rolling-update速度快很多)

查看部署状态

kubectl rolloutstatus deployment/test-dpm

kubectl describedeployment/test-dpm

升级

kubectl set image deployment/test-dpm test-dpm=app:v1

或者

kubectl edit deployment/test-dpm

编辑.spec.template.spec.containers[0].image的值

终止升级

kubectl rolloutpause deployment/test-dpm

继续升级

kubectl rolloutresume deployment/test-dpm

回滚

kubectl rolloutundo deployment/test-dpm

查看deployments版本

kubectl rollouthistory deployments

回滚到指定版本

kubectl rolloutundo deployment/test-dpm --to-revision=2

升级历史

kubectl describedeployment/test-dpm

Name:            test-dpmNamespace:       defaultCreationTimestamp:    Tue, 01 Aug 2017 16:56:45 +0800Labels:               app=test-dpm                 project=test                 software=apache                 version=v1Selector:        app=test-dpm,name=test-dpm,project=test,software=apache,version=v1Replicas:        3updated | 3 total | 3 available | 0 unavailableStrategyType:         RecreateMinReadySeconds: 30Conditions:  Type           Status     Reason  ----           ------     ------ Available      True  MinimumReplicasAvailableOldReplicaSets:  <none>NewReplicaSet:   test-dpm-4183418831 (3/3 replicas created)Events: FirstSeen LastSeen   Count From                  SubObjectPath    Type       Reason                Message --------- --------   ----- ----                  -------------    --------   ------                -------  29m      29m        1     {deployment-controller }               Normal           ScalingReplicaSet     Scaledup replica set test-dpm-2823415590 to 3  28m      28m        1     {deployment-controller }               Normal           ScalingReplicaSet     Scaleddown replica set test-dpm-2823415590 to 0  28m      28m        1     {deployment-controller }               Normal           ScalingReplicaSet     Scaledup replica set test-dpm-4001949646 to 3  26m      26m        1     {deployment-controller }               Normal           ScalingReplicaSet     Scaleddown replica set test-dpm-4001949646 to 0  26m      26m        1     {deployment-controller }               Normal           ScalingReplicaSet     Scaledup replica set test-dpm-4183418831 to 3


yaml文件

apiVersion: extensions/v1beta1kind: Deploymentmetadata: name: test-dpm labels:   software: apache   project: test   app: test-dpm   version: v1 annotations:            #自定义注解列表    -name: String        #自定义注解名字spec: replicas: 3 #副本数量 minReadySeconds: 30 #滚动升级时30s后认为该pod就绪 strategy:   type: recreate #升级方式   #rollingUpdate:##由于replicas为3,则整个升级,pod个数在2-4个之间   #  maxSurge: 3 #滚动升级时会先启动3个pod   #  maxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数 selector:   matchLabels:     name: test-dpm     software: apache     project: test     app: test-dpm     version: v1 template:    metadata:     labels:       name: test-dpm       software: apache       project: test       app: test-dpm       version: v1   spec:     terminationGracePeriodSeconds: 60 ##k8s将会给应用发送SIGTERM信号,可以用来正确、优雅地关闭应用,默认为30秒     containers:     - name: test-dpm       image: web:apache       command: [ "sh", "/etc/run.sh" ]       ports:       - containerPort: 80         name: http         protocol: TCP       resources:         requests:           cpu: 0.05           memory: 16Mi         limits:           cpu: 0.1           memory: 32Mi       livenessProbe:#livenessProbe是K8S认为该pod是存活的,不存在则需要kill掉,然后再新启动一个,以达到RS指定的个数。         httpGet:           path: /           port: 80           scheme: HTTP         initialDelaySeconds: 30         timeoutSeconds: 5         successThreshold: 1         failureThreshold: 5       readinessProbe:#readinessProbe是K8S认为该pod是启动成功的,这里根据每个应用的特性,自己去判断,可以执行command,也可以进行httpGet。         httpGet:           path: /           port: 80           scheme: HTTP         initialDelaySeconds: 30         timeoutSeconds: 5         successThreshold: 1         failureThreshold: 5

strategy中的type

升级策略有recreate和rollingUpdate。recreate--删除所有已存在的pod,重新创建新的; rollingUpdate--滚动升级,逐步替换的策略,同时滚动升级时,支持更多的附加参数,例如设置最大不可用pod数量,最小升级间隔时间等等。

如何使用哪种策略,需要看应用场景。recreate策略将会在升级过程中,停止服务,但会保证应用版本一致;使用rollingUpdate不会中断服务,但会导致调用时出现应用版本不一致的情况,输出内容不一致。

maxSurge与maxUnavailable

maxSurge: 1 表示滚动升级时会先启动1个pod

maxUnavailable:1 表示滚动升级时允许的最大Unavailable的pod个数。由于replicas为3,则整个升级,pod个数在2-4个之间

terminationGracePeriodSeconds

k8s将会给应用发送SIGTERM信号,可以用来正确、优雅地关闭应用,默认为30秒。

如果需要更优雅地关闭,则可以使用k8s提供的pre-stop lifecycle hook 的配置声明,将会在发送SIGTERM之前执行。

livenessProbe与readinessProbe

livenessProbe是K8S认为该pod是存活的,不存在则需要kill掉,然后再新启动一个,以达到RS指定的个数。

readinessProbe是K8S认为该pod是启动成功的,这里根据每个应用的特性,自己去判断,可以执行command,也可以进行httpGet。比如对于使用java web服务的应用来说,并不是简单地说tomcat启动成功就可以对外提供服务的,还需要等待spring容器初始化,数据库连接连接上等等。对于spring boot应用,默认的actuator带有/health接口,可以用来进行启动成功的判断。

其中readinessProbe.initialDelaySeconds可以设置为系统完全启动起来所需的最少时间,livenessProbe.initialDelaySeconds可以设置为系统完全启动起来所需的最大时间+若干秒。


广告 广告

评论区