kubenetes入门学习-八-Pod控制器--控制器类型以及功能-Deployment

╰半橙微兮° 2022-03-10 09:26 374阅读 0赞

Deployment控制器  
    Deployment为Pod和Replica Set（下一代Replication Controller）提供声明式更新。  
只需要在 Deployment 中描述想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。

可以定义一个全新的Deployment来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。

典型的用例如下：  
（1）使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod。检查启动状态，看它是成功还是失败。  
（2）然后，通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会创建一个新的ReplicaSet，Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中。  
（3）如果当前状态不稳定，回滚到之前的Deployment revision。每次回滚都会更新Deployment的revision。  
（4）扩容Deployment以满足更高的负载。  
（5）暂停Deployment来应用PodTemplateSpec的多个修复，然后恢复上线。  
（6）根据Deployment 的状态判断上线是否hang住了。  
（7）清除旧的不必要的 ReplicaSet。

deployment--控制replicaset--控制pod  
==============================  
（1）命令行查看deployment清单定义规则  
kubectl explain deployment  
kubectl explain deployment.spec.  
kubectl explain deployment.spec.strategy  
kubectl explain deployment.spec.strategy.rollingUpdate

Replicas（副本数量）：  
　　.spec.replicas 是可以选字段，指定期望的pod数量，默认是1。  
Selector（选择器）：  
　　.spec.selector是可选字段，用来指定 label selector ，圈定Deployment管理的pod范围。如果被指定，.spec.selector 必须匹配 .spec.template.metadata.labels，否则它将被API拒绝。如果 .spec.selector 没有被指定，.spec.selector.matchLabels 默认是.spec.template.metadata.labels。  
　　在Pod的template跟.spec.template不同或者数量超过了.spec.replicas规定的数量的情况下，Deployment会杀掉label跟selector不同的Pod。  
Pod Template（Pod模板）：  
　　.spec.template 是 .spec中唯一要求的字段。  
　　.spec.template 是 pod template. 它跟 Pod有一模一样的schema，除了它是嵌套的并且不需要apiVersion 和 kind字段。  
　　另外为了划分Pod的范围，Deployment中的pod template必须指定适当的label（不要跟其他controller重复了，参考selector）和适当的重启策略。  
　　.spec.template.spec.restartPolicy 可以设置为 Always , 如果不指定的话这就是默认配置。  
strategy（更新策略）：  
　　.spec.strategy 指定新的Pod替换旧的Pod的策略。 .spec.strategy.type 可以是"Recreate"或者是 "RollingUpdate"。"RollingUpdate"是默认值。  
　　Recreate： 重建式更新，就是删一个建一个。类似于ReplicaSet的更新方式，即首先删除现有的Pod对象，然后由控制器基于新模板重新创建新版本资源对象。  
　　rollingUpdate：滚动更新，简单定义 更新期间pod最多有几个等。可以指定maxUnavailable 和 maxSurge 来控制 rolling update 进程。　  
    maxSurge：.spec.strategy.rollingUpdate.maxSurge 是可选配置项，用来指定可以超过期望的Pod数量的最大个数。该值可以是一个绝对值（例如5）或者是期望的Pod数量的百分比（例如10%）。当MaxUnavailable为0时该值不可以为0。通过百分比计算的绝对值向上取整。默认值是1。  
　　例如，该值设置成30%，启动rolling update后新的ReplicatSet将会立即扩容，新老Pod的总数不能超过期望的Pod数量的130%。旧的Pod被杀掉后，新的ReplicaSet将继续扩容，旧的ReplicaSet会进一步缩容，确保在升级的所有时刻所有的Pod数量和不会超过期望Pod数量的130%。　　  
    maxUnavailable：.spec.strategy.rollingUpdate.maxUnavailable 是可选配置项，用来指定在升级过程中不可用Pod的最大数量。该值可以是一个绝对值（例如5），也可以是期望Pod数量的百分比（例如10%）。通过计算百分比的绝对值向下取整。  如果.spec.strategy.rollingUpdate.maxSurge 为0时，这个值不可以为0。默认值是1。  
　　例如，该值设置成30%，启动rolling update后旧的ReplicatSet将会立即缩容到期望的Pod数量的70%。新的Pod ready后，随着新的ReplicaSet的扩容，旧的ReplicaSet会进一步缩容确保在升级的所有时刻可以用的Pod数量至少是期望Pod数量的70%。  
PS：maxSurge和maxUnavailable的属性值不可同时为0，否则Pod对象的副本数量在符合用户期望的数量后无法做出合理变动以进行更新操作。

在配置时，用户还可以使用Deployment控制器的spec.minReadySeconds属性来控制应用升级的速度。新旧更替过程中，新创建的Pod对象一旦成功响应就绪探测即被认为是可用状态，然后进行下一轮的替换。而spec.minReadySeconds能够定义在新的Pod对象创建后至少需要等待多长的时间才能会被认为其就绪，在该段时间内，更新操作会被阻塞。

revisionHistoryLimit（历史版本记录）：  
　　Deployment revision history存储在它控制的ReplicaSets中。默认保存记录10个　　  
　　.spec.revisionHistoryLimit 是一个可选配置项，用来指定可以保留的旧的ReplicaSet数量。该理想值取决于心Deployment的频率和稳定性。如果该值没有设置的话，默认所有旧的Replicaset或会被保留，将资源存储在etcd中，是用kubectl get rs查看输出。每个Deployment的该配置都保存在ReplicaSet中，然而，一旦删除的旧的RepelicaSet，Deployment就无法再回退到那个revison了。  
　　如果将该值设置为0，所有具有0个replica的ReplicaSet都会被删除。在这种情况下，新的Deployment rollout无法撤销，因为revision history都被清理掉了。

PS：为了保存版本升级的历史，需要再创建Deployment对象时，在命令中使用"--record"选项

rollbackTo：　　　　　　  
 　　.spec.rollbackTo 是一个可以选配置项，用来配置Deployment回退的配置。设置该参数将触发回退操作，每次回退完成后，该值就会被清除。  
　　 revision：.spec.rollbackTo.revision是一个可选配置项，用来指定回退到的revision。默认是0，意味着回退到上一个revision。  
progressDeadlineSeconds：　　  
　　.spec.progressDeadlineSeconds 是可选配置项，用来指定在系统报告Deployment的failed progressing——表现为resource的状态中type=Progressing、Status=False、 Reason=ProgressDeadlineExceeded前可以等待的Deployment进行的秒数。Deployment controller会继续重试该Deployment。未来，在实现了自动回滚后， deployment controller在观察到这种状态时就会自动回滚。  
　　如果设置该参数，该值必须大于 .spec.minReadySeconds。  
paused：  
　.spec.paused是可以可选配置项，boolean值。用来指定暂停和恢复Deployment。Paused和没有paused的Deployment之间的唯一区别就是，所有对paused deployment中的PodTemplateSpec的修改都不会触发新的rollout。Deployment被创建之后默认是非paused。

（2）解析Deployment实例  
\[root@master manifests\]\# cat deployment.yaml   
apiVersion: apps/v1  
kind: Deployment  
metadata:  
    name: myapp-deploy  
    namespace: default  
spec:  
    replicas: 2  
    selector:  
        matchLabels:  
            app: myapp  
            release: canary  
    template:  
        metadata:  
            labels:  
                app: myapp  
                release: canary  
        spec:  
            containers:  
              - name: myapp  
                image: nginx  
                ports:  
                  - name: http  
                    containerPort: 80  
                      
kubectl appliy和kubectl create 区别是前者修改配置后多次执行，配置更新到etcd，现有状态更新到期望状态

deployment--控制replicaset--控制pod  
\[root@master manifests\]\# kubectl apply -f deployment.yaml   
deployment.apps/myapp-deploy created  
\[root@master manifests\]\# kubectl get deploy  
NAME           READY   UP-TO-DATE   AVAILABLE   AGE  
myapp-deploy   2/2     2            2           2m5s     创建了  
nginx          3/3     3            3           8d  
nginx-deploy   1/1     1            1           9d  
\[root@master manifests\]\# kubectl get rs  
NAME                      DESIRED   CURRENT   READY   AGE  
myapp-deploy-69dc8c7655   2         2         2       2m16s  自动创建了2个rs  
nginx-775ff75bc8          0         0         0       8d  
nginx-7849c4bbcd          3         3         3       8d  
nginx-deploy-84cbfc56b6   1         1         1       9d  
\[root@master manifests\]\# kubectl get pods  
NAME                            READY   STATUS    RESTARTS   AGE  
liveness-httpget-pod            1/1     Running   1          4d17h  
myapp-deploy-69dc8c7655-jkkwv   1/1     Running   0          11s  
myapp-deploy-69dc8c7655-q97jc   1/1     Running   0          11s  
nginx-7849c4bbcd-dscjr          1/1     Running   0          8d  
nginx-7849c4bbcd-vdd45          1/1     Running   0          8d  
nginx-7849c4bbcd-wrvks          1/1     Running   0          8d  
nginx-deploy-84cbfc56b6-mjcw5   1/1     Running   0          8d  
\[root@master manifests\]\# vi deployment.yaml    这里修改配置  
spec:  
    replicas: 2  修改为3  
\[root@master manifests\]\# kubectl apply -f deployment.yaml 动态更新到etcd，现在有状态逼近期望状态  
deployment.apps/myapp-deploy configured

\[root@master manifests\]\# kubectl describe deploy myapp-deploy  看详细信息

======================================  
升级或者扩容

在修改版本，修改到另一个版本，这里使用动态命令观测更新过程，创建一个，终止一个，这个过程  
1、修改配置文件  
\[root@master manifests\]\# vi deployment.yaml   
\[root@master manifests\]\# kubectl apply -f deployment.yaml   
deployment.apps/myapp-deploy configured  
\[root@master manifests\]\# kubectl get pods -l app=myapp -w  
\[root@master ~\]\# kubectl get rs -o wide

2、使用kubectl set image  
\[root@k8s-master ~\]\# kubectl set image deployment/myapp-deploy myapp=ikubernetes/myapp:v2

3、之前说过一种方式  
\[root@master ~\]\# kubectl scale deployment myapp-deploy --replicas 5

=============================  
修改滚动跟新策略  
1、直接使用命令打补丁  
\[root@master ~\]\# kubectl patch deployment myapp-deploy -p '\{"spec":\{"replicas":5\}\}'  
deployment.extensions/myapp-deploy patched  
\[root@master ~\]\# kubectl get pods  
NAME                            READY   STATUS    RESTARTS   AGE  
liveness-httpget-pod            1/1     Running   1          4d17h  
myapp-deploy-69dc8c7655-jkkwv   1/1     Running   0          20m  
myapp-deploy-69dc8c7655-q97jc   1/1     Running   0          20m  
myapp-deploy-69dc8c7655-sldk8   1/1     Running   0          15s  
myapp-deploy-69dc8c7655-v9dvc   1/1     Running   0          15s  
myapp-deploy-69dc8c7655-x5qth   1/1     Running   0          13m  
nginx-7849c4bbcd-dscjr          1/1     Running   0          8d  
nginx-7849c4bbcd-vdd45          1/1     Running   0          8d  
nginx-7849c4bbcd-wrvks          1/1     Running   0          8d  
nginx-deploy-84cbfc56b6-mjcw5   1/1     Running   0          8d

2、通过set 命令直接修改image的版本进行升级  
\[root@master ~\]\# kubectl patch deployment myapp-deploy -p '\{"spec":\{"strategy":\{"rollingUpdate":\{"maxSurge":1,"maxUnavailable":0\}\}\}\}'  
deployment.extensions/myapp-deploy patched

================================  
金丝雀发布  
Deployment控制器支持自定义控制更新过程中的滚动节奏，如“暂停(pause)”或“继续(resume)”更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布（Canary Release），如下命令演示：  
（1）更新deployment的v3版本，并配置暂停deployment  
\[root@k8s-master ~\]\# kubectl set image deployment myapp-deploy myapp=ikubernetes/myapp:v3 && kubectl rollout pause deployment myapp-deploy      
deployment "myapp-deploy" image updated  
deployment "myapp-deploy" paused  
\[root@k8s-master ~\]\# kubectl rollout status deployments myapp-deploy　　\#观察更新状态  
（2）监控更新的过程，可以看到已经新增了一个资源，但是并未按照预期的状态去删除一个旧的资源，就是因为使用了pause暂停命令  
\[root@k8s-master ~\]\# kubectl get pods -l app=myapp -w   
NAME                            READY     STATUS    RESTARTS   AGE  
myapp-deploy-869b888f66-dpwvk   1/1       Running   0          24m  
myapp-deploy-869b888f66-frspv   1/1       Running   0         24m  
myapp-deploy-869b888f66-sgsll   1/1       Running   0         24m  
myapp-deploy-7cbd5b69b9-5s4sq   0/1       Pending   0         0s  
myapp-deploy-7cbd5b69b9-5s4sq   0/1       Pending   0         0s  
myapp-deploy-7cbd5b69b9-5s4sq   0/1       ContainerCreating   0         1s  
myapp-deploy-7cbd5b69b9-5s4sq   0/1       ContainerCreating   0         2s  
myapp-deploy-7cbd5b69b9-5s4sq   1/1       Running   0         19s  
（3）确保更新的pod没问题了，继续更新  
\[root@k8s-master ~\]\# kubectl rollout resume deploy  myapp-deploy  
4）查看最后的更新情况  
\[root@k8s-master ~\]\# kubectl get pods -l app=myapp -w   
NAME                            READY     STATUS    RESTARTS   AGE  
myapp-deploy-869b888f66-dpwvk   1/1       Running   0          24m  
myapp-deploy-869b888f66-frspv   1/1       Running   0         24m  
myapp-deploy-869b888f66-sgsll   1/1       Running   0         24m  
myapp-deploy-7cbd5b69b9-5s4sq   0/1       Pending   0         0s  
myapp-deploy-7cbd5b69b9-5s4sq   0/1       Pending   0         0s  
myapp-deploy-7cbd5b69b9-5s4sq   0/1       ContainerCreating   0         1s  
myapp-deploy-7cbd5b69b9-5s4sq   0/1       ContainerCreating   0         2s  
myapp-deploy-7cbd5b69b9-5s4sq   1/1       Running   0         19s  
myapp-deploy-869b888f66-dpwvk   1/1       Terminating   0         31m  
myapp-deploy-7cbd5b69b9-p6kzm   0/1       Pending   0         1s  
myapp-deploy-7cbd5b69b9-p6kzm   0/1       Pending   0         1s  
myapp-deploy-7cbd5b69b9-p6kzm   0/1       ContainerCreating   0         1s  
myapp-deploy-7cbd5b69b9-p6kzm   0/1       ContainerCreating   0         2s  
myapp-deploy-869b888f66-dpwvk   0/1       Terminating   0         31m  
myapp-deploy-869b888f66-dpwvk   0/1       Terminating   0         31m  
myapp-deploy-869b888f66-dpwvk   0/1       Terminating   0         31m  
myapp-deploy-7cbd5b69b9-p6kzm   1/1       Running   0         18s  
myapp-deploy-869b888f66-frspv   1/1       Terminating   0         31m  
myapp-deploy-7cbd5b69b9-q8mvs   0/1       Pending   0         0s  
myapp-deploy-7cbd5b69b9-q8mvs   0/1       Pending   0         0s  
myapp-deploy-7cbd5b69b9-q8mvs   0/1       ContainerCreating   0         0s  
myapp-deploy-7cbd5b69b9-q8mvs   0/1       ContainerCreating   0         1s  
myapp-deploy-869b888f66-frspv   0/1       Terminating   0         31m  
myapp-deploy-869b888f66-frspv   0/1       Terminating   0         31m  
myapp-deploy-869b888f66-frspv   0/1       Terminating   0         31m  
myapp-deploy-869b888f66-frspv   0/1       Terminating   0         31m

================================  
Deployment版本回退  
　　默认情况下，kubernetes 会在系统中保存前两次的 Deployment 的 rollout 历史记录，以便可以随时回退（您可以修改revision history limit来更改保存的revision数）。  
　　注意： 只要 Deployment 的 rollout 被触发就会创建一个 revision。也就是说当且仅当 Deployment 的 Pod template（如.spec.template）被更改，例如更新template 中的 label 和容器镜像时，就会创建出一个新的 revision。  
其他的更新，比如扩容 Deployment 不会创建 revision——因此我们可以很方便的手动或者自动扩容。这意味着当您回退到历史 revision 时，只有 Deployment 中的 Pod template 部分才会回退。  
\[root@master ~\]\# kubectl rollout history deploy  myapp-deploy  
deployment.extensions/myapp-deploy   
REVISION  CHANGE-CAUSE  
2         <none>  
3         <none>  
这里在创建deployment时没有增加--record参数，所以并不能看到revision的变化。在创建 Deployment 的时候使用了--record参数可以记录命令，就可以方便的查看每次 revision 的变化。  
查看单个revision 的详细信息：

\[root@master ~\]\# kubectl rollout history deployment/myapp-deploy --revision=2  
回退历史版本，默认是回退到上一个版本：

\[root@master ~\]\# kubectl rollout undo deployment/myapp-deploy  
deployment "myapp-deploy" rolled back    
也可以使用 --revision参数指定某个历史版本：  
默认undo是回滚到上一个版本

\[root@master ~\]\# kubectl rollout undo deployment/myapp-deploy --to-revision=2  
deployment "myapp-deploy" rolled back

\[root@master ~\]\#kubectl get rs -o wide  
查看最终使用那个版本  
================================  
命令行查看deployment清单定义规则  
\[root@master ~\]\# kubectl explain deployment  
KIND:     Deployment  
VERSION:  extensions/v1beta1

DESCRIPTION:  
     DEPRECATED - This group version of Deployment is deprecated by  
     apps/v1beta2/Deployment. See the release notes for more information.  
     Deployment enables declarative updates for Pods and ReplicaSets.

FIELDS:  
   apiVersion    <string>  
     APIVersion defines the versioned schema of this representation of an  
     object. Servers should convert recognized schemas to the latest internal  
     value, and may reject unrecognized values. More info:  
     https://git.k8s.io/community/contributors/devel/api-conventions.md\#resources

kind    <string>  
     Kind is a string value representing the REST resource this object  
     represents. Servers may infer this from the endpoint the client submits  
     requests to. Cannot be updated. In CamelCase. More info:  
     https://git.k8s.io/community/contributors/devel/api-conventions.md\#types-kinds

metadata    <Object>  
     Standard object metadata.

spec    <Object>  
     Specification of the desired behavior of the Deployment.

status    <Object>  
     Most recently observed status of the Deployment.

\[root@master ~\]\# kubectl explain deployment.spec.  
KIND:     Deployment  
VERSION:  extensions/v1beta1

RESOURCE: spec <Object>

DESCRIPTION:  
     Specification of the desired behavior of the Deployment.

DeploymentSpec is the specification of the desired behavior of the  
     Deployment.

FIELDS:  
   minReadySeconds    <integer>  
     Minimum number of seconds for which a newly created pod should be ready  
     without any of its container crashing, for it to be considered available.  
     Defaults to 0 (pod will be considered available as soon as it is ready)

paused    <boolean>  
     Indicates that the deployment is paused and will not be processed by the  
     deployment controller.

progressDeadlineSeconds    <integer>  
     The maximum time in seconds for a deployment to make progress before it is  
     considered to be failed. The deployment controller will continue to process  
     failed deployments and a condition with a ProgressDeadlineExceeded reason  
     will be surfaced in the deployment status. Note that progress will not be  
     estimated during the time a deployment is paused. This is set to the max  
     value of int32 (i.e. 2147483647) by default, which means "no deadline".

replicas    <integer>  
     Number of desired pods. This is a pointer to distinguish between explicit  
     zero and not specified. Defaults to 1.

revisionHistoryLimit    <integer>  
     The number of old ReplicaSets to retain to allow rollback. This is a  
     pointer to distinguish between explicit zero and not specified. This is set  
     to the max value of int32 (i.e. 2147483647) by default, which means  
     "retaining all old RelicaSets".

rollbackTo    <Object>  
     DEPRECATED. The config this deployment is rolling back to. Will be cleared  
     after rollback is done.

selector    <Object>  
     Label selector for pods. Existing ReplicaSets whose pods are selected by  
     this will be the ones affected by this deployment.

strategy    <Object>  
     The deployment strategy to use to replace existing pods with new ones.

template    <Object> -required-  
     Template describes the pods that will be created.

\[root@master ~\]\# kubectl explain deployment.spec.strategy  
KIND:     Deployment  
VERSION:  extensions/v1beta1

RESOURCE: strategy <Object>

DESCRIPTION:  
     The deployment strategy to use to replace existing pods with new ones.

DeploymentStrategy describes how to replace existing pods with new ones.

FIELDS:  
   rollingUpdate    <Object>  
     Rolling update config params. Present only if DeploymentStrategyType =  
     RollingUpdate.

type    <string>  
     Type of deployment. Can be "Recreate" or "RollingUpdate". Default is  
     RollingUpdate.  
\[root@master ~\]\# kubectl explain deployment.spec.strategy.rollingUpdate  
KIND:     Deployment  
VERSION:  extensions/v1beta1

RESOURCE: rollingUpdate <Object>

DESCRIPTION:  
     Rolling update config params. Present only if DeploymentStrategyType =  
     RollingUpdate.

Spec to control the desired behavior of rolling update.

FIELDS:  
   maxSurge    <string>  
     The maximum number of pods that can be scheduled above the desired number  
     of pods. Value can be an absolute number (ex: 5) or a percentage of desired  
     pods (ex: 10%). This can not be 0 if MaxUnavailable is 0. Absolute number  
     is calculated from percentage by rounding up. By default, a value of 1 is  
     used. Example: when this is set to 30%, the new RC can be scaled up  
     immediately when the rolling update starts, such that the total number of  
     old and new pods do not exceed 130% of desired pods. Once old pods have  
     been killed, new RC can be scaled up further, ensuring that total number of  
     pods running at any time during the update is atmost 130% of desired pods.

maxUnavailable    <string>  
     The maximum number of pods that can be unavailable during the update. Value  
     can be an absolute number (ex: 5) or a percentage of desired pods (ex:  
     10%). Absolute number is calculated from percentage by rounding down. This  
     can not be 0 if MaxSurge is 0. By default, a fixed value of 1 is used.  
     Example: when this is set to 30%, the old RC can be scaled down to 70% of  
     desired pods immediately when the rolling update starts. Once new pods are  
     ready, old RC can be scaled down further, followed by scaling up the new  
     RC, ensuring that the total number of pods available at all times during  
     the update is at least 70% of desired pods.  
       
解析Deployment实例  
\[root@master manifests\]\# kubectl apply -f deployment.yaml   
deployment.apps/myapp-deploy created

\[root@master manifests\]\# kubectl get pods  
NAME                            READY   STATUS    RESTARTS   AGE  
liveness-httpget-pod            1/1     Running   1          4d17h  
myapp-deploy-69dc8c7655-jkkwv   1/1     Running   0          7s  
myapp-deploy-69dc8c7655-q97jc   1/1     Running   0          7s  
nginx-7849c4bbcd-dscjr          1/1     Running   0          8d  
nginx-7849c4bbcd-vdd45          1/1     Running   0          8d  
nginx-7849c4bbcd-wrvks          1/1     Running   0          8d  
nginx-deploy-84cbfc56b6-mjcw5   1/1     Running   0          8d  
\[root@master manifests\]\# kubectl get deploy  
NAME           READY   UP-TO-DATE   AVAILABLE   AGE  
myapp-deploy   2/2     2            2           2m5s  
nginx          3/3     3            3           8d  
nginx-deploy   1/1     1            1           9d  
\[root@master manifests\]\# kubectl get rs  
NAME                      DESIRED   CURRENT   READY   AGE  
myapp-deploy-69dc8c7655   2         2         2       2m16s  
nginx-775ff75bc8          0         0         0       8d  
nginx-7849c4bbcd          3         3         3       8d  
nginx-deploy-84cbfc56b6   1         1         1       9d

\[root@master manifests\]\# kubectl get pods  
NAME                            READY   STATUS    RESTARTS   AGE  
liveness-httpget-pod            1/1     Running   1          4d17h  
myapp-deploy-69dc8c7655-jkkwv   1/1     Running   0          6m19s  
myapp-deploy-69dc8c7655-q97jc   1/1     Running   0          6m19s  
nginx-7849c4bbcd-dscjr          1/1     Running   0          8d  
nginx-7849c4bbcd-vdd45          1/1     Running   0          8d  
nginx-7849c4bbcd-wrvks          1/1     Running   0          8d  
nginx-deploy-84cbfc56b6-mjcw5   1/1     Running   0          8d  
\[root@master manifests\]\# vi deployment.yaml   
\[root@master manifests\]\# vi deployment.yaml    这里修改配置  
spec:  
    replicas: 2  修改为3  
\[root@master manifests\]\# kubectl apply -f deployment.yaml   
deployment.apps/myapp-deploy configured  
\[root@master manifests\]\# kubectl get pods  
NAME                            READY   STATUS    RESTARTS   AGE  
liveness-httpget-pod            1/1     Running   1          4d17h  
myapp-deploy-69dc8c7655-jkkwv   1/1     Running   0          7m29s  
myapp-deploy-69dc8c7655-q97jc   1/1     Running   0          7m29s  
myapp-deploy-69dc8c7655-x5qth   1/1     Running   0          46s  
nginx-7849c4bbcd-dscjr          1/1     Running   0          8d  
nginx-7849c4bbcd-vdd45          1/1     Running   0          8d  
nginx-7849c4bbcd-wrvks          1/1     Running   0          8d  
nginx-deploy-84cbfc56b6-mjcw5   1/1     Running   0          8d

\[root@master manifests\]\# kubectl describe deploy myapp-deploy  
Name:                   myapp-deploy  
Namespace:              default  
CreationTimestamp:      Sun, 10 Mar 2019 03:17:45 -0400  
Labels:                 <none>  
Annotations:            deployment.kubernetes.io/revision: 1  
                        kubectl.kubernetes.io/last-applied-configuration:  
                          \{"apiVersion":"apps/v1","kind":"Deployment","metadata":\{"annotations":\{\},"name":"myapp-deploy","namespace":"default"\},"spec":\{"replicas":3...  
Selector:               app=myapp,release=canary  
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=myapp  
           release=canary  
  Containers:  
   myapp:  
    Image:        nginx  
    Port:         80/TCP  
    Host Port:    0/TCP  
    Environment:  <none>  
    Mounts:       <none>  
  Volumes:        <none>  
Conditions:  
  Type           Status  Reason  
  ----           ------  ------  
  Progressing    True    NewReplicaSetAvailable  
  Available      True    MinimumReplicasAvailable  
OldReplicaSets:  <none>  
NewReplicaSet:   myapp-deploy-69dc8c7655 (3/3 replicas created)  
Events:  
  Type    Reason             Age    From                   Message  
  ----    ------             ----   ----                   -------  
  Normal  ScalingReplicaSet  9m19s  deployment-controller  Scaled up replica set myapp-deploy-69dc8c7655 to 2  
  Normal  ScalingReplicaSet  2m36s  deployment-controller  Scaled up replica set myapp-deploy-69dc8c7655 to 3  
    
\[root@master ~\]\# kubectl get rs -o wide  
NAME                      DESIRED   CURRENT   READY   AGE     CONTAINERS     IMAGES              SELECTOR  
myapp-deploy-69dc8c7655   3         3         3       17m     myapp          nginx               app=myapp,pod-template-hash=69dc8c7655,release=canary  
myapp-deploy-78c767689f   0         0         0       3m55s   myapp          apache:2.4          app=myapp,pod-template-hash=78c767689f,release=canary  
nginx-775ff75bc8          0         0         0       8d      nginx          nginx               pod-template-hash=775ff75bc8,run=nginx  
nginx-7849c4bbcd          3         3         3       8d      nginx          nginx:1.14-alpine   pod-template-hash=7849c4bbcd,run=nginx  
nginx-deploy-84cbfc56b6   1         1         1       9d      nginx-deploy   nginx:1.14-alpine   pod-template-hash=84cbfc56b6,run=nginx-deploy

打补丁  
\[root@master ~\]\# kubectl patch deployment myapp-deploy -p '\{"spec":\{"replicas":5\}\}'  
deployment.extensions/myapp-deploy patched  
\[root@master ~\]\# kubectl get pods  
NAME                            READY   STATUS    RESTARTS   AGE  
liveness-httpget-pod            1/1     Running   1          4d17h  
myapp-deploy-69dc8c7655-jkkwv   1/1     Running   0          20m  
myapp-deploy-69dc8c7655-q97jc   1/1     Running   0          20m  
myapp-deploy-69dc8c7655-sldk8   1/1     Running   0          15s  
myapp-deploy-69dc8c7655-v9dvc   1/1     Running   0          15s  
myapp-deploy-69dc8c7655-x5qth   1/1     Running   0          13m  
nginx-7849c4bbcd-dscjr          1/1     Running   0          8d  
nginx-7849c4bbcd-vdd45          1/1     Running   0          8d  
nginx-7849c4bbcd-wrvks          1/1     Running   0          8d  
nginx-deploy-84cbfc56b6-mjcw5   1/1     Running   0          8d

\[root@master ~\]\# kubectl patch deployment myapp-deploy -p '\{"spec":\{"strategy":\{"rollingUpdate":\{"maxSurge":1,"maxUnavailable":0\}\}\}\}'  
deployment.extensions/myapp-deploy patched  
\[root@master ~\]\# kubectl describe deployment myapp-deploy  
Name:                   myapp-deploy  
Namespace:              default  
CreationTimestamp:      Sun, 10 Mar 2019 03:17:45 -0400  
Labels:                 app=myapp  
                        release=canary  
Annotations:            deployment.kubernetes.io/revision: 3  
                        kubectl.kubernetes.io/last-applied-configuration:  
                          \{"apiVersion":"apps/v1","kind":"Deployment","metadata":\{"annotations":\{\},"name":"myapp-deploy","namespace":"default"\},"spec":\{"replicas":3...  
Selector:               app=myapp,release=canary  
Replicas:               5 desired | 5 updated | 5 total | 5 available | 0 unavailable  
StrategyType:           RollingUpdate  
MinReadySeconds:        0  
RollingUpdateStrategy:  0 max unavailable, 1 max surge  
Pod Template:  
  Labels:  app=myapp  
           release=canary  
  Containers:  
   myapp:  
    Image:        nginx  
    Port:         80/TCP  
    Host Port:    0/TCP  
    Environment:  <none>  
    Mounts:       <none>  
  Volumes:        <none>  
Conditions:  
  Type           Status  Reason  
  ----           ------  ------  
  Progressing    True    NewReplicaSetAvailable  
  Available      True    MinimumReplicasAvailable  
OldReplicaSets:  <none>  
NewReplicaSet:   myapp-deploy-69dc8c7655 (5/5 replicas created)  
Events:  
  Type    Reason             Age    From                   Message  
  ----    ------             ----   ----                   -------  
  Normal  ScalingReplicaSet  26m    deployment-controller  Scaled up replica set myapp-deploy-69dc8c7655 to 2  
  Normal  ScalingReplicaSet  19m    deployment-controller  Scaled up replica set myapp-deploy-69dc8c7655 to 3  
  Normal  ScalingReplicaSet  12m    deployment-controller  Scaled up replica set myapp-deploy-78c767689f to 1  
  Normal  ScalingReplicaSet  11m    deployment-controller  Scaled down replica set myapp-deploy-78c767689f to 0  
  Normal  ScalingReplicaSet  5m41s  deployment-controller  Scaled up replica set myapp-deploy-69dc8c7655 to 5

实验参考：[https://www.cnblogs.com/linuxk/p/9578211.html][https_www.cnblogs.com_linuxk_p_9578211.html]  这个师兄总结的好

群名称：k8s学习群   群   号：153144292

[https_www.cnblogs.com_linuxk_p_9578211.html]: https://www.cnblogs.com/linuxk/p/9578211.html