什么是 Kubernetes?

Kubernetes 是一个可移植、可扩大的开源平台，用于治理容器化工作负载和服务，有助于申明式配置和自动化。它领有宏大且疾速倒退的生态系统。Kubernetes 服务、反对和工具宽泛可用。

Kubernetes 这个名字来源于希腊语，意思是舵手或飞行员。K8s 作为一个缩写，是通过计算“K”和“s”之间的八个字母得出的。Google 于 2014 年开源了 Kubernetes 我的项目。当初各大厂商都在进行容器化革新，那么为什么抉择kubernetes，那它能做什么呢？有什么用呢？上面详解：

为什么须要 Kubernetes 以及它能够做什么

容器是捆绑和运行应用程序的好办法。在生产环境中，您须要治理运行应用程序的容器并确保没有停机。例如，如果一个容器呈现故障，则须要启动另一个容器。如果这种行为由零碎解决，会不会更容易？

这就是 Kubernetes 来救济的形式！Kubernetes 为您提供了一个框架来弹性地运行分布式系统。它负责您的应用程序的扩大和故障转移，提供部署模式等等。例如，Kubernetes 能够轻松地为您的系统管理金丝雀部署。

Kubernetes：

  • 服务发现和负载平衡 Kubernetes 能够应用 DNS 名称或应用本人的 IP 地址公开容器。如果容器的流量很高，Kubernetes 可能负载平衡和调配网络流量，从而使部署稳固。
  • 主动推出和回滚 您能够应用 Kubernetes 形容已部署容器的所需状态，它能够以受控的速率将理论状态更改为所需状态。例如，您能够自动化 Kubernetes 为您的部署创立新容器、删除现有容器并将其所有资源用于新容器。
  • 存储编排 Kubernetes 容许您主动挂载您抉择的存储系统，例如本地存储、公共云提供商等。
  • 主动装箱 你为 Kubernetes 提供了一个节点集群，它能够用来运行容器化的工作。你通知 Kubernetes 每个容器须要多少 CPU 和内存 (RAM)。Kubernetes 能够将容器装置到您的节点上，以充分利用您的资源。
  • 自我修复 Kubernetes 会重新启动失败的容器、替换容器、杀死不响应用户定义的健康检查的容器，并且在它们筹备好服务之前不会将它们通告给客户端。
  • 机密和配置管理 Kubernetes 容许您存储和治理敏感信息，例如明码、OAuth 令牌和 SSH 密钥。您能够部署和更新秘密和应用程序配置，而无需从新构建容器映像，也无需在堆栈配置中公开秘密。

Kubenetes的架构图

一个kubernetes集群都至多由一个Master节点和若干个Node节点组成。

Master节点是集群管制节点，负责整个集群的治理和管制，基本上Kubernetes所有的管制命令都是发给它，它来负责具体的执行过程。

因为Master节点的重要性，它通常会独占一个物理机或虚拟机。

Master节点外的其它机器被称为Node节点，Node节点是集群中的工作负载节点，每个Node都会被Master调配一些工作负载（如Docker容器），当某个Node宕机时，其工作负载会被Master主动转移到其余节点上。

Kubernetes术语理念

Mashi ter节点组件提供整个集群的控制面板：

kube-apiserver: 裸露API操作接口，是kubernetes外面所有资源增，删，改，查等操作的惟一入口；也是集群管制的入口。etcd: 集群的主数据库，集群外面的所有数据都存储于此。kube-controller-manager: kubernetes里所有资源对象的自动化控制中心， 控制器的大管家。kube-scheduler: 负责资源调度（Pod调度）的过程，为新创建的Pod调配Node节点去运行。

Node节点组件维持Pods的运行：

kubelet: 负责Pod对应容器的创立，启动，进行等工作； 同时与Master节点密切协作，实现集群治理的基本功能。kube-proxy: 实现Service的通信和负载平衡机制的重要组件。docker: docker引擎，负责本节点的容器创立和管理工作。supervisord: 过程监控，放弃kubelet和docker的失常运行。fluentd: 日志收集

kubernetes集群中的对象或资源

pod:是能够在 Kubernetes 中创立和治理的、最小的可部署的计算单元。label:一组绑定到kubernetes对象上的键/值对，同一对象的labels属性的Key必须举世无双。label selector: kubernetes外围的分组机制，通过它客户端可能辨认一组有独特特色或属性的kubernetes对象。serivece: pod正本组成的集群实例。次要由一个IP和一个label selector组成。 实现pod集群的IP代理和负载平衡。voLume:相似于虚拟机的磁盘。Pod中能被多个容器拜访的共享目录。namespaces:用于多租户的资源隔离。replicaSet:决定一个pod有多少同时容许的正本，并保障这些正本的冀望状态与以后状态保持一致。Deployment: replicaset的升级版DaemonSet: 让所有Node节点运行同一个podJob: 相似于QuartzstatefulSet: 用来治理某 Pod 汇合的部署和扩缩， 并为这些 Pod 提供长久存储和长久标识符。

pod是什么？

Pod:是Kubernetes的最重要最根本的概念。它是可能被创立，调度和治理的最小部署单元。一个Pod代表集群中一个运行的过程。

pod的组成

一个Pod由一个非凡的根容器Pause容器和若干个严密相干的用户业务容器组成。Pause容器作为Pod的根容器，它的状态代表整个容器组的状态。Pod里的多个容器共享Pause容器的IP，共享Pause容器挂载的Volume.Kubernetes为每个Pod都调配了惟一的IP地址，称之为Pod IP，一个Pod里的多个容器共享Pod IP地址。Kubernetes要求底层网络反对集群内任意两个Pod之间的TCP/IP间接通信，这通常采纳虚构二层网络技术来实现。一个Pod里的容器与另外主机上的Pod容器可能间接通信。Pod外面的容器除了共享网络和存储外，还共享:PID namespace:一个Pod内的容器可能看到对方容器的过程IPC namespace:一个Pod内的容器可能应用POSIX音讯队列进行通信UTS namespace : 一个Pod内的容器共享主机名。

Pod生命周期

取值形容
Pending（悬决）Pod已被 Kubernetes零碎承受,但有一个或者多个容器尚未创立亦未运行。此阶段包含期待Pod被调度的工夫和通过网络下载镜像的工夫。
Running（运行中）Pod 曾经绑定到了某个节点，Pod 中所有的容器都已被创立。至多有一个容器仍在运行，或者正处于启动或重启状态。
Succeeded（胜利）Pod 中的所有容器都已胜利终止，并且不会再重启。
Failed（失败）Pod 中的所有容器都已终止，并且至多有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被零碎终止。
Unknown（未知）因为某些起因无奈获得 Pod 的状态。这种状况通常是因为与 Pod 所在主机通信失败。

Pod重启策略

Pod 的 spec 中蕴含一个 restartPolicy 字段，其可能取值包含 Always、OnFailure 和 Never。默认值是 Always。

Always：只有退出就重启（默认）。OnFailure：失败退出时（exit code不为0）才重启。Never：永远不重启。

restartPolicy 实用于 Pod 中的所有容器。restartPolicy 仅针对同一节点上 kubelet 的容器重启动作。当 Pod 中的容器退出时，kubelet 会按指数回退 形式计算重启的提早（10s、20s、40s、...），其最长提早为 5 分钟。 一旦某容器执行了 10 分钟并且没有呈现问题，kubelet 对该容器的重启回退计时器执行 重置操作。

Pod健康检查

livenessProbe:批示容器是否正在运行。如果存活态探测失败，则 kubelet 会杀死容器， 并且容器将依据其重启策略决定将来。如果容器不提供存活探针， 则默认状态为 Success。

startupProbe: 批示容器中的利用是否曾经启动。如果提供了启动探针，则所有其余探针都会被 禁用，直到此探针胜利为止。如果启动探测失败，kubelet 将杀死容器，而容器依其 重启策略进行重启。 如果容器没有提供启动探测，则默认状态为 Success。

readinessProbe:批示容器是否筹备好为申请提供服务。如果就绪态探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始提早之前的就绪态的状态值默认为 Failure。 如果容器不提供就绪态探针，则默认状态为 Success。

  • ExecAction：在容器外部执行一个命令，如果该命令的返回值为0，则示意容器衰弱。
  • TCPSocketAction:通过容器ip地址和端口号执行TCP查看,如果可能建设tcp连贯表明容器衰弱。
  • HTTPGetAction：通过容器Ip地址、端口号及门路调用http get办法，如果响应的状态吗大于200且小于400，则认为容器衰弱。

Pod的调度

在Kubernetes零碎中，Pod在大部分场景下都只是容器的载体而已，通常须要通过RC、Deployment、DaemonSet、Job等对象来实现Pod的调度和自动控制性能。

Pod主动调度

nodeSelector： 定向调度
Kubernetes Master上的scheduler服务（kube-Scheduler过程）负责实现Pod的调度，整个过程通过一系列简单的算法，最终为每个Pod计算出一个最佳的指标节点，通常咱们无奈晓得Pod最终会被调度到哪个节点上。理论状况中，咱们须要将Pod调度到咱们指定的节点上，能够通过Node的节点标签和pod的nodeSelector属性相匹配来达到目标。

NodeAffinity： 亲和性调度
调度策略是未来替换NodeSelector的新一代调度策略。因为NodeSelector通过Node的Label进行准确匹配，所有NodeAffinity减少了In、NotIn、Exists、DoesNotexist、Gt、Lt等操作符来抉择Node。调度侧露更加灵便
NotIn 和 DoesNotExist 可用来实现节点反亲和性行为。

给节点增加标签

kubectl get nodes --show-labels #列出集群中的节点及其标签kubectl label nodes <your-node-name> disktype=ssd #抉择一个节点，给它增加一个标签

上面清单形容了一个 Pod，它有一个节点亲和性配置requiredDuringSchedulingIgnoredDuringExecution，disktype=ssd。 这意味着 pod 只会被调度到具备 disktype=ssd 标签的节点上。

apiVersion: v1kind: Podmetadata:  name: nginxspec:  affinity:    nodeAffinity:      requiredDuringSchedulingIgnoredDuringExecution:        nodeSelectorTerms:        - matchExpressions:          - key: disktype            operator: In            values:            - ssd              containers:  - name: nginx    image: nginx    imagePullPolicy: IfNotPresent

Pod的文件配置

Kubernetes里的所有资源对象都采纳yaml或者JSON格局的文件来定义或形容，上面是Pod资源定义文件的模板：

#yaml格局的pod定义文件残缺内容：apiVersion: v1 #必选，版本号，例如v1kind: Pod #必选，Podmetadata: #必选，元数据name: string #必选，Pod名称namespace: string #必选，Pod所属的命名空间labels: #自定义标签- name: string #自定义标签名字annotations: #自定义正文列表- name: stringspec: #必选，Pod中容器的具体定义containers: #必选，Pod中容器列表- name: string #必选，容器名称image: string #必选，容器的镜像名称imagePullPolicy: [Always | Never | IfNotPresent] #获取镜像的策略 Alawys示意下载镜像 IfnotPresent示意优先应用本地镜像，否则下载镜像，Nerver示意仅应用本地镜像command: [string] #容器的启动命令列表，如不指定，应用打包时应用的启动命令args: [string] #容器的启动命令参数列表workingDir: string #容器的工作目录volumeMounts: #挂载到容器外部的存储卷配置- name: string #援用pod定义的共享存储卷的名称，需用volumes[]局部定义的的卷名mountPath: string #存储卷在容器内mount的绝对路径，应少于512字符readOnly: boolean #是否为只读模式ports: #须要裸露的端口库号列表- name: string #端口号名称containerPort: int #容器须要监听的端口号hostPort: int #容器所在主机须要监听的端口号，默认与Container雷同protocol: string #端口协定，反对TCP和UDP，默认TCPenv: #容器运行前需设置的环境变量列表- name: string #环境变量名称value: string #环境变量的值resources: #资源限度和申请的设置limits: #资源限度的设置cpu: string #Cpu的限度，单位为core数，将用于docker run --cpu-shares参数memory: string #内存限度，单位能够为Mib/Gib，将用于docker run --memory参数requests: #资源申请的设置cpu: string #Cpu申请，容器启动的初始可用数量memory: string #内存分明，容器启动的初始可用数量livenessProbe: #对Pod内个容器健康检查的设置，当探测无响应几次后将主动重启该容器，查看办法有exec、httpGet和tcpSocket，对一个容器只需设置其中一种办法即可exec: #对Pod容器内查看形式设置为exec形式command: [string] #exec形式须要制订的命令或脚本httpGet: #对Pod内个容器健康检查办法设置为HttpGet，须要制订Path、portpath: stringport: numberhost: stringscheme: stringHttpHeaders:- name: stringvalue: stringtcpSocket: #对Pod内个容器健康检查形式设置为tcpSocket形式port: numberinitialDelaySeconds: 0 #容器启动实现后首次探测的工夫，单位为秒timeoutSeconds: 0 #对容器健康检查探测期待响应的超时工夫，单位秒，默认1秒periodSeconds: 0 #对容器监控查看的定期探测工夫设置，单位秒，默认10秒一次successThreshold: 0failureThreshold: 0securityContext:privileged: falserestartPolicy: [Always | Never | OnFailure] #Pod的重启策略，Always示意一旦不论以何种形式终止运行，kubelet都将重启，OnFailure示意只有Pod以非0退出码退出才重启，Nerver示意不再重启该PodnodeSelector: obeject #设置NodeSelector示意将该Pod调度到蕴含这个label的node上，以key：value的格局指定imagePullSecrets: #Pull镜像时应用的secret名称，以key：secretkey格局指定- name: stringhostNetwork: false #是否应用主机网络模式，默认为false，如果设置为true，示意应用宿主机网络volumes: #在该pod上定义共享存储卷列表- name: string #共享存储卷名称 （volumes类型有很多种）emptyDir: {} #类型为emtyDir的存储卷，与Pod同生命周期的一个长期目录。为空值hostPath: string #类型为hostPath的存储卷，示意挂载Pod所在宿主机的目录path: string #Pod所在宿主机的目录，将被用于同期中mount的目录secret: #类型为secret的存储卷，挂载集群与定义的secre对象到容器外部scretname: stringitems:- key: stringpath: stringconfigMap: #类型为configMap的存储卷，挂载预约义的configMap对象到容器外部name: stringitems:- key: stringpath: string

Label和Label Selector

  1. 什么是Label

    • Label是Kubernetes系列中另外一个外围概念。是一组绑定到K8s资源对象上的key/value对。同一个对象的labels属性的key必须惟一。label能够附加到各种资源对象上，如Node,Pod,Service,RC等。

  2. 什么是Label selector

    • Label selector是Kubernetes外围的分组机制，通过label selector客户端/用户可能辨认一组有独特特色或属性的资源对象。

  3. Label Selector 应用场合

    • kube-controller过程通过资源对象RC,上定义的Label Selector来筛选要监控的Pod正本数量，从而实现Pod正本的数量始终合乎预期设定的全自动管制流程。
    • 通过对某些Node定义特定的Label,并且在Pod定义文件中应用NodeSelector这种标签调度策略，Kube-scheduler过程能够实现Pod定向调度的个性
    • kupe-proxy过程通过Service的Label Selector来抉择对应的Pod，主动建设器每个Service到对应Pod的申请转发路由表，从而实现Service的智能负载平衡机制

Replication Controller

RC是kubernetes的外围概念之一。确保在任何时候都有特定数量的 Pod 正本处于运行状态。 换句话说，ReplicationController 确保一个 Pod 或一组同类的 Pod 总是可用的。 它由以下几个局部组成：

  • Pod期待的正本数（replicas）
  • 用于筛选指标Pod的Label Selector
  • 当Pod的正本数量小于预期数量的时候，用于创立新Pod的Pod模板。

示例 ReplicationController 配置运行 nginx Web 服务器的三个正本。

apiVersion: v1kind: ReplicationControllermetadata:  name: nginxspec:  replicas: 3  selector:    app: nginx  template:    metadata:      name: nginx      labels:        app: nginx    spec:      containers:      - name: nginx        image: nginx        ports:        - containerPort: 80

以下命令查看 ReplicationController 的状态

kubectl describe replicationcontrollers/nginx

要以机器可读的模式列出属于 ReplicationController 的所有 Pod，能够应用如下命令：

pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})echo $pods

ReplicaSet

ReplicaSet 的目标是保护一组在任何时候都处于运行状态的 Pod 正本的稳固汇合。 因而，它通常用来保障给定数量的、完全相同的 Pod 的可用性。
Replica Sets是下一代的RC，它与RC以后存在的惟一区别是，它反对基于汇合的Label selector; 而RC只反对基于等式的Label Selector。
kubectl命令行工具实用于RC的绝大部分命令都同样实用于Replica Sets. 以后咱们很少独自应用Replica Set, 它次要被Deployment 这个更高层的资源对象所应用，从而造成一整套Pod创立，删除更新的编排机制。
示例如下：

apiVersion: apps/v1kind: ReplicaSetmetadata:  name: frontend  labels:    app: guestbook    tier: frontendspec:  # 按你的理论状况批改正本数  replicas: 3  selector:    matchLabels:      tier: frontend  template:    metadata:      labels:        tier: frontend    spec:      containers:      - name: php-redis        image: gcr.io/google_samples/gb-frontend:v3

Deployments

一个 Deployment 为 Pod 和 ReplicaSet 提供申明式的更新能力。

以下是 Deployments 的典型用例：

  • 创立 Deployment 以将 ReplicaSet 上线。 ReplicaSet 在后盾创立 Pods。 查看 ReplicaSet 的上线状态，查看其是否胜利。
  • 更新 Deployments 的 PodTemplateSpec，申明 Pod 的新状态 。 新的 ReplicaSet 会被创立，Deployment 以受控速率将 Pod 从旧 ReplicaSet 迁徙到新 ReplicaSet。 每个新的 ReplicaSet 都会更新 Deployment 的订正版本。
  • Deployment 的以后状态不稳固，回滚到较早的 Deployment 版本。 每次回滚都会更新 Deployment 的订正版本。
  • 扩充 Deployment 规模以承当更多负载
  • 暂停 Deployment 以利用对 PodTemplateSpec 所作的多项批改， 而后复原其执行以启动新的上线版本。
  • 应用 Deployment 状态来断定上线过程是否呈现停滞。

上面是一个 Deployment 示例。其中创立了一个 ReplicaSet，负责启动三个 nginx Pods：

apiVersion: apps/v1kind: Deploymentmetadata:  name: nginx-deployment  labels:    app: nginxspec:  replicas: 3  selector:    matchLabels:      app: nginx  template:    metadata:      labels:        app: nginx    spec:      containers:      - name: nginx        image: nginx:1.14.2        ports:        - containerPort: 80

在查看集群中的 Deployment 时，所显示的字段有：

1. NAME 列出了集群中 Deployment 的名称。2. READY 显示应用程序的可用的“正本”数。显示的模式是“就绪个数/冀望个数”。3. UP-TO-DATE 显示为了达到冀望状态曾经更新的正本数。4. AVAILABLE 显示利用可供用户应用的正本数。5. AGE 显示利用程序运行的工夫。

要查看 Deployment 上线状态 运行：

 kubectl rollout status deployment/nginx-deployment

要查看 Deployment 创立的 ReplicaSet（rs），运行 kubectl get rs。 输入相似于：

NAME                          DESIRED   CURRENT   READY   AGEnginx-deployment-75675f5897   3         3         3       18s

ReplicaSet 输入中蕴含以下字段：

1. NAME 列出名字空间中 ReplicaSet 的名称；2. DESIRED 显示利用的冀望正本个数，即在创立 Deployment 时所定义的值。 此为冀望状态；3. CURRENT 显示以后运行状态中的正本个数；4. READY 显示利用中有多少正本能够为用户提供服务；5. AGE 显示利用曾经运行的工夫长度。

要查看每个 Pod 主动生成的标签，运行:

kubectl get pods --show-labels

StatefulSet

StatefulSet 是用来治理有状态利用的工作负载 API 对象,治理某 Pod 汇合的部署和扩缩， 并为这些 Pod 提供长久存储和长久标识符。
StatefulSet 为它们的每个 Pod 保护了一个有粘性的 ID。这些 Pod 是基于雷同的规约来创立的， 然而不能互相替换：无论怎么调度，每个 Pod 都有一个永恒不变的 ID。

应用 StatefulSet的意义：

  • 稳固的、惟一的网络标识符。
  • 稳固的、长久的存储。
  • 有序的、优雅的部署和扩缩。
  • 有序的、主动的滚动更新。

在下面形容中，“稳固的”意味着 Pod 调度或重调度的整个过程是有持久性的。 如果应用程序不须要任何稳固的标识符或有序的部署、删除或扩缩， 则应该应用由一组无状态的正本控制器提供的工作负载来部署应用程序，比方 Deployments 或者 ReplicaSet 可能更实用于你的无状态利用部署须要。

上面的示例演示了 StatefulSet 的组件。

apiVersion: v1kind: Servicemetadata:  name: nginx  labels:    app: nginxspec:  ports:  - port: 80    name: web  clusterIP: None  selector:    app: nginx---apiVersion: apps/v1kind: StatefulSetmetadata:  name: webspec:  selector:    matchLabels:      app: nginx # 必须匹配 .spec.template.metadata.labels  serviceName: "nginx"  replicas: 3 # 默认值是 1  minReadySeconds: 10 # 默认值是 0  template:    metadata:      labels:        app: nginx # 必须匹配 .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

上述例子中：

  • 名为 nginx 的 Headless Service 用来管制网络域名。
  • 名为 web 的 StatefulSet 有一个 Spec，它表明将在独立的 3 个 Pod 正本中启动 nginx 容器。
  • volumeClaimTemplates 将通过 PersistentVolumes 驱动提供的 PersistentVolumes 来提供稳固的存储。

StatefulSet 的命名须要遵循 DNS 子域名标准:

不能超过 253 个字符只能蕴含小写字母、数字，以及 '-' 和 '.'必须以字母数字结尾必须以字母数字结尾

Job

job控制器用于执行单次工作
能够设置运行次数，失败重试的次数，以及并行数。
job的三种应用场景：

  • 非并行任务：只启一个pod，pod胜利，job失常完结
  • 并行任务同时指定胜利个数：.spec.completions为指定胜利个数，能够指定也能够不指定.spec.parallelism（指定>1，会有多个工作并行运行）。当胜利个数达到.spec.completions，工作完结。
  • 有工作队列的并行任务：.spec.completions默认为1，.spec.parallelism为大于0的整数。此时并行启动多个pod，只有有一个胜利，工作完结，所有pod完结.

相干参数：

  1. completions:指定job启动的工作（如：pod）胜利运行completions次，job才算胜利完结
  2. parallelism:指定job同时运行的工作（如：pod）个数，Parallelism默认为1，如果设置为0，则job会暂停。
  3. backoffLimit:job倡议指定pod的重启策略为never，如：.spec.template.spec.restartPolicy = "Never"，而后通过job的backoffLimit来指定失败重试次数。在达到backoffLimit指定的次数后，job状态设置为failed（默认为6次），重试工夫采纳指数躲避（10s, 20s, 40s …），并限度在6分钟内
  4. activeDeadlineSeconds:通过指定job存活工夫，来完结一个job。当job运行工夫达到activeDeadlineSeconds指定的工夫后，job会进行由它启动的所有工作（如：pod），并设置job的状态为failed, reason: DeadlineExceeded

留神：

activeDeadlineSeconds的优先级高于backoffLimit

样例：

apiVersion: batch/v1kind: Jobmetadata:  name: pispec:  template:    spec:      containers:      - name: pi        image: perl:5.34.0        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]      restartPolicy: Never  backoffLimit: 4

查看 Job 对应的已实现的 Pod，能够执行

kubectl get pods

以机器可读的形式列举隶属于某 Job 的全副 Pod，你能够应用相似上面这条命令：

pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')echo $pods

CronJob

CronJob定时执行工作，理论就是基于Job实现的。

#      ┌────────────────── 时区 (可选)#      |      ┌───────────── 分钟 (0 - 59)#      |      │ ┌───────────── 小时 (0 - 23)#      |      │ │ ┌───────────── 月的某天 (1 - 31)#      |      │ │ │ ┌───────────── month (1 - 12)#      |      │ │ │ │ ┌───────────── 周的某天 (0 - 6)（周日到周一；在某些零碎上，7 也是星期日）#      |      │ │ │ │ │                                #      |      │ │ │ │ │#      |      │ │ │ │ │#  CRON_TZ=UTC * * * * *

样例：

apiVersion: batch/v1kind: CronJobmetadata:  name: hellospec:  schedule: "* * * * *"  jobTemplate:    spec:      template:        spec:          containers:          - name: hello            image: busybox:1.28            imagePullPolicy: IfNotPresent            command:            - /bin/sh            - -c            - date; echo Hello from the Kubernetes cluster          restartPolicy: OnFailure

获取CronJob信息：

kubectl get jobs --watch

删除 CronJob：

kubectl delete cronjob <cronjob name>

查看Pod日志：

kubectl logs $pods

如有@侵权，请分割 2787950493@qq.com 改版。