kubernetes资源对象--deployment

爱被打了一巴掌 2022-05-24 06:26 229阅读 0赞

本文基于kubernetes 1.5.2版本编写

# 概念 #

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参数，使用此参数将记录后续创建对象的操作，方便管理与问题追溯

## 查看部署状态 ##

kubectl rolloutstatus deployment/lykops-dpm
    kubectl describe deployment/lykops-dpm

## 升级 ##

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

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

## 暂定升级 ##

kubectl rolloutpause deployment/lykops-dpm

## 继续升级 ##

kubectl rolloutresume deployment/lykops-dpm

## 回滚 ##

kubectl rolloutundo deployment/lykops-dpm

## 查看deployments版本 ##

kubectl rollouthistory deployments

## 回滚到指定版本 ##

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

## 升级历史 ##

kubectl describedeployment/lykops-dpm
    Name:            lykops-dpm
    Namespace:       default
    CreationTimestamp:    Tue, 01 Aug 2017 16:56:45 +0800
    Labels:               app=lykops-dpm
                     project=lykops
                     software=apache
                     version=v1
    Selector:        app=lykops-dpm,name=lykops-dpm,project=lykops,software=apache,version=v1
    Replicas:        3updated | 3 total | 3 available | 0 unavailable
    StrategyType:         Recreate
    MinReadySeconds: 30
    Conditions:
      Type           Status     Reason
      ----           ------     ------
     Available      True  MinimumReplicasAvailable
    OldReplicaSets:  <none>
    NewReplicaSet:   lykops-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 lykops-dpm-2823415590 to 3
      28m      28m        1     {deployment-controller }               Normal           ScalingReplicaSet     Scaleddown replica set lykops-dpm-2823415590 to 0
      28m      28m        1     {deployment-controller }               Normal           ScalingReplicaSet     Scaledup replica set lykops-dpm-4001949646 to 3
      26m      26m        1     {deployment-controller }               Normal           ScalingReplicaSet     Scaleddown replica set lykops-dpm-4001949646 to 0
      26m      26m        1     {deployment-controller }               Normal           ScalingReplicaSet     Scaledup replica set lykops-dpm-4183418831 to 3

# 例子 #

apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
     name: lykops-dpm
     labels:
       software: apache
       project: lykops
       app: lykops-dpm
       version: v1
    spec:
     replicas: 3 #副本数量
     minReadySeconds: 30 #滚动升级时，容器准备就绪时间最少为30s
     strategy:
       type: recreate #升级方式
       #rollingUpdate:##由于replicas为3,则整个升级,pod个数在2-4个之间
       #  maxSurge: 3 #滚动升级时会先启动3个pod
       #  maxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数
     selector:
       matchLabels:
         name: lykops-dpm
         software: apache
         project: lykops
         app: lykops-dpm
         version: v1
     template:
        metadata:
         labels:
           name: lykops-dpm
           software: apache
           project: lykops
           app: lykops-dpm
           version: v1
       spec:
         terminationGracePeriodSeconds: 60 ##k8s将会给应用发送SIGTERM信号，可以用来正确、优雅地关闭应用,默认为30秒
         containers:
         - name: lykops-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可以设置为系统完全启动起来所需的最大时间+若干秒。

转自：https://blog.csdn.net/liyingke112/article/details/76546630