Kubernetes(k8s)容器编排控制器使用1

1 Pod控制器

1.1 Pod控制器是什么

Pod控制器就是帮助我们自动的调度管理Pod，并满足期望的Pod数量。

  Pod控制器是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，会尝试进行重启，当根据重启策略无效，则会重新新建pod的资源。
  创建为具体的控制器对象之后，每个控制器均通过`API Server`提供的接口持续监控相关资源对象的当前状态，并在因故障、更新或其他原因导致系统状态发生变化时，尝试让资源的当前状态想期望状态迁移和逼近。

1.2 Pod和Pod控制器

Pod控制器资源通过持续性地监控集群中运行着的Pod资源对象来确保受其管控的资源严格符合用户期望的状态，例如资源副本的数量要精确符合期望等。

通常，一个Pod控制器资源至少应该包含三个基本的组成部分：

• 标签选择器：匹配并关联Pod资源对象，并据此完成受其管控的Pod资源计数。
• 期望的副本数：期望在集群中精确运行着的Pod资源的对象数量。

• Pod模板：用于新建Pod资源对象的Pod模板资源。

1.3 控制器的必要性

  自主式`Pod`对象由调度器调度到目标工作节点后即由相应节点上的`kubelet`负责监控其容器的存活状态，容器主进程崩溃后，`kubelet`能够自动重启相应的容器，但对出现非主进程崩溃类的容器错误却无从感知，这便依赖于`pod`资源对象定义的存活探测，以便`kubelet`能够探知到此类故障。
  但若`pod`被删除或者工作节点自身发生故障（工作节点上都有`kubelet`，`kubelet`不可用，因此其健康状态便无法保证），则便需要控制器来处理相应的容器重启和配置。

1.4 常见的控制器

Pod控制器由master的kube-controller-manager组件提供，常见的此类控制器有以下几种

1.4.1 ReplicaSet

代用户创建指定数量的`pod`副本数量，确保`pod`副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能

1.4.2 Deployment

工作在`ReplicaSet`之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。

1.4.3 DaemonSet

用于确保集群中的每一个节点只运行特定的`pod`副本，常用于实现系统级后台任务，比如`ELK`服务

2 ReplicaSet控制器

2.1 ReplicaSet概述

ReplicaSet是取代早期版本中的ReplicationController控制器，其功能基本上与ReplicationController

相同

`ReplicaSet`（简称RS）是`Pod`控制器类型的一种实现，用于确保由其管控的`Pod`对象副本数在任意时刻都能精确满足期望的数量，`ReplicaSet

2.2 ReplicaSet功能

ReplicaSet能够实现以下功能：

2.2.1 精确反应期望值

**确保Pod资源对象的数量精确反映期望值：**`ReplicaSet`需要确保由其控制运行的Pod副本数量精确吻合配置中定义的期望值，否则就会自

2.2.2 保证高可用

**确保Pod健康运行：**探测到由其管控的`Pod`对象因其所在的工作节点故障而不可用时，自动请求由调度器于其他工作节点创建缺失的`Po

2.2.3 弹性伸缩

**弹性伸缩：**可通过`ReplicaSet`控制器动态扩容或者缩容`Pod`资源对象的数量，必要时还可以通过`HPA`控制器实现`Pod`资源规模的

2.3 创建ReplicaSet

2.3.1 核心属性

spec字段一般嵌套使用以下几个属性字段：

2.3.2 ReplicaSet示例

创建资源清单

vi nginx-rs.yml
apiVersion: apps/v1  #api版本定义
kind: ReplicaSet  #定义资源类型为ReplicaSet
metadata:  #元数据定义
  name: nginx-rs
  namespace: default
spec:  #ReplicaSet的规格定义
  replicas: 2  #定义副本数量为2个
  selector:  #标签选择器，定义匹配Pod的标签
    matchLabels:
      app: nginx
  template:  #Pod的模板定义
    metadata:  #Pod的元数据定义
      name: nginx-pod  #自定义Pod的名称
      labels:  #定义Pod的标签，需要和上面的标签选择器内匹配规则中定义的标签一致，可以多出其他标签
        app: nginx
    spec:  #Pod的规格定义
      containers:  #容器定义
      - name: nginx  #容器名称
        image: nginx:1.12  #容器镜像
        imagePullPolicy: IfNotPresent  #拉取镜像的规则
        ports:  #暴露端口
        - name: http  #端口名称
          containerPort: 80

创建rs控制器

kubectl apply -f nginx-rs.yaml

查看rs控制器

kubectl get rs

查看pod容器

通过查看pod可以看出pod命令是规则是前面是replicaset控制器的名称加随机生成的字符串

kubectl get pods -o wide -w

2.4 更新控制器

修改上面创建的replicaset示例文件，将镜像nginx:1.12改为1.20版本

vi nginx-rs.yml
apiVersion: apps/v1  #api版本定义
kind: ReplicaSet  #定义资源类型为ReplicaSet
metadata:  #元数据定义
  name: nginx-rs
  namespace: default
spec:  #ReplicaSet的规格定义
  replicas: 2  #定义副本数量为2个
  selector:  #标签选择器，定义匹配Pod的标签
    matchLabels:
      app: nginx
  template:  #Pod的模板定义
    metadata:  #Pod的元数据定义
      name: nginx-pod  #自定义Pod的名称
      labels:  #定义Pod的标签，需要和上面的标签选择器内匹配规则中定义的标签一致，可以多出其他标签
        app: nginx
    spec:  #Pod的规格定义
      containers:  #容器定义
      - name: nginx  #容器名称
        image: nginx:1.20  #容器镜像
        imagePullPolicy: IfNotPresent  #拉取镜像的规则
        ports:  #暴露端口
        - name: http  #端口名称
          containerPort: 80

2.4.1 应用更新

kubectl apply -f nginx-rs.yaml

查看更新流程

kubectl get pods -o wide -w

我们发现pod没有任何更新变化

查看Pod版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

这里并没有更新pod的nginx版本号

删除pod应用

这里虽然重载了，但是已有的pod所使用的镜像仍然是1.12版本的，只是新建pod时才会使用1.20版本，这里测试先手动删除已有的pod。

kubectl delete pods -l app=nginx

查看版本

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

现在我们发现pod的版本已经更新正确了

2.5 RS扩缩容

可以直接通过vim 编辑清单文件修改replicas字段，也可以通过kubect edit 命令去编辑

`kubectl`还提供了一个专用的子命令`scale`用于实现应用规模的伸缩，支持从资源清单文件中获取新的目标副本数量，也可以直接在命令行

2.5.1 scale命令扩容

命令扩容一般用于短期的临时性扩容，应付完成后要记得缩容到原来水平

查看容量

可看到当前是两个节点

kubectl get pods -o wide

执行扩容

使用scale命令可以对集群进行扩缩容

kubectl scale replicasets nginx-rs --replicas=4

查看扩容过程

在更新前打开新窗口，监控pod的更新变化

kubectl get pods -o wide -w

在更新前打开新窗口，监控RS的更新变化

kubectl get rs -o wide -w

我们发现扩容后只是在原来的RS集群上面增加了两个节点

2.5.2 配置文件缩容

配置文件扩容一般用于初始容量变更，长期进行扩容

查看容量

可看到当前是四个节点

kubectl get pods -o wide

应用配置

因为没有变更配置文件可以直接应用配置文件

kubectl apply -f nginx-rs.yml

查看缩容容过程

在更新前打开新窗口，监控pod的更新变化

kubectl get pods -o wide -w

在更新前打开新窗口，监控RS的更新变化

kubectl get rs -o wide -w

我们发现扩容后只是在原来的RS集群上面减少了两个节点