Deployment-k8s

Deployment

Deployment 为 Pod 和 ReplicaSet 提供了⼀个声明式定义(declarative)⽅法，⽤来替代以前的ReplicationController 来⽅便的管理应⽤

典型的应⽤场景包括:

定义Deployment来创建Pod和ReplicaSet
滚动升级和回滚应⽤
扩容和缩容
暂停和继续Deployment

一个简单的nginx应⽤可以定义为
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

扩容
kubectl scale deployment nginx-deployment --replicas 10

如果集群⽀持 horizontal pod autoscaling 的话，还可以为Deployment设置⾃动扩展：
kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80

更新镜像也⽐较简单:
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

回滚：
kubectl rollout undo deployment/nginx-deployment

Deployment 是什么？

Deployment为Pod和Replica Set（下⼀代Replication Controller）提供声明式更新

您只需要在 Deployment 中描述您想要的⽬标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的⽬标状态。您可以定义⼀个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建⼀个新的来替换

典型的⽤例如下：

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

Replication Controller和Replica Set两种资源对象:

RC和RS的功能相似，RS支持集合的selector 。

RC是k8s的核心概念，其功能：

1，确保Pod数量：它会确保Kubernetes中有指定数量的Pod在运行，如果少于指定数量的Pod，RC就会创建新的，反之这会删除多余的，保证Pod的副本数量不变。
2，确保Pod健康：当Pod不健康，比如运行出错了，总之无法提供正常服务时，RC也会杀死不健康的Pod，重新创建新的。
3，弹性伸缩：在业务高峰或者低峰的时候，可以用过RC来动态的调整Pod数量来提供资源的利用率，当然我们也提到过如果使用HPA这种资源对象的话可以做到自动伸缩
4，滚动升级：滚动升级是一种平滑的升级方式，通过逐步替换的策略，保证整体系统的稳定性

Deployment功能：管理pod

1，RC的全部功能：Deployment具备上面描述的RC的全部功能
2，事件和状态查看：可以查看Deployment的升级详细进度和状态
3，回滚：当升级Pod的时候如果出现问题，可以使用回滚操作回滚到之前的任一版本
4，版本记录：每一次对Deployment的操作，都能够保存下来，这也是保证可以回滚到任一版本的基础 
5，暂停和启动：对于每一次升级都能够随时暂停和启动

一个Deployment拥有多个Replica Set，而一个Replica Set拥有一个或多个Pod。一个Deployment控制多个rs主要是为了支持回滚机制，每当Deployment操作时，Kubernetes会重新生成一个Replica Set并保留，以后有需要的话就可以回滚至之前的状态

创建 Deployment

$ kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record

将kubectl的 --record 的 flag 设置为 true 可以在 annotation 中记录当前命令创建或者升级了该资源。这在未来会很有⽤，例如，查看在每个 Deployment revision 中执⾏了哪些命令

立即执行：

$ kubectl get deployments
NAME            DESIRED    CURRENT     UP-TO-DATE    AVAILABLE      AGE
nginx-deployment 3         0            0            0              1s

输出结果表明我们希望的repalica数是3（根据deployment中的 .spec.replicas 配置）当前replica数（
.status.replicas ）是0, 最新的replica数（ .status.updatedReplicas ）是0，可⽤的replica数
（ .status.availableReplicas ）是0。

过⼏秒后再执⾏ get 命令，

$ kubectl get deployments
NAME            DESIRED      CURRENT    UP-TO-DATE    AVAILABLE     AGE
nginx-deployment 3           3           3             3            18s

看到Deployment已经创建了3个 replica，所有的 replica 都已经是最新的了（包含最新的pod template），可
⽤的（根据Deployment中的 .spec.minReadySeconds 声明，处于已就绪状态的pod的最少个数）。执⾏ kubectl get
rs 和 kubectl get pods 会显示Replica Set（RS）和Pod已创建

$ kubectl get rs
NAME                        DESIRED     CURRENT     READY        AGE
nginx-deployment-2035384211 3            3          0            18s

 ReplicaSet 的名字总是 <Deployment的名字>-<pod template的hash值> 
 
$ kubectl get pods --show-labels
NAME                              READY STATUS RESTARTS AGE LABELS
nginx-deployment-2035384211-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211
nginx-deployment-2035384211-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211
nginx-deployment-2035384211-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211

刚创建的Replica Set将保证总是有3个 nginx 的 pod 存在。
注意：您必须在 Deployment 中的 selector 指定正确的 pod template label（在该示例中是 app = nginx ），不要跟其他的 controller 的 selector 中指定的 pod template label 搞混了（包括 Deployment、Replica Set、Replication
Controller 等）。Kubernetes 本身并不会阻⽌您任意指定 pod template label ，但是如果您真的这么做了，这些
controller 之间会相互打架，并可能导致不正确的⾏为

更新Deployment

注意： Deployment 的 rollout 当且仅当 Deployment 的 pod template（例如 .spec.template ）中的label更新或者镜像更改时被触发。其他更新，例如扩容Deployment不会触发 rollout。

假如我们现在想要让 nginx pod 使⽤ nginx:1.9.1 的镜像来代替原来的 nginx:1.7.9 的镜像。
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
deployment "nginx-deployment" image updated

我们可以使⽤ edit 命令来编辑 Deployment，修改 .spec.template.spec.containers[0].image ，将 nginx:1.7.9 改写成nginx:1.9.1 。
$ kubectl edit deployment/nginx-deployment
deployment "nginx-deployment" edited


查看 rollout 的状态，只要执⾏：
$ kubectl rollout status deployment/nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-deployment" successfully rolled out


Rollout 成功后， get Deployment：
$ kubectl get deployments
NAME                DESIRED   CURRENT   UP-TO-DATE   AVAILABLE    AGE
nginx-deployment     3          3         3           3           36s

UP-TO-DATE 的 replica 的数⽬已经达到了配置中要求的数⽬
CURRENT 的 replica 数表示 Deployment 管理的 replica 数量，AVAILABLE 的 replica 数是当前可⽤的replica数量。

我们通过执⾏ kubectl get rs 可以看到 Deployment 更新了Pod，通过创建⼀个新的 ReplicaSet 并扩容了3个 replica，同时将原来的 ReplicaSet 缩容到了0个 replica。
$ kubectl get rs
NAME                         DESIRED CURRENT READY AGE
nginx-deployment-1564180365  3       3       0     6s
nginx-deployment-2035384211  0       0       0     36s

执⾏ get pods 只会看到当前的新的 pod:
$ kubectl get pods
NAME                              READY STATUS    RESTARTS   AGE
nginx-deployment-1564180365-khku8 1/1   Running   0          14s
nginx-deployment-1564180365-nacti 1/1   Running   0          14s
nginx-deployment-1564180365-z9gth 1/1   Running   0          14s

下次更新这些 pod 的时候，只需要更新 Deployment 中的 pod 的 template 即可。
Deployment 可以保证在升级时只有⼀定数量的 Pod 是 down 的。默认的，它会确保⾄少有⽐期望的Pod数量少⼀个是
up状态（最多⼀个不可⽤）。
Deployment 同时也可以确保只创建出超过期望数量的⼀定数量的 Pod。默认的，它会确保最多⽐期望的Pod数量多⼀
个的 Pod 是 up 的（最多1个 surge ）

$ kubectl describe deployments

Label selector 更新

不⿎励更新 label selector，我们建议事先规划好您的 selector。

任何情况下，只要您想要执⾏ label selector 的更新，请⼀定要谨慎并确认您已经预料到所有可能因此导致的后果。
增添 selector 需要同时在 Deployment 的 spec 中更新新的 label，否则将返回校验错误。此更改是不可覆盖的，这
意味着新的 selector 不会选择使⽤旧 selector 创建的 ReplicaSet 和 Pod，从⽽导致所有旧版本的 ReplicaSet 都被
丢弃，并创建新的 ReplicaSet。
更新 selector，即更改 selector key 的当前值，将导致跟增添 selector 同样的后果。
删除 selector，即删除 Deployment selector 中的已有的 key，不需要对 Pod template label 做任何更改，现有的
ReplicaSet 也不会成为孤⼉，但是请注意，删除的 label 仍然存在于现有的 Pod 和 ReplicaSet 中。

回退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 部分才会回退

假设我们在更新 Deployment 的时候犯了⼀个拼写错误，将镜像的名字写成了 nginx:1.91 ，⽽正确的名字应该
是 nginx:1.9.1 ：
kubectl set image deployment/nginx-deployment nginx=nginx:1.91
Rollout 将会卡住
kubectl rollout status deployments nginx-deployment
按住 Ctrl-C 停⽌上⾯的 rollout 状态监控。

kubectl get rs
您会看到旧的 replica（nginx-deployment-1564180365 和 nginx-deployment-2035384211）和新的 replica （nginxdeployment-3066724191）数⽬都是2个
看下创建 Pod，您会看到有两个新的 ReplicaSet 创建的 Pod 处于 ImagePullBackOff 状态，循环拉取镜像
$ kubectl get pods

注意，Deployment controller会⾃动停⽌坏的 rollout，并停⽌扩容新的 ReplicaSet。
$ kubectl describe deployment

##修复错误：回滚
检查 Deployment 升级的历史记录
检查下 Deployment 的 revision：
$ kubectl rollout history deployment/nginx-deployment

创建 Deployment 的时候使⽤了 --record 参数可以记录命令，我们可以很⽅便的查看每次 revision 的变化
查看单个revision 的详细信息：
$ kubectl rollout history deployment/nginx-deployment --revision=2
回退到历史版本
kubectl rollout undo deployment/nginx-deployment
也可以使⽤ --revision 参数指定某个历史版本
$ kubectl rollout undo deployment/nginx-deployment --to-revision=2

该 Deployment 现在已经回退到了先前的稳定版本。如您所⻅，Deployment controller产⽣了⼀个回退到revison 2
的 DeploymentRollback 的 event
$ kubectl get deployment

清理 Policy

您可以通过设置 .spec.revisonHistoryLimit 项来指定 deployment 最多保留多少 revision 历史记录。默认的会保留所有的revision；如果将该项设置为0，Deployment就不允许回退了。

Deployment 扩容

$ kubectl scale deployment nginx-deployment --replicas 10

假设您的集群中启⽤了horizontal pod autoscaling，您可以给 Deployment 设置⼀个 autoscaler，基于当前 Pod的 CPU利⽤率选择最少和最多的 Pod 数。
$ kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80

⽐例扩容

RollingUpdate Deployment ⽀持同时运⾏⼀个应⽤的多个版本。或者 autoscaler 扩容 RollingUpdate Deployment 的时候，正在中途的 rollout（进⾏中或者已经暂停的），为了降低⻛险，Deployment controller 将会平衡已存在的活动中的ReplicaSet（有 Pod 的 ReplicaSet）和新加⼊的 replica。这被称为⽐例扩容。
例如，您正在运⾏中含有10个 replica 的 Deployment。maxSurge=3，maxUnavailable=2

$ kubectl get deploy

暂停和恢复Deployment

可以在发出⼀次或多次更新前暂停⼀个 Deployment，然后再恢复它。这样您就能多次暂停和恢复 Deployment，在此期间进⾏⼀些修复⼯作，⽽不会发出不必要的 rollout。

$ kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 3 3 3 3 1m
[mkargaki@dhcp129-211 kubernetes]$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-2142116321 3 3 3 1m


暂停 Deployment：
$ kubectl rollout pause deployment/nginx-deployment
deployment "nginx-deployment" paused

然后更新 Deplyment中的镜像：
$ kubectl set image deploy/nginx nginx=nginx:1.9.1
deployment "nginx-deployment" image updated

注意新的 rollout 启动了：
$ kubectl rollout history deploy/nginx
deployments "nginx"
REVISION CHANGE-CAUSE
1 <none>
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-2142116321 3 3 3 2m
您可以进⾏任意多次更新，例如更新使⽤的资源：
$ kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi
deployment "nginx" resource requirements updated

Deployment 暂停前的初始状态将继续它的功能，⽽不会对 Deployment 的更新产⽣任何影响，只要 Deployment是暂停
的。
最后，恢复这个 Deployment，观察完成更新的 ReplicaSet 已经创建出来了

$ kubectl rollout resume deploy nginx
$ KUBECTL get rs -w
$ KUBECTL get rs

Deployment 状态

Deployment 在⽣命周期中有多种状态。在创建⼀个新的 ReplicaSet 的时候它可以是 progressing 状态， complete 状态，或者 fail to progress 状态。

进⾏中的 Deployment
Kubernetes 将执⾏过下列任务之⼀的 Deployment 标记为 progressing 状态：
Deployment 正在创建新的ReplicaSet过程中。
Deployment 正在扩容⼀个已有的 ReplicaSet。
Deployment 正在缩容⼀个已有的 ReplicaSet。
有新的可⽤的 pod 出现。

使⽤ kubectl rollout status 命令监控 Deployment 的进度

Kubernetes 将包括以下特性的 Deployment 标记为 complete 状态：

Deployment 最⼩可⽤。最⼩可⽤意味着 Deployment 的可⽤ replica 个数等于或者超过 Deployment 策略中的期望个数。
所有与该 Deployment 相关的replica都被更新到了您指定版本，也就说更新完成。
该 Deployment 中没有旧的 Pod 存在。

您可以⽤ kubectl rollout status 命令查看 Deployment 是否完成。如果 rollout 成功完成， kubectl rollout status 将返回⼀个0值的 Exit Code

$ kubectl rollout status deploy/nginx

失败的 Deployment

Deployment 在尝试部署新的 ReplicaSet 的时候可能卡住，永远也不会完成。这可能是因为以下⼏个因素引起
的：

⽆效的引⽤
不可读的 probe failure
镜像拉取错误
权限不够
范围限制
程序运⾏时配置错误

探测这种情况的⼀种⽅式是，在您的 Deployment spec 中指定 spec.progressDeadlineSeconds 。 spec.progressDeadlineSeconds 表示 Deployment controller 等待多少秒才能确定（通过Deployment status）Deployment进程是卡住的。

下⾯的 kubectl 命令设置 progressDeadlineSeconds 使 controller 在 Deployment 在进度卡住10分钟后报告：
$ kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'

当超过截⽌时间后，Deployment controller 会在 Deployment 的 status.conditions 中增加⼀条DeploymentCondition，
它包括如下属性：
Type=Progressing
Status=False
Reason=ProgressDeadlineExceeded
注意： kubernetes除了报告 Reason=ProgressDeadlineExceeded 状态信息外不会对卡住的 Deployment 做任何操作。更⾼层次的协调器可以利⽤它并采取相应⾏动，例如，回滚 Deployment 到之前的版本。
注意：如果您暂停了⼀个 Deployment，在暂停的这段时间内kubernetnes不会检查您指定的 deadline。您可以在
Deployment 的 rollout 途中安全的暂停它，然后再恢复它，这不会触发超过deadline的状态。

kubectl get deployment nginx-deployment -o yaml

⼀旦超过 Deployment 进程的 deadline，kuberentes 会更新状态和导致 Progressing 状态的原因

Conditions:
Type Status Reason

Available True MinimumReplicasAvailable
Progressing False ProgressDeadlineExceeded
ReplicaFailure True FailedCreate

您可以通过缩容 Deployment的⽅式解决配额不⾜的问题，或者增加您的 namespace 的配额。如果您满⾜了配额条件后，Deployment controller 就会完成您的 Deployment rollout，您将看到 Deployment 的状态更新为成功状态
（ Status=True 并且 Reason=NewReplicaSetAvailable ）。
Conditions:
Type Status Reason

Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable

Type=Available 、 Status=True 以为这您的Deployment有最⼩可⽤性。最⼩可⽤性是在Deployment策略中指定的参
数。 Type=Progressing 、 Status=True 意味着您的Deployment 或者在部署过程中，或者已经成功部署，达到了期望的最少的可⽤replica数量（查看特定状态的Reason——在我们的例⼦中 Reason=NewReplicaSetAvailable 意味着Deployment已经完成）

⾦丝雀 Deployment

如果您想要使⽤ Deployment 对部分⽤户或服务器发布 release，您可以创建多个 Deployment，每个 Deployment 对应⼀个 release，参照 managing resources 中对⾦丝雀模式的描述

Deployment 实操

Deployment，它创建了一个Replica Set来启动3个nginx pod

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx-deploy
  labels:
    k8s-app: nginx-demo
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
#执行
$ kubectl create -f nginx-deployment.yaml
#查看
$ kubectl get deployments
NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deploy   3         0         0            0           1s
稍等几秒再查看
$ kubectl get deployments
NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deploy   3         3         3            3           4m
#查看Replica Set 执行下面的命令查看rs和pod
$ kubectl get rs
NAME                     DESIRED   CURRENT   READY     AGE
nginx-deploy-431080787   3         3         3         6m

$ kubectl get pod --show-labels
NAME                           READY     STATUS    RESTARTS   AGE       LABELS
nginx-deploy-431080787-53z8q   1/1       Running   0          7m        app=nginx,pod-template-hash=431080787
nginx-deploy-431080787-bhhq0   1/1       Running   0          7m        app=nginx,pod-template-hash=431080787
nginx-deploy-431080787-sr44p   1/1       Running   0          7m        app=nginx,pod-template-hash=431080787

#滚动升级
将刚刚保存的yaml文件中的nginx镜像修改为nginx:1.13.3，然后在spec下面添加滚动升级策略：
minReadySeconds: 5
strategy:
  # indicate which strategy we want for rolling update
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 1
    
minReadySeconds:
    Kubernetes在等待设置的时间后才进行升级
    如果没有设置该值，Kubernetes会假设该容器启动起来后就提供服务了
    如果没有设置该值，在某些极端情况下可能会造成服务不正常运行
maxSurge:
    升级过程中最多可以比原先设置多出的POD数量
    例如：maxSurage=1，replicas=5,则表示Kubernetes会先启动1一个新的Pod后才删掉一个旧的POD，整个升级过程中最多会有5+1个POD。
maxUnavaible:
    升级过程中最多有多少个POD处于无法提供服务的状态
    当maxSurge不为0时，该值也不能为0
    例如：maxUnavaible=1，则表示Kubernetes整个升级过程中最多会有1个POD处于无法服务的状态。
#然后执行命令：
$ kubectl apply -f nginx-deployment.yaml

#使用rollout命令
$ kubectl rollout status deployment/nginx-deploy   查看状态
$ kubectl rollout pause deployment <deployment>    暂停升级
$ kubectl rollout resume deployment <deployment>   继续升级
升级结束，查看状态
$ kubectl get rs

#回滚Deployment
查看Deployment的升级历史
$ kubectl rollout history deployment nginx-deploy  
在执行Deployment升级的时候最好带上record参数，便于我们查看历史版本信息。
默认情况下，所有通过kubectl xxxx --record都会被kubernetes记录到etcd进行持久化，这无疑会占用资源，最重要的是，时间久了，当你kubectl get rs时，会有成百上千的垃圾RS返回给你，那时你可能就眼花缭乱了。

上生产时，我们最好通过设置Deployment的.spec.revisionHistoryLimit来限制最大保留的revision number，比如15个版本，回滚的时候一般只会回滚到最近的几个版本就足够了。其实rollout history中记录的revision都和ReplicaSets一一对应。如果手动delete某个ReplicaSet，对应的rollout history就会被删除，也就是还说你无法回滚到这个revison了。

rollout history和ReplicaSet的对应关系，可以在kubectl describe rs $RSNAME返回的revision字段中得到，这里的revision就对应着rollout history返回的revison。

$ kubectl rollout history deployment nginx-deploy --revision=3  查看单个版本信息
假如现在要直接回退到当前版本的前一个版本
$ kubectl rollout undo deployment nginx-deploy
也可以用revision回退到指定的版本
$ kubectl rollout undo deployment nginx-deploy --to-revision=2

StatefulSet

StatefulSet 作为 Controller 为 Pod 提供唯⼀的标识。它可以保证部署和 scale 的顺序

StatefulSet是为了解决有状态服务的问题（对应Deployments和ReplicaSets是为⽆状态服务⽽设计），其应⽤场景包
括：

稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
稳定的⽹络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的
Service）来实现
有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进⾏（即从0到N-1，
在下⼀个Pod运⾏之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现有序收缩，有序删除（即从N-1到0）

StatefulSet由以下⼏个部分组成：

⽤于定义⽹络标志（DNS domain）的Headless Service
⽤于创建PersistentVolumes的volumeClaimTemplates
定义具体应⽤的StatefulSet

StatefulSet中每个Pod的DNS格式为 statefulSetName-{0..N-1}.serviceName.namespace.svc.cluster.local ，其中

serviceName 为Headless Service的名字
0..N-1 为Pod所在的序号，从0开始到N-1
statefulSetName 为StatefulSet的名字
namespace 为服务所在的namespace，Headless Servic和StatefulSet必须在相同的namespace
.cluster.local 为Cluster Domain

StatefulSet 适⽤于有以下某个或多个需求的应⽤：

稳定，唯⼀的⽹络标志。
稳定，持久化存储。
有序，优雅地部署和 scale。
有序，优雅地删除和终⽌。
有序，⾃动的滚动升级。

稳定是 Pod （重新）调度中持久性的代名词。如果应⽤程序不需要任何稳定的标识符、有序部署、删除和scale，则应该使⽤提供⼀组⽆状态副本的 controller 来部署应⽤程序，例如 Deployment 或 ReplicaSet 可能更适合您的⽆状态需求

posted @ 2020-04-21 15:40 Lust4Life 阅读(255) 评论(0) 编辑收藏举报

刷新页面返回顶部

Loading

𝖑𝖚𝖘𝖙4𝖑𝖎𝖋𝖊