kubernetes系列(八) - 控制器的资源清单定义

• 1. ReplicaSet
  • 1.1 ReplicaSet资源清单
  • 1.2 selector
• 2. Deployment
  • 2.1 Deployment资源清单
  • 2.2 其他相关操作
    • 2.2.1 应用yaml创建
    • 2.2.2 扩容
    • 2.2.3 自动扩容
    • 2.2.4 更新容器中的镜像
    • 2.2.5 回滚
    • 2.2.6 使用edit命令编辑Deployment
  • 2.3 deploy保存的rs历史版本数量
• 3. DaemonSet
  • 3.1 DaemonSet资源清单
  • 3.2 其他相关操作
    • 3.2.1 查看daemonset
• 4. Job
  • 4.1 Job资源清单
  • 4.2 其他操作
    • 4.2.1 查看job
    • 4.2.2 job出现错误的情况
    • 4.2.3 job成功运行的情况
• 5. CronJob
  • 5.1 CronJob资源清单
  • 5.2 CronJob Spec
  • 5.3 CronJob的限制

1. ReplicaSet

1.1 ReplicaSet资源清单

apiVersion: extensions/v1beta1
kind: ReplicaSet 
metadata:
  name: rs-test
spec:
  replicas: 3 #有3个副本
  selector: #标签选择器
    matchLabels:
      tier: frontend 
  template: # pod模板
    metadata:
      1abels:
        tier: frontend 
    spec:
      containers:
      - name: toc 
        image: lzw5399/tocgenerator
        env:
        - name: GET_HOSTS_FROM 
          value:dns 
        ports:
        - containerPort: 80

1.2 selector

rs通过selector标签来认定哪些pod是属于它当前的，所以跟下面template的labels必须对应起来

验证步骤

1. 显示当前pod的labels

kubectl get po --show-labels

可以看到下面被replicaSet托管的pod有label

2. 强行修改运行的pod的label

kubectl label pod tocgenerator-6b57695c6f-9nfqc app=eee --override

再次查看pod，发现重新控制器重新创建了一个新的pod

2. Deployment

2.1 Deployment资源清单

apiVersion: apps/v1
kind: Deployment 
metadata:
  name: toc-deploy 
spec:
  replicas: 3
  selector: #标签选择器
    matchLabels: # 跟下面的labels必须对应起来
      app: toc 
  template:
    metadata:
      labels: # 跟上面的matchLabels必须对应起来
        app: toc 
    spec:
      containers:   
      - name: toc 
        image: lzw5399/tocgenerator
        ports:
        - containerPort: 80

2.2 其他相关操作

2.2.1 应用yaml创建

# --record参数可以记录命令，我们可以很方便的查看每次 revision 的变化
# 更新的时候可以记录状态，每一步是使用什么命令进行更新的
kubectl apply -f temp.yaml --record 

2.2.2 扩容

kubectl scale deployment toc-deploy --replicas 10 

2.2.3 自动扩容

• 如果集群支持horizontal pod autoscaling的话，还可以为Deployment设置自动扩展

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

2.2.4 更新容器中的镜像

kubectl set image deployment/toc-deploy tocgenerator=lzw5399/tocgenerator:xxx

2.2.5 回滚

1. 回滚到上一次

kubectl rollout undo deployment/toc-deploy

2. 回滚到指定版本

# 这个revision可以通过kubectl rollout history deployment/toc-deploy查找
kubectl rollout undo deployment/toc-deploy --to-revision=2

3. 查看回滚的状态

kubectl rollout status deployments toc-deploy

4. 查看可回滚的历史版本

kubectl rollout history deployment toc-deploy 

2.2.6 使用edit命令编辑Deployment

kubectl edit deployment/toc-deploy

2.3 deploy保存的rs历史版本数量

默认保存所有的历史rs，可以通过spec.revisonHistoryLimit来配置

如果将该项设置为0，Deployment 就不允许回退了

3. DaemonSet

3.1 DaemonSet资源清单

apiVersion: apps/v1 
kind: DaemonSet 
metadata:
  name: deamonset-test 
  labels:
    app: daemonset
spec:
  selector:
    matchLabels:
      name: dd 
  template:
    metadata:
      labels: 
        name: dd
    spec: 
      containers:
      - name: daemonset-example 
        image: lzw5399/tocgenerator

3.2 其他相关操作

3.2.1 查看daemonset

kubectl get ds

• 由于daemonset会避开有污点的节点，所以daemonset默认不会往主节点调度pod

• 下面的截图是去除了master的污点的情况下，daemonset往主节点调度的情形

4. Job

4.1 Job资源清单

apiVersion: batch/v1 
kind: Job 
metadata:
  name: pi
spec:
  template:
    metadata:
      name: pi
    spec:
      containers:
      - name: pi 
        image: lzw5399/tocgenerator
        command: ["echo","doneee!!!!"]
      restartPolicy: Never # job的policy建议用Never，不会丢失日志。如果是OnFailure，一旦达到backoffLimit，运行job的容器将被终止。这会使调试job更加困难
  backoffLimit: 4 # 如果job失败，最多的重试次数，默认为6
  activeDeadlineSeconds: 100 # job运行的时间限制，包括失败后启动其他pod继续运行的时间，优先级大于backoffLimit

4.2 其他操作

4.2.1 查看job

kubectl get job

可以看到需要完成次数是1，已完成是0

4.2.2 job出现错误的情况

• 可以看到，由于我们的job有错误无法完成执行，所以k8s会重复地执行该job，知道执行完成或者达到重试次数

默认重试次数是6

4.2.3 job成功运行的情况

• job完成后，不会再创建其他Pod，但是Pod也不会被删除，而是状态变为completed

5. CronJob

5.1 CronJob资源清单

apiVersion: batch/v1beta1 
kind: CronJob 
metadata:
  name: he11o 
spec:
  schedule: "*/1 * * * *" # 1分钟执行一次
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: lzw5399/tocgenerator 
            command: # 输出当前时间和hello
            - /bin/sh 
            - -c 
            - date;echo Hello from the Kubernetes cluster 
          restartPolicy: OnFailure

5.2 CronJob Spec

1. spec.template格式同Pod
2. RestartPolicy仅支持Never或OnFailure
3. 单个Pod时，默认Pod成功运行后Job即结束·
4. spec.completions标志Job结束需要成功运行的Pod个数，默认为1·
5. spec.parallelism标志并行运行的Pod的个数，默认为1
6. spec.activeDeadlineSeconds标志失败Pod的重试最大时间，超过这个时间不会继续重试
7. spec.schedule：调度，必需字段，指定任务运行周期，格式同 Cron·
8. spec.jobTemplate:Job模板，必需字段，指定需要运行的任务，格式同Job
9. spec.startingDeadlineSeconds:启动Job的期限（秒级别），该字段是可选的。如果因为任何原因而错过了被调度的时间，那么错过执行时间的Job将被认为是失败的。如果没有指定，则没有期限
10. spec.concurrencyPolicy:并发策略，该字段也是可选的。它指定了如何处理被 Cron Job创建的Job的并发执行。只允许指定下面策略中的一种：

• Allow（默认）：允许并发运行Job
• Forbid：禁止并发运行，如果前一个还没有完成，则直接跳过下一个
• Replace：取消当前正在运行的Job，用一个新的来替换

注意，当前策略只能应用于同一个CronJob创建的Job。如果存在多个Cron Job，它们创建的Job之间总是允许并发运行。

11. spec.suspend：挂起，该字段也是可选的。如果设置为true，后续所有执行都会被挂起。它对已经开始执行的Job不起作用。默认值为false。
12. spec.successfulJobsHistoryLimit和spec.failed]obsHistoryLimit:历史限制，是可选的字段。它们指定了可以保留多少完成和失败的Job。默认情况下，它们分别设置为3和1。设置限制的值为1，相关类型的Job完成后将不会被保留。

5.3 CronJob的限制

1. 创建Job操作应该是幂等的
2. CronJob并不太好去判断任务是否成功，CronJob通过创建Job去完成任务，Job成功与否可以判断，但CronJob无法链接到Job去获取成功与否，Cron只会定期的去创建Job，仅此而已。