kubernetes系列(八)

1. ReplicaSet
- 1.1 ReplicaSet资源清单
- 1.2 selector
2. Deployment
3. DaemonSet
- 3.1 DaemonSet资源清单
- 3.2 其他相关操作
  - 3.2.1 查看daemonset
4. Job
- 4.1 Job资源清单
- 4.2 其他操作
5. 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必须对应起来

验证步骤

显示当前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 回滚

回滚到上一次

kubectl rollout undo deployment/toc-deploy

回滚到指定版本

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

查看回滚的状态

kubectl rollout status deployments toc-deploy

查看可回滚的历史版本

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

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

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

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

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

5.3 CronJob的限制

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