k8s学习笔记二(资源清单和控制)

2023-10-30

资源清单

资源类型

  1. 名称空间级别:
  • 工作负载型资源(workload) : Pod、Replica Set、Deployment、Stateful Set、Daemon Set、Job、 CronJob(Replication Controller在v 1.11版本被废弃)
  • 服务发现及负载均衡型资源(Service Discovery Load Balance) : Service、Ingress、 .
  • 配置与存储型资源: Volume(存储卷) 、CSI(容器存储接口, 可以扩展各种各样的第三方存储卷)
  • 特殊类型的存储卷:Config Map(当配置中心来使用的资源类型) 、Secret(保存敏感数据) 、
  • Downward API(把外部环境中的信息输出给容器)
  1. 集群级别:
    • 集群级资源: :Namespace、Node、Role、ClusterRole、RoleBinding、ClusterRoleBinding
  2. 元数据型:
    • 元数据型资源:HPA、PodTemplate、LimitRange

资源清单

在k8s中,一般使用 yaml 格式的文件来创建符合我们预期期望的pod, 这样的yaml 文件我们一般 称为资源清单

yaml基本使用

  • 基本语法
  1. 缩进时不允许使用Tab键, 只允许使用空格
  2. 缩进的空格数目不重要,只要相同层级的元素左侧对齐即可
  3. #标识注释,从这个字符一直到行尾,都会被解释器忽略
  • YAML支持的数据结构
  1. 对象:键值对的集合, 又称为映射(mapping) /哈希(hashes) ) /字典(dictionary) 装
  2. 数组:一组按次序排列的值, 又称为序列(sequence) /列表 (list)
  3. 纯量(scalars) :单个的、不可再分的值
  • 对象类型:对象的一组键值对,使用冒号结构表示
    name:Steve age: 18

  • Yaml也允许另一种写法, 将所有键值对写成一个行内对象
    hash: :{name:Steve, age:18}

  • 数组类型:一组连词线开头的行,构成一个数组
    animal
    - Cat
    - Dog

  • 数组也可以采用行内表示法
    animal:[Cat, Dog]

  • 复合结构:对象和数组可以结合使用,形成复合结构
    languages:
    - Ruby
    - Perl
    - Python
    websites
    YAML:yaml.org
    Ruby:ruby-lang.org
    Python:python.org
    Perl:use.perl.org

  • 纯量:纯量是最基本的、不可再分的值。以下数据类型都属于纯量

    1. 字符串 布尔值 整数 浮点数 Null
    2. 时间日期
    • 数值直接以字面量的形式表示
      number :12.30
    • 布尔值用true和false表示
      is Set:true
    • null用~表示
      parent:~
    • 时间采用IS08601格式
      iso8601:2001-12-14t21:59:43.10-05:00
    • 日期采用复合iso 8601格式的年、月、日表示
      date:1976-07-31
    • YAML允许使用两个感叹号, 强制转换数据类型
      e: !!str 123
      f: !!str true
  • 字符串

    • 字符串默认不使用引号表示
      str:这是一行字符串
    • 如果字符串之中包含空格或特殊字符,需要放在引号之中
      str: ‘内容: 字符串’
    • 单引号和双引号都可以使用,双引号不会对特殊字符转义
      s1: ‘内容\n字符串’
      s2: “内容\n字符串”
    • 单引号之中如果还有单引号,必须连续使用两个单引号转义
      str: : ‘labor’‘s day’
    • 字符串可以写成多行,从第二行开始,必须有一个单空格缩进。换行符会被转为空格
      str:这是一段
      多行
      字符串
    • 多行字符串可以使用|保留换行符,也可以使用>折叠换行
      this: |
      Foo
      Bar
      that:>
      Foo
      Bar
    • +表示保留文字块末尾的换行,-表示删除字符串末尾的换行
      s1: |
      Foo
      s2: |+
      Foo
      s3: |-
      Foo

资源清单格式

apiVersion: group/apiversion #如果没有给定group名称, 那么默认为core, 可以使用kubectl api-versions #获取当前k8s版本上所有的api Version版本信息(每个版本可能不同) 
kind: #资源类别 
metadata: #资源元数据 
  name 
  namespace 
  lables 
  annotations #主要目的是方便用户阅读查找 
spec: #期望的状态(disi redstate) 
status: #当前状态, 本字段有Kubernetes自身维护, 用户不能去定义 

资源清单的常用命令

kubectl api-versions  # 获取api version版本信息
# 获取资源的api Version版本信息 
kubectl explain pod  
kubectl explain Ingress
kubectl explain pod # 获取字段设置帮助文档

字段配置格式

apiVersion <string>  # 表示字符串类型 
metadata <Object>  # 表示需要嵌套多层字段 
labels <map[string] string>  # 表示由k:v组成的映射 
finalizers<[]string>   # 表示字串列表 
ownerReferences<[]Object>   # 表示对象列表 
hostPID<boolean>   # 布尔类型 
priority<integer>  # 整型 
name<string> -required-  # 如果类型后面接 -required-, 表示为必填字段

通过定义清单文件创建Pod

apiVersion: v1 
kind: Pod 
metadata:  
  name: pod-demo 
  namespace: default 
  labels: 
    app: myapp 
spec: 
  containers: 
  - name: myapp-1 
    image: my.example.com/library/myapp:v1 
  - name: busybox 
    image: busybox:latest 
    command: 
    - "/bin/sh" 
    - "-c"
    - "sleep 3600"

kubectl get pod xx.xx.xx -o yaml

常用字段说明

参数名 字段类型 说明
必填字段
versions String 这里是指的是K8SAPI的版本, 目前基本上是v1, 可以用kubectl api-version 命令查询
kind String 这里指的是yaml文件定义的资源类型和角色, 比如:Pod
metadata Object 元数据对象, 固定值就写metadata
metadata.name String 元数据对象的名字, 这里由我们编写, 比如命名Pod的名字
metadata.namespace String 元数据对象的命名空间,由我们自身定义
Spec Object 详细定义对象, 固定值就写Spec
spec.containers[] list 这里是Spec对象的容器列表定义, 是个列表
spec.containers[] .name String 这里定义容器的名字
spec.containers[] .image String 这里定义要用到的镜像名称
主要字段
spec.containers[] .imagePullPolicy String 定义镜像拉取策略, 有Always、Never、 If Not Present 三个值可选 (1) Always:意思是 每次都尝试重新拉取镜像 (2) Never:表示仅 使用本地镜像 (3) If Not Present:如果本地有 镜像就使用本地镜像,没有就拉取在线镜像。 上面三个值都没设置的话, 默认是Always。
spec.containers[].command[] List 指定容器启动命令,因为是数组可以指定多个,不指定则使用镜像打包时使用的启动命令。
spec.containers[].args[] List 指定容器启动命令参数,因为是数组可以指定多个。
spec.containers[].workingDir String 指定容器的工作目录
spec.containers[] .volumeMounts[] List 指定容器内部的存储卷配置
spec.containers[].volumeMounts[].name String 指定可以被容器挂载的存储卷的名称
spec.containers[].volume Mounts[].mountPath String 指定可以被容器挂载的存储卷的路径
spec.containers[].volume Mounts[].readOnly String 设置存储卷路径的读写模式, ture或者false, 默认为读写模式
spec.containers[].ports[] List 指定容器需要用到的端口列表
spec.containers[].ports[].name String 指定端口名称
spec.containers[].ports[].containerPort String 指定容器需要监听的端口号
spec.containers[].ports[].hostPort String 指定容器所在主机需要监听的端口号,默认跟上面containerPort相同, 注意设置了hostPort同一台主机无法启动该容器的相同副本(因为主机的端口号不能相同,这样会冲突)
spec.containers[].ports[].protocol String 指定端口协议, 支持TCP和UDP, 默认值为TCP
spec.containers[].env[] List 指定容器运行前需设置的环境变量列表
spec.containers[].env[].name String 指定环境变量名称
spec.containers[].env[].value String 指定环境变量值
spec.containers[].resources Object 指定资源限制和资源请求的值(这里开始就是设置容器的资源上限)
spec.containers[].resources.limits Object 指定设置容器运行时资源的运行上限
spec.containers[].resources.limits.cpu String 指定CPU的限制, 单位为core数, 将用于 docker run --cpu-shares参数
spec.containers[].resources.limits.memory String 指定MEM内存的限制, 单位为MIB、GiB
spec.containers[].resources.requests Object 指定容器启动和调度时的限制设置
spec.containers[].resources.requests.cpu String CPU请求, 单位为core数, 容器启动时初始化可用数量
spec.containers[].resources.requests.memory String 内存请求,单位为MIB、GiB, 容器启动的初始化可用数量
额外字段
spec.restartPolicy String 定义Pod的重启策略, 可选值为Always、OnFailure、Never, 默认值为 Always. 1.Always:Pod一旦终止运行, 则无论容器是如何终止的, kubelet服务都将重启它。 2.OnFailure:只有Pod以非零退出码终止时, kubelet才会重启该容 器。如果容器正常结束(退出码为0) , 则kubelet将不会重启它。 3.Never:Pod终止后, kubelet将退出码报告给Master, 不会重启该 Pod。
spec.nodeSelector Object 定义Node的Label过滤标签, 以keyvalue格式指定
spec.imagePullSecrets Object 定义pull镜像时使用secret名称, 以name:secretkey格式指定
spec.hostNetwork Boolean 定义是否使用主机网络模式, 默认值为false。设置true表示使用宿主机网络, 不使用docker网桥, 同时设置了true将无法在同一台宿主机 上启动第二个副本。

容器生命周期

在这里插入图片描述
kubectl --> kubeapi --> etcd --> kubelet
kubellet --> 容器环境初始化 --> pause --> (init C)* --> Main C --> START(?) # *和?为正则
readiness <> Main C <> Liveness
Main C --> STOP

Init容器

Pod能够具有多个容器, 应用运行在容器里面, 但是它也可能有一个或多个先于应用容器启动的Init 容器
Init容器与普通的容器非常像, 除了如下两点:

  • Init容器总是运行到成功完成为止
  • 每个Init容器都必须在下一个Init容器启动之前成功完成

如果Pod的Init容器失败, Kubernetes会不断地重启该Pod, 直到Init容器成功为止。然而如果Pod对应的restartPolicy为Never, 它不会重新启动

Init容器的作用

因为Init容器具有与应用程序容器分离的单独镜像, 所以它们的启动相关代码具有如下优势:

  • 它们可以包含并运行实用工具,但是出于安全考虑,是不建议在应用程序容器镜像中包含这 些实用工具的
  • 它们可以包含使用工具和定制化代码来安装,但是不能出现在应用程序镜像中。例如,创建镜像没必要FROM另一个镜像, 只需要在安装过程中使用类似sed、 awk、 python或dig 这样的工具。
  • 应用程序镜像可以分离出创建和部署的角色,而没有必要联合它们构建一个单独的镜像
  • Init容器使用Linux Namespace, 所以相对应用程序容器来说具有不同的文件系统视图。因 此,它们能够具有访问Secret的权限, 而应用程序容器则不能。
  • 它们必须在应用程序容器启动之前运行完成, 而应用程序容器是并行运行的, 所以Init容 器能够提供了一种简单的阻塞或延迟应用容器的启动的方法,直到满足了一组先决条件。
Init容器的特殊说明
  • 在Pod启动过程中, Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出
  • 如果由于运行时或失败退出, 将导致容器启动失败, 它会根据Pod的restartPolicy指定的策略进行重试。然而, 如果Pod的restartPolicy设置为Always, Init容器失败时会使用 RestartPolicy策略
  • 在所有的Init容器没有成功之前, Pod将不会变成Ready状态。Init容器的端口将不会在 Service中进行聚集。 正在初始化中的Pod处于Pending状态, 但应该会将Initializing状态设置为true
  • 如果Pod重启, 所有Init容器必须重新执行
  • #对Init容器 spec的修改被限制在容器image字段, 修改其他字段都不会生效。更改Init 容器的image字段, 等价于重启该Pod
  • Init容器具有应用容器的所有字段。除了readinessProbe, 因为Init容器无法定义不同于完成 (completion) 的就绪(readiness) 之外的其他状态。这会在验证过程中强制执行
  • 在Pod中的每个app和Init容器的名称必须唯一; 与任何其它容器共享同一个名称, 会在验证时抛出错误
Init容器 yaml模板
# init模板 
apiVersion: v1 
kind: Pod 
metadata: 
  name: myapp-pod 
  labels: 
    app: myapp 
spec: 
  containers: 
  - name: mvapp-container 
    image: busybox 
    command: ['sh', ,'-c', , 'echo The app is running!&&sleep 3600'] 
  initContainers: 
  - name: init-myservice 
    image: busybox 
    command: ['sh', ,'-c', , 'until nslookup my service;do echo waiting for my service;sleep 2;done;'] 
  - name: init-mydb 
    image: busybox 
    command: ['sh', ,'-c', , 'until nslookup my db;do echo waiting for my db;sleep 2;done;' 

---
# svc myservice 配置
kind: Service 
apiVersion: v1 
metadata: 
  name:myservice 
spec: 
  ports: 
    - protocol: TCP 
      port: 80 
      targetPort: 9376 
# svc mydb配置
kind: Service 
apiVersion: v1 
metadata: 
  name: mydb 
spec: 
  ports: 
    - protocol: TCP 
      port: 80 
      targetPort: 9377

容器探针

探针是由kubelet对容器执行的定期诊断。要执行诊断, kubelet调用由容器实现的Handler。有三 种类型的处理程序:

  • ExecAction:在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。
  • TCPSocketAction:对指定端口上的容器的IP地址进行TCP检查。如果端口打开, 则诊断被认为是成功的。
  • HTTPGetAction; :对指定的端口和路径上的容器的IP地址执行HTTP Get请求。如果响应的 状态码大于等于200且小于400,则诊断被认为是成功的

每次探测都将获得以下三种结果之一:

  • 成功:容器通过了诊断。
  • 失败:容器未通过诊断。
  • 未知:诊断失败,因此不会采取任何行动
探测方式
  1. livenessProbe: :指示容器是否正在运行。如果存活探测失败, 则kubelet会杀死容器, 并且容器将受到其 重启策略的影响。如果容器不提供存活探针, 则默认状态为Success
  2. readinessProbe:指示容器是否准备好服务请求。如果就绪探测失败, 端点控制器将从与Pod匹配的所有Service的端点中删除该Pod的IP地址。初始延迟之前的就绪状态默认为Failure。如果容 器不提供就绪探针, 则默认状态为Success
就绪检测 readinessProbe 配置
# readinessProbe-httpget 模式

apiVersion: v1 
kind: Pod 
metadata: 
  name: readiness-httpget-pod 
  namespace: default 
spec: 
  containers: 
  - name: readiness-httpget-container 
    image: myapp:v1 
    imagePullPolicy: IfNotPresent 
    readinessProbe: 
      httpGet: 
        port: 80 
        path: /index1.html 
      initialDelaySeconds: 1 
      periodSeconds: 3 
存活检测 livenessProbe 配置
# livenessProbe-exec 
apiVersion: v1 
kind: Pod 
metadata: 
  name: liveness-exec-pod 
  namespace: default 
spec: 
  containers: 
  - name: liveness-exec-container 
    image: busybox 
    imagePullPolicy: IfNotPresent 
    command: ["/bin/sh", "-c", "touch/tmp/live; sleep 60; rm-rf/tmp/live; sleep 3600"] 
    livenessProbe:
      exec: 
        command: ["test", "-e", "/tmp/live"] 
      initialDelaySeconds : 1 
      periodSeconds: 3
      
# livenessProbe-httpget
apiVersion: v1 
kind: Pod 
metadata: 
  name: liveness-httpget-pod 
  namespace: default 
spec: 
  containers: 
  - name: liveness-httpget-container 
    image: myapp:v1 
    imagePullPolicy: IfNotPresent 
    ports:
    - name: http
      containerPort: 80
    livenessProbe: 
      httpGet: 
        port: 80 
        path: /index1.html 
      initialDelaySeconds: 1 
      periodSeconds: 3 
      timeoutSeconds: 10

# livenessProbe-tcp
apiVersion: v1 
kind: Pod 
metadata: 
  name: liveness-tcp-pod 
spec: 
  containers: 
  - name: liveness-tcp-container 
    image: myapp:v1 
    imagePullPolicy: IfNotPresent 
    livenessProbe: 
      tcpSocket: 
        port: 80 
      initialDelaySeconds: 5
      timeoutSeconds: 2
启动和退出运作配置

apiVersion: v1 
kind: Pod 
metadata: 
  name: lifecycle-demo
spec: 
  containers: 
  - name: lifecycle-demo-container 
    image: myapp:v1 
    lifecycle: 
      postStart: 
        exec:  ["/bin/sh", "-c", "echo will start"]
      preStop: 
        exec: ["/bin/sh", "-c", "echo will stop"]

Pod hook

Pod hook(钩子) 是由Kubernetes管理的kubelet发起的, 当容器中的进程启动前或者容器中的进程终止之前运行, 这是包含在容器的生命周期之中。可以同时为Pod中的所有容器都配置hook
Hook 的类型包括两种:

  1. exec: 执行一段命令
  2. HTTP:发送HTTP请求

重启策略

Pod Spec中有一个restartPolicy字段, 可能的值为Always、On Failure和Never。默认为 Always。
restartPolicy适用于Pod中的所有容器。restartPolicy仅指通过同一节点上的 kubelet重新启动容器。失败的容器由kubelet 以五分钟为上限的指数退避延迟(10秒,20秒,40 秒…) 重新启动, 并在成功执行十分钟后重置。如Pod文档中所述, 一旦绑定到一个节点, Pod将永远不会重新绑定到另一个节点。

Pod phase

Pod的status 字段是一个PodStatus对象, PodStatus中有一个phase字段。
Pod的相位(phase) 是Pod在其生命周期中的简单宏观概述。该阶段并不是对容器或Pod 的综合汇 总,也不是为了做为综合状态机
Pod相位的数量和含义是严格指定的。除了本文档中列举的状态外, 不应该再假定Pod有其他的 phase值

Pod phase可能的状态值
  1. 挂起(Pending) :Pod已被Kubernetes系统接受, 但有一个或者多个容器镜像尚未创建。等待时间包括调度Pod的时间和通过网络下载镜像的时间, 这可能需要花点时间
  2. 运行中(Running) :该Pod已经绑定到了一个节点上, Pod中所有的容器都已被创建。至少有一个容器正在运行,或者正处于启动或重启状态
  3. 成功(Succeeded) :Pod中的所有容器都被成功终止, 并且不会再重启
  4. 失败(Failed) :Pod中的所有容器都已终止了, 并且至少有一个容器是因为失败终止。也就是说, 容器以非0状态退出或者被系统终止
  5. 未知(Unknown) :因为某些原因无法取得Pod的状态, 通常是因为与Pod所在主机通信失败

Pod控制器类型

ReplicationController

ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数,如果有容器异常退出,会自动创建新的Pod来替代;异常多出来的容器也会自动回收,在新版本的k8s中建议使用ReplicaSet来取代ReplicationController

ReplicaSet

和ReplicationController没有本质的不同,ReplicaSet支持集合式的selector
虽然ReplicaSet可以独立使用,但一般还是建议用命Deployment来自动管理ReplicaSet(解决跟其它机制的不兼容问题,如ReplicaSet不支持rolling-update,但Deployment支持)

apiVersion: extensions/v1beta1 
kind: ReplicaSet 
metadata: 
  name: frontend 
spec: 
  replicas: 3 
  selector: 
    matchLabels: 
      tier: frontend  # 期望值是匹配这个标签
  template: 
    metadata: 
      labels: 
        tier: frontend  # RS创建的容器会打上这个标签
    spec: # 这下面放的就是普通的pod 参数
      containers: 
      - name: php-redis 
        image: gcr.io/google_samples/gb-frontend:v3 
        env: 
        - name: GET_HOSTSFROM 
          value: dns 
        ports: 
        - containerPort: 80

RS和Deployment的关联

在这里插入图片描述

Deployment

为Pod和ReplicaSet提供了一个声明式定义(declarative)方法,用来替代以前的ReplicationController来方便管理应用.
典型的应用场景包括:
1. 定义Deployment来创建Pod和ReplicaSet
2. 滚动升级和回滚应用
3. 扩容和缩容
4. 暂停和继续Deployment

一个简单的Deployment-Nginx配置

apiVersion: extensions/v1beta1 
kind: Deployment
metadata: 
  name: nginx-deployment
spec: 
  replicas: 3 
  template: 
    metadata: 
      labels: 
        app: nginx  # RS创建的容器会打上这个标签
    spec: # 这下面放的就是普通的pod 参数
      containers: 
      - name: nginx 
        image: nginx:1.7.9 
        ports: 
        - containerPort: 80

Deployment会自动创建一个RS来管理Pod

扩容

kubectl scale deployment nginx-deployment --replicas 10

自动扩展

集群支持 horizontal pod autoscaling的话还可以为 deployment设置自动扩展

kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80

更新镜像

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.7

回滚

kubectl rollout undo deployment/nginx-deployment

Deployment更新策略

Deployment可以保证在升级时只有一定数量的Pod是down的。默认的, 它会确保至少有比期望的Pod数量少 一个是up状态(最多一个不可用)
Deployment同时也可以确保只创建出超过期望数量的一定数量的Pod。默认的, 它会确保最多比期望的Pod数 量多一个的Pod是up的(最多1个surge)
未来的Kuberentes版本中, 将从1-1变成25%-25%

  • 先创建新的RS,创建25%的新POD,然后再去旧的RS里面删除25%,最终全部替换掉
kubectl describe deployments

Rollover (多个rollout并行)

假如您创建了一个有5个niginx:1.7.9replica的Deployment,但是当还只有3个nginx:1.7.9的replica创建出来的时候您就开始更新含有5个nginx:1.9.1replica的Deployment。在这种情况下, Deployment会立即杀掉已创建的3个nginx:1.7.9的Pod,并开始创建nginx:1.9.1的Pod。它不会等到所有的5个nginx:1.7.9的Pod都创建完成后才开始改变航道

可以用kubectl rollout status命令查看 deployment是否完成 ,如果roolout成功完成 , kubectl rollout status 将返回一个0值的exit code
kubectl rollout status deployment/deploymentName
echo $?
可以通过设置 .spec.revisionHistoryLimit项来指定deployment最多保留多不revision历史记录.默认的会保留所有的revision,如果将该项设置为0,deployment就不允许回退了

HPA(Horizontal Pod Autoscaling)

仅适用于Deployment和ReplicaSet,在V1版本中仅支持根据Pod的CPU利用率扩缩容,在v1 alpha版本中,支持根据内存和用户自定义的metric扩缩容

  • 后续补充

StatefullSet

  • 后续补充
    是为了解决有状态服务的问题,(对应Deployment和ReplicaSet是为无状态服务而设计),应用场景包括:

    1. 稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于PVC实现
    2. 稳定的网络标志,即Pod重新调度后其PodName和HostName不变,基于Headless Service(即没有Cluster IP的Service)来实现
    3. 有序部署,有序扩展,即Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依次进行(在下一次Pod运行之前所有之前的Pod必须都是Running和Ready状态),基于init containers来实现
    4. 有序收缩,有序删除(从N-1到0)

DaemonSet

确保全部(或者一些)Node上运行一个Pod的副本,当有Node加入集群时,也会为他们新增一个Pod.当有Node从集群移除时,这些Pod也会被回收.删除DaemonSet将会删除它创建的所有Pod
使用DaemonSet的一些典型用法:
即: 给每个node节点创建一个且只有一个的pod

	1. 运行集群存储daemon,例如在每个Node上运行glusterd,ceph
	2. 在每个Node上运行日志收集daemon,例如fluentd,logstash
	3. 在每个Node上运行监控daemon,例如Prometheus Node Exporter
apiVersion: apps/v1 
kind: DaemonSet 
metadata: 
  name: deamonset-example 
  labels: 
    app: daemonset 
spec: 
  selector: 
    matchLabels: 
      name: deamonset-example 
    template: 
      metadata: 
        labels: 
          name: deamonset-example 
      spec: 
        containers: 
        - name: daemonset-example 
          image: myapp:v1

Job

Job负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个Pod成功结束

特殊说明:

  • spec.template格式同Pod .
  • RestartPolicy仅支持Never或On Failure
  • 单个Pod时, 默认Pod成功运行后Job即结束 .
  • .spec.completions 标志Job结束需要成功运行的Pod个数, 默认为1
  • .spec.parallelism标志并行运行的Pod的个数, 默认为1
  • .spec.activeDeadlineSeconds标志失败Pod的重试最大时间, 超过这个时间不会继续重试

Example:

apiVersion: batch/v1 
kind: Job 
metadata: 
  name:pi 
spec: 
  template: 
    metadata: 
      name: pi 
    spec: 
      containers: 
      - name: pi 
        image: perl 
        command: :["perl", "-M bignum=bpi" , "-wle", "print bpi(2000)"] 
      restartPolicy: Never

Cronjob

管理基于时间的Job:
	1. 在给定时间点只运行一次
	2. 周期性地在给定时间点运行

使用条件: k8s集群版本 >=1.8
限制条件: 创建Job的操作应该是 幂等的
典型的用法:
1. 在给定的时间点调度Job运行 
2. 创建周期性运行的Job, 例如:数据库备份、发送邮件

CronJob Spec

  • .spec.schedule: 调度, 必需字段, 指定任务运行周期, 格式同cron
  • .spec.jobTemplate: Job模板, 必需字段, 指定需要运行的任务, 格式同Job
  • .spec.startingDeadlineSeconds: 启动Job的期限(秒级别) ),该字段是可选的。如果因为任何原因而错 过了被调度的时间, 那么错过执行时间的Job将被认为是失败的。如果没有指定, 则没有期限
  • .spec.concurrencyPolicy: 并发策略, 该字段也是可选的。它指定了如何处理被CronJob创建的Job的 并发执行。只允许指定下面策略中的一种
    • Allow (默认) : 允许并发运行Job
    • Forbid: 禁止并发运行, 如果前一个还没有完成, 则直接跳过下一个
    • Replace: 取消当前正在运行的Job, 用一个新的来替换
      注意, 当前策略只能应用于同一个CronJob创建的Job。如果存在多个CronJob, 它们创建的Job之间总 是允许并发运行
  • .spec.suspend: 挂起,该字段也是可选的。如果设置为 true ,后续所有执行都会被挂起。它对已经开始执行的Job不起作用。默认值为 false。
  • .spec.successfulJobsHistoryLimit和 .spec.failedJobsHistoryLimit: 历史限制, 是可选的字段。它 们指定了可以保留多少完成和失败的Job。默认情况下, 它们分别设置为 3和 1.设置限制的值为0,相关类型的Job完成后将不会被保留。

配置示例Example

apiVersion: batch/v1beta1 
kind: CronJob  
metadata: 
  name: hello 
spec: 
  schedule: "*/1 * * * *"
  jobTemplate:
    spec: 
      template: 
        spec: 
          containers: 
          - name: hello 
            image: busybox 
            args: 
            - /bin/sh 
            - --C 
            - -date; echo Hello from the Ku bernetes cluster 
          restartPolicy: OnFailure 

kubectl get cronjob 
# NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE 
# hello */1** * * False 0 <none> 
kube ctl get jobs 
# NAME DESIRED SUCCESSFUL AGE 
# hello -1202039034 49s 
pods=$(kubectl get pods --selector=job-name=hello-1202039034 --output=jsonpath={.items..metadata.name} 
kubectl logs $pods 
# Mon Aug 29 21:34:09 UTC 2016 
# Hello from the Ku bernet es cluster 
#注意, 删除cronjob的时候不会自动删除job, 这些job可以用kubectl delete job来删除 
kubectl delete cronjob hello 
# cronjob "hello" deleted

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

k8s学习笔记二(资源清单和控制) 的相关文章

随机推荐

  • 代码随想录算法训练营第三天

    LeetCode203 力扣 移除链表元素 为了将处理头结点的逻辑和处理其他节点逻辑保持一致 引入了dummyHead package algor trainingcamp import algor junior algor list Li
  • YOLOv5导出jit,onnx,engine

    一 YOLOv5导出jit YOLOv5自导出 我们可以直接用它的导出代码 models export py Exports a YOLOv5 pt model to ONNX and TorchScript formats Usage e
  • 微信小程序【获取用户昵称头像和昵称(附源码)】

    获取用户昵称头像和昵称 wx getUserProfile bindgetuserinfo 登录过程 前端源码 https pan baidu com s 1uz2Gm2FMB 8RFVkhlHY3kQ 提取码 zb4w 后端源码 http
  • JS-设置、获取对象的键

    Object defineProperty 设置对象的键 将 name 刘备 phone 17783453234 转化为 刘备 17783453234 handleFamilyNumber let obj this family numbe
  • java将秒化为分钟和秒

    package Second import java util Scanner public class Demo1 将秒化为分钟和秒 author zll public static void main String args Scann
  • RS-485通信协议(ModBus版)

    从机 设备 的通信参数 波特率 2400 115200bps 出厂默认9600bps 数据位 7 9位 出厂默认8位 停止位 1 2位 出厂默认1位 奇偶校验 无校验 奇校验 偶校验 RS485 ModBus通信格式 主机向485总线发送问
  • spring boot整合shiro引用配置文件配置是出现的问题

    Spring boot 整合shiro 使用yml配置文件 最近自己玩一下springBoot配置 然后整合一下常用的框架 遇到一个问题 配置LifecycleBeanPostProcessorBean 的时候总是先于spring 读取ym
  • 力扣724.寻找数组的中心索引——python

    题目要求中心索引左右之和相等 没有的话我们返回 1 重复的返回最左边的 我们可以直接遍历所有 分别进行求和 满足条件我们返回值 否则 1 for i in range len nums if sum nums i sum nums i 1
  • Scanner类中next()与nextLine()的区别

    Scanner类 Scanner是Java5的新特性 我们可以通过Scanner类来从键盘获取用户输入的内容 下面是创建Scanner对象的语法 创建之前需要导入Scanner的包 import java util Scanner Scan
  • 文字的背景划过效果

    文章中的效果模仿的是 CodePen 网站中的效果 传送门 原理 给 h1 的前面添加一个 伪元素 设置他的收缩比例为 0 收缩中心在 右下角 right bottom 在鼠标移上时 设置 收缩中心在 左下角 left bottom 并设置
  • S8-codelab02

    import news cnn model import numpy as np import os import pandas as pd import pickle import shutil import tensorflow as
  • 如何将ajax传过来的数据转为,spring 接收前台ajax传来的参数的几个方法

    知识补充 JSON stringify 将value Object Array String Number 序列化为JSON字符串 JSON parse 将JSON数据解析为js原生值 toJSON 作为JSON stringify中第二个
  • java/php/net/python美容美发店会员管理系统

    本系统带文档lw万字以上 文末可领取本课题的JAVA源码参考 开发环境 开发语言 Java 框架 ssm 技术 JSP JDK版本 JDK1 8 服务器 tomcat7 数据库 mysql 5 7 一定要5 7版本 数据库工具 Navica
  • 【中大加机试之最后的挣扎之“循环移位”】

    题目描述 给出字符串A和B 判断A是否是B的进行循环移位得到的子串 如A ABC B BCDEFA 则是 输入输出格式 输入描述 多组输入 输入两个字符串A和B 输出描述 如果是循环移位子串输出yes 否则输出no 如 ABC BCDEFA
  • spyder python调试查看类信息_Python调试工具-Spyder

    OS Windows 7 关键字 Python IDE Spyder 1 安装工具pip https pip pypa io en latest installing html 运行cmd python get pip py 注 Pytho
  • 软件测试习题附答案

    转载 https blog csdn net qq 23994787 article details 73699212 单项选择题 共20小题 每小题1 分 满分20分 请将答案填入题后括号中 1 在软件生命周期的哪一个阶段 软件缺陷修复费
  • 对某个字段相同的值根据另一个字段排序(Oracle数据库)

    对某个字段相同的值根据另一个字段排序 Oracle数据库 SELECT a id a material code RANK OVER PARTITION BY a material code ORDER BY a id DESC RK FR
  • 华硕电脑光驱位换成固态硬盘

    因为要拆机 不太敢自己动手 找了专业的电脑维修人员给我换的 记录一下换的过程 一共20分钟 看起来也不是很难的样子 把光驱叉掉换成240G的固态硬盘 下次要学会自己换 科普一下 笔记本拆掉光驱换固态硬盘就必须要购买一个重要配件 叫光驱位硬盘
  • ARP协议工作原理

    ARP协议工作原理 每个主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表 以表示 IP 地址和 MAC 地址之间的对应关系 主机 网络接口 新加入网络时 也可能只是mac地址发生变化 接口重启等 会发送免费ARP报文把自己IP地址与
  • k8s学习笔记二(资源清单和控制)

    资源清单 资源类型 名称空间级别 工作负载型资源 workload Pod Replica Set Deployment Stateful Set Daemon Set Job CronJob Replication Controller在