search

Deployment

circle-info

Deployment-->Replica Set-->Pods

hashtag
1 创建

一个 Deployment 拥有多个 Replica Set，而一个 Replica Set 拥有一个或多个 Pod。一个 Deployment 控制多个 rs 主要是为了支持回滚机制，每当 Deployment 操作时，Kubernetes 会重新生成一个 Replica Set 并保留，以后有需要的话就可以回滚至之前的状态。 下面创建一个 Deployment，它创建了一个 Replica Set 来启动 3 个 nginx pod，yaml 文件如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  labels:
    k8s-app: nginx-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

将上面内容保存为：nginx-deployment.yaml，执行命令：

然后执行一下命令查看刚刚创建的 Deployment:

隔一会再次执行上面命令：

我们可以看到 Deployment 已经创建了 1 个 Replica Set 了，执行下面的命令查看 rs 和 pod:

上面的 Deployment 的 yaml 文件中的replicas:3将会保证我们始终有 3 个 POD 在运行。

hashtag
2 滚动升级

现在我们将刚刚保存的 yaml 文件中的 nginx 镜像修改为nginx:1.13.3，然后在 spec 下面添加滚动升级策略：

  • 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 处于无法服务的状态。

然后执行命令：

然后我们可以使用rollout命令：

  • 查看状态：

  • 暂停升级

  • 继续升级

升级结束后，继续查看 rs 的状态：

根据 AGE 我们可以看到离我们最近的当前状态是：3，和我们的 yaml 文件是一致的，证明升级成功了。用describe命令可以查看升级的全部信息：

hashtag
3 回滚 Deployment

我们已经能够滚动平滑的升级我们的 Deployment 了，但是如果升级后的 POD 出了问题该怎么办？我们能够想到的最好最快的方式当然是回退到上一次能够提供正常工作的版本，Deployment 就为我们提供了回滚机制。

首先，查看 Deployment 的升级历史：

从上面的结果可以看出在执行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。

同样我们可以使用下面的命令查看单个revison的信息：

假如现在要直接回退到当前版本的前一个版本：

当然也可以用revision回退到指定的版本：

现在可以用命令查看 Deployment 现在的状态了。

PreviousReplicationControllerNextJob/Cronjob

Last updated