银川市住房和城乡建设局网站,可以做直播卖产品的网站,免费空间资源,wordpress网站样式目录 1.什么是POD控制器
2.POD控制器有几种类型
3.POD与控制器之间的关系
4.示例
4.1 Deployment
4.2 SatefulSet
①为什么要有headless#xff1f;
②为什么要有volumeClainTemplate#xff1f;
③服务发现#xff1a;就是应用服务之间相互定位的过程。
④K8S里服…目录 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 和 ReplicaSetDeployment 控制器负责创建并管理多个 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: 1creationTimestamp: 2021-04-19T08:13:50Zgeneration: 1labels:app: nginx #Deployment资源的标签name: nginx-deploymentnamespace: defaultresourceVersion: 167208selfLink: /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 可以通过 PersistentVolumeClaimPVC来实现稳定的持久化存储确保 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: nginxreplicas: 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-classresources: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 svcvim 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 statefulsetkubectl explain statefulset.specKIND: StatefulSet
VERSION: apps/v1RESOURCE: spec ObjectDESCRIPTION: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 的专用存储卷。 #创建pvstor01节点
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 --replicas4 #扩容副本增加到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 pods4.5 Job
JobJob 是 Kubernetes 中用于运行一次性任务的控制器。它确保一个或多个 Pod 成功完成任务后终止并且能够处理任务失败时的重试和并行处理等情况。
CronJobCronJob 是基于时间表达式的定时任务控制器允许用户在指定的时间间隔内运行 Job。通过 CronJob用户可以轻松地设置定时任务例如每天凌晨执行一次备份任务。
应用场景Job 和 CronJob 在很多场景下非常有用包括数据库迁移、批处理脚本的执行、安全扫描如 kube-bench、离线数据处理以及视频解码等业务需求。这些任务通常是一次性的、定时的或者需要在集群中定期执行的。
vim job.yamlapiVersion: batch/v1
kind: Job
metadata:name: pi
spec:template:spec:containers:- name: piimage: perlcommand: [perl, -Mbignumbpi, -wle, print bpi(2000)]restartPolicy: NeverbackoffLimit: 4注意
.spec.template.spec.restartPolicy该属性拥有三个候选值OnFailureNever和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 busybox4.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
