做漆包线的招聘网站网址域名

目录

1.什么是POD控制器

2.POD控制器有几种类型

3.POD与控制器之间的关系

4.示例

4.1 Deployment

4.2 SatefulSet

①为什么要有headless？

②为什么要有volumeClainTemplate？

③服务发现：就是应用服务之间相互定位的过程。

④K8S里服务发现的方式---DNS，使K8S集群能够自动关联Service资源的“名称”和“CLUSTER-IP”，从而达到服务被集群自动发现的目的。

4.3 安装CoreDNS，仅二进制部署环境需要安装CoreDNS

无状态应用（Stateless Applications）：

有状态应用（Stateful Applications）：

常规 Service 和无头服务（Headless Service）的区别：

4.4 DaemonSet

4.5 Job

4.6 CronJob 

---

1.什么是POD控制器

Pod控制器是 Kubernetes 中用于管理和控制 Pod 的重要资源，包括 ReplicaSet 和 Deployment 等。它们通过定义 Pod 模板来创建和管理 Pod 副本，实现自动扩缩容、滚动更新、故障恢复等功能。Pod 控制器负责监控 Pod 的运行状态，确保其符合用户定义的规则和策略。

Pod 控制器是 Kubernetes 应用生命周期管理的关键组件，提供了丰富的功能和灵活的配置选项，帮助用户轻松管理和运维应用程序的 Pod 资源。在 Pod 控制器中，用户可以指定副本数量、滚动更新策略、健康检查等参数，以确保应用程序的高可用性、伸缩性和稳定性。

总的来说，Pod 控制器是 Kubernetes 中实现工作负载管理的中间层，保证 Pod 资源处于预期状态。当 Pod 出现故障时，Pod 控制器会尝试重启或重新创建 Pod 资源，根据配置的重启策略进行相应的处理。这样可以确保应用程序持续可用并按照用户期望的方式运行。

---

2.POD控制器有几种类型

• ReplicaSet：用于创建指定数量的 Pod 副本，确保 Pod 数量符合预期状态。主要组成包括用户定义的副本数量、标签选择器和根据 Pod 模板创建新的 Pod 资源。虽然 ReplicaSet 不是直接使用的控制器，但通常与 Deployment 结合使用。

• Deployment：在 ReplicaSet 的基础上，用于管理无状态应用程序，支持滚动更新、回滚功能，并提供声明式配置。Deployment 是目前应用最广泛的控制器，逐渐取代之前的 ReplicationController。

• DaemonSet：确保集群中每个节点运行特定的 Pod 副本，通常用于实现系统级后台任务。适用于无状态服务和守护进程类应用。

• StatefulSet：用于管理有状态应用程序，为每个 Pod 分配唯一标识符，确保状态的稳定性和持久性。

• Job：执行一次性任务，任务完成后立即退出，不需要重启或重新创建。适用于一次性作业。

• CronJob：用于周期性任务控制，按照预定的时间表周期性地执行任务，不需要持续后台运行。

---

3.POD与控制器之间的关系

Pod 控制器在 Kubernetes 集群中起着至关重要的作用，用于管理和运行容器化应用程序的 Pod 对象。Pod 通过标签选择器（label-selector）与控制器相关联，控制器负责监控、调度和维护一组 Pod，确保它们符合用户定义的期望状态。

Pod 控制器为用户提供了一种抽象层，通过控制器可以实现对应用程序的运维管理，包括但不限于：

• 伸缩：控制器可以根据用户定义的策略自动扩展或缩减 Pod 的数量，以应对流量变化或负载情况。

• 升级：控制器支持滚动升级功能，可以逐步替换旧版本的 Pod 为新版本，确保应用程序的平稳升级。

• 故障恢复：当 Pod 发生故障或所在节点不可用时，控制器会重新调度 Pod 到其他可用节点上，确保应用程序的高可靠性。

• 负载均衡：控制器可以结合服务发现机制实现负载均衡，确保请求能够均匀分布到各个 Pod 上。

Pod 控制器是 Kubernetes 中实现应用程序管理和运维的核心组件，通过控制器可以轻松实现对应用程序的自动化管理，减少人工干预，提高系统的稳定性和可靠性。

---

4.示例

4.1 Deployment

• 部署无状态应用：Deployment 控制器通常用于部署无状态应用程序，它通过管理 Pod 和 ReplicaSet 来确保应用程序的可用性和健康运行。

• 管理 Pod 和 ReplicaSet：Deployment 控制器负责创建并管理多个 Pod 的副本（ReplicaSet），以确保根据用户定义的副本数来维持应用程序的运行状态。

• 具有上线部署、副本设定、滚动升级、回滚等功能：Deployment 控制器提供了丰富的功能，包括支持灰度发布（rolling updates）、副本数量配置、滚动升级（rolling upgrades）以及回滚到先前版本等操作。

• 提供声明式更新：Deployment 控制器支持声明式配置更新，用户可以只更新一个新的容器镜像（image），而不必关心具体的升级操作步骤，简化了应用程序的更新流程。

• 应用场景：Deployment 控制器适用于部署需要水平扩展、自动恢复、灵活升级的应用场景，特别适合用于部署 Web 服务等无状态应用程序。

Deployment 控制器是 Kubernetes 中用于管理应用程序部署和更新的关键组件，通过 Deployment 控制器，用户可以方便地进行应用程序的部署、扩展、更新和回滚，提高了应用程序的可靠性和可管理性。

vim nginx-deployment.yamlapiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx	
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.15.4ports:- containerPort: 80kubectl create -f nginx-deployment.yamlkubectl get pods,deploy,rs

#查看控制器配置

kubectl edit deployment/nginx-deploymentapiVersion: apps/v1
kind: Deployment
metadata:annotations:deployment.kubernetes.io/revision: "1"creationTimestamp: "2021-04-19T08:13:50Z"generation: 1labels:app: nginx					#Deployment资源的标签name: nginx-deploymentnamespace: defaultresourceVersion: "167208"selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx-deploymentuid: d9d3fef9-20d2-4196-95fb-0e21e65af24a
spec:progressDeadlineSeconds: 600replicas: 3					#期望的pod数量，默认是1revisionHistoryLimit: 10selector:matchLabels:app: nginxstrategy:rollingUpdate:maxSurge: 25%				#升级过程中会先启动的新Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值maxUnavailable: 25%		#升级过程中在新的Pod启动好后销毁的旧Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值type: RollingUpdate			#滚动升级template:metadata:creationTimestamp: nulllabels:app: nginx				#Pod副本关联的标签spec:containers:- image: nginx:1.15.4				#镜像名称imagePullPolicy: IfNotPresent	#镜像拉取策略name: nginxports:- containerPort: 80				#容器暴露的监听端口protocol: TCPresources: {}terminationMessagePath: /dev/termination-logterminationMessagePolicy: FilednsPolicy: ClusterFirstrestartPolicy: Always				#容器重启策略schedulerName: default-schedulersecurityContext: {}terminationGracePeriodSeconds: 30
......

#查看历史版本

kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment
REVISION  CHANGE-CAUSE
1         <none>

4.2 SatefulSet

• 部署有状态应用：StatefulSet 适用于需要持久化数据和稳定标识的有状态应用，如数据库、消息队列等。

• 稳定的持久化存储：StatefulSet 可以通过 PersistentVolumeClaim（PVC）来实现稳定的持久化存储，确保 Pod 在重新调度后仍能访问相同的持久化数据。

• 稳定的网络标志：通过 Headless Service（无 Cluster IP 的 Service）来实现稳定的网络标志，确保 Pod 在重新调度后其 PodName 和 HostName 不变。

• 有序部署和扩展：StatefulSet 支持有序部署和扩展，即在部署或者扩展时，Pod 将按照定义的顺序依次进行，init containers 可以用于确保有序性。

• 有序收缩和删除：StatefulSet 还支持有序收缩和删除，即在收缩或删除时，Pod 也将按照相反的顺序依次进行。

StatefulSet 提供了一种解决有状态应用部署和管理中的一些复杂性的方法，使得在 Kubernetes 集群中部署和运行有状态应用更加可靠和稳定。

apiVersion: v1
kind: Service
metadata:name: nginxlabels:app: nginx
spec:ports:- port: 80name: webclusterIP: Noneselector:app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:name: web
spec:selector:matchLabels:app: nginx # has to match .spec.template.metadata.labelsserviceName: "nginx"replicas: 3 # by default is 1template:metadata:labels:app: nginx # has to match .spec.selector.matchLabelsspec:terminationGracePeriodSeconds: 10containers:- name: nginximage: k8s.gcr.io/nginx-slim:0.8ports:- containerPort: 80name: webvolumeMounts:- name: wwwmountPath: /usr/share/nginx/htmlvolumeClaimTemplates:- metadata:name: wwwspec:accessModes: [ "ReadWriteOnce" ]storageClassName: "my-storage-class"resources:requests:storage: 1Gi

注意：

根据上面提到的应用场景，可以总结出 StatefulSet 在 Kubernetes 中的关键组成部分和作用：

• Headless Service（无头服务）：

  • 用于为 StatefulSet 中每个 Pod 资源生成可解析的 DNS 记录。
  • 每个 Pod 都具有唯一的标识符，并且可以通过 DNS 进行发现和通信。
  • 提供了稳定的网络标识和服务发现机制，适用于需要直接访问每个 Pod 的场景。

• volumeClaimTemplates（存储卷申请模板）：

  • 基于静态或动态 PV 供给方式为 StatefulSet 中的 Pod 资源提供专有的固定存储。
  • 通过定义存储卷申请模板，可以确保每个 Pod 都拥有独立的持久化存储，避免数据丢失和混乱。
  • 支持在 Pod 重启或迁移时保持数据的持久性和一致性。

• StatefulSet：

  • 用于管控管理 StatefulSet 中的 Pod 资源，确保这些资源按照指定的顺序和规则被创建、更新和删除。
  • 提供了有状态应用的部署和管理能力，适用于需要稳定标识、顺序部署和有状态数据处理的场景。
  • 与 Deployment 类似，但更适合管理有状态应用，如数据库、缓存等需要持久化存储和稳定标识的服务。

通过组合使用 Headless Service、volumeClaimTemplates 和 StatefulSet，可以有效地部署和管理有状态应用，确保数据的持久性、可靠性和稳定性，并提供强大的服务发现和通信机制，满足不同场景下对有状态应用的需求。

①为什么要有headless？

在deployment中，每一个pod是没有名称，是随机字符串，是无序的。而statefulset中是要求有序的，每一个pod的名称必须是固定的。当节点挂了，重建之后的标识符是不变的，每一个节点的节点名称是不能改变的。pod名称是作为pod识别的唯一标识符，必须保证其标识符的稳定并且唯一。
为了实现标识符的稳定，这时候就需要一个headless service 解析直达到pod，还需要给pod配置一个唯一的名称。

②为什么要有volumeClainTemplate？

大部分有状态副本集都会用到持久存储，比如分布式系统来说，由于数据是不一样的，每个节点都需要自己专用的存储节点。而在 deployment中pod模板中创建的存储卷是一个共享的存储卷，多个pod使用同一个存储卷，而statefulset定义中的每一个pod都不能使用同一个存储卷，由此基于pod模板创建pod是不适应的，这就需要引入volumeClainTemplate，当在使用statefulset创建pod时，会自动生成一个PVC，从而请求绑定一个PV，从而有自己专用的存储卷。

③服务发现：就是应用服务之间相互定位的过程。

应用场景：

• 自动关联：Kubernetes 集群中的 Pod 可以通过 DNS 来解析 Service 的名称，无需手动配置 IP 地址，从而实现自动关联。
• 动态性强：由于 Pod 可能会在集群中的不同节点上飘移，使用 DNS 可以保证无论 Pod 在哪个节点上，都能够通过 Service 名称来访问其他服务。
• 更新发布频繁：由于互联网应用的小步快跑特点，Service 的更新和发布频繁，使用 DNS 可以确保服务在更新后仍然可以被其他服务发现和访问。
• 支持自动伸缩：Kubernetes 中的自动伸缩功能可以根据负载情况动态调整 Pod 的数量，而使用 DNS 可以确保新增或减少的 Pod 能够被自动发现并加入到服务发现机制中。

使用 DNS 服务进行服务发现可以极大地简化应用程序的部署和扩展，并且适应了动态性强、更新发布频繁和自动伸缩等场景的需求。

④K8S里服务发现的方式---DNS，使K8S集群能够自动关联Service资源的“名称”和“CLUSTER-IP”，从而达到服务被集群自动发现的目的。

对于不同版本的 Kubernetes，有不同的 DNS 插件来实现服务发现功能：

• SkyDNS：适用于 Kubernetes 1.3 之前的版本。SkyDNS 基于 etcd 存储 DNS 记录，通过 Go 语言实现，是早期 Kubernetes 版本中用于服务发现的默认插件。
• kube-dns：适用于 Kubernetes 1.3 到 Kubernetes 1.11 的版本。kube-dns 包含 kube-dns、dns-masq 和 sidecar 三个组件，通过 etcd 存储 DNS 记录，并使用轻量级的 DNS 服务器 dns-masq 进行缓存。
• CoreDNS：适用于 Kubernetes 1.11 版本及以后。CoreDNS 是一个功能强大且可扩展的 DNS 服务器，支持多种协议和后端存储，取代了 kube-dns 成为默认的 DNS 插件，具有更好的性能和可扩展性。

这些 DNS 插件都能够实现将 Service 的名称映射到 ClusterIP 地址，使得在 Kubernetes 集群中，应用服务可以通过使用 Service 的名称来发现和相互通信，而无需直接暴露 IP 地址或进行复杂的手动配置。这样便于管理和维护整个集群的服务发现机制。

4.3 安装CoreDNS，仅二进制部署环境需要安装CoreDNS

#上传 coredns.yaml 文件

kubectl create -f coredns.yamlkubectl get pods -n kube-systemvim nginx-service.yamlapiVersion: v1  
kind: Service  
metadata:name: nginx-servicelabels:app: nginx  
spec:type: NodePort  ports:- port: 80targetPort: 80  selector:app: nginxkubectl create -f nginx-service.yamlkubectl get svc

vim pod6.yaml apiVersion: v1
kind: Pod
metadata:name: dns-test
spec:containers:- name: busyboximage: busybox:1.28.4args:- /bin/sh- -c- sleep 36000restartPolicy: Neverkubectl create -f pod6.yaml 

#解析kubernetes和nginx-service名称

kubectl exec -it dns-test sh
/ # nslookup kubernetes
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localName:      kubernetes
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local
/ # nslookup nginx-service
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localName:      nginx-service
Address 1: 10.96.173.115 nginx-service.default.svc.cluster.local

#查看statefulset的定义

kubectl explain statefulset

kubectl explain statefulset.specKIND:     StatefulSet
VERSION:  apps/v1RESOURCE: spec <Object>DESCRIPTION:Spec defines the desired identities of pods in this set.A StatefulSetSpec is the specification of a StatefulSet.FIELDS:podManagementPolicy	<string>  #Pod管理策略replicas	<integer>    #副本数量revisionHistoryLimit	<integer>   #历史版本限制selector	<Object> -required-    #选择器，必选项serviceName	<string> -required-  #服务名称，必选项template	<Object> -required-    #模板，必选项updateStrategy	<Object>       #更新策略volumeClaimTemplates	<[]Object>   #存储卷申请模板，必选项

#清单定义StatefulSet
如上所述，一个完整的 StatefulSet 控制器由一个 Headless Service、一个 StatefulSet 和一个 volumeClaimTemplate 组成。如下资源清单中的定义：

vim stateful-demo.yaml
apiVersion: v1
kind: Service
metadata:name: myapp-svclabels:app: myapp-svc
spec:ports:- port: 80name: webclusterIP: Noneselector:app: myapp-pod
---
apiVersion: apps/v1
kind: StatefulSet
metadata:name: myapp
spec:serviceName: myapp-svcreplicas: 3selector:matchLabels:app: myapp-podtemplate:metadata:labels:app: myapp-podspec:containers:- name: myappimage: ikubernetes/myapp:v1ports:- containerPort: 80name: webvolumeMounts:- name: myappdatamountPath: /usr/share/nginx/htmlvolumeClaimTemplates:- metadata:name: myappdataannotations:          #动态PV创建时，使用annotations在PVC里声明一个StorageClass对象的标识进行关联volume.beta.kubernetes.io/storage-class: nfs-client-storageclassspec:accessModes: ["ReadWriteOnce"]resources:requests:storage: 2Gi

解析上例：由于 StatefulSet 资源依赖于一个实现存在的 Headless 类型的 Service 资源，所以需要先定义一个名为 myapp-svc 的 Headless Service 资源，用于为关联到每个 Pod 资源创建 DNS 资源记录。接着定义了一个名为 myapp 的 StatefulSet 资源，它通过 Pod 模板创建了 3 个 Pod 资源副本，并基于 volumeClaimTemplates 向前面创建的PV进行了请求大小为 2Gi 的专用存储卷。
#创建pv：stor01节点

mkdir -p /data/volumes/v{1,2,3,4,5}vim /etc/exports
/data/volumes/v1 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v2 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v3 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v4 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v5 192.168.80.0/24(rw,no_root_squash)systemctl restart rpcbind
systemctl restart nfsexportfs -arvshowmount -e

#定义PV

vim pv-demo.yamlapiVersion: v1
kind: PersistentVolume
metadata:name: pv001labels:name: pv001
spec:nfs:path: /data/volumes/v1server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv002labels:name: pv002
spec:nfs:path: /data/volumes/v2server: stor01accessModes: ["ReadWriteOnce"]capacity:storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv003labels:name: pv003
spec:nfs:path: /data/volumes/v3server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv004labels:name: pv004
spec:nfs:path: /data/volumes/v4server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv005labels:name: pv005
spec:nfs:path: /data/volumes/v5server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 2Gikubectl apply -f pv-demo.yamlkubectl get pv

#创建statefulset

kubectl apply -f stateful-demo.yaml kubectl get svc  #查看创建的无头服务myapp-svckubectl get sts    #查看statefulsetkubectl get pvc    #查看pvc绑定kubectl get pv    #查看pv绑定kubectl get pods   #查看Pod信息kubectl delete -f stateful-demo.yaml	

#当删除的时候是从myapp-2开始进行删除的，关闭是逆向关闭

kubectl get pods -w

#此时PVC依旧存在的，再重新创建pod时，依旧会重新去绑定原来的pvc

kubectl apply -f stateful-demo.yamlkubectl get pvc

#滚动更新

#StatefulSet 控制器将在 StatefulSet 中删除并重新创建每个 Pod。它将以与 Pod 终止相同的顺序进行（从最大的序数到最小的序数），每次更新一个 Pod。在更新其前身之前，它将等待正在更新的 Pod 状态变成正在运行并就绪。如下操作的滚动更新是按照2-0的顺序更新。

vim stateful-demo.yaml  		#修改image版本为v2
.....
image: ikubernetes/myapp:v2
....kubectl apply -f stateful-demo.yamlkubectl get pods -w   #查看滚动更新的过程

#在创建的每一个Pod中，每一个pod自己的名称都是可以被解析的

kubectl exec -it myapp-0 /bin/sh

#从上面的解析，我们可以看到在容器当中可以通过对Pod的名称进行解析到ip。其解析的域名格式如下：

(pod_name).(service_name).(namespace_name).svc.cluster.local

无状态应用（Stateless Applications）：

• Deployment 视所有的 Pod 都是相同的，可以随意创建和销毁。
• 无需考虑执行顺序或特定节点上的运行。
• 可以随意扩展和缩减副本数量，适用于横向扩展。
• 适合处理请求和响应，对数据的持久性要求不高。

有状态应用（Stateful Applications）：

• 每个实例都有独特的特性和元数据，如 etcd、ZooKeeper 等。
• 实例之间存在差异，依赖外部存储，要求数据持久性和稳定性。
• 不同实例之间可能需要维护状态或连接关系。

常规 Service 和无头服务（Headless Service）的区别：

• Service：为一组 Pod 提供统一的访问入口，提供负载均衡、服务发现和集群内通信。具有 ClusterIP，通过该 ClusterIP 可以访问 Service 提供的服务。
• Headless Service：无头服务，不分配 ClusterIP，而是通过 DNS 记录直接暴露每个 Pod 的 IP 地址。适用于需要直接访问 Pod IP 或进行 Pod 级别的服务发现的场景，不提供负载均衡功能。

vim pod6.yaml apiVersion: v1
kind: Pod
metadata:name: dns-test
spec:containers:- name: busyboximage: busybox:1.28.4args:- /bin/sh- -c- sleep 36000restartPolicy: Nevervim sts.yaml
apiVersion: v1
kind: Service
metadata:name: nginxlabels:app: nginx
spec:ports:- port: 80name: webclusterIP: Noneselector:app: nginx
---
apiVersion: apps/v1beta1  
kind: StatefulSet  
metadata:name: nginx-statefulset  namespace: default
spec:serviceName: nginx  replicas: 3  selector:matchLabels:  app: nginxtemplate:  metadata:labels:app: nginx  spec:containers:- name: nginximage: nginx:latest  ports:- containerPort: 80  kubectl apply -f sts.yamlkubectl apply -f pod6.yamlkubectl get pods,svc

kubectl exec -it dns-test shkubectl exec -it nginx-statefulset-0 bash

#扩展伸缩

kubectl scale sts myapp --replicas=4  #扩容副本增加到4个kubectl get pods -w  #动态查看扩容kubectl get pv  #查看pv绑定kubectl patch sts myapp -p '{"spec":{"replicas":2}}'  #打补丁方式缩容kubectl get pods -w  #动态查看缩容

4.4 DaemonSet

DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

• 自动部署和回收：当新的节点加入集群时，DaemonSet 会为其创建相应的 Pod，而当节点从集群移除时，DaemonSet 也会回收相应的 Pod。

• 全局部署：DaemonSet 确保在整个集群范围内都有相同数量的 Pod 实例在运行，无论节点数量如何变化。

• 典型用途：DaemonSet 的典型应用场景包括运行集群存储 daemon、日志收集 daemon、监控 daemon 等，这些都是需要在每个节点上运行一个实例的应用程序。

• 应用场景：在 Agent 场景下，DaemonSet 特别适合用来部署运行在每个节点上的代理程序，例如服务发现代理、监控代理、日志收集代理等，确保在整个集群范围内都有这些代理程序的实例在运行。

vim ds.yaml apiVersion: apps/v1
kind: DaemonSet 
metadata:name: nginx-daemonSetlabels:app: nginx
spec:selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.15.4ports:- containerPort: 80kubectl apply -f ds.yaml

#DaemonSet会在每个node节点都创建一个Pod

kubectl get pods

4.5 Job

Job：Job 是 Kubernetes 中用于运行一次性任务的控制器。它确保一个或多个 Pod 成功完成任务后终止，并且能够处理任务失败时的重试和并行处理等情况。

CronJob：CronJob 是基于时间表达式的定时任务控制器，允许用户在指定的时间间隔内运行 Job。通过 CronJob，用户可以轻松地设置定时任务，例如每天凌晨执行一次备份任务。

应用场景：Job 和 CronJob 在很多场景下非常有用，包括数据库迁移、批处理脚本的执行、安全扫描（如 kube-bench）、离线数据处理以及视频解码等业务需求。这些任务通常是一次性的、定时的或者需要在集群中定期执行的。

vim job.yamlapiVersion: batch/v1
kind: Job
metadata:name: pi
spec:template:spec:containers:- name: piimage: perlcommand: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]restartPolicy: NeverbackoffLimit: 4

注意：

.spec.template.spec.restartPolicy该属性拥有三个候选值：OnFailure，Never和Always。默认值为Always。它主要用于描述Pod内容器的重启策略。在Job中只能将此属性设置为OnFailure或Never，否则Job将不间断运行。

.spec.backoffLimit用于设置job失败后进行重试的次数，默认值为6。默认情况下，除非Pod失败或容器异常退出，Job任务将不间断的重试，此时Job遵循 .spec.backoffLimit上述说明。一旦.spec.backoffLimit达到，作业将被标记为失败。
#在所有node节点下载perl镜像

docker pull perlkubectl apply -f job.yaml kubectl get pods

#结果输出到控制台

kubectl logs pi-bqtf7

#backoffLimit

vim job-limit.yaml
apiVersion: batch/v1
kind: Job
metadata:name: busybox
spec:template:spec:containers:- name: busyboximage: busyboximagePullPolicy: IfNotPresentcommand: ["/bin/sh", "-c", "sleep 10;date;exit 1"]restartPolicy: NeverbackoffLimit: 2kubectl apply -f job-limit.yamlkubectl get job,podskubectl describe job busybox

4.6 CronJob 

CronJob 是一种周期性任务控制器，类似于 Linux 中的 Crontab，允许用户根据预定的时间表达式来执行作业。一些常见的应用场景包括发送通知、执行备份等需要定期执行的任务。

#每分钟打印hello

vim cronjob.yamlapiVersion: batch/v1beta1
kind: CronJob
metadata:name: hello
spec:schedule: "*/1 * * * *"jobTemplate:spec:template:spec:containers:- name: helloimage: busyboximagePullPolicy: IfNotPresentargs:- /bin/sh- -c- date; echo Hello from the Kubernetes clusterrestartPolicy: OnFailure

注意：cronjob其它可用参数的配置

spec:
  concurrencyPolicy: Allow            #要保留的失败的完成作业数（默认为1）
  schedule: '*/1 * * * *'            #作业时间表。在此示例中，作业将每分钟运行一次
  startingDeadlineSeconds: 15        #pod必须在规定时间后的15秒内开始执行，若超过该时间未执行，则任务将不运行，且标记失败
  successfulJobsHistoryLimit: 3        #要保留的成功完成的作业数（默认为3）
  terminationGracePeriodSeconds: 30    #job存活时间 默认不设置为永久
  jobTemplate:                        #作业模板。这类似于工作示例

kubectl create -f cronjob.yaml kubectl get cronjobkubectl get pods