公司网站 仿站什么意思,wordpress注册logo,手机CPA网站建设源码修改,网站开发多少钱一单前言 Pod 是 Kubernetes 集群中能够被创建和管理的最小部署单元。所以需要有工具去操作和管理它们的生命周期,这里就需要用到控制器了。 Pod 控制器由 master 的 kube-controller-manager 组件提供#xff0c;常见的此类控制器有 Replication Controller、ReplicaSet、Deploym…前言 Pod 是 Kubernetes 集群中能够被创建和管理的最小部署单元。所以需要有工具去操作和管理它们的生命周期,这里就需要用到控制器了。 Pod 控制器由 master 的 kube-controller-manager 组件提供常见的此类控制器有 Replication Controller、ReplicaSet、Deployment、DaemonSet、StatefulSet、Job 和 CronJob 等它们分别以不同的方式管理 Pod 资源对象。 一、pod 控制器的相关知识 1.1 pod控制器的作用 Pod控制器又称之为工作负载workload是用于实现管理pod的中间层确保pod资源符合预期的状态pod的资源出现故障时会尝试进行重启当根据重启策略无效则会重新新建pod的资源。 按照pod的创建安方式可以将其分为两类 自主式podkubernetes直接创建出来的pod这种pod删除后就没有了也不会重建控制器创建的pod通过控制器创建的pod这种pod删除了之后还会自动重建 Pod与控制器之间的关系 controllers在集群上管理和运行容器的 pod 对象 pod 通过 label-selector 相关联。 Pod 通过控制器实现应用的运维如伸缩升级等。 1.2 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周期性任务控制不需要持续后台运行 1.3 pod容器中的有状态和无状态的对比  1有状态实例  实例之间有差别每个实例都有自己的独特性元数据不同例如etcdzookeeper实例之间不对等的关系以及依靠外部存储的应用  2无状态实例  deployment认为所有的pod都是一样的不用考虑顺序的要求不用考虑在哪个node节点上运行可以随意扩容和缩容 二、Deployment 控制器 部署无状态应用 管理Pod和ReplicaSet 具有上线部署、副本设定、滚动升级、回滚等功能 提供声明式更新例如只更新一个新的image 应用场景web服务 示例 vim nginx-deployment.yaml apiVersion: 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-deployment apiVersion: 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 三、SatefulSet 控制器 部署有状态应用稳定的持久化存储即Pod重新调度后还是能访问到相同的持久化数据基于PVC来实现稳定的网络标志即Pod重新调度后其PodName和HostName不变基于Headless Service即没有Cluster IP的Service来实现有序部署有序扩展即Pod是有顺序的在部署或者扩展的时候要依据定义的顺序依次进行即从0到N-1在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态基于init containers来实现有序收缩有序删除即从N-1到0 常见的应用场景数据库 StatefulSet | Kubernetes 示例 apiVersion: v1 kind: Service metadata:name: nginx #服务名称labels:app: nginx spec:ports:- port: 80name: webclusterIP: None #表明这是一个Headless Service无头服务即没有ClusterIP #通常用于StatefulSet以直接访问Pods。selector:app: nginx #服务选择器用于关联具有相同标签app: nginx的Pods --- apiVersion: apps/v1 kind: StatefulSet #表示创建的是有状态应用集 metadata:name: web #应用集名称 spec:selector:matchLabels:app: nginx #选择器标签确保StatefulSet管理的Pods具有匹配的标签app: nginx。serviceName: nginx #引用的Service名称用于Pod间的通信replicas: 3 #声明副本数量为3template: #Pod模板定义了每个Pod的元数据和规范metadata:labels:app: nginxspec:terminationGracePeriodSeconds: 10containers:- name: nginximage: nginx:1.18ports:- containerPort: 80name: webvolumeMounts:- name: wwwmountPath: /usr/share/nginx/html #卷挂载将名为www的卷挂载到/usr/share/nginx/html路径以便存储静态网页内容。volumeClaimTemplates: #卷声明模板定义了动态创建PVC 的规则- metadata:name: www # PVC名称spec:accessModes: [ ReadWriteOnce ] #设置卷访问模式storageClassName: my-storage-class #指定存储类名resources:requests:storage: 1Gi #请求的存储资源量 3.1 StatefulSet 的 三个组件 从上面的应用场景可以发现StatefulSet由以下几个部分组成 ●Headless Service无头服务用于为Pod资源标识符生成可解析的DNS记录。 ●volumeClaimTemplates存储卷申请模板基于静态或动态PV供给方式为Pod资源提供专有的固定存储。 ●StatefulSet用于管控Pod资源。 (1) 为什么要有headless 在deployment中每一个pod是没有名称是随机字符串是无序的。而statefulset中是要求有序的每一个pod的名称必须是固定的。当节点挂了重建之后的标识符是不变的每一个节点的节点名称是不能改变的。pod名称是作为pod识别的唯一标识符必须保证其标识符的稳定并且唯一。         为了实现标识符的稳定这时候就需要一个headless service 解析直达到pod还需要给pod配置一个唯一的名称。 (2)为什么要有volumeClaimTemplate 大部分有状态副本集都会用到持久存储比如分布式系统来说由于数据是不一样的每个节点都需要自己专用的存储节点。而在 deployment中pod模板中创建的存储卷是一个共享的存储卷多个pod使用同一个存储卷而statefulset定义中的每一个pod都不能使用同一个存储卷由此基于pod模板创建pod是不适应的这就需要引入volumeClainTemplate当在使用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开始至今 3.2 SatefulSet 控制器的案例演示 安装CoreDNS仅二进制部署环境需要安装CoreDNS 方法一 下载链接https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/coredns/coredns.yaml.basevim 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/gsed -f transforms2sed.sed coredns.yaml.base coredns.yaml该命令的作用是应用transforms2sed.sed文件中定义的sed规则或脚本对coredns.yaml.base文件进行 文本处理或转换然后将处理后的结果保存到新的文件coredns.yaml中。这种操作常用于配置文件的批量 修改、格式调整等场景通过编写sed脚本可以高效地自动化处理文本任务方法二上传 coredns.yaml 文件kubectl create -f coredns.yamlkubectl get pods -n kube-systemvim nginx-service.yaml apiVersion: 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 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: 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 KIND: StatefulSet VERSION: apps/v1DESCRIPTION:StatefulSet represents a set of pods with consistent identities. Identitiesare defined as: - Network: A single stable DNS and hostname. - Storage: Asmany VolumeClaims as requested. The StatefulSet guarantees that a givennetwork identity will always map to the same storage identity.FIELDS:apiVersion stringkind stringmetadata Objectspec Objectstatus Object kubectl explain statefulset.spec KIND: 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 组成。如下资源清单中的定义 apiVersion: v1 kind: Service metadata:name: myapp-svc #服务名称labels:app: myapp-svc #服务标签 spec:ports:- port: 80name: web #定义了一个端口容器端口80名称为webclusterIP: None #设置为None表明这是一个无头服务selector:app: myapp-pod #选择器标签,用于匹配StatefulSet中Pod的标签 --- apiVersion: apps/v1 kind: StatefulSet metadata:name: myapp #有状态应用集名称 spec:serviceName: myapp-svc #指定了关联的Service服务名称replicas: 3selector:matchLabels:app: myapp-pod #匹配Pod的标签template:metadata:labels:app: myapp-pod #Pod模板的标签spec:containers:- name: myappimage: ikubernetes/myapp:v1ports:- containerPort: 80name: web #容器开放端口80与服务定义相匹配(name名称要一样)volumeMounts:- name: myappdatamountPath: /usr/share/nginx/html#将名为myappdata的卷挂载到容器的/usr/share/nginx/html目录下volumeClaimTemplates:- metadata:name: myappdata #定义了PVC的名称annotations: #动态PV创建时使用annotations在PVC里声明一个StorageClass对象的标识进行关联volume.beta.kubernetes.io/storage-class: nfs-client-storageclassspec:accessModes: [ReadWriteOnce] #设置访问模式resources:requests:storage: 2Gi #请求2Gi的存储空间 解析上例由于 StatefulSet 资源依赖于一个实现存在的 Headless 类型的 Service 资源所以需要先定义一个名为 myapp-svc 的 Headless Service 资源用于为关联到每个 Pod 资源创建 DNS 资源记录。接着定义了一个名为 myapp 的 StatefulSet 资源它通过 Pod 模板创建了 3 个 Pod 资源副本并基于 volumeClaimTemplates 向前面创建的PV进行了请求大小为 2Gi 的专用存储卷。 如果你StorageClass nfs-client-provisioner 动态创建pv已经创建完成那么可直接加载该yaml文件。 想要进行动态部署可见我上一个博客。 kubectl apply -f stateful-demo.yaml kubectl get pvc 若你没有 做动态创建那么可以使用静态创建    步骤如下 //创建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.yaml apiVersion: 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 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 扩容与缩容演示 当删除的时候是从myapp-2开始进行删除的关闭是逆向关闭 kubectl delete -f stateful-demo.yaml 可以看到在我们执行了delete命令后 statefulset控制的pod 并没有如我们所想逆向关闭 若要确保Pod按照预期的顺序逆向关闭除非有特殊需求使用直接删除StatefulSet的方式否则建议通过操作StatefulSet的副本数比如逐步减少.spec.replicas的数量来优雅地缩容应用这样Kubernetes会更有序地管理Pod的生命周期。如果确实需要直接删除单个Pod可通过kubectl delete pod pod-name命令并且监控删除过程以确认行为符合预期。 想要达到效果 我们可以使用以下方法 缩容 kubectl edit statefulsets.apps myapp 不过需要注意的是对于StatefulSet而言由于每个Pod都有固定的标识和顺序减少副本数至0的操作应当更加谨慎特别是涉及到有状态应用和持久化存储时确保数据妥善处理和备份避免数据丢失或混乱。而对于无状态应用的Deployment减少副本数到0则是较为常规的操作。 通过降序进行pod的删除 注意此时PVC依旧存在的再重新创建扩容pod时依旧会重新去绑定原来的pvc kubectl apply -f stateful-demo.yaml 或 kubectl edit statefulsets.apps myapp 滚动更新 StatefulSet 控制器将在 StatefulSet 中删除并重新创建每个 Pod。它将以与 Pod 终止相同的顺序进行从最大的序数到最小的序数每次更新一个 Pod。在更新其前身之前它将等待正在更新的 Pod 状态变成正在运行并就绪。 如下操作的滚动更新是按照2-0的顺序更新。 vim stateful-demo.yaml #修改image版本为v2 ..... image: ikubernetes/myapp:v2 ....kubectl apply -f stateful-demo.yaml kubectl get pods -w   #查看滚动更新的过程 解析 pod 名称 SatefulSet 在创建的每一个Pod中每一个pod自己的名称都是可以被解析的 从上面的解析我们可以看到在容器当中可以通过对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地址。 四、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 官方案例监控DaemonSet | Kubernetes 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: 80 DaemonSet会在每个node节点都创建一个Pod 五、Job 控制器 Job分为普通任务Job和定时任务CronJob 常用于运行那些仅需要执行一次的任务 应用场景数据库迁移、批处理脚本、kube-bench扫描、离线数据处理视频解码等业务 Job | Kubernetes vim job.yaml apiVersion: batch/v1 kind: Job metadata:name: pi spec:template:spec:nodeName: node01containers:- 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达到作业将被标记为失败。perl 运行的命令。 -Mbignumbpi Perl模块加载参数启用大数支持以计算圆周率。 -wle 执行Perl脚本的选项其中-w开启警告-l使输出自动换行-e后面跟执行的代码。 print bpi(2000) 实际执行的Perl代码计算圆周率到小数点后2000位。 在node01节点下载perl镜像因为镜像比较大所以建议提前下载好 docker pull perl 在master节点上执行 kubectl apply -f job.yaml  清除job资源 kubectl delete -f job.yaml 六、CronJob  周期性任务像Linux的Crontab一样。 周期性任务 应用场景通知备份 使用 CronJob 运行自动化任务 | Kubernetes //每分钟打印hello vim cronjob.yaml apiVersion: 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 #声明了 CronJob 创建的任务执行时发生重叠如何处理并发性规则仅适用于相同 CronJob 创建的任务。spec仅能声明下列规则中的一种:●Allow (默认)CronJob 允许并发任务执行。●ForbidCronJob 不允许并发任务执行如果新任务的执行时间到了而老任务没有执行完CronJob 会忽略新任务的执行。●Replace如果新任务的执行时间到了而老任务没有执行完CronJob 会用新任务替换当前正在运行的任务。startingDeadlineSeconds: 15 #它表示任务如果由于某种原因错过了调度时间开始该任务的截止时间的秒数。过了截止时间CronJob 就不会开始任务且标记失败.如果此字段未设置那任务就没有最后期限。successfulJobsHistoryLimit: 3 #要保留的成功完成的任务数默认为3failedJobsHistoryLimit1 #要保留多少已完成和失败的任务数默认为1suspendtrue #如果设置为 true 后续发生的执行都会被挂起。 这个设置对已经开始的执行不起作用。默认是 false。schedule: */1 * * * * #必需字段作业时间表。在此示例中作业将每分钟运行一次jobTemplate: #必需字段作业模板。这类似于工作示例 kubectl create -f cronjob.yaml kubectl get cronjob //如果报错Error from server (Forbidden): Forbidden (usersystem:anonymous, verbget, resourcenodes, subresourceproxy) ( pods/log hello-1621587780-c7v54) //解决办法绑定一个cluster-admin的权限 kubectl create clusterrolebinding system:anonymous --clusterrolecluster-admin --usersystem:anonymous 总结 Pod 控制器有几种 1、DeploymentReplicaSet 部署无状态应用的Pod 2、StatefulSet 部署有状态应用的Pod 3、DaemonSet 在K8S集群的所有Node节点上部署相同的Pod 4、Job 部署一次性的任务Pod完成后就会退出并不会重启 5、CronJob 部署周期性的任务Pod完成后就会退出并不会重启Deployment 1、部署无状态应用的 2、创建和管理 ReplicaSet(RS)和Pod资源维护Pod副本数量与期望值相同 3、创建和删除Pod时是并行执行的升级时是先创建一部分新Pod再删除一部分旧PodStatefulSet 1、部署有状态应用的 2、每个Pod的名称是唯一且固定不变的而且每个Pod应该拥有自己专属的持久化存储基于PVC模板volumeClaimTemplates绑定PV 3、需要关联 Headless ServiceClusterIP为None在K8S集群内部可通过pod_name.svc.name.namespace_name.svc.cluster.local 的格式解析出Pod IP 基于无头服务和CoreDNS实现4、创建、删除、升级、扩缩容Pod都是有序进行的默认为串行执行的创建 是升序执行的顺序为Pod标识序号0..n-1删除、升级是逆序执行的顺序为 n-1..0扩缩容都是逆序执行的顺序为 n-1..0升级时会先删除旧Pod再创建新Podspec.podManagementPolicy: Parallel #可设置StatefulSet创建和删除Pod时为并行执行service类型种类 41 ClusterIP 虚拟IP NodePort 对外开放 LoadBalancer ExtenalNameHeadless Service 无头服务常规service与Headless Service的区别 常规service一组Pod的访问策略提供ClusterIP在K8S集群内部访问还提供负载均衡和服务发现功能 Headless Service无头服务可以不需要ClusterIP与StatefulSet资源关联配合CoreDNS 实现通过 Pod名称 解析出 PodIPDaemonSet 1、理论上可以在K8S集群的所有Node节点上创建同类型的Pod资源无论Node节点什么加入到K8S集群 2、会受到Node节点上的污点或者cordon不可调度设置的影响。可以在Pod配置中设置容忍忽略污点设置uncordon解除不可调度 3、不需要设置副本数replicasJob 1、部署一次性任务的资源pod 2、任务正常完成后Pod容器会立即退出并不会再重启Job类型Pod容器的retartPolicy通常设置为Never也不会重建Pod 3、如果任务异常完成Pod容器异常退出会重建Pod重试任务重试次数根据 backoffLimit 配置默认6次CronJob 1、部署周期性任务的资源一次任务至少创建一个Pod 2、任务正常完成后Pod容器会立即退出并不会再重启Job类型Pod容器的retartPolicy不设置为Always也不会重建Pod 3、使用 spec.schedule 字段设置时间周期表格式为 分 时 日 月 周