k8s的Pod控制器详解（八）

已于 2024-04-18 11:19:16 修改
阅读量720 收藏 1
点赞数
分类专栏： kubernetes 文章标签： kubernetes docker 运维
于 2021-11-11 12:40:24 首次发布
原文链接：https://www.yuque.com/fairy-era/yg511q/gqxqgg#68e194a3
版权

1 Pod控制器的介绍

● 在kubernetes中，按照Pod的创建方式可以将其分为两类：

  • ○ 自主式Pod：kubernetes直接创建出来的Pod，这种Pod删除后就没有了，也不会重建。
  • ○ 控制器创建Pod：通过Pod控制器创建的Pod，这种Pod删除之后还会自动重建。

● Pod控制器：Pod控制器是管理Pod的中间层，使用了Pod控制器之后，我们只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它就会创建出满足条件的Pod并确保每一个Pod处于用户期望的状态，如果Pod在运行中出现故障，控制器会基于指定的策略重启或重建Pod。
● 在kubernetes中，有很多类型的Pod控制器，每种都有自己的适合的场景，常见的有下面这些：

  • ○ ReplicationController：比较原始的Pod控制器，已经被废弃，由ReplicaSet替代。
  • ○ ReplicaSet：保证指定数量的Pod运行，并支持Pod数量变更，镜像版本变更。
  • ○ Deployment：通过控制ReplicaSet来控制Pod，并支持滚动升级、版本回退。
  • ○ Horizontal Pod Autoscaler：可以根据集群负载自动调整Pod的数量，实现削峰填谷。
  • ○ DaemonSet：在集群中的指定Node上都运行一个副本，一般用于守护进程类的任务。
  • ○ Job：它创建出来的Pod只要完成任务就立即退出，用于执行一次性任务。
  • ○ CronJob：它创建的Pod会周期性的执行，用于执行周期性的任务。
  • ○ StatefulSet：管理有状态的应用。

2 ReplicaSet（RS）

2.1 概述

● ReplicaSet的主要作用是保证一定数量的Pod能够正常运行，它会持续监听这些Pod的运行状态，一旦Pod发生故障，就会重启或重建。同时它还支持对Pod数量的扩缩容和版本镜像的升级。

在这里插入图片描述
● ReplicaSet的资源清单文件：

apiVersion: apps/v1 # 版本号 
kind: ReplicaSet # 类型 
metadata: # 元数据 
  name: # rs名称
  namespace: # 所属命名空间 
  labels: #标签 
    controller: rs 
spec: # 详情描述 
  replicas: 3 # 副本数量 
  selector: # 选择器，通过它指定该控制器管理哪些po
    matchLabels: # Labels匹配规则 
      app: nginx-pod 
    matchExpressions: # Expressions匹配规则 
      - {key: app, operator: In, values: [nginx-pod]} 
template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本 
  metadata: 
    labels: 
      app: nginx-pod 
  spec: 
    containers: 
      - name: nginx 
        image: nginx:1.17.1 
        ports: 
        - containerPort: 80

● 在这里，需要新了解的配置项就是spec下面几个选项：

  • ○ replicas：指定副本数量，其实就是当然rs创建出来的Pod的数量，默认为1.
  • ○ selector：选择器，它的作用是建立Pod控制器和Pod之间的关联关系，采用了Label
    Selector机制（在Pod模块上定义Label，在控制器上定义选择器，就可以表明当前控制器能管理哪些Pod了）。
  • ○ template：模板，就是当前控制器创建Pod所使用的模板，里面其实就是前面学过的Pod的定义。

2.2 创建ReplicaSet

● 创建pc-replicaset.yaml文件，内容如下：

apiVersion: apps/v1 # 版本号
kind: ReplicaSet # 类型
metadata: # 元数据
  name: pc-replicaset # rs名称
  namespace: dev # 命名类型
spec: # 详细描述
  replicas: 3 # 副本数量
  selector: # 选择器，通过它指定该控制器可以管理哪些Pod
    matchLabels: # Labels匹配规则
      app: nginx-pod
  template: # 模块 当副本数据不足的时候，会根据下面的模板创建Pod副本
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
        - name: nginx # 容器名称
          image: nginx:1.17.1 # 容器需要的镜像地址
          ports:
            - containerPort: 80 # 容器所监听的端口

创建rs：

kubectl create -f pc-replicaset.yaml

在这里插入图片描述
查看rs：

kubectl get rs pc-replicaset -n dev -o wide

在这里插入图片描述
查看当前控制器创建出来的Pod（控制器创建出来的Pod的名称是在控制器名称后面拼接了-xxx随机码）：

kubectl get pod -n dev

在这里插入图片描述

2.3 扩缩容

编辑rs的副本数量，修改spec:replicas:6即可。

kubectl edit rs pc-replicaset -n dev

在这里插入图片描述
再执行kubectl get pod -n dev查看，出现六个pod。
在这里插入图片描述

使用scale命令实现扩缩容，后面加上–replicas=n直接指定目标数量即可。

kubectl scale rs pc-replicaset --replicas=2 -n dev

在这里插入图片描述

2.4 镜像升级

● 编辑rs的容器镜像，修改spec:containers:image为nginx:1.17.2即可。

kubectl edit rs pc-replicaset -n dev

在这里插入图片描述
在这里插入图片描述
使用set命令实现镜像升级。

# 语法
kubectl set image rs rs名称 容器名称=镜像版本 -n 命名空间

kubectl set image rs pc-replicaset nginx=nginx:1.17.1 -n dev

在这里插入图片描述

2.5 删除ReplicaSet

● 使用kubectl delete rs 命令会删除ReplicaSet和其管理的Pod。

# 在kubernetes删除ReplicaSet前，会将ReplicaSet的replicas调整为0，等到所有的Pod被删除后，再执行ReplicaSet对象的删除
kubectl delete rs pc-replicaset -n dev

在这里插入图片描述
● 如果希望仅仅删除ReplicaSet对象（保留Pod），只需要在使用kubectl delete rs命令的时候添加–cascade=false选项（不推荐）：

kubectl delete rs pc-replicaset -n dev --cascade=false

● 使用yaml直接删除（推荐）：

kubectl delete -f pc-replicaset.yaml

3 Deployment（Deploy）

3.1 概述

● 为了更好的解决服务编排的问题，kubernetes在v1.2版本开始，引入了Deployment控制器。值得一提的是，Deployment控制器并不直接管理Pod，而是通过管理ReplicaSet来间接管理Pod，即：Deployment管理ReplicaSet，ReplicaSet管理Pod。所以Deployment的功能比ReplicaSet强大。

无状态负载（Deployment）
Pod是Kubernetes创建或部署的最小单位，但是Pod是被设计为相对短暂的一次性实体，Pod可以被驱逐（当节点资源不足时）、随着集群的节点崩溃而消失。Kubernetes提供了Controller（控制器）来管理Pod，Controller可以创建和管理多个Pod，提供副本管理、滚动升级和自愈能力，其中最为常用的就是Deployment。
在这里插入图片描述
● Deployment的主要功能如下：

  • ○ 支持ReplicaSet的所有功能。
  • ○ 支持发布的停止、继续。
  • ○ 支持版本滚动更新和版本回退。

● Deployment的资源清单：

apiVersion: apps/v1 # 版本号 
kind: Deployment # 类型 
metadata: # 元数据 
  name: # rs名称 
  namespace: # 所属命名空间 
  labels: #标签 
    controller: deploy 
spec: # 详情描述 
  replicas: 3 # 副本数量 
  revisionHistoryLimit: 3 # 保留历史版本，默认为10 
  paused: false # 暂停部署，默认是false 
  progressDeadlineSeconds: 600 # 部署超时时间（s），默认是600 
  strategy: # 策略 
    type: RollingUpdate # 滚动更新策略 
    rollingUpdate: # 滚动更新 
      maxSurge: 30% # 最大额外可以存在的副本数，可以为百分比，也可以为整数 maxUnavailable: 30% # 最大不可用状态的    Pod 的最大值，可以为百分比，也可以为整数 
  selector: # 选择器，通过它指定该控制器管理哪些pod 
    matchLabels: # Labels匹配规则 
      app: nginx-pod 
    matchExpressions: # Expressions匹配规则 
      - {key: app, operator: In, values: [nginx-pod]} 
  template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本 
    metadata: 
      labels: 
        app: nginx-pod 
    spec: 
      containers: 
      - name: nginx 
        image: nginx:1.17.1 
        ports: 
        - containerPort: 80

3.2 创建Deployment

● 创建pc-deployment.yaml文件，内容如下：

apiVersion: apps/v1 # 版本号
kind: Deployment # 类型
metadata: # 元数据
  name: pc-deployment # deployment的名称
  namespace: dev # 命名类型
spec: # 详细描述
  replicas: 3 # 副本数量
  selector: # 选择器，通过它指定该控制器可以管理哪些Pod
    matchLabels: # Labels匹配规则
      app: nginx-pod
  template: # 模块 当副本数据不足的时候，会根据下面的模板创建Pod副本
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
        - name: nginx # 容器名称
          image: nginx:1.17.1 # 容器需要的镜像地址
          ports:
            - containerPort: 80 # 容器所监听的端口

创建Deployment：

kubectl create -f pc-deployment.yaml

在这里插入图片描述
查看Deployment：

# UP-TO-DATE 最新版本的Pod数量
# AVAILABLE 当前可用的Pod数量
kubectl get deploy pc-deployment -n dev

在这里插入图片描述
查看ReplicaSet：

kubectl get rs -n dev

在这里插入图片描述
查看Pod：

kubectl get pod -n dev

在这里插入图片描述

3.3 扩缩容

● 使用scale命令实现扩缩容：

kubectl scale deploy pc-deployment --replicas=5 -n dev

在这里插入图片描述
编辑Deployment的副本数量，修改spec:replicas:4即可。

kubectl edit deployment pc-deployment -n dev

图示：略

3.4 镜像更新

3.4.1 概述

Deployment支持两种镜像更新的策略：重建更新和滚动更新（默认），可以通过strategy选项进行配置。

strategy: 指定新的Pod替代旧的Pod的策略，支持两个属性
  type: 指定策略类型，支持两种策略
    Recreate：在创建出新的Pod之前会先杀掉所有已经存在的Pod
    RollingUpdate：滚动更新，就是杀死一部分，就启动一部分，在更新过程中，存在两个版本的Pod
  rollingUpdate：当type为RollingUpdate的时候生效，用于为rollingUpdate设置参数，支持两个属性：
    maxUnavailable：用来指定在升级过程中不可用的Pod的最大数量，默认为25%。
    maxSurge： 用来指定在升级过程中可以超过期望的Pod的最大数量，默认为25%。

3.4.2 重建更新

编辑pc-deployment.yaml文件，在spec节点下添加更新策略

apiVersion: apps/v1 # 版本号
kind: Deployment # 类型
metadata: # 元数据
  name: pc-deployment # deployment的名称
  namespace: dev # 命名类型
spec: # 详细描述
  replicas: 3 # 副本数量
  strategy: # 镜像更新策略
    type: Recreate # Recreate：在创建出新的Pod之前会先杀掉所有已经存在的Pod
  selector: # 选择器，通过它指定该控制器可以管理哪些Pod
    matchLabels: # Labels匹配规则
      app: nginx-pod
  template: # 模块 当副本数据不足的时候，会根据下面的模板创建Pod副本
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
        - name: nginx # 容器名称
          image: nginx:1.17.1 # 容器需要的镜像地址
          ports:
            - containerPort: 80 # 容器所监听的端口

更新Deployment：

kubectl apply -f pc-deployment.yaml

镜像升级：

kubectl set image deployment pc-deployment nginx=nginx:1.17.2 -n dev

在这里插入图片描述
查看升级过程：

kubectl get pod -n dev -w

在这里插入图片描述

3.4.3 滚动更新

编辑pc-deployment.yaml文件，在spec节点下添加更新策略：

apiVersion: apps/v1 # 版本号
kind: Deployment # 类型
metadata: # 元数据
  name: pc-deployment # deployment的名称
  namespace: dev # 命名类型
spec: # 详细描述
  replicas: 3 # 副本数量
  strategy: # 镜像更新策略
    type: RollingUpdate # RollingUpdate：滚动更新，就是杀死一部分，就启动一部分，在更新过程中，存在两个版本的Pod
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
  selector: # 选择器，通过它指定该控制器可以管理哪些Pod
    matchLabels: # Labels匹配规则
      app: nginx-pod
  template: # 模块 当副本数据不足的时候，会根据下面的模板创建Pod副本
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
        - name: nginx # 容器名称
          image: nginx:1.17.1 # 容器需要的镜像地址
          ports:
            - containerPort: 80 # 容器所监听的端口

● 更新Deployment：

kubectl apply -f pc-deployment.yaml

● 镜像升级：

kubectl set image deployment pc-deployment nginx=nginx:1.17.3 -n dev

在这里插入图片描述

● 查看升级过程：

kubectl get pod -n dev -w

在这里插入图片描述
● 滚动更新的过程：

在这里插入图片描述
镜像更新中rs的变化：

# 查看rs，发现原来的rs依旧存在，只是Pod的数量变为0，而后又产生了一个rs，Pod的数量变为3
# 其实这就是deployment能够进行版本回退的奥妙所在
kubectl get rs -n dev

在这里插入图片描述

3.5 版本回退

Deployment支持版本升级过程中的暂停、继续功能以及版本回退等诸多功能，下面具体来看：

# 版本升级相关功能
kubetl rollout 参数 deploy xx  # 支持下面的选择
# status 显示当前升级的状态
# history 显示升级历史记录
# pause 暂停版本升级过程
# resume 继续已经暂停的版本升级过程
# restart 重启版本升级过程
# undo 回滚到上一级版本 （可以使用--to-revision回滚到指定的版本）

查看当前升级版本的状态：

kubectl rollout status deployment pc-deployment -n dev

在这里插入图片描述

查看升级历史记录：

kubectl rollout history deploymen![在这里插入图片描述](https://img-blog.csdnimg.cn/6d1a8d7c99dd42218a64dd76e1ef66dc.png)
t pc-deployment -n dev

在这里插入图片描述
注意：change-cause展示的是更新时，执行的命令详情，这里不显示是因为创建控制器时，没有加上【–record】

版本回退：

# 可以使用-to-revision=1回退到1版本，如果省略这个选项，就是回退到上个版本，即2版本
kubectl rollout undo deployment pc-deployment --to-revision=1 -n dev

在这里插入图片描述
下面展示一个完整的版本回退示例：
1、删除原来的控制器，并创建新的【记得加上 --record】
在这里插入图片描述
2、查看新建的deploy、rs、pod，当前nginx为1.17.1
在这里插入图片描述
3、更新nginx为1.17.2
在这里插入图片描述
4、更新nginx为1.17.3
在这里插入图片描述
5、查看rs更新记录
在这里插入图片描述
6、执行版本回退
7、查看版本回退记录

3.6 金丝雀发布

● Deployment支持更新过程中的控制，如暂停更新操作（pause）或继续更新操作（resume）。
● 例如有一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求到新版本的Pod应用，继续观察能够稳定的按照期望的方式运行，如果没有问题之后再继续完成余下的Pod资源的滚动更新，否则立即回滚操作。
● 更新Deployment的版本，并配置暂停Deployment：

kubectl set image deployment pc-deployment nginx=nginx:1.17.4 -n dev && kubectl rollout pause deployment pc-deployment -n dev

在这里插入图片描述
观察更新状态：

kubectl rollout status deployment pc-deployment -n dev

在这里插入图片描述
监控更新的过程，可以看到已经新增了一个资源，但是并没有按照预期的状态去删除一个旧的资源，因为使用了pause暂停命令：

kubectl get rs -n dev -o wide

在这里插入图片描述
● 查看Pod：

kubectl get pod -n dev

在这里插入图片描述
确保更新的Pod没问题之后，继续更新：

kubectl rollout resume deployment pc-deployment -n dev

在这里插入图片描述
● 查看最后的更新情况：

kubectl get rs -n dev -o wide

kubectl get pod -n dev

在这里插入图片描述

3.7 删除Deployment

删除Deployment，其下的ReplicaSet和Pod也会一起被删除：

kubectl delete -f pc-deployment.yaml

在这里插入图片描述

4 Horizontal Pod Autoscaler（HPA）

4.1 概述

● 我们已经可以通过手动执行kubectl scale命令实现Pod的扩缩容，但是这显然不符合kubernetes的定位目标–自动化和智能化。kubernetes期望可以通过监测Pod的使用情况，实现Pod数量的自动调整，于是就产生了HPA这种控制器。
● HPA可以获取每个Pod的利用率，然后和HPA中定义的指标进行对比，同时计算出需要伸缩的具体值，最后实现Pod的数量的调整。其实HPA和之前的Deployment一样，也属于一种kubernetes资源对象，它通过追踪分析目标Pod的负载变化情况，来确定是否需要针对性的调整目标Pod的副本数。

在这里插入图片描述

4.2 安装metrics-server（v0.3.6）

metrics-server可以用来收集集群中的资源使用情况。
获取metrics-server，需要注意使用的版本：

wget https://github.com/kubernetes-sigs/metrics-server/archive/v0.3.6.tar.gz

解压v0.3.6.tar.gz文件：

tar -zxvf v0.3.6.tar.gz

进入metrics-server-0.3.6/deploy/1.8+/目录：

cd metrics-server-0.3.6/deploy/1.8+/

修改metrics-server-deployment.yaml文件：

vim metrics-server-deployment.yaml

按图中添加下面选项
hostNetwork: true
image: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server-amd64:v0.3.6 
args:
  - --kubelet-insecure-tls 
  - --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP

在这里插入图片描述
● 安装metrics-server：

kubectl apply -f ./

在这里插入图片描述
● 查看metrics-server生成的Pod：

kubectl get pod -n kube-system

在这里插入图片描述
查看资源使用情况：

kubectl top node

kubectl top pod -n kube-system

在这里插入图片描述
4.3 安装metrics-server（v0.4.1）
● 获取metrics-server：

wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.4.1/components.yaml

● 修改components.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: metrics-server
  strategy:
    rollingUpdate:
      maxUnavailable: 0
  template:
    metadata:
      labels:
        k8s-app: metrics-server
    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=4443
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        - --kubelet-use-node-status-port
        # 修改部分
        - --kubelet-insecure-tls
        # 修改部分
        image: registry.cn-shanghai.aliyuncs.com/xuweiwei-kubernetes/metrics-server:v0.4.1

在这里插入图片描述
安装metrics-server：

kubectl apply -f components.yaml

4.4 准备Deployment和Service

● 创建Deployment：
○ 创建nginx.yaml文件，内容如下：

apiVersion: apps/v1 # 版本号
kind: Deployment # 类型
metadata: # 元数据
  name: nginx # deployment的名称
  namespace: dev # 命名类型
spec: # 详细描述
  selector: # 选择器，通过它指定该控制器可以管理哪些Pod
    matchLabels: # Labels匹配规则
      app: nginx-pod
  template: # 模块 当副本数据不足的时候，会根据下面的模板创建Pod副本
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
        - name: nginx # 容器名称
          image: nginx:1.17.1 # 容器需要的镜像地址
          ports:
            - containerPort: 80 # 容器所监听的端口
          resources: # 资源限制
            requests:
              cpu: "100m" # 100m表示100millicpu，即0.1个CPU

○ 创建Deployment：

kubectl create -f nginx.yaml

在这里插入图片描述
查看Deployment和Pod：

kubectl get pod,deploy -n dev

在这里插入图片描述
创建Service：

kubectl expose deployment nginx --name=nginx --type=NodePort --port=80 --target-port=80 -n dev

查看Service：

kubectl get svc -n dev

在这里插入图片描述

4.5 部署HPA

创建pc-hpa.yaml文件，内容如下：

apiVersion: autoscaling/v1 # 版本号
kind: HorizontalPodAutoscaler # 类型
metadata: # 元数据
  name: pc-hpa # deployment的名称
  namespace: dev # 命名类型
spec:
  minReplicas: 1 # 最小Pod数量
  maxReplicas: 10 # 最大Pod数量
  targetCPUUtilizationPercentage: 3 # CPU使用率指标
  scaleTargetRef:  # 指定要控制的Nginx的信息
    apiVersion: apps/v1
    kind: Deployment
    name: nginx

创建hpa：

kubectl create -f pc-hpa.yaml

在这里插入图片描述
● 查看hpa：

kubectl get hpa -n dev

在这里插入图片描述

4.6 测试

使用压测工具如Jmeter对service的地址http://192.168.18.100:30395进行压测，然后通过控制台查看hpa和pod的变化。
hpa的变化：

kubectl get hpa -n dev -w

在这里插入图片描述
Deployment的变化：

kubectl get deployment -n dev -w

在这里插入图片描述
Pod的变化：

kubectl get pod -n dev -w

在这里插入图片描述

5 DaemonSet（DS）

5.1 概述

● DaemonSet类型的控制器可以保证集群中的每一台（或指定）节点上都运行一个副本，一般适用于日志收集、节点监控等场景。也就是说，如果一个Pod提供的功能是节点级别的（每个节点都需要且只需要一个），那么这类Pod就适合使用DaemonSet类型的控制器创建。

在这里插入图片描述
DaemonSet控制器的特点：

  • 每向集群中添加一个节点的时候，指定的Pod副本也将添加到该节点上。
  • 当节点从集群中移除的时候，Pod也会被垃圾回收。

DaemonSet的资源清单：

apiVersion: apps/v1 # 版本号
kind: DaemonSet # 类型
metadata: # 元数据
  name: # 名称
  namespace: #命名空间
  labels: #标签
    controller: daemonset
spec: # 详情描述
  revisionHistoryLimit: 3 # 保留历史版本
  updateStrategy: # 更新策略
    type: RollingUpdate # 滚动更新策略
    rollingUpdate: # 滚动更新
      maxUnavailable: 1 # 最大不可用状态的Pod的最大值，可用为百分比，也可以为整数
  selector: # 选择器，通过它指定该控制器管理那些Pod
    matchLabels: # Labels匹配规则
      app: nginx-pod
    matchExpressions: # Expressions匹配规则
      - key: app
        operator: In
        values:
          - nginx-pod
  template: # 模板，当副本数量不足时，会根据下面的模板创建Pod模板
     metadata:
       labels:
         app: nginx-pod
     spec:
       containers:
         - name: nginx
           image: nginx:1.17.1
           ports:
             - containerPort: 80

5.2 创建DaemonSet

● 创建pc-daemonset.yaml文件，内容如下：

apiVersion: apps/v1 # 版本号
kind: DaemonSet # 类型
metadata: # 元数据
  name: pc-damonset # 名称
  namespace: dev #命名空间
spec: # 详情描述
  selector: # 选择器，通过它指定该控制器管理那些Pod
    matchLabels: # Labels匹配规则
      app: nginx-pod
  template: # 模板，当副本数量不足时，会根据下面的模板创建Pod模板
     metadata:
       labels:
         app: nginx-pod
     spec:
       containers:
         - name: nginx
           image: nginx:1.17.1
           ports:
             - containerPort: 80

创建DaemonSet：

kubectl create -f pc-daemonset.yaml

在这里插入图片描述

5.3 查看DaemonSet

查看DaemonSet：

kubectl get ds -n dev -o wide

在这里插入图片描述

5.4 删除DaemonSet

删除DaemonSet：

kubectl delete ds pc-damonset -n dev

在这里插入图片描述

6 Job

6.1 概述

● Job主要用于负责批量处理短暂的一次性任务。
● Job的特点：

  • ○ 当Job创建的Pod执行成功结束时，Job将记录成功结束的Pod数量。
  • ○ 当成功结束的Pod达到指定的数量时，Job将完成执行。

Job可以保证指定数量的Pod执行完成。

在这里插入图片描述
Job的资源清单：

apiVersion: batch/v1 # 版本号
kind: Job # 类型
metadata: # 元数据
  name:  # 名称
  namespace:  #命名空间
  labels: # 标签
    controller: job
spec: # 详情描述
  completions: 1 # 指定Job需要成功运行Pod的总次数，默认为1
  parallelism: 1 # 指定Job在任一时刻应该并发运行Pod的数量，默认为1
  activeDeadlineSeconds: 30 # 指定Job可以运行的时间期限，超过时间还没结束，系统将会尝试进行终止
  backoffLimit: 6 # 指定Job失败后进行重试的次数，默认为6
  manualSelector: true # 是否可以使用selector选择器选择Pod，默认为false
  selector: # 选择器，通过它指定该控制器管理那些Pod
    matchLabels: # Labels匹配规则
      app: counter-pod
    matchExpressions: # Expressions匹配规则
      - key: app
        operator: In
        values:
          - counter-pod
  template: # 模板，当副本数量不足时，会根据下面的模板创建Pod模板
     metadata:
       labels:
         app: counter-pod
     spec:
       restartPolicy: Never # 重启策略只能设置为Never或OnFailure
       containers:
         - name: counter
           image: busybox:1.30
           command: ["/bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1;do echo $i;sleep 20;done"]

关于模板中的重启策略的说明：
● 如果设置为OnFailure，则Job会在Pod出现故障的时候重启容器，而不是创建Pod，failed次数不变。
● 如果设置为Never，则Job会在Pod出现故障的时候创建新的Pod，并且故障Pod不会消失，也不会重启，failed次数+1。
● 如果指定为Always的话，就意味着一直重启，意味着Pod任务会重复执行，这和Job的定义冲突，所以不能设置为Always。

6.2 创建Job

● 创建pc-job.yaml文件，内容如下：

apiVersion: batch/v1 # 版本号
kind: Job # 类型
metadata: # 元数据
  name: pc-job # 名称
  namespace: dev #命名空间
spec: # 详情描述
  manualSelector: true # 是否可以使用selector选择器选择Pod，默认为false
  selector: # 选择器，通过它指定该控制器管理那些Pod
    matchLabels: # Labels匹配规则
      app: counter-pod
  template: # 模板，当副本数量不足时，会根据下面的模板创建Pod模板
    metadata:
      labels:
        app: counter-pod
    spec:
      restartPolicy: Never # 重启策略只能设置为Never或OnFailure
      containers:
        - name: counter
          image: busybox:1.30
          command: [ "/bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1;do echo $i;sleep 3;done" ]

创建Job：

kubectl create -f pc-job.yaml

在这里插入图片描述

6.3 查看Job

● 查看Job：

kubectl get job -n dev -w

在这里插入图片描述
● 查看Pod：

kubectl get pod -n dev -w

在这里插入图片描述

6.4 删除Job

删除Job：

kubectl delete -f pc-job.yaml

在这里插入图片描述
7 CronJob（CJ）

7.1 概述

● CronJob控制器以Job控制器为其管控对象，并借助它管理Pod资源对象，Job控制器定义的作业任务在其控制器资源创建之后便会立即执行，但CronJob可以以类似Linux操作系统的周期性任务作业计划的方式控制器运行时间点及重复运行的方式，换言之，CronJob可以在特定的时间点反复去执行Job任务。
在这里插入图片描述

CronJob的资源清单：

apiVersion: batch/v1beta1 # 版本号
kind: CronJob # 类型
metadata: # 元数据
  name:  # 名称
  namespace:  #命名空间
  labels:
    controller: cronjob
spec: # 详情描述
  schedule: # cron格式的作业调度运行时间点，用于控制任务任务时间执行
  concurrencyPolicy: # 并发执行策略
  failedJobsHistoryLimit: # 为失败的任务执行保留的历史记录数，默认为1
  successfulJobsHistoryLimit: # 为成功的任务执行保留的历史记录数，默认为3
  jobTemplate: # job控制器模板，用于为cronjob控制器生成job对象，下面其实就是job的定义
    metadata: {}
    spec:
      completions: 1 # 指定Job需要成功运行Pod的总次数，默认为1
      parallelism: 1 # 指定Job在任一时刻应该并发运行Pod的数量，默认为1
      activeDeadlineSeconds: 30 # 指定Job可以运行的时间期限，超过时间还没结束，系统将会尝试进行终止
      backoffLimit: 6 # 指定Job失败后进行重试的次数，默认为6
      template: # 模板，当副本数量不足时，会根据下面的模板创建Pod模板
        spec:
          restartPolicy: Never # 重启策略只能设置为Never或OnFailure
          containers:
            - name: counter
              image: busybox:1.30
              command: [ "/bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1;do echo $i;sleep 20;done" ]

schedule：cron表达式，用于指定任务的执行时间。

  • ● */1 * * * *：表示分钟 小时 日 月份 星期。
  • ● 分钟的值从0到59。
  • ● 小时的值从0到23。
  • ● 日的值从1到31。
  • ● 月的值从1到12。
  • ● 星期的值从0到6，0表示星期日。
  • ● 多个时间可以用逗号隔开，范围可以用连字符给出：* 可以作为通配符，/表示每…

concurrencyPolicy：并发执行策略

  • ● Allow：运行Job并发运行（默认）。
  • ● Forbid：禁止并发运行，如果上一次运行尚未完成，则跳过下一次运行。
  • ● Replace：替换，取消当前正在运行的作业并使用新作业替换它。

7.2 创建CronJob

● 创建pc-cronjob.yaml文件，内容如下：

apiVersion: batch/v1beta1 # 版本号
kind: CronJob # 类型
metadata: # 元数据
  name: pc-cronjob # 名称
  namespace: dev  #命名空间
spec: # 详情描述
  schedule: "*/1 * * * * " # cron格式的作业调度运行时间点，用于控制任务任务时间执行
  jobTemplate: # job控制器模板，用于为cronjob控制器生成job对象，下面其实就是job的定义
    metadata: {}
    spec:
      template: # 模板，当副本数量不足时，会根据下面的模板创建Pod模板
        spec:
          restartPolicy: Never # 重启策略只能设置为Never或OnFailure
          containers:
            - name: counter
              image: busybox:1.30
              command: [ "/bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1;do echo $i;sleep 2;done" ]

● 创建CronJob：

kubectl create -f pc-cronjob.yaml

在这里插入图片描述

7.3 查看CronJob

查看CronJob：

kubectl get cronjob -n dev -w

在这里插入图片描述
● 查看Job：

kubectl get job -n dev -w

在这里插入图片描述
● 查看Pod：

kubectl get pod -n dev -w

在这里插入图片描述

7.4 删除CronJob

删除CronJob：

kubectl delete -f pc-cronjob.yaml

在这里插入图片描述

7 StatefulSet

Deployment控制器下的Pod都有个共同特点，那就是每个Pod除了名称和IP地址不同，其余完全相同。需要的时候，Deployment可以通过Pod模板创建新的Pod；不需要的时候，Deployment就可以删除任意一个Pod。

但是在某些场景下，这并不满足需求，比如有些分布式的场景，要求每个Pod都有自己单独的状态时，比如分布式数据库，每个Pod要求有单独的存储，这时Deployment无法满足业务需求。

分布式有状态应用的特点主要是应用中每个部分的角色不同（即分工不同），比如数据库有主备、Pod之间有依赖，在Kubernetes中部署有状态应用对Pod有如下要求：

Pod能够被别的Pod找到，要求Pod有固定的标识。
每个Pod有单独存储，Pod被删除恢复后，必须读取原来的数据，否则状态就会不一致。
Kubernetes提供了StatefulSet来解决这个问题，其具体如下：

StatefulSet给每个Pod提供固定名称，Pod名称增加从0-N的固定后缀，Pod重新调度后Pod名称和HostName不变。
StatefulSet通过Headless Service给每个Pod提供固定的访问域名。
StatefulSet通过创建固定标识的PVC保证Pod重新调度后还是能访问到相同的持久化数据。
在这里插入图片描述

沉泽·
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
k8s中控制器使用详解
congge
01-24 6933
k8s控制器
阿里Kubernetes（k8s）详解
09-02
阿里Kubernetes（k8s）详解 Kubernetes（简称k8s）是由Google开源的一款容器编排系统，现由CNCF（Cloud Native Computing Foundation）维护。阿里云作为国内领先的云计算服务提供商，深度参与了Kubernetes的发展，...
k8s-----------控制器
weixin_51432789的博客
04-20 371
目录Deployment(部署无状态应用)Pod与控制器之间的关系SatefulSet（部署有状态应用）无状态和有状态无状态有状态常规service和无头服务区别DaemonSetjobCronJob 控制器：又称之为工作负载，分别包含以下类型控制器 Deployment(部署无状态应用) Pod与控制器之间的关系 controllers：在集群上管理和运行容器的对象通过label-selector相关联 Pod通过控制器实现应用的运维，如伸缩，升级等 管理Pod和ReplicaSet,具有上线部署、副本
k8s常用控制器
最新发布
@猿程序的博客
07-02 778
​ ReplicaSet 是 kubernetes 中的一种副本控制器，简称 rs，主要作用是控制由其管理的 pod，使 pod副本的数量始终维持在预设的个数。它的主要作用就是保证一定数量的 Pod 能够在集群中正常运行，它会持续监听这些 Pod 的运行状态，在 Pod 发生故障时重启 pod，pod 数量减少时重新运行新的 Pod 副本。
K8S控制器
L2111533547的博客
07-27 1778
被控制对象的定义,则来自于一个"模板".比如,Deployment里的template字段.可以看到,Deployment这个template字段里的内容,跟一个标准的Pod对象的API定义,丝毫不差.而所有被这个Deployment管理的Pod实例,其实都是根据这个template字段的内容创建出来的.控制器是个好东西，要学会选择适合的控制器，以达到生产需求httpshttpshttpshttpshttps。...
K8s Pod控制器
Ybaocheng的博客
03-07 1033
FIELDS:podManagementPolicy <string> #Pod管理策略replicas <integer> #副本数量revisionHistoryLimit <integer> #历史版本限制selector <Object> -required- #选择器，必选项serviceName <string> -required- #服务名称，必选项template <Object> -required- #模板，必选项。
k8s-pod控制器
baidu_39267608的博客
11-27 374
Pod控制器资源通过持续性地监控集群中运行着的Pod资源对象来确保受其管控的资源严格符合用户期望的状态，例如资源副本的数量要精确符合期望等。通常，一个Pod控制器资源至少应该包含三个基本的组成部分。 标签选择器：匹配并关联Pod资源对象，并据此完成受其管控的Pod资源计数。 期望的副本数：期望在集群中精确运行着的Pod资源的对象数量。 Pod模板：用于新建Pod资源对...
k8s之kube-controller-manager
11-03
3. **主要控制器详解** - **ReplicaSet控制器**：负责维护Deployment对象的副本数，确保每个Deployment下的Pod数量符合预设值。 - **节点控制器**：监控节点状态，如节点故障时，会将节点标记为“未就绪”，并尝试...
详解k8s组件Ingress边缘路由器并落地到微服务-kubernetes
01-28
2. Ingress Controller：这是k8s的一个控制器，持续监控Ingress资源的变更，并根据新的路由规则更新反向代理Web服务器的配置。它通过与API Server交互，获取Service和Pod的IP信息，实现服务发现。 3. Ingress资源：...
K8S(kubernetes)学习指南
01-14
控制器是Kubernetes集群的核心组件之一，它负责管理和维护集群中的各种资源，例如Pod、Deployment、Service等。控制器是集群的“大脑”，它通过观察和控制集群中的资源来维持集群的稳定运行。 控制器的主要功能有：...
kubernetes-controller:一个简单的Kubernetes控制器
04-18
Kubernetes控制器 这演示了如何使用官方的Kubernetes API和为其提供的自动配置来编写代码。 Kubernetes API可用于编写控制器，协调器，CRD和运算符。 此示例演示如何构建一个枚举部署到群集/命名空间中的Pod的应用程序。
【云原生】K8S中的pod控制器
怎么也想不出名字的博客
03-15 592
而在 deployment中pod模板中创建的存储卷是一个共享的存储卷，多个pod使用同一个存储卷，而statefulset定义中的每一个pod都不能使用同一个存储卷，由此基于pod模板创建pod是不适应的，这就需要引入volumeClainTemplate，当在使用statefulset创建pod时，会自动生成一个PVC，从而请求绑定一个PV，从而有自己专用的存储卷。当节点挂了，重建之后的标识符是不变的，每一个节点的节点名称是不能改变的。如下操作的滚动更新是按照2-0的顺序更新。镜像可以进行版本升级。
K8s-----（四）控制器的使用
qq_41582883的博客
02-26 525
ReplicaSet 编辑清单资源文件：vim deployment.yml apiVersion: apps/v1 kind: ReplicaSet metadata: name: deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containe
K8s中控制器的用法
qq_48480384的博客
09-25 496
所有的控制器集合都是在kube-controller-manager中完成的。master节点基础插件有kube-schedulerr、kube-apiserver、kube-contoller-manager这三个的。控制器都遵循 Kubernetes 项目中的一个通用编排模式，即：控制循环（control loop）。比如，现在有一种待编排的对象 X，它有一个对应的控制器。
k8s-Pod控制器详解
王子老师
11-22 776
身不苦则福禄不厚，心不苦则智慧不开。心无旁骛，身披金甲，势如破竹。 Pod控制器详解 创建方式： 1、自主式pod: k8s直接创建的pod，删除之后不会重建 2、控制器创建的pod： 删除之后还会自动重建 控制器种类： 1、replicationController: 最原始的控制器，已废弃，由replicaset取代 2、replicaset： 保证指定数量的pod运行，支持pod数量变更、镜像版本迭代 3、deployment: 通过控制replicaset来控制pod，并支持滚动升级和版本回退 .
K8S 的 5种控制器
weixin_45691464的博客
05-25 7149
Pod通过控制器实现应用的运维，如伸缩、升级等，控制器决定了创建pod资源的方式和类型，在集群上管理和运行容器的对象通过label-selector 相关联。 控制器 又称之为工作负载，分别包含以下类型控制器： 5种控制器类型 1： Deployment 2： StatefulSet 3： DaemonSet 4：Job 5： CronJob 第一种控制器类型：deployment 特点： 部署无状态应用，只关心数量，不论角色等，称无状态 管理Pod和ReplicaSet 具有上线部署、副本设定、滚动升级、
玩转k8s：Pod控制器详解
duansamve的博客
03-16 974
Pod是kubernetes的最小管理单元，在kubernetes中，按照pod的创建方式可以将其分为两类：自主式pod：kubernetes直接创建出来的Pod，这种pod删除后就没有了，也不会重建控制器创建的pod：kubernetes通过控制器创建的pod，这种pod删除了之后还会自动重建什么是Pod控制器Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。
K8S资源控制器常用维护命令
pizi110的专栏
02-13 254
1、扩容 kubectl scale deployment nginx-deployment --replicas=10 2、更新镜像 [root@master testdir]# kubectl set image deployment/nginx-deployment nginx1=ub.atguigu.com/library/nginx:v2 #更新为v2版本 nginx1为容器名称 ...
K8S技术深度探讨：Pod详解与管理策略
Pod控制器如ReplicaSet、Deployment和StatefulSet，用于管理Pod的副本数量和状态。它们确保指定数量的Pod副本始终可用，并在Pod失败时自动替换。 **Pod探针** Pod探针（Liveness Probe和Readiness Probe）用于检查...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值