副本机制和其他控制器

每个节点上运行一个pod

pod执行系统级别的与基础结构相关的操作，比如希望在每个节点上运行日志收集器和资源监控器时需要每个节点上都运行一个这样的pod

使用DaemonSet在每个节点上运行一个pod

DaemonSet对象没有期望副本数的概念，它的工作是确保一个pod匹配它的选择器并在每个节点上运行，DaemonSet创建的pod，已经有一个指定的目标节点并跳过Kubernetes调度器，不是随机分配在集群上。

使用DaemonSet在特定节点上运行pod

DaemonSet可以通过在pod模板中的nodeSelector属性指定pod要运行的节点，即使节点设置为不可调度，因为DaemonSet管理的pod完全绕过调度器。

创建DaemonSet

1. 创建一个DaemonSet YAML文件

    apiVersion: apps/v1beta2 #DaemonSet在apps的API组中，版本是v1beta2
    kind: DaemonSet          #定义类型
    metadata:
        name: ssd-monitor    #DaemonSet名
    spec:
        selector:
            matchLabels:
                app: ssd-monitor  #定义匹配pod标签选择器
        template:
            metadata:
                labels:
                    app: ssd-monitor #pod标签
            spec:
                nodeSelector:
                    disk: ssd   #节点选择器
                containers:
                -   name: main  #容器名
                    image: luksa/ssd-monitor #指定pod运行镜像

2. 创建DaemonSet

    kubectl create -f ssd-monitor-daemonset.yaml

3. 查看创建的DaemonSet

    kubectl get ds

节点添加标签

1. 查询所有节点

    kubectl get nods

2. 给节点添加标签

    kubectl label node 节点名 disk=ssd

3. 查看DaemonSet在节点上创建pod

    kubectl get po

4. 修改节点标签

    kubectl label node 节点名 disk=hdd --overwrite

5. DaemonSet将从该节点终止pod

    kubectl get po

执行单个任务的pod

在一个可完成任务中，进程终止后，不应该再重新启动，不同于ReplicationController、ReplicaSet和DaemonSet会持续运行任务，没有完成状态。

Job资源简介

Kubernetes通过Job资源提供了对可完成任务的支持。Job资源允许你运行一种pod，该pod在内部进程成功结束时，不重启容器，一旦任务完成，pod就被认为处于完成状态。如果节点发生故障，Job管理的pod将按照ReplicaSet的pod方式重新安排在其他节点上，如果该进程本身异常退出，可以将pod配置为重新启动容器。

定义Job资源

    apiVersion: batch/v1    #Job属于batch API组，版本为v1
    kind: Job
    metadata:
        name: batch-job
    spec:
        template:
            metadata:
                labels: 
                    app: batch-job  #指定pod标签（没有指定pod选择器将根据pod模板中的标签创建）
            spec:
                restartPolicy: OnFailure #Job不能使用Always为默认的重新启动策略
                containers:
                -   name: main
                    image: luksa/batch-job

pod通过restartPolicy指定进程结束是Kubernetes会做什么，默认为Always。对于Job资源需明确将重启策略设置为OnFailure或Never

查看Job运行pod

1. 创建Job

    kubectl create -f exporter.yaml

2. 查看Job资源

    kubectl get jobs

3. 查看pod状态

    kubectl get po

pod执行完任务之后将会标记为完成不在出现在pod列表中，可通过–show-all（或-a）查看所有pod
4. 查看执行完成Job日志

    kubectl logs pod名

在Job中运行多个pod实例

Job可以创建多个pod实例，并以并行或串行方式运行

顺序运行pod

需要一个Job运行多次，则可以将completions设置为你希望作业的pod运行多少次

    apiVersion: batch/v1
    kind: Job
    metadata:
        name: multi-completion-batch-job
    spec:
        completions: 5 #串行运行5个pod
        tempalte:
        ....

并行运行Job pod

通过parallelism Job配置属性，指定允许多少个pod并行执行

    apiVersion: batch/v1
    kind: Job
    metadata:
        name: multi-completion-batch-job
    spec:
        completions: 5
        parallelism: 2
        template:
        .....

Job的缩放

在Job运行时可以更改Job的parallelism属性让Job增加或减少pod

    kubectl scale job multi-completion-batch-job --replicas 3

限制Job pod完成任务时间

通过activeDeadlineSeconds属性可以限制pod的时间，如果pod运行时间超过此时间，系统将尝试终止pod，并将Job标记为失败。spec.backoffLimit配置Job被标记为失败后重试次数，默认6次

定期运行或在将来运行一次pod

Kubernetes中的cron任务通过创建CronJob资源进行配置

创建一个CronJob

    apiVersion: batch/v1betal   #API组是batch，版本是v1beta1
    kind: CronJob                   
    metadata:
        name: batch-job-every-fifteen-minutes
    spec:
        schedule: "0,15,30,45 * * * *" #这项任务在每天每小时0、15、30和45分钟运行
        jobTemplate:
            spec:
                template:
                    metadata:
                        labels:
                            app: periodic-batch-job
                    spec:
                        restartPolicy: OnFailure
                        containers:
                        -   name: main
                            image: luksa/batch-job

了解计划任务运行方式

在计划时间内，CronJob资源会创建Job资源，然后Job创建pod。可能存在Job或pod创建并运行相对较晚，可以通过startingDeadlineSeconds字段指定截止日期

    apiVersion: batch/v1beta1
    kind: CronJob
    spec:
        schedule: "0,15,30,45 * * * *"
        startingDeadlineSeconds: 15 #pod最迟必须在预定时间后15秒开始运行

如果任务超过预定时间任务将不会运行，并将显示为Failed。CronJob总是为计划中配置的每个执行创建一个Job，但也可能会同时创建俩个Job，或根本不创建，因此你的任务应该是幂等的，确保下一个任务运行完成本应该由上一次（错过的）运行完成的任何工作