rc与deployment的区别

曾经终败给现在 2022-03-24 15:56 130阅读 0赞

rolling update，可以使得服务近乎无缝地平滑升级，即在不停止对外服务的前提下完成应用的更新。

## replication controller与deployment的区别 ##

### replication controller ###

Replication Controller为Kubernetes的一个核心内容，应用托管到Kubernetes之后，需要保证应用能够持续的运行，Replication Controller就是这个保证的key，主要的功能如下：

*  确保pod数量：它会确保Kubernetes中有指定数量的Pod在运行。如果少于指定数量的pod，Replication Controller会创建新的，反之则会删除掉多余的以保证Pod数量不变。
 *  确保pod健康：当pod不健康，运行出错或者无法提供服务时，Replication Controller也会杀死不健康的pod，重新创建新的。
 *  弹性伸缩 ：在业务高峰或者低峰期的时候，可以通过Replication Controller动态的调整pod的数量来提高资源的利用率。同时，配置相应的监控功能（Hroizontal Pod Autoscaler），会定时自动从监控平台获取Replication Controller关联pod的整体资源使用情况，做到自动伸缩。
 *  滚动升级：滚动升级为一种平滑的升级方式，通过逐步替换的策略，保证整体系统的稳定，在初始化升级的时候就可以及时发现和解决问题，避免问题不断扩大。

### Deployment ###

Deployment同样为Kubernetes的一个核心内容，主要职责同样是为了保证pod的数量和健康，90%的功能与Replication Controller完全一样，可以看做新一代的Replication Controller。但是，它又具备了Replication Controller之外的新特性：

*  Replication Controller全部功能：Deployment继承了上面描述的Replication Controller全部功能。
 *  事件和状态查看：可以查看Deployment的升级详细进度和状态。
 *  回滚：当升级pod镜像或者相关参数的时候发现问题，可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。
 *  版本记录: 每一次对Deployment的操作，都能保存下来，给予后续可能的回滚使用。
 *  暂停和启动：对于每一次升级，都能够随时暂停和启动。
 *  多种升级方案：Recreate：删除所有已存在的pod,重新创建新的; RollingUpdate：滚动升级，逐步替换的策略，同时滚动升级时，支持更多的附加参数，例如设置最大不可用pod数量，最小升级间隔时间等等。

## deployment的常用命令 ##

### 查看部署状态 ###

1.  `kubectl rollout status deployment/review-demo --namespace=scm`
2.  `kubectl describe deployment/review-demo --namespace=scm`

或者这种写法

1.  `kubectl rollout status deployments review-demo --namespace=scm`
2.  `kubectl describe deployments review-demo --namespace=scm`

### 升级 ###

kubectl set image deployment/review-demo review-demo=library/review-demo:0.0.1 --namespace=scm

或者

kubectl edit deployment/review-demo --namespace=scm

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

### 终止升级 ###

kubectl rollout pause deployment/review-demo --namespace=scm

### 继续升级 ###

kubectl rollout resume deployment/review-demo --namespace=scm

### 回滚 ###

kubectl rollout undo deployment/review-demo --namespace=scm

### 查看deployments版本 ###

kubectl rollout history deployments --namespace=scm

回滚到指定版本

kubectl rollout undo deployment/review-demo --to-revision=2 --namespace=scm

## 升级历史 ##

kubectl describe deployment/review-demo --namespace=scm
    
    Name: review-demo
    
    Namespace: scm
    
    CreationTimestamp: Tue, 31 Jan 2017 16:42:01 +0800
    
    Labels: app=review-demo
    
    Selector: app=review-demo
    
    Replicas: 3 updated | 3 total | 3 available | 0 unavailable
    
    StrategyType: RollingUpdate
    
    MinReadySeconds: 0
    
    RollingUpdateStrategy: 1 max unavailable, 1 max surge
    
    OldReplicaSets: <none>
    
    NewReplicaSet: review-demo-2741031620 (3/3 replicas created)
    
    Events:
    
    FirstSeen LastSeen Count From SubobjectPath Type Reason Message
    
    --------- -------- ----- ---- ------------- -------- ------ -------
    
    1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set review-demo-2741031620 to 1
    
    1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set review-demo-1914295649 to 2
    
    1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set review-demo-2741031620 to 2
    
    1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set review-demo-1914295649 to 1
    
    1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set review-demo-2741031620 to 3
    
    1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set review-demo-1914295649 to 0

## deployment文件 ##

apiVersion: extensions/v1beta1
    
    kind: Deployment
    
    metadata:
    
    name: review-demo
    
    namespace: scm
    
    labels:
    
    app: review-demo
    
    spec:
    
    replicas: 3
    
    # minReadySeconds: 60 #滚动升级时60s后认为该pod就绪
    
    strategy:
    
    rollingUpdate: ##由于replicas为3,则整个升级,pod个数在2-4个之间
    
    maxSurge: 1 #滚动升级时会先启动1个pod
    
    maxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数
    
    template:
    
    metadata:
    
    labels:
    
    app: review-demo
    
    spec:
    
    terminationGracePeriodSeconds: 60 ##k8s将会给应用发送SIGTERM信号，可以用来正确、优雅地关闭应用,默认为30秒
    
    containers:
    
    - name: review-demo
    
    image: library/review-demo:0.0.1-SNAPSHOT
    
    imagePullPolicy: IfNotPresent
    
    livenessProbe: #kubernetes认为该pod是存活的,不存活则需要重启
    
    httpGet:
    
    path: /health
    
    port: 8080
    
    scheme: HTTP
    
    initialDelaySeconds: 60 ## equals to the maximum startup time of the application + couple of seconds
    
    timeoutSeconds: 5
    
    successThreshold: 1
    
    failureThreshold: 5
    
    readinessProbe: #kubernetes认为该pod是启动成功的
    
    httpGet:
    
    path: /health
    
    port: 8080
    
    scheme: HTTP
    
    initialDelaySeconds: 30 ## equals to minimum startup time of the application
    
    timeoutSeconds: 5
    
    successThreshold: 1
    
    failureThreshold: 5
    
    resources:
    
    # keep request = limit to keep this container in guaranteed class
    
    requests:
    
    cpu: 50m
    
    memory: 200Mi
    
    limits:
    
    cpu: 500m
    
    memory: 500Mi
    
    env:
    
    - name: PROFILE
    
    value: "test"
    
    ports:
    
    - name: http
    
    containerPort: 8080

## 几个重要参数说明 ##

### 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是kubernetes认为该pod是存活的，不存在则需要kill掉，然后再新启动一个，以达到replicas指定的个数。

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

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

> 这几个参数配置好了之后，基本就可以实现近乎无缝地平滑升级了。对于使用服务发现的应用来说，readinessProbe可以去执行命令，去查看是否在服务发现里头应该注册成功了，才算成功。
> 
>  
> 
>  
> 
> 在新版本的Kubernetes中建议使用ReplicaSet来取代ReplicationCtronller。ReplicaSet跟ReplicationCtronller没有本质的不同，只是名字不一样，并且ReplicaSet支持集合式的selector。
> 
> 虽然ReplicaSet可以独立使用，但一般还是建议使用 Deployment 来自动管理ReplicaSet，这样就无需担心跟其他机制的不兼容问题（比如ReplicaSet不支持rolling-update但Deployment支持）。