Kubernetes | 运行应用

                         --昨夜西风凋碧树，独上高楼，望尽天涯路

• Deployment

部署一个应用，配置文件如下：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-yml
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx

通过kubectl apply -f nginx.yml运行：

通过kubectl get pod -o wide查看，已经在两个node节点上运行了pod。

1）弹性伸缩

修改配置文件如下：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-yml
spec:
  replicas: 6
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx

目前是两个node节点上各运行一个副本，修改运行副本数后再次执行kubectl apply：

此时已将在原来的基础上动态的增加了4个副本在两个节点上。再次修改配置文件中的replicas为3，执行kubectl apply发现：

可以看到两个副本被删除。

2）Failove

通过在node2虚拟机上执行halt -h模拟node2宕机：

在master上查看node和Pod，发现原先只想在node2上面的两个副本已经标价为Unknown，并且在node1上面生成了两个副本：

重启node2之后再次查看pod发现，Unknown的Pod会被删除，运行在node1的副本不会调度货到node2：

3）label

默认情况下，Scheduler会将Pod调度到所有可用的Node。有时候我们需要根据host的配置以及性能需要将不同的Pod部署到不同的Node

Kubernetes通过label来实现这个功能。label是key-value对，各种资源都可以设置label，灵活添加各种自定义属性。

通过kubectl label node 给node添加label;通过kubectl get node --show-labels查看节点的label

查看node的label发现label已经添加到node中，下面编辑配置文件指定label，运行应用：

此时所有的Pod都部署到了label为cputype=niubi的node节点上

通过kubectl label node 192.168.46.191 cputype-来删除node上面的label（删除label之后部署的副本并不会重新分配，必须修改配置文件，重新kubectl apply才会重新部署Pod）：

• DaemonSet

Deployment部署的Pod会分布在各个Node上，并且每个Node可以同事运行好几个副本。DaemonSet则是每个Node上最多只能运行一个副本

DaemonSet的典型应用场景有：

1）在集群的每个节点上运行存储Daemon，比如glusterd或ceph

2）在每个节点上运行日志收集Daemon，比如flunentd或logstash

3）在每个节点上运行监控Daemon，比如Prometheus Node Exporter或collectd

kubernetes的网络组件flannel实际上就是通过DaemonSet运行的

通过kubectl get daemonset --namespace=kube-system查看：

通过 kubectl edit daemonset kube-flannel-ds --namespace=kube-system查看系统namespace下的kube-flannel-ds的配置文件发现kind类型为DaemonSet：

• Job

容器按照持续运行的时间可分为两类:服务类容器和工作类容器 。

服务类容器通常持续提供服务，需要一直运行，例如Nginx,数据库。

工作类容器是一次性任务，例如批处理程序，完成后程序就退出。

Kubernetes的Deployment、ReplicaSet和DaemonSet都用于管理服务类容器；Job管理工作类容器。

编写一个kind为job的配置文件（restartPolicy指定什么情况下需要重启容器。对于Job，只能设置为Never或者OnFailure。对于其他controller，可以设置为Always）：

kubectl apply该Job：

查看运行Job的信息，发现STATUS已经为completed

通过kubectl logs查看运行中Pod的日志

删除Job：

Job失败后的情况：

修改yml配置文件，引入一个错误之后：

运行应用，并且查看发现SUCCESS数目为0以及STATUS为ContainerCannotRun：

但是为什么kubectl get pod会看到这么多失败的Pod呢？

由于第一个Pod启动时，容器失败退出，根据restartPolicy:Never，此失败容器不会被重启，但Job DESIRED的Pod是1，目前SUCCESSF为0，不满足，所以Job会不断重启新的Pod直到SUCCESS为1。

修改配置文件中的restartPolicy为OnFailure，再启动应用：

查看发现，成功数为0，STATUS为RunContainerError，并且正在不断重启

Job的并行性：

当需要同时运行多个Pod，提高Job的执行效率的时候。可以通过parallelism设置：

apiVersion: batch/v1
kind: Job
metadata:
  name: job
spec:
  parallelism: 2
  template:
    metadata:
      name: job
    spec:
      containers:
      - name: busybox
        image: busybox
        command: ["echo", "我是要成为海贼王的男人"]
      restartPolicy: OnFailure

设置并行数量为2，执行：

Job一共启动了两个Pod，而且AGE相同，并行运行

还可以通过completions设置Job的总数，每次运行两个Pod，直到6个Pod完成：

定时Job：

Kubernetes的CronJob提供了定时任务的功能，配置文件如下

schedule指定每分钟启动一次，jobTemplate定义Job的模板

apiVersion: batch/v2alpha1
kind: CronJob
metadata:
  name: cronJob
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: cronJob
            image: busybox
            command: ["echo", "我是要成为海贼王的男人"]
          restartPolicy: OnFailure

运行发现：

这是由于Kubernetes默认没有开启CronJob，修改kube-apiserver的配置文件/etc/kubernetes/apiserver，kube-apiserver本身也是一个Pod，在启动参数中加上--runtime-config=batch/v2alpha1=true

通过 systemctl restart kube-apiserver重启kube-apiservber，通过kubectl api-versions查看发现已经添加：

再次运行，发现报错：

这是由于配置文件中的name不允许出现大写字母，修改配置文件：

再次启动并查看：

发现每隔一分钟启动一个定时任务，查看log：