Kubernetes工作负载管理（上）

fldj

发布于 2022-8-26 16:25

浏览

0收藏

作者 | 乔克

来源 |运维开发故事(ID：mygsdcsf)

转载请联系授权(微信ID：wanger5354)

在Kubernetes中，Pod是最小的管理单元，是一组紧密关联的容器组合。

但是，单独的Pod并不能保障总是可用，比如我们创建一个nginx的Pod，因为某些原因，该Pod被意外删除，我们希望其能够自动新建一个同属性的Pod。很遗憾，单纯的Pod并不能满足需求。

为此，Kubernetes实现了一系列控制器来管理Pod，使Pod的期望状态和实际状态保持一致。目前常用的控制器有：

Deployment
StatefulSet
DaemonSet
Job/CronJob
这里只介绍Deployment、DaemonSet、Job/CronJob。StatefulSet留到后面Kubernetes有状态应用管理章节再来介绍，因为它涉及到很多其他的知识点，比如Service、PV/PVC，等这些知识点介绍完成过后再来说StatefulSet要好一点。

Deployment
在说Deployment之前，先来了解一下ReplicaSet（RS）。

在Kubernetes初期，是使用RC（Replication Controller）来控制Pod，保证其能够按照用户的期望运行，但是后面因为各种原因淘汰了RC，转而使用RS来替代它。从功能上看RC和RS没多大的变化，唯一的区别RS支持集合的Selector，可以方便定义更复杂的条件。

我们可以定义一个简单的ReplicaSet来感受一下：

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-set
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

创建结果如下：

$ kubectl get po
NAME              READY   STATUS              RESTARTS   AGE
nginx-set-hmtq4   0/1     ContainerCreating   0          2s
nginx-set-j2jpr   0/1     ContainerCreating   0          2s
$ kubectl get rs
NAME        DESIRED   CURRENT   READY   AGE
nginx-set   2         2         0       5s

可以看到我们期望replicas: 2创建2个Pod，所以通过kubectl get pod的时候可以看到有2两个Pod正在创建，这时候如果我们删除一个Pod，RS会立马给我们重新拉一个Pod，以满足我们的期望。

不过，在实际中很少去直接使用RS，而是使用Deployment。Deployment是比RS更高层的资源对象，它会去控制管理RS，如下：

Kubernetes工作负载管理（上）-鸿蒙开发者社区

从上图可以看到Deployment、ReplicaSet、Pod它们以层层控制关系，Deployment可以拥有多个ReplicaSet，一个ReplicaSet可以拥有多个Pod。一个Deployment拥有多个ReplicaSet主要是为了支持回滚操作，每当操作Deployment的时候，就会生成一个新的ReplicaSet，然后逐步更新新的Pod，而老的ReplicaSet会逐步减少Pod直到新的ReplicaSet全部接管。这时候并不会删除老的ReplicaSet，系统会将其保存下来，以备回滚使用。

ReplicaSet还负责通过"控制器模式"，保证系统的Pod数永远等于期望数，这也是Deployment只允许restartPolicy=Always的原因：只有在容器能保证自己始终处于running状态，通过ReplicaSet调整Pod的数量才有意义。

而在此基础上，Deployment同样通过"控制器模式"，来操作ReplicaSet的个数和属性，进而实现水平扩展/收缩和滚动更新这两个动作。其中水平扩展和收缩非常容易实现，Deployment Controller只需要修改它的ReplicaSet的Pod副本数就可以了。

创建一个Deployment的清单如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

启动过后可以看到如下信息：

$ kubectl get deployments.apps 
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           19s
$ kubectl get rs
NAME                         DESIRED   CURRENT   READY   AGE
nginx-deployment-8f458dc5b   3         3         3       21s
$ kubectl get po
NAME                               READY   STATUS    RESTARTS   AGE
nginx-deployment-8f458dc5b-8nn5c   1/1     Running   0          24s
nginx-deployment-8f458dc5b-hxc57   1/1     Running   0          24s
nginx-deployment-8f458dc5b-znrff   1/1     Running   0          24s

从上面信息可知，如果创建一个Deployment对象，会自动创建一个RS对象，然后通过RS对象创建对应的Pod数。

水平扩展/收缩
上面我们创建一个3副本的Pod，如果现在需要对其进行扩展/收缩，则可以通过以下三种方式：

kubectl scale命令
kubectl edit运行中的Deployment
通过修改YAML清单，然后使用kubectl apply进行更新
具体采用哪种方式根据情况而定。

1、通过kubectl scale命令进行扩缩
扩展和收缩的命令是一样，扩展就是增加副本数，收缩就是减少副本数。
（1）扩展我们现在有3个副本，如果想要4个副本，则使用以下命令：

$ kubectl scale deployment nginx-deployment --replicas 4
deployment.apps/nginx-deployment scaled

可以看到Pod数变成了4个。

$ kubectl get po
NAME                               READY   STATUS    RESTARTS   AGE
nginx-deployment-8f458dc5b-8nn5c   1/1     Running   0          8m3s
nginx-deployment-8f458dc5b-cv6mw   1/1     Running   0          29s
nginx-deployment-8f458dc5b-hxc57   1/1     Running   0          8m3s
nginx-deployment-8f458dc5b-znrff   1/1     Running   0          8m3s

（2）收缩现在集群里有4个副本，如果只想要2个副本，则使用如下命令

$ kubectl scale deployment nginx-deployment --replicas 2
deployment.apps/nginx-deployment scaled

现在集群里就只有两个Pod了。

$ kubectl get po
NAME                               READY   STATUS    RESTARTS   AGE
nginx-deployment-8f458dc5b-8nn5c   1/1     Running   0          9m36s
nginx-deployment-8f458dc5b-hxc57   1/1     Running   0          9m36s

2、通过kubectl edit直接编辑Deployment
我们也可以直接通过kubectl edit直接编辑运行中的Deployment，修改其副本数，如下：

$ kubectl edit deployments.apps nginx-deployment -oyaml

编辑界面如下：

Kubernetes工作负载管理（上）-鸿蒙开发者社区

修改过后使用:wq保存退出，可以看到副本数又变成4个了。

$ kubectl get po
NAME                               READY   STATUS    RESTARTS   AGE
nginx-deployment-8f458dc5b-8nn5c   1/1     Running   0          14m
nginx-deployment-8f458dc5b-hxc57   1/1     Running   0          14m
nginx-deployment-8f458dc5b-mq69h   1/1     Running   0          92s
nginx-deployment-8f458dc5b-xktq2   1/1     Running   0          92s

3、通过修改本地YAML文件，使用kubectl apply更新
我们还可以通过直接修改本地YAML的方式扩缩，比如直接在YAML文件中将副本数改成2：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

然后直接使用kubectl apply -f nginx.yaml部署即可。

滚动更新/回滚
业务应用基本都是通过Deployment的方式部署在Kubernetes中的，应用的更新和回滚是常态的工作，特别是在互联网企业，快速迭代抓住用户的一个重要途径。

但是，并不是每一次的迭代都是100%正常的，如果异常，如何快速恢复也是要考虑的事情。

为适应这种场景，Deployment提供滚动更新和快速回滚的能力。

滚动更新
Deployment默认的更新方式就是滚动更新，可以通过strategy.type来指定更新方式。

Recreate：先删除所有的Pod，再创建
RollingUpdate：先启动新的Pod，再替换老的Pod
如果要更改更新方式，配置如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
...
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1

说明：
（1）、maxSurge：定义除了DESIRED数量之外，在一次滚动更新过程中，Deployment还可以创建多少Pod；
（2）、maxUnavailable：定义在一次滚动更新过程中，Deployment最多可以删除多少Pod；另外，这两个配置还可以通过设置百分值来表示。

一般情况下，我们就保持默认的更新方式即可，这也是在生产中用的比较多的。

现在，来看看滚动更新的效果。首先创建一个nginx应用，如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.8

然后使用kubectl apply -f deploy.yaml，然后使用kubectl get po -w观察升级效果。

另外开启一个shell窗口，使用以下命令更新应用：

$ kubectl patch deployment nginx-deployment --patch '{"spec": {"template": {"spec": {"containers": [{"name": "nginx","image":"nginx:1.9"}]}}}}'

然后可以从另一个窗口查看升级的过程，如下：

$ kubectl get po -w
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-6c74f576b9-h565l   1/1     Running   0          22s
nginx-deployment-6c74f576b9-k65q6   1/1     Running   0          22s
nginx-deployment-6c74f576b9-qr2xc   1/1     Running   0          22s
nginx-deployment-778d9f5866-n69qd   0/1     Pending   0          0s
nginx-deployment-778d9f5866-n69qd   0/1     Pending   0          0s
nginx-deployment-778d9f5866-n69qd   0/1     ContainerCreating   0          0s
nginx-deployment-778d9f5866-n69qd   0/1     ContainerCreating   0          0s
nginx-deployment-778d9f5866-n69qd   1/1     Running             0          41s
nginx-deployment-6c74f576b9-qr2xc   1/1     Terminating         0          3m23s
nginx-deployment-778d9f5866-42vhv   0/1     Pending             0          0s
nginx-deployment-778d9f5866-42vhv   0/1     Pending             0          0s
nginx-deployment-778d9f5866-42vhv   0/1     ContainerCreating   0          0s
nginx-deployment-778d9f5866-42vhv   0/1     ContainerCreating   0          1s
nginx-deployment-6c74f576b9-qr2xc   1/1     Terminating         0          3m24s
nginx-deployment-6c74f576b9-qr2xc   0/1     Terminating         0          3m24s
nginx-deployment-778d9f5866-42vhv   1/1     Running             0          1s
nginx-deployment-6c74f576b9-k65q6   1/1     Terminating         0          3m24s
nginx-deployment-778d9f5866-tndn8   0/1     Pending             0          0s
nginx-deployment-778d9f5866-tndn8   0/1     Pending             0          0s
nginx-deployment-778d9f5866-tndn8   0/1     ContainerCreating   0          0s
nginx-deployment-6c74f576b9-k65q6   1/1     Terminating         0          3m24s
nginx-deployment-6c74f576b9-qr2xc   0/1     Terminating         0          3m24s
nginx-deployment-6c74f576b9-qr2xc   0/1     Terminating         0          3m24s
nginx-deployment-778d9f5866-tndn8   0/1     ContainerCreating   0          0s
nginx-deployment-6c74f576b9-k65q6   0/1     Terminating         0          3m25s
nginx-deployment-6c74f576b9-k65q6   0/1     Terminating         0          3m25s
nginx-deployment-6c74f576b9-k65q6   0/1     Terminating         0          3m25s
nginx-deployment-778d9f5866-tndn8   1/1     Running             0          1s
nginx-deployment-6c74f576b9-h565l   1/1     Terminating         0          3m25s
nginx-deployment-6c74f576b9-h565l   1/1     Terminating         0          3m25s
nginx-deployment-6c74f576b9-h565l   0/1     Terminating         0          3m26s
nginx-deployment-6c74f576b9-h565l   0/1     Terminating         0          3m26s
nginx-deployment-6c74f576b9-h565l   0/1     Terminating         0          3m26s

老的版本是nginx-deployment-6c74f576b9-*，新的版本是nginx-deployment-778d9f5866-*，会先创建一个新版本Pod，再删除老版本Pod，依次下去直到所有老的版本都被替换掉。

背后的实际逻辑是通过Deployment创建一个新的ReplicaSet，然后通过新的RS来创建新的Pod，可以通过kubectl get rs来查看：

$ kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-6c74f576b9   0         0         0       9m49s
nginx-deployment-778d9f5866   3         3         3       7m7s

这种滚动更新的好处是：如果在更新过程中，新版本Pod有问题，那么滚动更新就会停止，这时候运维和开发就可以介入查看其原因，由于应用本身还有两个旧版本的Pod在线，所以并不会对服务造成太大的影响；当然，这时候应在Pod中加上health check检查应用的健康状态，而不是简单的依赖容器的running状态。为了进一步保证服务的延续性，Deployment Controller还会确保在任何时间窗口内，只有指定比例的Pod处于离线状态，同时它也会确保在任何时间窗口内，只有指定比例的Pod被创建，这个比例默认是DESIRED的25%。

当然可以通过修改Deployment对象的一个字段RollingUpdateStrategy来自定义，比如：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
...
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1

如此，我们可以得到如下关系图：

Kubernetes工作负载管理（上）-鸿蒙开发者社区

Deployment实际控制的是ReplicaSet的数目以及每个ReplicaSet的属性。而一个应用版本，对应的就是一个ReplicaSet，而这个版本应有的Pod数量，是通过ReplicaSet自己的控制器来管理。

分类

云原生

标签

Kubernetes

已于2022-8-26 16:25:17修改

51CTO

51CTO博客

51CTO学堂

Kubernetes工作负载管理（上）

目录

订阅鸿蒙技术特刊，精选内容抢先看