【云原生 | 从零开始学Kubernetes】十五、k8s核心技术-Deployment 控制器

什么是Deployment 控制器

• Deployment控制器可以部署无状态应用
• 管理Pod和ReplicaSet
• 部署滚动升级等功能
• 应用场景web服务微服务

Deployment表示用户对K8S集群的一次更新操作。Deployment是一个比RS( Replica Set, RS) 应用模型更广的 API 对象可以是创建一个新的服务更新一个新的服务也可以是滚动升级一个服务。滚动升级一个服务实际是创建一个新的RS然后逐渐将新 RS 中副本数增加到理想状态将旧RS中的副本数减少到0的复合操作。

这样一个复合操作用一个RS是不好描述的所以用一个更通用的Deployment来描述。以K8S的发展方向未来对所有长期伺服型的业务的管理都会通过Deployment来管理。

Deployment 概述

Deployment 是 kubernetes 中最常用的资源对象为 ReplicaSet 和 Pod 的创建提供了一种声明式的定义方法在 Deployment 对象中描述一个期望的状态Deployment 控制器就会按照一定的控制速率把实际状态改成期望状态通过定义一个 Deployment 控制器会创建一个新的 ReplicaSet 控制器通过 ReplicaSet 创建 pod删除 Deployment 控制器也会删除 Deployment 控制器下对应的 ReplicaSet 控制器和 pod 资源。

使用 Deployment 而不直接创建 ReplicaSet 是因为 Deployment 对象拥有许多 ReplicaSet 没有的特性例如滚动升级和回滚。

扩展声明式定义是指直接修改资源清单 yaml 文件然后通过 kubectl apply -f 资源清单 yaml 文 件就可以更改资源。Deployment 控制器是建立在 rs 之上的一个控制器可以管理多个 rs每次更新镜像版本都会生成一个新的 rs把旧的 rs 替换掉多个 rs 同时存在但是只有一个 rs 运行。

rs v1 控制三个 pod删除一个 pod在 rs v2 上重新建立一个依次类推直到全部都是由 rs v2 控制如果 rs v2 有问题还可以回滚Deployment 是建构在 rs 之上的多个 rs 组成一个 Deployment但是只有一个 rs 处于活跃状态.

Deployment 工作原理如何管理 rs 和 Pod？

Deployment 可以使用声明式定义直接在命令行通过纯命令的方式完成对应资源版本的内容的修改也就是通过打补丁的方式进行修改；Deployment 能提供滚动式自定义自控制的更新；对 Deployment 来讲我们在实现更新时还可以实现控制更新节奏和更新逻辑。

什么叫做更新节奏和更新逻辑呢？

比如说 Deployment 控制 5 个 pod 副本pod 的期望值是 5 个但是升级的时候需要额外多几个 pod那我们控制器可以控制在 5 个 pod 副本之外还能再增加几个 pod 副本。比方说能多一个但是不能少那么升级的时候就是先增加一个再删除一个增加一个删除一个始终保持 pod 副本数是 5 个。还有一种情况最多允许多一个最少允许少一个也就是最多 6 个最少 4 个第一次加一个删除两个第二次加两个删除两个依次类推可以自己控制更新方式这种滚动更新需要加 readinessProbe 和 livenessProbe 探测确保 pod 中容器里的应用都正常启动了才删除之前的 pod。

启动第一步刚更新第一批就暂停了也可以；假如目标是 5 个允许一个也不能少允许最多可以 10 个那一次加 5 个即可；这就是我们可以自己控制节奏来控制更新的方法。

通过 Deployment 对象你可以轻松的做到以下事情

1、创建 ReplicaSet 和 Pod

2、滚动升级（不停止旧服务的状态下升级和回滚应用（将应用回滚到之前的版本

3、平滑地扩容和缩容

4、暂停和继续 Deployment

简单使用Deployment

但是我们可以尝试使用上面的代码创建一个镜像【只是尝试不会创建】

kubectl create deployment web --image=nginx --dry-run -o yaml > nginx.yaml

然后输出一个yaml配置文件 nginx.yml 配置文件如下所示

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: web
    spec:
      containers:
      - image: nginx
        name: nginx
        resources: {}
status: {}

我们看到的 selector 和 label 就是我们Pod 和 Controller之间建立关系的桥梁

使用YAML创建Pod

通过刚刚的代码快速创建Pod镜像

kubectl apply -f nginx.yaml

但是因为这个方式创建的我们只能在集群内部进行访问所以我们还需要对外暴露端口

kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web1

关于上述命令有几个参数

• –port就是我们内部的端口号
• –target-port就是暴露外面访问的端口号
• –name名称
• –type类型

同理我们一样可以导出对应的配置文件

kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web1 -o yaml > web1.yaml

得到的web1.yaml如下所示

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2022-07-11T07:21:58Z"
  labels:
    app: web
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:labels:
          .: {}
          f:app: {}
      f:spec:
        f:externalTrafficPolicy: {}
        f:ports:
          .: {}
          k:{"port":80,"protocol":"TCP"}:
            .: {}
            f:port: {}
            f:protocol: {}
            f:targetPort: {}
        f:selector:
          .: {}
          f:app: {}
        f:sessionAffinity: {}
        f:type: {}
    manager: kubectl
    operation: Update
    time: "2022-07-11T07:21:58Z"
  name: web-5dcb957ccc-246f9
  namespace: default
  resourceVersion: "49814"
  selfLink: /api/v1/namespaces/default/services/web-5dcb957ccc-246f9
  uid: 05dbb353-3b46-4907-a6fe-7f345d178d93
spec:
  clusterIP: 10.105.31.251
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 30438
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: web
  sessionAffinity: None
  type: NodePort
status:
  loadBalancer: {}

然后我们可以通过下面的命令来查看对外暴露的服务

kubectl get pods,svc

然后我们访问对应的url即可看到 nginx了 http://192.168.11.139:32639/

升级回滚和弹性伸缩

• 升级 假设从版本为1.14 升级到 1.15 这就叫应用的升级【升级可以保证服务不中断】
• 回滚从版本1.15 变成 1.14这就叫应用的回滚
• 弹性伸缩我们根据不同的业务场景来改变Pod的数量对外提供服务这就是弹性伸缩

应用升级和回滚

首先我们先创建一个 1.14版本的Pod

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: web
    spec:
      containers:
      - image: nginx:1.14
        name: nginx
        resources: {}
status: {}

我们先指定版本为1.14然后开始创建我们的Pod

kubectl apply -f nginx.yaml

然后我们查看podsnginx在node2过去使用docker images命令就能看到我们成功拉取到了一个 1.14版本的镜像

nginx                                1.14                295c7be07902        3 years ago         109MB

我们使用下面的命令可以将nginx从 1.14 升级到 1.15

kubectl set image deployment web nginx=nginx:1.15

在我们执行完命令后能看到升级的过程

[root@k8smaster node]# kubectl get pods
NAME                    READY   STATUS              RESTARTS   AGE
web-65b7447c7-9rp9v     1/1     Running             0          107s
web-7d9697b7f8-fdtbv    0/1     ContainerCreating   0          21s
[root@k8smaster node]# kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
nginx-f89759699-5qdtn   1/1     Running   2          14d
web-7d9697b7f8-fdtbv    1/1     Running   0          37s

• 首先是开始的nginx 1.14版本的Pod在运行然后 1.15版本的在创建
• 然后在1.15版本创建完成后就会暂停1.14版本
• 最后把1.14版本的Pod移除完成我们的升级

我们在下载 1.15版本容器就处于ContainerCreating状态然后下载完成后就用 1.15版本去替换1.14版本了这么做的好处就是升级可以保证服务不中断

我们到我们的node2节点上查看我们的 docker images;

能够看到我们已经成功拉取到了 1.15版本的nginx了

查看升级状态

下面可以查看升级状态

kubectl rollout status deployment web

查看历史版本

我们还可以查看历史版本

kubectl rollout history deployment web

应用回滚

我们可以使用下面命令完成回滚操作也就是回滚到上一个版本

kubectl rollout undo deployment web

然后我们就可以查看状态

kubectl rollout status deployment web

同时我们还可以回滚到指定版本

kubectl rollout undo deployment web --to-revision=2

弹性伸缩

弹性伸缩也就是我们通过命令一下创建多个副本

kubectl scale deployment web --replicas=10

能够清晰看到我们一下创建了10个副本

写在最后

创作不易如果觉得内容对你有帮助麻烦给个三连关注支持一下我如果有错误请在评论区指出我会及时更改
目前正在更新的系列从零开始学k8s
感谢各位的观看文章掺杂个人理解如有错误请联系我指出~