kubernetes应用类型

kubernetes在最新的版本里面支持多种类型的服务的创建．比如deployment, job, cronjob,不同应用类型有什么区别，以及如何去选择正确的应用类型来创建应用．

Deployment

Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController来方便的管理应用。主要针对于无状态应用，可以实现：
1. 定义Deployment来创建Pod和ReplicaSet
2. 滚动升级和回滚应用
3. 扩容和缩容(通过HPA根据CPU等指标实现自动扩缩容)
4. 暂停和继续Deployment
一个简单的例子

apiVersion: apps/v1beta1 # for versions before 1.6.0 use extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Job

Job创建一个或多个pod，并确保其指定数量的成功终止。 随着pod成功完成，Job将跟踪Pod是否成功的完成。 当达到指定数量的成功完成时，Job本身就完成了。 删除Job时候指定级联删除将清除其创建的pod。
Job可用于并行运行多个pod，存在三种主要类型的jobs
1. 非并行Job

通常只有一个pod启动，除非pod失败。
一旦Pod成功完成，Job就会完成。

2. 具有固定完成数量的并行Job：

1. 在定义Job的时候设置.spec.completions指定一个非零的正值。
2. 创建多个pod, 1到.spec.completions之间的pod都成功的完成，Job完成。

3. 具有工作队列的并行Job：

1. 不要指定.spec.completions，默认为.spec.Parallelism。 -
2. Pod必须与自己或外部服务进行协调，以确定每个应该工作的Job。
3. 每个pod独立地能够确定其所有对等体是否完成，从而完成整个Job。
4. 当任何pod成功终止时，不会创建新的pod。
5. 一旦至少一个pod已经成功终止，并且所有pod都被终止，则该Job完成成功。

Job适用于处理批处理的任务,运行一段时间已完成所处理的任务，例如并行计算和备份操作，Job会持续监控Pod是否完成．

一个简单的例子

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

CronJob

CronJob管理基于时间的Job，比如：在指定的时间点执行的任务或者需要指定的时间点反复执行的定时任务

一个CronJob对象就像一个crontab（cron表）文件的一行。 它以给定的时间表定期运行，以Cron格式写入。
典型的用例是：
１. 在给定时间点安排Job执行。
2. 创建定期工作，例如 数据库备份，发送电子邮件

apiVersion: batch/v2alpha1
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 Kubernetes cluster
          restartPolicy: OnFailure

Daemonset

DaemonSet确保所有（或某些）节点运行pod的副本。 随着节点被添加到集群，pod被添加到它们。 当从集群中删除节点时，这些pod被垃圾回收。 删除DaemonSet将清理它创建的pod。
DaemonSet的一些典型用途是：
1. 在每个节点上运行集群存储守护程序，如glusterd，ceph。
2. 在每个节点上运行日志收集守护进程，如fluentd或logstash。
3.在每个节点上运行节点监视守护程序，如Prometheus Node Exporter，collectd，Datadog Agent，New Relic Agent或Ganglia gmond。

在一个简单的情况下，覆盖所有节点的一个DaemonSet将用于每种类型的守护进程。 一个更复杂的设置可能会使用多种DaemonSets作为一种类型的守护进程，但对不同的硬件类型使用不同的flag和设置不同的内存和cpu请求

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      containers:
      - name: fluentd-elasticsearch
        image: gcr.io/google-containers/fluentd-elasticsearch:1.20
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers
  

StatefulSets

与Deployment一样，StatefulSets可以管理基于相同容器规范的Pod。 然而，尽管他们的规格是一样的，但是statefulsets中的pod不可互换。 每个Pod都有一个永久标识符，如果发生重新调度该标识符也不会发生变化,是为有状态应用来设计的．
有状态应用拥有以下特点：
1. 稳定唯一的网络标识：Pod重新调度后，podName和hostName等信息保持不变
2. 稳定的持久化存储：Pod通过PVC来使用持久化存储，重新调度后，仍然能够访问之前的持久化数据．
3. 有序优雅的部署和扩展：pod是有序创建和扩展，在下一个pod创建的时候，之前创建的pod都是运行中的．
4. 有序优雅的删除和终止：statefulsets关联的pod，是根据创建pod的顺序相反依次进行删除．
6. 有序的自动滚动更新：pod更新是有序进行更新．
例子

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
   

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: gcr.io/google_containers/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