Kubernetes Pod升级与回滚 - 风哥博客

/ 2019-11-05 14:00:55 / 0评 / 0

当集群中的某个服务需要升级时,我们需要停止目前与该服务相关的所有Pod,然后下载新版本镜像并创建新的Pod。如果集群规模比较大,则这个工作变成了一个挑战,而且先全部停止然后逐步升级的方式会导致较长时间的服务不可用。Kubernetes提供了滚动升级功能来解决上述问题。如果在更新过程中发生了错误,则还可以通过回滚操作恢复Pod的版本。

Deployment升级

现有如下deployment定义(nginx-deployment.yml):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      name: nginx
  replicas: 3
  template:
    metadata:
      labels:
        name: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.7.9
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80

创建该deployment:

通过kubectl命令将nginx的版本更新到1.9.1:

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

查看滚动升级的过程:

查看Pod,会发现名称已经改变了:

上述滚动升级的过程可以用下图表示:

查看Deployment nginx-deployment的详细事件信息可以证明这一点:

kubectl describe deployments/nginx-deployment

查看rs:

默认的升级策略为RollingUpdate(滚动更新),Kubernetes还支持Recreate(重建)策略:

  1. Recreate:先杀掉所有正在运行的Pod,然后创建新的Pod。
  2. RollingUpdate:以滚动更新的方式来逐个更新Pod。同时,可以通过设置spec.strategy.rollingUpdate下的两个参数(maxUnavailable和maxSurge)来控制滚动更新的过程。

RollingUpdate的两个参数含义如下:

  1. maxUnavailable:用于指定Deployment在更新过程中不可用状态的Pod数量的上限。该maxUnavailable的数值可以是绝对值(例如1)或Pod期望的副本数的百分比(例如10%)。
  2. maxSurge:用于指定在Deployment更新Pod的过程中Pod总数超过Pod期望副本数部分的最大值。该maxSurge的数值可以是绝对值(例如5)或Pod期望副本数的百分比(例如10%)。

此外,除了使用kubectl命令升级外,我们也可以直接通过修改deployment.yml的方式来完成。

Deployment回滚

如果升级后效果不满意的话,我们也可以将Deployment回滚到升级之前,使用下面这条命令查看滚动升级的历史:

kubectl rollout history deployment/nginx-deployment

REVISION为升级的历史版本,我们只完成了nginx从1.7.9升级到1.9.1的过程,所以REVISION 1表示nginx为1.7.9的版本,REVISION 2表示nginx为1.9.1的版本。因为我们在创建deployment的时候没有加上--record=true参数,所以CHANGE-CACSE列是空的。

需要查看特定版本的详细信息,则可以加上–revision=参数:

要将nginx回退到1.7.9版本,我们可以将REVISION指定为1:

kubectl rollout undo deployment/nginx-deployment --to-revision=1

暂停与恢复

因为Deployment配置一旦修改就会触发升级操作,所以当修改的地方较多的时候就会频繁触发升级。我们可以先暂停升级操作,当所有配置都修改好后再恢复升级。

暂停:

kubectl rollout pause deployment/nginx-deployment

暂停后,对nginx-deployment的修改不会触发升级。修改好后,恢复升级:

kubectl rollout resume deployment/nginx-deployment

其他Pod管理对象升级策略

DaemonSet

DaemonSet的升级策略包括两种:OnDelete和RollingUpdate:

  1. OnDelete(默认):在创建好新的DaemonSet配置之后,新的Pod并不会被自动创建,直到用户手动删除旧版本的Pod,才触发新建操作。
  2. RollingUpdate:和前面介绍的一致,不过不支持rollout,只能通过将配置改回去来实现。

StatefulSet

支持Recreate、OnDelete和RollingUpdate。

发表评论

邮箱地址不会被公开。 必填项已用*标注