【kubernetes】Pod控制器
| 阿里云国内75折 回扣 微信号：monov8 |
| 阿里云国际，腾讯云国际，低至75折。AWS 93折 免费开户实名账号 代冲值 优惠多多 微信号：monov8 飞机：@monov6 |
目录
Pod控制器及其功用
Pod控制器又称之为工作负载workload是用于实现管理pod的中间层确保pod资源符合预期的状态pod的资源出现故障时会尝试进行重启当根据重启策略无效则会重新新建pod的资源。
pod控制器有多种类型
1、ReplicaSet
代用户创建指定数量的pod副本确保pod副本数量符合预期状态并且支持滚动式自动扩容和缩容功能。
ReplicaSet主要三个组件组成
1用户期望的pod副本数量
2标签选择器判断哪个pod归自己管理
3当现存的pod数量不足会根据pod资源模板进行新建
帮助用户管理无状态的pod资源精确反应用户定义的目标数量但是RelicaSet不是直接使用的控制器而是使用Deployment。
2、Deployment
工作在ReplicaSet之上用于管理无状态应用目前来说最好的控制器。支持滚动更新和回滚功能还提供声明式配置。
ReplicaSet 与Deployment 这两个资源对象逐步替换之前RC的作用。
3、DaemonSet
用于确保集群中的每一个节点只运行特定的pod副本通常用于实现系统级后台任务。比如ELK服务
特性服务是无状态的
服务必须是守护进程
4、StatefulSet
管理有状态应用
5、Job
只要完成就立即退出不需要重启或重建
6、Cronjob
周期性任务控制不需要持续后台运行
Pod与控制器之间的关系
controllers在集群上管理和运行容器的 pod 对象 pod 通过 label-selector 相关联。
Pod 通过控制器实现应用的运维如伸缩升级等。
1、Deployment
部署无状态应用
管理Pod和ReplicaSet
具有上线部署、副本设定、滚动升级、回滚等功能
提供声明式更新例如只更新一个新的image
应用场景web服务
示例
vim nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.4
ports:
- containerPort: 80kubectl create -f nginx-deployment.yamlkubectl get pods,deploy,rs查看控制器配置
kubectl edit deployment/nginx-deployment
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
creationTimestamp: "2021-04-19T08:13:50Z"
generation: 1
labels:
app: nginx #Deployment资源的标签
name: nginx-deployment
namespace: default
resourceVersion: "167208"
selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx-deployment
uid: d9d3fef9-20d2-4196-95fb-0e21e65af24a
spec:
progressDeadlineSeconds: 600
replicas: 3 #期望的pod数量默认是1
revisionHistoryLimit: 10
selector:
matchLabels:
app: nginx
strategy:
rollingUpdate:
maxSurge: 25% #升级过程中会先启动的新Pod的数量不超过期望的Pod数量的25%也可以是一个绝对值
maxUnavailable: 25% #升级过程中在新的Pod启动好后销毁的旧Pod的数量不超过期望的Pod数量的25%也可以是一个绝对值
type: RollingUpdate #滚动升级
template:
metadata:
creationTimestamp: null
labels:
app: nginx #Pod副本关联的标签
spec:
containers:
- image: nginx:1.15.4 #镜像名称
imagePullPolicy: IfNotPresent #镜像拉取策略
name: nginx
ports:
- containerPort: 80 #容器暴露的监听端口
protocol: TCP
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always #容器重启策略
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
......查看历史版本
kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment
REVISION CHANGE-CAUSE
1 <none>2、SatefulSet
部署有状态应用
稳定的持久化存储即Pod重新调度后还是能访问到相同的持久化数据基于PVC来实现
稳定的网络标志即Pod重新调度后其PodName和HostName不变基于Headless Service即没有Cluster IP的Service来实现
有序部署有序扩展即Pod是有顺序的在部署或者扩展的时候要依据定义的顺序依次进行即从0到N-1在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态基于init containers来实现
有序收缩有序删除即从N-1到0
常见的应用场景数据库
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx # has to match .spec.template.metadata.labels
serviceName: "nginx"
replicas: 3 # by default is 1
template:
metadata:
labels:
app: nginx # has to match .spec.selector.matchLabels
spec:
terminationGracePeriodSeconds: 10
containers:
- name: nginx
image: k8s.gcr.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "my-storage-class"
resources:
requests:
storage: 1Gi从上面的应用场景可以发现StatefulSet由以下几个部分组成
●Headless Service无头服务用于为Pod资源标识符生成可解析的DNS记录。
●volumeClaimTemplates存储卷申请模板基于静态或动态PV供给方式为Pod资源提供专有的固定存储。
●StatefulSet用于管控Pod资源。
为什么要有headless
在deployment中每一个pod是没有名称是随机字符串是无序的。而statefulset中是要求有序的每一个pod的名称必须是固定的。当节点挂了重建之后的标识符是不变的每一个节点的节点名称是不能改变的。pod名称是作为pod识别的唯一标识符必须保证其标识符的稳定并且唯一。
为了实现标识符的稳定这时候就需要一个headless service 解析直达到pod还需要给pod配置一个唯一的名称。
为什么要有volumeClaimTemplate
大部分有状态副本集都会用到持久存储比如分布式系统来说由于数据是不一样的每个节点都需要自己专用的存储节点。而在 deployment中pod模板中创建的存储卷是一个共享的存储卷多个pod使用同一个存储卷而statefulset定义中的每一个pod都不能使用同一个存储卷由此基于pod模板创建pod是不适应的这就需要引入volumeClaimTemplate当在使用statefulset创建pod时会自动生成一个PVC从而请求绑定一个PV从而有自己专用的存储卷。
服务发现就是应用服务之间相互定位的过程。
应用场景
●动态性强Pod会飘到别的node节点
●更新发布频繁互联网思维小步快跑先实现再优化老板永远是先上线再慢慢优化先把idea变成产品挣到钱然后再慢慢一点一点优化
●支持自动伸缩一来大促肯定是要扩容多个副本
K8S里服务发现的方式---DNS使K8S集群能够自动关联Service资源的“名称”和“CLUSTER-IP”从而达到服务被集群自动发现的目的。
实现K8S里DNS功能的插件
●skyDNSKubernetes 1.3之前的版本
●kubeDNSKubernetes 1.3至Kubernetes 1.11
●CoreDNSKubernetes 1.11开始至今
安装CoreDNS仅二进制部署环境需要安装CoreDNS
方法一
下载链接https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/coredns/coredns.yaml.base
vim transforms2sed.sed
s/__DNS__SERVER__/10.0.0.2/g
s/__DNS__DOMAIN__/cluster.local/g
s/__DNS__MEMORY__LIMIT__/170Mi/g
s/__MACHINE_GENERATED_WARNING__/Warning: This is a file generated from the base underscore template file: coredns.yaml.base/g
sed -f transforms2sed.sed coredns.yaml.base > coredns.yaml方法二
上传 coredns.yaml 文件
kubectl create -f coredns.yaml
kubectl get pods -n kube-systemvim nginx-service.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-service
labels:
app: nginx
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
selector:
app: nginxkubectl create -f nginx-service.yamlkubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 5d19h
nginx-service NodePort 10.96.173.115 <none> 80:31756/TCP 10svim pod6.yaml
apiVersion: v1
kind: Pod
metadata:
name: dns-test
spec:
containers:
- name: busybox
image: busybox:1.28.4
args:
- /bin/sh
- -c
- sleep 36000
restartPolicy: 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.local
Name: 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.local
Name: nginx-service
Address 1: 10.96.173.115 nginx-service.default.svc.cluster.local查看statefulset的定义
kubectl explain statefulset
KIND: StatefulSet
VERSION: apps/v1
DESCRIPTION:
StatefulSet represents a set of pods with consistent identities. Identities
are defined as: - Network: A single stable DNS and hostname. - Storage: As
many VolumeClaims as requested. The StatefulSet guarantees that a given
network identity will always map to the same storage identity.
FIELDS:
apiVersion <string>
kind <string>
metadata <Object>
spec <Object>
status <Object>kubectl explain statefulset.spec
KIND: StatefulSet
VERSION: apps/v1
RESOURCE: 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-svc
labels:
app: myapp-svc
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: myapp-pod
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: myapp
spec:
serviceName: myapp-svc
replicas: 3
selector:
matchLabels:
app: myapp-pod
template:
metadata:
labels:
app: myapp-pod
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- containerPort: 80
name: web
volumeMounts:
- name: myappdata
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: myappdata
annotations: #动态PV创建时使用annotations在PVC里声明一个StorageClass对象的标识进行关联
volume.beta.kubernetes.io/storage-class: nfs-client-storageclass
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 2Gi解析上例由于 StatefulSet 资源依赖于一个实现存在的 Headless 类型的 Service 资源所以需要先定义一个名为 myapp-svc 的 Headless Service 资源用于为关联到每个 Pod 资源创建 DNS 资源记录。接着定义了一个名为 myapp 的 StatefulSet 资源它通过 Pod 模板创建了 3 个 Pod 资源副本并基于 volumeClaimTemplates 向前面创建的PV进行了请求大小为 2Gi 的专用存储卷。
创建pv
NFS节点
mkdir -p /data/volumes/v{1,2,3,4,5}
vim /etc/exports
/data/volumes/v1 192.168.110.0/24(rw,no_root_squash)
/data/volumes/v2 192.168.110.0/24(rw,no_root_squash)
/data/volumes/v3 192.168.110.0/24(rw,no_root_squash)
/data/volumes/v4 192.168.110.0/24(rw,no_root_squash)
/data/volumes/v5 192.168.110.0/24(rw,no_root_squash)
systemctl restart rpcbind
systemctl restart nfs
exportfs -arv
showmount -e定义PV
vim pv-demo.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv001
labels:
name: pv001
spec:
nfs:
path: /data/volumes/v1
server: stor01
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv002
labels:
name: pv002
spec:
nfs:
path: /data/volumes/v2
server: stor01
accessModes: ["ReadWriteOnce"]
capacity:
storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv003
labels:
name: pv003
spec:
nfs:
path: /data/volumes/v3
server: stor01
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv004
labels:
name: pv004
spec:
nfs:
path: /data/volumes/v4
server: stor01
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv005
labels:
name: pv005
spec:
nfs:
path: /data/volumes/v5
server: stor01
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 2Gikubectl apply -f pv-demo.yamlkubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv001 1Gi RWO,RWX Retain Available 7s
pv002 2Gi RWO Retain Available 7s
pv003 2Gi RWO,RWX Retain Available 7s
pv004 2Gi RWO,RWX Retain Available 7s
pv005 2Gi RWO,RWX Retain Available 7s创建statefulset
kubectl apply -f stateful-demo.yaml kubectl get svc #查看创建的无头服务myapp-svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 50d
myapp-svc ClusterIP None <none> 80/TCP 38skubectl get sts #查看statefulset
NAME DESIRED CURRENT AGE
myapp 3 3 55skubectl get pvc #查看pvc绑定
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
myappdata-myapp-0 Bound pv002 2Gi RWO 1m
myappdata-myapp-1 Bound pv003 2Gi RWO,RWX 1m
myappdata-myapp-2 Bound pv004 2Gi RWO,RWX 1mkubectl get pv #查看pv绑定
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv001 1Gi RWO,RWX Retain Available 6m
pv002 2Gi RWO Retain Bound default/myappdata-myapp-0 6m
pv003 2Gi RWO,RWX Retain Bound default/myappdata-myapp-1 6m
pv004 2Gi RWO,RWX Retain Bound default/myappdata-myapp-2 6m
pv005 2Gi RWO,RWX Retain Available 6mkubectl get pods #查看Pod信息
NAME READY STATUS RESTARTS AGE
myapp-0 1/1 Running 0 2m
myapp-1 1/1 Running 0 2m
myapp-2 1/1 Running 0 2m当删除一个 StatefulSet 时该 StatefulSet 不提供任何终止 Pod 的保证。为了实现 StatefulSet 中的 Pod 可以有序且体面地终止可以在删除之前将 StatefulSet 缩容到 0。
kubectl scale statefulset myappdata-myapp --replicas=0
kubectl delete -f stateful-demo.yaml 此时PVC依旧存在的再重新创建pod时依旧会重新去绑定原来的pvc
kubectl apply -f stateful-demo.yamlkubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
myappdata-myapp-0 Bound pv002 2Gi RWO 5m
myappdata-myapp-1 Bound pv003 2Gi RWO,RWX 5m
myappdata-myapp-2 Bound pv004 2Gi RWO,RWX滚动更新
//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 #查看滚动更新的过程
NAME READY STATUS RESTARTS AGE
myapp-0 1/1 Running 0 29s
myapp-1 1/1 Running 0 27s
myapp-2 0/1 Terminating 0 26s
myapp-2 0/1 Terminating 0 30s
myapp-2 0/1 Terminating 0 30s
myapp-2 0/1 Pending 0 0s
myapp-2 0/1 Pending 0 0s
myapp-2 0/1 ContainerCreating 0 0s
myapp-2 1/1 Running 0 31s
myapp-1 1/1 Terminating 0 62s
myapp-1 0/1 Terminating 0 63s
myapp-1 0/1 Terminating 0 66s
myapp-1 0/1 Terminating 0 67s
myapp-1 0/1 Pending 0 0s
myapp-1 0/1 Pending 0 0s
myapp-1 0/1 ContainerCreating 0 0s
myapp-1 1/1 Running 0 30s
myapp-0 1/1 Terminating 0 99s
myapp-0 0/1 Terminating 0 100s
myapp-0 0/1 Terminating 0 101s
myapp-0 0/1 Terminating 0 101s
myapp-0 0/1 Pending 0 0s
myapp-0 0/1 Pending 0 0s
myapp-0 0/1 ContainerCreating 0 0s
myapp-0 1/1 Running 0 1s在创建的每一个Pod中每一个pod自己的名称都是可以被解析的
kubectl exec -it myapp-0 /bin/sh
Name: myapp-0.myapp-svc.default.svc.cluster.local
Address 1: 10.244.2.27 myapp-0.myapp-svc.default.svc.cluster.local
/ # nslookup myapp-1.myapp-svc.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolve
Name: myapp-1.myapp-svc.default.svc.cluster.local
Address 1: 10.244.1.14 myapp-1.myapp-svc.default.svc.cluster.local
/ # nslookup myapp-2.myapp-svc.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolve
Name: myapp-2.myapp-svc.default.svc.cluster.local
Address 1: 10.244.2.26 myapp-2.myapp-svc.default.svc.cluster.local从上面的解析我们可以看到在容器当中可以通过对Pod的名称进行解析到ip。其解析的域名格式如下
(pod_name).(service_name).(namespace_name).svc.cluster.local总结
无状态
1deployment 认为所有的pod都是一样的
2不用考虑顺序的要求
3不用考虑在哪个node节点上运行
4可以随意扩容和缩容
有状态
1实例之间有差别每个实例都有自己的独特性元数据不同例如etcdzookeeper
2实例之间不对等的关系以及依靠外部存储的应用。
常规service和无头服务区别
service一组Pod访问策略提供cluster-IP群集之间通讯还提供负载均衡和服务发现。
Headless service无头服务不需要cluster-IP而是直接以DNS记录的方式解析出被代理Pod的IP地址。
vim pod6.yaml
apiVersion: v1
kind: Pod
metadata:
name: dns-test
spec:
containers:
- name: busybox
image: busybox:1.28.4
args:
- /bin/sh
- -c
- sleep 36000
restartPolicy: Nevervim sts.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
name: nginx-statefulset
namespace: default
spec:
serviceName: nginx
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80 kubectl apply -f sts.yaml
kubectl apply -f pod6.yamlkubectl get pods,svckubectl exec -it dns-test sh
/ # nslookup nginx-statefulset-0.nginx.default.svc.cluster.local
/ # nslookup nginx-statefulset-1.nginx.default.svc.cluster.local
/ # nslookup nginx-statefulset-2.nginx.default.svc.cluster.local
kubectl exec -it nginx-statefulset-0 bash
/# curl nginx-statefulset-0.nginx
/# curl nginx-statefulset-1.nginx
/# curl nginx-statefulset-2.nginx扩展伸缩
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 #动态查看缩容
3、DaemonSet
DaemonSet 确保全部或者一些Node 上运行一个 Pod 的副本。当有 Node 加入集群时也会为他们新增一个 Pod 。当有 Node 从集群移除时这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
使用 DaemonSet 的一些典型用法
●运行集群存储 daemon例如在每个 Node 上运行 glusterd、ceph。
●在每个 Node 上运行日志收集 daemon例如fluentd、logstash。
●在每个 Node 上运行监控 daemon例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理或 Ganglia gmond。
应用场景Agent
//官方案例监控
https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
示例
vim ds.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nginx-daemonSet
labels:
app: nginx
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.4
ports:
- containerPort: 80kubectl apply -f ds.yamlDaemonSet会在每个node节点都创建一个Pod
kubectl get pods
nginx-deployment-4kr6h 1/1 Running 0 35s
nginx-deployment-8jrg5 1/1 Running 0 35s4、Job
Job分为普通任务Job和定时任务CronJob
常用于运行那些仅需要执行一次的任务
应用场景数据库迁移、批处理脚本、kube-bench扫描、离线数据处理视频解码等业务
https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
示例
vim job.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
spec:
containers:
- name: pi
image: perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
backoffLimit: 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 perl
kubectl apply -f job.yaml
kubectl get pods
pi-bqtf7 0/1 Completed 0 41s结果输出到控制台
kubectl logs pi-bqtf7
3.14159265......清除job资源
kubectl delete -f job.yaml backoffLimit
vim job-limit.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: busybox
spec:
template:
spec:
containers:
- name: busybox
image: busybox
imagePullPolicy: IfNotPresent
command: ["/bin/sh", "-c", "sleep 10;date;exit 1"]
restartPolicy: Never
backoffLimit: 2kubectl apply -f job-limit.yamlkubectl get job,pods
NAME COMPLETIONS DURATION AGE
job.batch/busybox 0/1 4m34s 4m34s
NAME READY STATUS RESTARTS AGE
pod/busybox-dhrkt 0/1 Error 0 4m34s
pod/busybox-kcx46 0/1 Error 0 4m
pod/busybox-tlk48 0/1 Error 0 4m21skubectl describe job busybox
......
Warning BackoffLimitExceeded 43s job-controller Job has reached the specified backoff limit5、CronJob
周期性任务像Linux的Crontab一样。
周期性任务
应用场景通知备份
https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/
示例
每分钟打印hello
vim cronjob.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
imagePullPolicy: IfNotPresent
args:
- /bin/sh
- -c
- date; echo Hello from the Kubernetes cluster
restartPolicy: OnFailurecronjob其它可用参数的配置
spec:
concurrencyPolicy: Allow #声明了 CronJob 创建的任务执行时发生重叠如何处理并发性规则仅适用于相同 CronJob 创建的任务。spec仅能声明下列规则中的一种:
●Allow (默认)CronJob 允许并发任务执行。
●ForbidCronJob 不允许并发任务执行如果新任务的执行时间到了而老任务没有执行完CronJob 会忽略新任务的执行。
●Replace如果新任务的执行时间到了而老任务没有执行完CronJob 会用新任务替换当前正在运行的任务。
startingDeadlineSeconds: 15 #它表示任务如果由于某种原因错过了调度时间开始该任务的截止时间的秒数。过了截止时间CronJob 就不会开始任务且标记失败.如果此字段未设置那任务就没有最后期限。
successfulJobsHistoryLimit: 3 #要保留的成功完成的任务数默认为3
failedJobsHistoryLimit1 #要保留多少已完成和失败的任务数默认为1
suspendtrue #如果设置为 true 后续发生的执行都会被挂起。 这个设置对已经开始的执行不起作用。默认是 false。
schedule: '*/1 * * * *' #必需字段作业时间表。在此示例中作业将每分钟运行一次
jobTemplate: #必需字段作业模板。这类似于工作示例kubectl create -f cronjob.yaml kubectl get cronjob
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
hello */1 * * * * False 0 <none> 25skubectl get pods
NAME READY STATUS RESTARTS AGE
hello-1621587180-mffj6 0/1 Completed 0 3m
hello-1621587240-g68w4 0/1 Completed 0 2m
hello-1621587300-vmkqg 0/1 Completed 0 60skubectl logs hello-1621587180-mffj6
Fri May 21 09:03:14 UTC 2021
Hello from the Kubernetes cluster
//如果报错Error from server (Forbidden): Forbidden (user=system:anonymous, verb=get, resource=nodes, subresource=proxy) ( pods/log hello-1621587780-c7v54)
//解决办法绑定一个cluster-admin的权限
kubectl create clusterrolebinding system:anonymous --clusterrole=cluster-admin --user=system:anonymous