k8s控制

Sncot

已于 2024-04-10 16:39:46 修改

阅读量974

点赞数 28

文章标签： kubernetes java 容器

于 2024-04-10 16:38:20 首次发布

本文链接：https://blog.csdn.net/sncot/article/details/137602239

版权

1、控制pod

1、方式

方式一：交互式

kubectl run deploy

方式二：声明式

2、Namespace

交互式

声明式

3、 Pod

交互式

声明式

资源限制

容器中程序运行需要占用一定的资源，如cpu和内存，如果不对资源做限制他可能会占用用大量资源从而影响其他的pod的运行

这种机制主要通过resources选项来实现，有两个子选项

limits 用于限制运行时容器的最大占用资源，当容器占用资源超过limits时会被终止，并进行重启
requests 用于设置容器需要的最小资源，如果环境资源不够容器将无法启动

示例pod-resource.yaml

apiVersion: v1
kind: pod
metadata:
 name: pod-resource
 namespace: dev
spec:
 containers:
 - name: nginx
   image: nginx:latest
   resources: #资源配额
    limits:  # 资源限制（上限）
     cpu: "2" #cpu限制 单位是core
     memory: "10Gi"  #内存限制
    requests:  # 请求资源
     cpu: "1"  #cpu限制 单位是core
     memory: "10Mi"   #内存限制

####4、Deployment

交互式

kubectl run deploy

声明式

5、Service

交互式

kubectl expose deploy  nginx --name=svc-nginx --type=ClusterIP --port=8080 --target-port=80

声明式

# 声明一个ClasterIP类型的nginx-svc.yaml文件
apiVersion: v1
kind: Service
metadata:
 name: svc-nginx
 namespace: dev
spec:
 clusterIP: 10.109.179.231
 ports:
 - port: 80
   protocol: TCP
   targetPort: 80
 selector:
  run: nginx
 type: ClusterIP

kubectl create -f nginx-svc.yaml

详解Service（4层）

service很多情况下只是一个概念，起作用的是kube-proxy服务进程

开启ipvs

# 此模式必须安装ipvs内核模块，否则将极为iptables
kubectl edit cm kube-proxy -n kube-system    # 在文件的mode 中改为ipvs
# 删除当前的kube-proxy
kubectl delete pod -l k8s-app=kube-proxy -n kube-system
ipvsadm -Ln

6、label

交互式

#创建label
kubectl label

声明式

7、初始化容器

初始化容器

####8、钩子

9、容器探测

容器探测用于探测容器中的应用实例是否正常工作，以下为k8s提供的两种探针

livenessProbes：存活性探针用于检测实例是否处于运行状态，如果不是则重启
readinessProbes：就绪性探针用于检测当前实例是否可以接受请求，如果不能，k8s不会转发流量

以下是两种探针支持的三种探测方式：

EXEC命令：在容器内执行一次命令，如果命令执行退出码为零，则认为程序执行正常，否则不正常

......
 livenessProbe:
  exec:
   command:
   - cat
   - /tmp/healthy
......

示例： pod-liveness-exec.yaml

apiVersion: v1
kind: Pod
metadata:
 name: pod-liveness-exec
 namespace: dev
spec:
 containers:
 - name: nginx
   image: latest
   ports: 
    - name: nginx-port
      containerPort: 80
   livenessProbe:
    exec:
     command: ["/bin/cat","/tmp/hello.txt"] # 执行查看一个文件的命令

执行 kubectl create -f pod-liveness-exec.yaml

TCPSocket：竟会访问一个用户容器的端口，如果能够建立连接，则认为程序正常

......
 livenessProbe:
  tcpSocket:
   prot: 8080
......

示例： pod-liveness-tcpSocket.yaml

apiVersion: v1
kind: Pod
metadata:
 name: tcp-socket
 namespace: dev
spec:
 containers:
 - name: nginx
   image: nginx:latest
   ports:
   - name: nginx-port
     containerPort: 80
   livenessProbe:
    tcpSocket:
     port: 8080

执行： kubectl create -f pod-liveness-tcpSocket.yaml

HTTPGet ：调用容器内部的web应用url，如果返回的状态码在200-399之间，认为程序正常

......
 livenessProbe:
  httpGet:
   path: /#uri地址
   port: 80 
   host: 127.0.0.1
   scheme: HTTP #支持的协议 http/https
......

示例 pod-liveness-httpGet.yaml

apiVersion: v1
kind: Pod
metadata: 
 name: pod-liveness-httpGet
 namespace: dev
spec:
 containers:
 - name: nginx
   image: nginx:latest
   ports:
   - name: nginx-port
     containerPort: 80
   livenessProbe:
    scheme: HTTP
    host: 127.0.0.1
    port: 80
    path: /hello

其他子配置： kubectl explain pod.spec.containers.livenessProbe

......  
FIELDS:
 exec: <object>
 tcpSocket: <object>
 httpGet: <object>
 initialDelaySeconds: <integer> #容器启动后等待多少秒启动第一次探测
 timeoutSeconds: <integer> #探测超时时间。默认1s，最小1s
 periodSeconds: <integer>  #执行探测的频率，默认10s，最小1s
 failureThreshold: <integer> #连续探测多少次失败才被认定为失败。默认是3，最小是1
 successThreshold:  <integer> #连续探测多少次成功才被认定为成功，默认是1
 ......

10、重启策略

在上一小节中，如果pod的容器探测出现了问题，首次需要重启的容器，休要在需要时立即重启，随后再次重启的操作油kubelet延迟一段时间后进行，反复重启的延长时间依次为10s、20s、40s、80s、160s和300s，200s是最大延迟时长

Always：容器失败时自动重启该容器，这也是默认值
OnFailure：容器终止运行且退出码不为0时
Never：不论状态是啥都不重启

重启策略适用于pod对象中的所有容器

示例： pod-restartpolicy.yaml

apiVersion: v1
kind: Pod
metadata: 
 name: pod-restartpolicy
 namespace: dev
spec:
 containers:
 - name: nginx
   image: nginx:latest
   ports:
   - name: nginx-port
     containerPort: 80
   livenessProbe:
    httpGet:
     host: 127.0.0.1
     port: 80
     path: /hello
     scheme: HTTP
   restartPolicy: Never

2、pod调度

默认情况下，一个pod在哪个节点上运行是由scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的，但在实际使用过程中并不满足需求，k8s提供了以下四大调度规则

自动调度：愚兄在哪个节点上完全由scheduler经过算法计算的得出，默认调度
定向调度： NodeName、NodeSelector
亲和度调度： NodeAffinity、PodAffinity、PodAntiAffinity
污点（容忍度）调度：Tains、Toleration

1 定向调度

定向调度、是根据pod上声明的nodeName或者nodeSelector，以此将pod调度到期望的node节点上，注意这里的调度是强制的，如果该node不存在也会往上面调度，只是pod会失败而已。

NodeName

nodeName用于强制将pod调度到指定的node节点上，这种方式实际是调过了scheduler的调度逻辑直接写入到PodList中

示例：pod-nodeName.yaml

apiVersion: v1
kind: Pod
metadata:
 name: pod-node-name
 namespace: dev
spec:
 containers:
 - name: nginx
   image: nginx:latest
 nodeName: slave1  # 调度到指定node上

nodeSelector

nodeSelector用于将pod调度到指定标签node的节点上，它通过k8s的label-selector机制实现，也就是说在pod创建之前会有scheduler使用MatchNodeSelector调度策略进行label匹配，找出目标node并将pod调度上去，该匹配是强制约束

示例 pod-nodeSelector.yaml

# 为node添加标签
kubectl label nodes slave1 nodeenv=pro
kubectl label nodes slave1 nodeenv=test

pod-nodeSelector.yaml

apiVersion: v1
kind: Pod
metadata:
 name: pod-name-selector
 namespace: dev
spec:
 containers:
 - name: nginx
   image: nginx:latest
 nodeSelector:
  nodeenv: test

2 亲和性调度

此小节是k8s提供的一种亲和性调度，它在NodeSelector的基础上进行了拓展，可以通过配置的形式实现优先选择满足条件的node进行调度，如果没有，也可以调度到不满足条件的节点上，使调度更加灵活

Affinity主要分为三类

nodeAffinity（node亲和性）：以node为目标，解决pod可以调度到哪些node的问题
podAffinity（pod亲和性）：以pod为目标，解决pod可以和哪些已存在的pod部署在同一个拓扑域中的问题
podAntiAffinity（pod反亲和性）：以pod为目标i，解决pod不能和哪些已经存在的pod部署在同一个拓扑域中的问题

关于亲和性和反亲和性的使用场景说明

亲和性：如果两个应用频繁交互，那么可以利用亲和性让两个应用就静静静静可能的靠近，这样可以减少网络通信带来的性能损耗

反亲和性：当采用多副本部署时，有必要采用反亲和性让各个应用实例打散分布在各个node上，这样可以提高服务的高可用性

nodeAffinity

看一下nodeAffinity的可配置项

pod.spec.affinity.nodeAffinity
requiredDuringSchedulingIgnoredDuringExecution: # 硬限制  node节点必须满足指定的所有规则才可以
 nodeSelectorTerms:  #节点选择列表
  matchFields:     #按节点字段列出的节点选择器要求列表
  matchExpressions: #按节点标签列出的节点选择器要求列表（推荐）
   key:      #键
   values:   #值
   operator: #关系符 支持 Exists、DoesNotExists、In、NotIn、Gt、Lt、
preferredDuringSchedulingIgnoredDuringExecution: # 软限制 优先调度到满足条件的节点上去
- weight: #权重 范围1-100
  preference:   #一个节点选择器 与相应的权重相关联
   matchFields: #按节点字段列出的节点选择器要求列表
   matchExpressions: #按节点标签列出的节点选择器要求列表（推荐）
    key:      #键
    values:   #值
    operator: #关系符 支持 Exists、DoesNotExists、In、NotIn、Gt、Lt、

注意

NodeAffinity规则设置注意

1、如果同时定义了nodeSelector和nodeAffinity，那么两个条件必须同时都满足，pod才能有运行到指定node上

2、如果nodeAffinity指定了多个nodeSelectorTerms，那么只需要其中一个匹配成功即可

3、如果一个nodeSelectorTerms中有多个matchExpressions，则一个node必须满足所有的才算成功匹配

4、如果一个pod所在的node在pod运行期间其标签发生了改变，不再符合该pod的节点亲和性需求，则系统将忽略此变化

示例： pod-nodeAffinity.yaml

apiVersion: v1
kind: Pod
metadata:
 name: pod-node-affinity
 namespace: dev
spec:
 containers:
 - name: nginx
   image: nginx:latest
 affinity:
  nodeAffinity:
   requiredDuringSchedulingIgnoredDuringExecution: #硬限制  必须满足的条件
    nodeSelectorTerms:
    - matchExpressions: #匹配nodeenv的值在["xxx","yyy"]中的标签
     - key: nodeenv
       operator: In
       values: ["xxx","yyy"]

.......
a affinity:
  nodeAffinity:
   preferredDuringSchedulingIgnoredDuringExecution: #软限制  如果满足则按此规则调度
   - weight: 1  #权重
     preference:
      matchExpressions: #匹配env的值在["xxx","yyy"]中的标签
      - key: nodeenv
        operator: In
        values: ["xxx","yyy"]
 ......

podAffinity

podAffinity主要以一个运行的pod为参照，让新创建的pod和参照的pod在一个拓扑域中的功能

podAffinity的配置项

pod.spec.affinity.podAffinity
preferredDuringSchedulingIgnoredDuringExecution: #软限制
 podAffinityTerms:   #选项
  namespace:    #指定参照物的namespace
  topologyKey:   #指定调度作用域     作用域 - kubernetes.io/hostname  就是以node节点为区分范围 - beta.kubernetes.io/os 以node节点的操作系统来区分
  labelSelector:  #标签选择器
   matchExpressions:  #按节点标签列出节点选择器要求列表
    key:
    values: 
    operator: #关系符 支持In、NotIn、Exists、DoesNotExists
   matchLabels: #指定多个matchExpressions映射的内容
  weight: #倾向权重
requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
 namespace: #指定参照物的namespace
 topologyKey: #指定调度作用域
 labelSelector: #标签选择器
  matchExpressions: #按节点标签列出节点选择器要求列表
   key:
   values:
   operator: #关系符 支持In、NotIn、Exists、DoesNotExists
  matchLabels: #指定多个matchExpressions映射的内容

示例：pod-podAffinity.yaml

创建一个参照pod pod-target.yaml

apiVersion: v1
kind: Pod
metadata:
 name: pod-pod-affinity
 namespace: dev
spec:
 containers:
 - name: nginx
   images: nginx:latest
 hostname: slave1

pod-podAffinity.yaml

apiVersion: v1
kind: Pod
metadata:
 name: pod-pod-affinity
 namespace: dev
spec:
 containers:
 - name: nginx
   images: nginx:latest
 affinity:
  podAffinity:
   requiredDuringSchedulingIgnoredDuringExecution:
    namespace: dev
    - labelSelector:
      topologyKey: kubernetes.io/hostname
        matchExpressions:
        - key: nodeenv
          operator: In
          values: ["xxx","test"]

podAntiAffinity 反亲和性

以一个运行的pod为参照，让新建的pod远离参照pod

依照上面创建一个参照pod

然后创建一个新建pod pod-podAntiAffinity.yaml

apiVersion: v1
kind: Pod
metadata:
 name: pod-anti-affinity
 namespace: dev
spec:
 containers:
 - name: nginx
   image: nginx:latest
 affinity:
  podAntiAffinity:
   requiredDuringSchedulingIgnoredDuringExecution:
   - labelSelector:
     matchExpressions:
      - key: nodeenv
        operator: In
        values: ["pro"]
      topologyKey: kubernetes.io/hostname

3 污点（容忍性）调度

污点（Taints）

node上设置污点就和pod之间存在排斥关系了，进而拒绝pod调度进来，甚至可以把已经调度进来的pod驱逐出去，污点格式为key=value:effect,key和cvalue是五点的标签，effect是五点的作用，effect支持如下三选项

PreferNoSchedule 尽量避免往具有该污点的节点上调度pod
NoSchedule 不会把新创建的pod调度到具有该污点的节点上来
NoExecute 不会把pod调度到具有该污点的节点上来，同时也会把该节点上已有的pod驱逐

使用kubectl设置污点和去除污点

# 设置污点
kubectl taint nodes node1 key=value:effect
# 去除污点
kubectl taint node node1 key:effect-
# 去除所有污点
kubectl taint node node1 key-

示例：

kubectl taint node slave1 type=db:NoSchedule

为何创建pod时不往master上调度呢？

使用kubeadm创建集群时默认给master打一个节点且为NoSchedule 查看 kubectl describe node master

容忍（Toleration）

通过给pod添加容忍把pod调度到有污点的node上

示例 pod-toleration.yaml

apiVersion: v1
kind: Pod
metadata:
 name: pod-toleration
 namespace: dev
spec:
 containers:
  - name: nginx
    image: nginx:latest
  tolerations:  #添加容忍
  - key: "tag"  # 要容忍的污点key
    operator: "Equal"  #操作符    支持Equal和Exists（默认）
    value: "db"  #容忍污点的value
    effect: "NoExecute" #添加容忍的规则，这里必须和标记的五点规则相同
   #tolerationSeconds  #容忍时间 当effect为NoExecute时生效，表示pod在node上的停留时间

3、pod控制器

介绍：在k8s中，按pod的创建方式可以将其分为两类：

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

什么是pod控制器？

pod控制器是管理pod的中间层，使用了pod‘控制器之后，我们只需要告诉pod控制器，想要多少个什么样的pod就可以了，他会创建出满足条件的pod并确保每个pod处于用户期望的状态，如果pod在运行中出现故障，控制器会基于指定策略重启或重建pod

常见的pod控制器如下：

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

1 ReplicaSet

ReplicaSet的主要作用式维持一组pod的运行，本质就是保证一定数量的pod能够在集群中正常运行、他会持续监听这些pod的运行状态，一旦pod发生故障就会重启pod，如果数量减少了就会增加新的pod

ReplicaSet资源清单文件

apiVersion: v1  # 版本号
kind: ReplicaSet  #类型
metadata:  #元数据
 name: rs  #名称
 namespace: dev  #所属命名空间
 labels:  # 标签
  controller: rs
spec:   #详情描述
 replicas: 3  #副本数量
 selector:   # 选择器，通过它指定该控制器管理哪些pod
  matchLabels:   # Labels 匹配规则
   app: nginx-pod
  matchExpressions:   # Expressions 匹配规则
  - {key: app, operator: In, values: ["nginx-pod"]}
  template: 
    metadata:
     labels:
      app: nginx-pod
    spec:
     containers:
     - name: nginx
       image: nginx:latest\
       ports:
       - name: nginx-port
         containerPort: 80

示例： rs.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
 name: pc-rs
 namespace: dev
spec:
 replicas: 3
 selector:
  matchLabels:
   app: nginx-pod
 template:
  metadata:
   labels:
    app: nginx-pod
  spec:
   containers:
   - name: nginx
     image: nginx:latest
     ports:
     - containerPort: 80

扩缩容

编辑配置文件

kubectl edit rs pc-rs -n dev

交互式

kubectl scale re pc-rs -n dev --replicas=4

更换镜像

编辑配置文件式

kubectl edit rs pc-rs -n dev

交互式

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

删除ReplicaSet

删除ReplicaSet：首先将他管理的pod数量调整为0，等待所有的pod删除后执行对RS对象的删除

交互式

kubectl delete rs pc-rs -n dev

配置文件式

kubectl delete -f rs.yaml

2、deployment

deployment实在k8s1.2引入，deployment并不直接管理pod而是通过管理rs来简介管理pod 即deployment管理ReplicaSet ReplicaSet管理pod 因此功能更强大

deployment主要功能

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

Deployment资源清单

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

扩缩容

同ReplicaSet

更新

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

strategy: 指定新的pod替换旧的pod的策略，支持两个属性

type: 指定策略类型，支持两种策略 Recreate：在创建新的pod之前杀掉所有已存在的pod RollingUpdate：滚东更新，杀死一部分启动一部分，在更新过程中存在两个版本的pod

rollingUpdate：当type为rollingUpdate时生效，用于为rollingUpdate设置参数，支持两个属性

maxUnavailable：用来指定升级过程中最大不可用pod数量，默认25%

maxSurge：用来指定升级过程中可以超过期望的pod的最大数量，默认25%

更换镜像

交互式

kubectl set image deploy pod-deploy -n dev nginx=nginx:1.17.1

配置文件式

kubectl edit deploy pod-deploy -n dev

版本回退

deployment支持版本升级过程中的暂停、继续、回退等功能 kubectl rollout：版本升级相关功能，支持下面选项

status 显示当前升级状态
history 显示升级历史记录
pause 暂停版本升级过程
resume 继续已经暂停的版本升级过程
restart 重启版本升级过程
undo 回滚上一级版本（可以用–to-revision回滚到指定版本）

# 查看当前升级版本状态
kubectl rollout ststus deploy pod-deploy -n dev

# 查看历史升级记录
kubectl rollout history deploy pod-deploy -n dev

# 版本回滚   这里使用--to-revicion
kubectl rollout undo deploy pod-deploy -n dev --ro-revision=1

注意： 在执行 kubectl create -f pod-deploy.yaml --record 增加了一个–record参数否则的话查看历史版本时没有相关详细记录

金丝雀发布

在一批新的pod资源创建完成后立即暂停更新过程，此时仅存在一小部分的新版本应用，主体部分还是旧的版本，在筛选一小部分用户请求路由到新版本pod中，观察是否能稳定的按期望的方式运行，确定没问题之后继续完成余下的pod的资源滚动更新，否则立即回滚更新操作

kubectl set image deploy pod-deploy -n dev nginx=nginx:1.17.2 && kubectl rollout pause deploy pod-deploy -n dev

# 查看状态
kubectl rollout status deploy pod-deploy -n dev

# 继续更新过程
kubectl rollout resume deploy pod-deploy -n dev

删除

kubectl delete -f pod-deploy.yaml

3、HPA

1、安装metrics-server软件

metrics-server软件是用来监测pod资源使用的软件github 搜索 metrics-server 根据介绍下载安装

wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/high-availability-1.21+.yaml

修改镜像仓库为

        image: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server:v0.7.1

在args中加入

- --kubelet-insecure-tls

应用

kubectl apply -f high-availability-1.21+.yaml:wq

注意国外镜像的访问

2、准备deployment和service

创建nginx-deploy.yaml

apiVersion: apps/v1   #创建deployment
kind: Deployment
metadata:
 name: nginx-deploy
 namespace: dev
 labels:
  controller: nginx-deploy
spec:
 selector:
  matchLabels:
   app: nginx-pod
 template:
  metadata:
   name: nginx-po
   namespace: dev
   labels:
    app: nginx-pod
  spec:
   containers:
   - name: nginx
     image: nginx:latest
     resources:
      requests:
       cpu: 100m

创建service nginx-svc.yaml

apiVersion: v1   # 创建service
kind: Service
metadata:
 name: nginx-svc
 namespace: dev
spec:
 type: NodePort
 ports:
 - port: 80
   protocol: TCP
 selector:
  matchLabels:
   app: nginx-pod

3、部署HPA

创建hpa.yaml

apiVersion: autoscaling/v1   # 创建hpa
kind: HorizontalPodAutoscaler
metadata:
 name: pc-hpa
 namespace: dev
spec:
 minReplicas: 1   #最小pod数量
 maxReplicas: 5   # 最大pod数量
 targetCPUUtilizationPercentage: 3  #cpu使用指标
 scaleTargetRef:      # 指定要控制的nginx信息
  apiVersion: apps/v1
  kind: Deployment
  name: nginx

4、DaemonSet（DS）

此类型控制器适用于保证集群中每一台节点上都运行一个副本，一般用于日志收集，节点监督等场景。当集群中假如一个节点时，指定pod副本也会自动加入该节点

DaemonSet清单文件

apiVersion: apps:/v1   # 版本号
kind: DaemonSet   # 类型
metadata:  #元数据
 name:    #rs名称
 namespace:  # 所属命名空间
 labels:    # 标签
  controller: daemonset 
spec:   #详情描述
 revisionHistoryLimit:  # 保留历史版本
 updateStrategy:     # 更新策略
  type: RollingUpdate
  rollingUpdate:
   maxUnavailable:
 selector:
  matchLabels:
   app: nginx-pod
  matchExpression:
   - {key: app,operator: In, values: ["nginx-pod"]}
 template:
  metadata:
   labels:
    app: nginx-pod
  spec:
   containers:
   - name: nginx
     image: nginx:latest
     ports:
     - containerPort: 80

示例

apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: pc-daemonset
 namespace: dev
spec:
 selector:
  matchLabels:
   app: nginx-po
 template:
  metadata:
   labels:
    app: nginx-po
  spec:
   containers:
   - name: nginx
     image: nginx:latest

5、Job

主要用于负责批量处理短暂的一次性任务特点如下

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

Job的资源清单

apiVersion: batch/v1
kind: Job
metadata:
 name:
 namespace:
 labels:
  controller: job
spec:
 completions:    # 指定job需要成功运行pod的次数 默认值为1
 parallelism:     #指定job在任一时刻应该并发运行pod的数量    默认值为1
 actionDeadlineSeconds:    #指定job需要成功运行期间的时限，超过时间还未结束，系统将尝试终止
 backoffLimit:      # 指定job失败重试的次数，默认是6
 manualSelector:    # 是否可以使用selector选择器选择pod  默认false
 selector:      #选择器
  matchLabels:
   app: counter-pod
  matchExpressions:
   - {key: app,operator: In, values: ["counter-pod"]}
 template:    # 模板  当副本数量不足时，会根据下面的模板创建副本
  metadata:
   labels:
    app: counter-pod
  spec:
   restartPolicy: Never    # 重启策略只能设置为Never和OnFailure
   containers:
   - name: counter
     image: busybox:1.30

示例

apiVersion: batch/v1
kind: Job
metadata:
 name: pc-job
 namespace: dev
spec:
 manualSelector: true
 selector:
  matchLabels:
   app: counter-pod
 template:
  metadata:
   labels:
    app: counter-pod
  spec:
   restartPolicy: Never
   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"]

6、CronJob（cj）

CronJob是以job控制器为管控对象，并借助它管理pod资源对象，job控制器定义的作业任务在其控制资源创建之后便会立即执行，但CronJob可以以类似操作系统周期性任务作业计划的方式控制其运行时间点及重复运行方式，就是说，CronJob可以在特定时间点（反复）去运行Job任务

CronJob资源清单

apiVersion: batch/v1beta1
kind: CronJob
metadata: 
 name:
 namespace:
 labels:
  controller: cronjob
spec:
 schedule:    # cron格式的作业调度运行时间点，用于控制人物什么时间执行
 concurrencyPolicy:    # 并发执行策略 用于定义签一次作业运行生未完成时是否以及如何运行后一次作业   值  Allow、Forbid、Replace
 failedJobHistoryLimit:    # 为失败的任务保留的历史记录数，默认为1
 successfulJobHistoryLimit:    #为成功的任务执行保留历史记录数 ，默认为3
 startingDeadlineSeconds:    # 启动作业错误的超时时长
 jobTemplate:     # job控制器模板 用于为cronjob控制器生成job对象，下面就是job的定义
  metadata:
  spec:
   completions:
   parallelism:
   activeDeadlineSeconds:
   backoffLimit:
   manualSelector:
   selector:
    matchLabels:
     app: counter-pod
    matchExpression:
     - {key: app,operator: In,values: [counter-job]}
   template:
    metadata:
    containers:
 .......

示例：

apiVersion: batch/v1beta1
kind: Cronjob
metadata:
 name: pc-cronjob
 namespace: dev
 labels:
  controller: cronjob
spec:
 schedule: "*/1 * * * *"
 jobTemplate:
  metadata:
  spec:
    template:
     spec:
      restartPolicy: Never
      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"]