kubernetes控制器-Deployment

一 、ReplicaSet

1.1 传统的部署方式

传统部署应用，保证业务的高可用，都是通过2个或者2个以上多实例的方式进行部署，通过Nginx负载均衡的方式进行对外进行暴露，如果一个实例出现故障，仍然有一个实例提供服务，如果需要对实例进行扩缩容，就是需要通过Nginx的配置upstream的配置，进行配置实例，实现Nginx的负载均衡，对业务进行调度。

1.2 什么是ReplicaSet

在 Kubernetes 环境中，通过 ReplicaSet帮助我们实现集群的高可用， ReplicaSet (RS)的主要作用就是维持一组 Pod 副本的运行，保证一定数量的 Pod 在集群中正常运行，ReplicaSet 控制器会持续监听它控制的这些 Pod 的运行状态以及数量，保证应用集群的高可用;

1.3 ReplicaSet 的组成部分

ReplicaSet控制器包含了3个基本的组成部分

• seLector 标签选择器: 匹配并关联Pod对象，并加入控制器的管理中;
• repLicas期望的副本数: 期望在集群中所运行的Pod对象数量;
• template Pod模板: 实际上就是定义的Pod 规范，相当于把一个Pod 的描述以模板的形式嵌入到了 ReplicaSet

ReplicaSet:
如果想运行一个RS的控制器，来管理Pod；
1.必须有template字段，用来描述Pod规范（给Pod打标签）； 定义容器、定义镜像、定义resource、lifecycle、 做成一个模板；
2.必须在RS控制器申明我需要管理那些Pod；是通过标签选择器来选择要管理的Pod； Selector：
3.就可以通过RS控制器来管理并运行该Pod；（将Pod的描述信息通过模板的形式嵌入到了ReplicaSet中；）
4.如果期望运行的副本数是3或者是5；只需要通过修改replicas字段就可以完成；

1.4 ReplicaSet 的示例

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: king-replicaset
  namespace: king-dp
spec:                           # 定义RS的规范
  replicas: 5                   # 启动5个相同的Pod 
  selector:                     # RS通过Selector选择一组Pod，并进行管理
    matchLabels:
      app: nginx

  template:                     # 定义Pod的模板；当RS需要创建Pod时就通过模板来创建
    metadata:
      labels:                   # 所有通过该模板运行的Pod都有app=nginx这个标签
        app: nginx 
    spec:
      containers:
      - name: mall
        image: nginx:1.16
        ports:
        - name: http
          containerPort: 80

1.5 ReplicasSet 验证

kubectl  get rs -n king-dp  -o wide
kubectl  get pod -n king-dp -o wide 

• 即使删除pod都是会保持pod数量的期望值

二、Deployment

2.1 什么是Deployment

Deployment (简称为deploy) 是Kubernetes控制器的一种高级别实现，他构建于ReplicaSet控制器之上。
我们只需要描述Deployment中的目标Pod期望状态，而DepLoyment控制器以受控速率更改实际状态，使其变为期望状态，也就是说，后期我们部署应用不直接使用Pod和ReplicaSet，而是使用Deployment控制器来调用ReplicaSet来实现，Deployment控制器在ReplicaSet原有基础上，添加了部分特性。

• 1、事件和状态查看: 可以通过特定的命令查看Deployment对象的更新进度和状态;
• 2、版本记录: 将Deployment对象的更新操作都进行保存，以便后续执行回滚操作使用;
• 3、多种更新方案: Recreate重建，可以实现单批次更新所有PodRolLingUpdate可以实现多批次逐步替换Pod

2.2 Deployment的组成部分

DepLoyment 资源对象的格式和 ReplicaSet 几乎一致，Deployment 控制器也包含了3个基本的组成部分

• selector标签选择器: 匹配并关联Pod对象，并对授其管控的Pod对象计数;
• replicas期望的副本数: 期望在集群中所运行的Pod对象数量;
• template Pod模板: 实际上就是定义的 Pod 内容，相当于把一个Pod 的描述以模板的形式嵌入到了 ReplicaSet

2.3 Deployment示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3                   # 期望的副本数
  selector:                     # Deployment要管理的Pod有哪些 只要标签app=nginx就加入进行管理
    matchLabels:
      app: nginx

  template:                     # Pod模板；有标签；有Pod规范
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16
        ports:
        - name: http
          containerPort: 80

2.4 查看Deployment和ReplicaSet 的关系

kubectl  get replicasets
kubectl  get pod  -l app=nginx 
kubectl  get deployments

2.5 Deployment的场景应用

场景说明: 运行一个demoapp的应用，部署3个副本，然后通过service来实现负载均衡;

• 1、创建 Deployment资源，部署三个副本
• 2、创建 Service资源，通过标签选择器选择对应的Pod，以实现负载均衡;
• 3、使用 curl命令，或Chrome浏览器验证集群高可用;

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demoapp-deploy
  namespace: default
spec:
  strategy:
    type: Recreate      # 更新镜像的策略为Recreate
  replicas: 4            # 副本数
  selector:             # 通过标签选择器选择要管理的Pod
    matchLabels:
      app: demoapp
 
  template:
    metadata:
      labels:
        app: demoapp
    spec:
      containers:
      - name: webserver
        image: nginx
        ports:
        - name: http
          containerPort: 80

apiVersion: v1
kind: Service
metadata:
  name: demoapp-service
spec:
  selector:
    app: demoapp        # Service通过标签选择器将对应的Pod定义为一组backend，而后将所有请求调度到这组Pod上
  ports:
  - name: http
    port: 80            # 负载均衡的端口
    targetPort: 80      # 后端节点的端口

2.6 Deployment的负载均衡测试

• 跳转到pod的IP上
  

2.7 Deployment的水平伸缩

1、通过命令的方式进行replicaset的修改

kubectl  scale  deployment  demoapp-deploy  --replicas=2

2、通过修改yaml文件的方式修改replicaset副本数量

kubectl  edit  deployments demoapp-deploy  

2.8 Deployment的状态检查

• NAME 列出了集群中 Deployment 的名称。
• READY 显示应用程序的可用的“副本”数。显示的模式是"就绪个数期望个数”。
• UP-TO-DATE 显示为了达到期望状态已经更新的副本数。
• AVAILABLE 显示应用可供用户使用的副本数。
• AGE 显示应用程序运行的时间。

2.9 故障转移

• 模拟背景
  将所有的pod删除

kubectl  delete pod --all

• 再次查询有控制器控制的pod会继续起来,replicaset 会保持跟原来的保持一致，但是随机ID发生变化。保持原有的期望值。

kubectl get pod 

• 全部删除pod 但是pod的IP和node的节点也会发生变化，只有service负载不发生变化，还会继续调度到后端的pod中

3.0 滚动更新

• 方法一：

kubectl  set image deployment/nginx-deploy nginx=nginx:1.24.0 --record
kubectl get pod -l app=nginx -w  ## 进行状态跟踪
kubectl rollout status deployment/nginx-deploy

• 方法二：通过修改配置文件的方式

kubectl edit deployment nginx-deploy 

3.1 版本回退

• 1、查看deployment的发布的历史版本

kubectl rollout history deployment/nginx-deploy

因为第一次使用了的是yaml进行配置，导致历史版本没有被记录

• 2、回退到上一次，或者其他的历史版本

kubectl  rollout  undo  deployment/nginx-deploy  --to-revision=1
kubectl get deployment nginx-deploy -o yaml