关于kubernetes:Kuberneters及Pod概念详解

什么是 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 节点运行同一个 pod

Job: 相似于 Quartz

statefulSet: 用来治理某 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 生命周期

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: v1
kind: Pod
metadata:
  name: nginx
spec:
  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 #必选，版本号，例如 v1
kind: Pod #必选，Pod
metadata: #必选，元数据
name: string #必选，Pod 名称
namespace: string #必选，Pod 所属的命名空间
labels: #自定义标签
- name: string #自定义标签名字
annotations: #自定义正文列表
- name: string
spec: #必选，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，默认 TCP
env: #容器运行前需设置的环境变量列表
- 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、port
path: string
port: number
host: string
scheme: string
HttpHeaders:
- name: string
value: string
tcpSocket: #对 Pod 内个容器健康检查形式设置为 tcpSocket 形式
port: number
initialDelaySeconds: 0 #容器启动实现后首次探测的工夫，单位为秒
timeoutSeconds: 0 #对容器健康检查探测期待响应的超时工夫，单位秒，默认 1 秒
periodSeconds: 0 #对容器监控查看的定期探测工夫设置，单位秒，默认 10 秒一次
successThreshold: 0
failureThreshold: 0
securityContext:
privileged: false
restartPolicy: [Always | Never | OnFailure] #Pod 的重启策略，Always 示意一旦不论以何种形式终止运行，kubelet 都将重启，OnFailure 示意只有 Pod 以非 0 退出码退出才重启，Nerver 示意不再重启该 Pod
nodeSelector: obeject #设置 NodeSelector 示意将该 Pod 调度到蕴含这个 label 的 node 上，以 key：value 的格局指定
imagePullSecrets: #Pull 镜像时应用的 secret 名称，以 key：secretkey 格局指定
- name: string
hostNetwork: false #是否应用主机网络模式，默认为 false，如果设置为 true，示意应用宿主机网络
volumes: #在该 pod 上定义共享存储卷列表
- name: string #共享存储卷名称（volumes 类型有很多种）emptyDir: {} #类型为 emtyDir 的存储卷，与 Pod 同生命周期的一个长期目录。为空值
hostPath: string #类型为 hostPath 的存储卷，示意挂载 Pod 所在宿主机的目录
path: string #Pod 所在宿主机的目录，将被用于同期中 mount 的目录
secret: #类型为 secret 的存储卷，挂载集群与定义的 secre 对象到容器外部
scretname: string
items:
- key: string
path: string
configMap: #类型为 configMap 的存储卷，挂载预约义的 configMap 对象到容器外部
name: string
items:
- key: string
path: 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: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  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/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # 按你的理论状况批改正本数
  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/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.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   AGE
nginx-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: 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 # 必须匹配 .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/v1
kind: Job
metadata:
  name: pi
spec:
  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/v1
kind: CronJob
metadata:
  name: hello
spec:
  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 改版。