k8s资源类型详解

一、k8s资源类型简介

Deployment、Service、Pod是k8s最核心的3个资源对象。
Deployment:最常见的无状态应用的控制器，支持应用的扩缩容、滚动更新等操作。
Servcie:为弹性变动且存在生命周期的Pod对象提供了一个固定的访问接口，用于服务发现和服务访问。
Pod:是运行容器以及调度的最小单位。同一个Pod可以同时运行多个容器，这些容器共享NET、UTS、IPC。除此之外还有USER、PID、MOUNT。

二、deployment资源类型

创建一个Deployment资源对象，名称为bdqn1，replicas:5个，镜像使用httpd。

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: test1
spec:
  replicas: 5
  template:
    metadata:
      labels:
        app: test1
    spec:
      containers:
      - name: test1
        image: httpd
        ports:
            - containerPort: 80

分析Deployment为什么被称为高级的Pod控制器?

[root@master yaml]# kubectl describe deployments. test1
...
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  3m5s  deployment-controller  Scaled up replica set test1-644db4b57b to 4

注意:events属于事件提示，它描述了整个资源从开始到现在所经历的全部过程。Deployment没有像我们想象中直接创建并控制后端的Pod，而是又创建了一个新的资源对象:ReplicaSet(test1-644db4b57b)。
查看该RS的详细信息，会看到RS整个的Events。

[root@master yaml]# kubectl describe rs test1-644db4b57b
...
Events:
  Type    Reason            Age    From                   Message
  ----    ------            ----   ----                   -------
  Normal  SuccessfulCreate  9m53s  replicaset-controller  Created pod: test1-644db4b57b-4688l
  Normal  SuccessfulCreate  9m53s  replicaset-controller  Created pod: test1-644db4b57b-72vhc
  Normal  SuccessfulCreate  9m53s  replicaset-controller  Created pod: test1-644db4b57b-rmz8v
  Normal  SuccessfulCreate  9m53s  replicaset-controller  Created pod: test1-644db4b57b-w25q8

此时查看任意一个Pod的详细信息，能够看到此Pod的完整的工作流程。

[root@master yaml]# kubectl describe pod test1-644db4b57b-4688l
...
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  11m   default-scheduler  Successfully assigned default/test1-644db4b57b-4688l to node1
  Normal  Pulled     11m   kubelet, node1     Container image "192.168.229.187:5000/httpd:v1" already present on machine
  Normal  Created    11m   kubelet, node1     Created container test1
  Normal  Started    11m   kubelet, node1     Started container test1

三、service资源类型

创建一个Service资源，要求与上述test1进行关联。

kind: Service
apiVersion: v1
metadata:
  name: test-svc
spec:
  selector:
    app: test1
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

默认情况下Service的资源类型Cluster IP，上述YAML文件中，spec.ports.port:描述的是Cluster IP的端口。只是为后端的Pod提供了一个统一的访问入口（在k8s集群内有效）。

[root@master yaml]# kubectl get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP        23d
test-svc     NodePort    10.103.159.206   <none>        80:32767/TCP   6s
[root@master yaml]# curl 10.103.159.206
11111

如果想要让外网能够访问到后端Pod，这里应该将Service的资源类型改为NodePort。

kind: Service
apiVersion: v1
metadata:
  name: test-svc
spec:
  type: NodePort
  selector:
    app: test1
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 32034  #nodePort的有效范围是：30000-32767

上面我们看到了访问Cluster IP ,后端的Pod会轮替着为我们提供服务，也就是有负载均衡，如果没有Service资源，KUBE-PROXY组件也不会生效，因为它就是负责负载均衡，那么现在有了Service资源，它到底是怎么做到负载均衡的？底层的原理是什么？
表面上来看，通过describe命令，查看SVC资源对应的Endpoint，就能够知道后端真正的Pod。

[root@master yaml]# kubectl describe svc test-svc
...
Endpoints:                10.244.1.33:80,10.244.1.34:80,10.244.2.27:80 + 1 more...
...

通过查看iptables规则，可以了解一下具体的负载均衡过程。

[root@master yaml]# kubectl get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP        23d
test-svc     NodePort    10.103.159.206   <none>        80:32767/TCP   8m11s

[root@master yaml]# iptables-save | grep 10.103.159.206
-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.103.159.206/32 -p tcp -m comment --comment "default/test-svc: cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.103.159.206/32 -p tcp -m comment --comment "default/test-svc: cluster IP" -m tcp --dport 80 -j KUBE-SVC-W3OX4ZP4Y24AQZNW
#如果目标地址是10.103.159.206/32的80端口，并且走的是TCP协议，那么就把这个流量跳转到KUBE-SVC-W3OX4ZP4Y24AQZNW

[root@master yaml]# iptables-save | grep KUBE-SVC-W3OX4ZP4Y24AQZNW
-A KUBE-SVC-W3OX4ZP4Y24AQZNW -m statistic --mode random --probability 0.25000000000 -j KUBE-SEP-UNUAETQI6W3RVNLM
-A KUBE-SVC-W3OX4ZP4Y24AQZNW -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-QNYBCG5SL7K2IM5K
-A KUBE-SVC-W3OX4ZP4Y24AQZNW -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-NP7BZEGCZQZXEG4R
-A KUBE-SVC-W3OX4ZP4Y24AQZNW -j KUBE-SEP-5KNXDMFFQ4CLBFVI

[root@master yaml]# iptables-save | grep KUBE-SEP-UNUAETQI6W3RVNLM
:KUBE-SEP-UNUAETQI6W3RVNLM - [0:0]
-A KUBE-SEP-UNUAETQI6W3RVNLM -s 10.244.1.33/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-UNUAETQI6W3RVNLM -p tcp -m tcp -j DNAT --to-destination 10.244.1.33:80
-A KUBE-SVC-W3OX4ZP4Y24AQZNW -m statistic --mode random --probability 0.25000000000 -j KUBE-SEP-UNUAETQI6W3RVNLM

参数解释

SNAT:Source NAT(源地址转换);

DNAT:Destination NAT(目标地址转换);

MASQ:动态的源地址转换;

Service实现的负载均衡:默认使用的是iptables规则;

四、k8s资源的回滚操作

准备3个版本所使用的私有镜像，来模拟每次升级不同的镜像。

[root@master yaml]# vim test1.yaml
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: test1
spec:
  replicas: 4
  template:
    metadata:
      labels:
        test: test
    spec:
      containers:
      - name: test1
        image: 192.168.229.187:5000/httpd:v1
[root@master yaml]# vim test2.yaml
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: test1
spec:
  replicas: 4
  template:
    metadata:
      labels:
        test: test
    spec:
      containers:
      - name: test1
        image: 192.168.229.187:5000/httpd:v2
[root@master yaml]# vim test3.yaml
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: test1
spec:
  replicas: 4
  template:
    metadata:
      labels:
        test: test
    spec:
      containers:
      - name: test1
        image: 192.168.229.187:5000/httpd:v3

此处3个yaml文件指定不同版本的镜像。
运行一个服务，并记录一个版本信息。

[root@master yaml]# kubectl apply -f test1.yaml --record

查看有哪些版本信息

[root@master yaml]# kubectl rollout history deployment test1
deployment.extensions/test1
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=test1.yaml --record=true

运行并升级Depoyment资源，并记录版本信息。

[root@master yaml]# kubectl apply -f test2.yaml --record
[root@master yaml]# kubectl apply -f test3.yaml --record

把test1的版本进行升级

[root@master yaml]# kubectl set image deploy test1 test1=192.168.229.187:5000/httpd:v2

此时可以运行一个关联的Service资源去做验证，升级是否成功。

[root@master yaml]# kubectl apply -f test-svc.yaml
[root@master yaml]# kubectl get deployments. test1 -o wide

回滚到指定版本

[root@master yaml]# kubectl rollout undo deployment test1 --to-revision=1

五、用label控制pod的位置

添加节点标签

[root@master yaml]# kubectl label nodes node2 disk=ssd
node/node2 labeled
[root@master yaml]# kubectl get nodes --show-labels

删除节点标签

[root@master yaml]# kubectl label nodes node2 disk-
 ...
spec:
  revisionHistoryLimit: 10
  replicas: 3
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: test-web
        image: 192.168.1.10:5000/httpd:v1
        ports:
        - containerPort: 80
        nodeSelector:  #添加节点选择器
        disk: ssd  #和标签内容一致

六、namespace简介

默认的名称空间:Default
查看名称空间

[root@master yaml]# kubectl get ns
NAME              STATUS   AGE
default           Active   25d
kube-node-lease   Active   25d
kube-public       Active   25d
kube-system       Active   25d
test              Active   22m

查看名称空间详细信息

[root@master yaml]# kubectl describe ns default
Name:         default
Labels:       <none>
Annotations:  <none>
Status:       Active

No resource quota.

No resource limits.

创建名称空间

[root@master yaml]# kubectl create ns test
[root@master yaml]# vim test.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: test

注意:namespace资源对象仅用于资源对象的隔离，并不能隔绝不同名称空间的Pod之间的通信，那是网络策略资源的功能。
查看指定名称空间的资源可以使用–namespace或者-n选项

[root@master yaml]# kubectl get pod -n test
NAME   READY   STATUS    RESTARTS   AGE
test   1/1     Running   0          28m

删除某个名称空间

[root@master yaml]# kubectl delete ns test

注意:在执行删除某个名称空间的时候，千万注意，轻易不执行此操作。如果执行之后，默认会将所在此名称空间之下资源全部删除。

七、pod资源类型

1.利用yaml文件创建pod资源

[root@master yaml]# vim pod.yaml
kind: Pod
apiVersion: v1
metadata:
  name: test-pod
spec:
  containers:
  - name: test-app
    image: httpd

单个pod运行多个容器

[root@master yaml]# vim pod.yaml
kind: Pod
apiVersion: v1
metadata:
  name: test-pod
spec:
  containers:
  - name: test-app
    image: httpd
    
  - name: test-web
    image: busybox

2.Pod中镜像获取策略
将上述Pod资源的镜像下载策略改为IfNotPresent。

[root@master yaml]# vim pod.yaml
kind: Pod
apiVersion: v1
metadata:
  name: test-pod
spec:
  containers:
  - name: test-app
    image: httpd
    imagePullPolicy: IfNotPresent

k8s默认根据镜像的TAG的不同，有3中不同策略。

Always:镜像标签为"latest"或镜像标签不存在时，总是从指定的仓库(默认的官方仓库、或者私有仓库)中获取最新镜像。

IfNotPresent:仅当本地镜像不存在时才从目标仓库中下载。也就意味着，如果本地存在，直接使用本地镜像，无需再联网下载。

Never:禁止从仓库中下载镜像，即只使用本地镜像。

注意:对于标签为“latest”或者这标签不存在，其默认镜像下载策略为“Always”,而对于其他标签的镜像，默认则使用了“IfNotPresent”。
上述语句中提到的"本地"是指:docker images命令能够给查看到的镜像。
3.容器的重启策略
将上述Pod资源添加重启策略为OnFailure。

[root@master yaml]# vim pod.yaml
kind: Pod
apiVersion: v1
metadata:
  name: test-pod
spec:
  restartPolicy: OnFailure
  containers:
  - name: test-app
    image: httpd
    imagePullPolicy: IfNotPresent

策略如下:

Always:但凡Pod对象终止就将其重启，此为默认设定;

OnFailure:仅在Pod对象出现错误时才将其重启;

Never:从不重启;

简便方法:
同一个yaml文件内，可以同时存在多种资源对象，但最好是同一个服务相关的资源。并且在写的时候，不同的资源需要用“—”将资源隔离。其实默认是一个资源的yaml，最上方也有“—"不过是通常会省略不写。

[root@master yaml]# vim pod.yaml
---
apiVersion: v1
kind: Namespace
metadata:
  name: test
---
kind: Pod
apiVersion: v1
metadata:
  name: test-pod
  namespace: test
spec:
  restartPolicy: OnFailure
  containers:
  - name: test-app
    image: httpd
    imagePullPolicy: IfNotPresent

4.Pod的默认健康检查
根据Pod的默认重启策略，对Pod进行健康检查

[root@master yaml]# vim pod.yaml
kind: Pod
apiVersion: v1
metadata:
  name: healthcheck
  namespace: test
spec:
  restartPolicy: OnFailure
  containers:
  - name: test-app
    image: httpd
    imagePullPolicy: IfNotPresent
    args:
    - sh
    - -c
    - sleep 10; exit 1

监控pod的运行状态

[root@master yaml]# kubectl get pod -n test -w

如果此时我们将退出状态码改为0，也就是正常退出，仍使用OnFailure策略，但它就不会重启Pod了。

[root@master yaml]# vim pod.yaml
kind: Pod
apiVersion: v1
metadata:
  name: healthcheck
  namespace: test
spec:
  restartPolicy: OnFailure
  containers:
  - name: test-app
    image: httpd
    imagePullPolicy: IfNotPresent
    args:
    - sh
    - -c
    - sleep 10; exit 0

监控pod的运行状态

[root@master yaml]# kubectl get pod -n test -w

5.livenessprobe(活跃度、存活性)

kind: Pod
apiVersion: v1
metadata:
  name: liveness
  labels:
    test: liveness
spec:
  restartPolicy: OnFailure
  containers:
  - name: liveness
    image: busybox
    args:
    - sh
    - -c
    - touch /tmp/test; sleep 30; rm -rf /tmp/test; sleep 300
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/test
      initialDelaySeconds: 10  #pod运行10秒后开始探测
      periodSeconds: 5  #每5秒探测一次

注意:Liveness活跃度探测，根据探测某个文件是否存在，来确认某个服务是否正常运行，如果存在则正常，否则，它会根据你设置的Pod的重启策略操作Pod。
6.readiness(敏捷探测、就绪性探测)

kind: Pod
apiVersion: v1
metadata:
  name: readiness
  labels:
    test: readiness
spec:
  restartPolicy: OnFailure
  containers:
  - name: readiness
    image: busybox
    args:
    - sh
    - -c
    - touch /tmp/test; sleep 30; rm -rf /tmp/test; sleep 300
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/test
      initialDelaySeconds: 10
      periodSeconds: 5

注意

(1)liveness和readiness是两种健康检查机制，如果不特意配置，k8s将两种探测采取相同的默认行为，即通过判断容器启动进程的返回值是否为零，来判断探测是否成功。

(2)两种探测配置方法完全一样，不同之处在于探测失败后的行为：
liveness探测是根据Pod重启策略操作容器，大多数是重启容器;
readiness则是将容器设置为不可用，不接收Service转发的请求;

(3)两种探测方法可以独立存在，也可以同时使用。
用liveness判断容器是否需要重启实现自愈；
用readiness判断容器是否已经准备好对外提供服务;

八、健康检测的相关应用

1.在扩容中的应用

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: web
spec:
  replicas: 5
  template:
    metadata:
      labels:
        run: web
    spec:
      containers:
      - name: web
        image: httpd
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            scheme: HTTP
            path: /healthy
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 5
---
kind: Service
apiVersion: v1
metadata:
  name: web-svc
spec:
  type: NodePort
  selector:
    run: web
  ports:
  - protocol: TCP
    port: 90
    targetPort: 80
    nodePort: 30321

总结:服务扩容中，如果没有针对性就绪探测，往往扩容之后，表面看Pod的状态是没有问题的，但其实Pod内的服务是否运行正常也是我们要关注的，而Readiness的关注点就在这，如果Pod内的服务运行有问题，那么，这些新扩容的Pod就不会被添加到Service资源的转发中，从而保证用户能够有最起码正常的服务体验。
2.在更新过程中的应用

[root@master yaml]# vim update1.yaml
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: update
spec:
  replicas: 10
  template:
    metadata:
      labels:
        app: update
    spec:
      containers:
      - name: update
        image: 192.168.229.187:5000/httpd:v1
        args:
        - sh
        - -c
        - sleep 10; touch /tmp/health; sleep 300
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/health
          initialDelaySeconds: 10
          periodSeconds: 5

复制update1的yaml文件，命名update2.yaml,并更改镜像和args的命令部分，这里我们确定，更新肯定会失败，因为它没有符合readiness探测文件。

[root@master yaml]# vim update2.yml
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: update
spec:
  replicas: 10
  template:
    metadata:
      labels:
        app: update
    spec:
      containers:
      - name: update
        image: 192.168.229.187:5000/httpd:v2
        args:
        - sh
        - -c
        - sleep 300
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/health
          initialDelaySeconds: 10
          periodSeconds: 5

在更新的过程中，Readiness探测同样重要，想象一下，如果更新完成的Pod内没有更新的内容，并且也没有相对应的探测，那么有可能我们更新的Pod全部都会是不可用的。
其实在更新过程中，为了保证，即使更新失败，至少也有相对数量的副本数量仍能正常提供服务，其实是有数值可以设置的。

maxSurge:此参数控制滚动更新过程中，副本总数超过预期数的值。可以是整数，也可以是百分比，默认是1。
maxUnavailable:不可用Pod的值。默认为1。可以是整数，也可以是百分比。

测试题:
在更新过程中，期望的Replicas值为10个，更改rollingupdate策略，要求在更新过程中，最大不可用Pod的值为4个，允许同时出现的Pod的总数量为13个。

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: update
spec:
  strategy:
    rollingUpdate:
      maxSurge: 3
      maxUnavailable: 4
  replicas: 10
  template:
    metadata:
      labels:
        app: update
    spec:
      containers:
      - name: update
        image: 192.168.229.187:5000/httpd:v2
        args:
        - sh
        - -c
        - sleep 300
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5

九、ReplicaSet的相关介绍

Deployment是一种高级的Pod控制器，这种高级Pod控制器，并不是像想象中直接管理后端的Pod，而是又创建了RS这种Pod控制器，然后由RS控制后端的Pod，那么为什么这么做？因为RS资源并不支持滚动更新策略。
RC:Replication Controller（老一代的Pod控制器）
用于确保由其管控的Pod对象副本数量，能够满足用户期望，多则删除，少则通过模板创建。
特点

确保Pod资源对象的数量精准;

确保Pod健康运行;

弹性伸缩;

同样它也可以通过yaml或json格式的资源清单来创建。其中spec字段一般嵌套以下字段。

replicas:期望的Pod对象副本数量;

selector:当前控制器匹配Pod对象副本的标签选择器;

template:Pod副本的模板;

与RC相比而言，RS不仅支持基于等值的标签选择器，而且还支持基于集合的标签选择器。
1.labels与selector的关系
(1)现在有一个Pod资源，且是拥有2个标签。还有svc资源，selector选择器，仅有一个符合。

kind: Pod
apiVersion: v1
metadata:
  name: pod1
  labels:
    test: web
    app: httpd
spec:
  containers:
  - name: pod1
    image: httpd
---
kind: Service
apiVersion: v1
metadata:
  name: test-svc1
spec:
  selector:
    app: httpd
  ports:
  - port: 80

svc资源是否能成功的关联到上述的Pod资源？
(2)现在有一个Pod资源，且是拥有1个标签。还有svc资源，selector选择器，需要2个满足条件。

kind: Pod
apiVersion: v1
metadata:
  name: pod1
  labels:
    test: web
spec:
  containers:
  - name: pod1
    image: httpd
---
kind: Service
apiVersion: v1
metadata:
  name: test-svc1
spec:
  selector:
    app: httpd
    test: web
  ports:
  - port: 80

svc资源是否能成功的关联到上述的Pod资源？
结论:selector是拥有选择权的，而labels只能够被选择，所以labels必须全部满足selector的要求，才能被匹配。
常用标签
标签:解决同类型的资源对象越来越多，为了更好的管理，按照标签分组。
常用标签分类

release(版本):stable(稳定版)、canary(金丝雀版本)、beta(测试版);

environment(环境变量):dev(开发)、qa(测试)、production(生产);

application(应用):ui、as(application software应用软件)、pc、sc;

tier(架构层级):frontend(前端)、backend(后端)、cache(缓存);

partition(分区):customerA(客户A)、customerB(客户B);

track(品控级别):daily(每天)、weekly(每周);

示例:写一个Pod的yaml文件。

kind: Pod
apiVersion: v1
metadata:
  name: pod-labels
  labels:
    env: qa
    tier: frontend
spec:
  containers:
  - name: myapp
    image: httpd

通过下面命令显示资源对象的标签

[root@master ~]# kubectl get pod --show-labels

通过-l查看仅包含某个标签的资源

[root@master ~]# kubectl get pod -l env

给pod资源添加标签

[root@master ~]# kubectl label pod pod-labels release=v1
[root@master ~]# kubectl get pod pod-labels --show-labels

删除标签

[root@master ~]# kubectl label pod pod-labels release-

修改标签

[root@master ~]# kubectl label pod pod-labels env=dev --overwrite
[root@master ~]# kubectl get pod -l tier --show-labels

如果标签有多个，标签选择器选择其中一个，也可以关联成功。相反，如果选择器有多个，那么标签必须完全满足条件，才可以关联成功。
2.标签选择器
标签的查询过滤条件。

基于等值关系(equality-based)："="，"==","！="前边两个都是相等，最后是不等;

基于集合关系(set-based)："in"、"notin"、"exists"三种;

示例:

pod	标签
pod1	app: nginx、name: zhangsan、age: 18
pod2	app: nginx、name: lisi、age: 20
pod3	name: wangwu、age: 30

...
selector:
  matchLabels:
    app: nginx
  matchExpressions:
  #pod中有name这个关键字的，并且对应的值是:zhangsan或者lisi，那么此处会关联到Pod1、Pod2
    - {key: name,operator: In,values: [zhangsan,lisi]}
  #所有关键字是age的，并且忽略它的值，都会被选中，此处会关联到Pod1、Pod2、Pod3 
    - {key: age,operator: Exists,values:}
...

matchLabels:指定键值对表示的标签选择器;

matchExpressions:基于表达式来指定的标签选择器;

选择器列表间为“逻辑与”关系;使用In或者NotIn操作时，其values不强制要求为非空的字符串列表，而使用Exists或DostNotExist时，其values必须为空。
3.使用标签选择器的逻辑

1.同时指定的多个选择器之间的逻辑关系为“与“操作;

2.使用空值的标签选择器意味着每个资源对象都将被选择中;

3.空的标签选择器无法选中任何资源;

十、DaemonSet资源类型

它也是一种Pod控制器。
特点:它会在每一个Node节点上都会生成并且只能生成一个Pod资源。
使用场景:如果必须将Pod运行在固定的某个或某几个节点，且要优先于其他Pod的启动。通常情况下，默认每一个节点都会运行，并且只能运行一个Pod。这种情况推荐使用DaemonSet资源对象。
监控程序;
日志收集程序；
运行一个web服务，在每一个节点都运行一个Pod。

kind: DaemonSet
apiVersion: extensions/v1beta1
metadata:
  name: test-ds
spec:
  template:
    metadata:
      labels:
        name: test-ds
    spec:
      containers:
      - name: test-ds
        image: httpd

RC、RS、Deployment、DaemonSet都是Pod控制器。–> Controllermanager(维护集群状态，保证Pod处于期望的状态。)

十一、job资源对象

服务类的Pod容器:RC、RS、DS、Deployment.(Pod内运行的服务，要持续运行);

工作类的Pod容器:Job--->执行一次或者批量执行处理程序，完成就会退出容器;

1.编写一个job.yaml文件

[root@master ~]# vim job.yaml
kind: Job
apiVersion: batch/v1
metadata:
  name: test-job
spec:
  template:
    metadata:
      name: test-job
    spec:
      containers:
      - name: hello
        image: busybox
        command: ["echo","hello k8s job!"]
      restartPolicy: Never

注意:如果容器内执行任务有误，会根据容器的重启策略操作容器，不过这里的容器重启策略只能是：Never和OnFailure。
2.提高Job的执行效率
我们可以在Job.spec字段下加上parallelism选项。表示同时运行多少个Pod执行任务。
我们可以在Job.spec字段下加上completions选项。表示总共需要完成Pod的数量。
举例将上述Job任务进行更改。提示，更改Job任务的时候，需要先将原来的Job资源对象删除。

[root@master ~]# vim job.yaml
kind: Job
apiVersion: batch/v1
metadata:
  name: test-job
spec:
  parallelism: 2
  completions: 8
  template:
    metadata:
      name: test-job
    spec:
      containers:
      - name: hello
        image: busybox
        command: ["echo","hello k8s job!"]
      restartPolicy: Never

job的作用和之前提到的at命令有些相似，在K8s集群中，如果需要用到运行一次性工作任务的需求，可以考虑job资源对象。下面的cronjob和之前的crontab也是十分相似。

十二、CronJob资源类型

1.如何定时执行Job
编写一个cronjob.yaml文件

[root@master ~]# vim cronjob.yaml
kind: CronJob
apiVersion: batch/v1
metadata:
  name: test-cronjob
spec:
  schedule: "*/1 * * * *"  #分、时、日、月、周
  jobTemplate:
  spec:
    template:
      spec:
        containers:
        - name: hello
          image: busybox
          command: ["echo","hello cronjob!"]
        restartPolicy: Never

此时查看Pod的状态，会发现每分钟都会运行一个新的Pod来执行命令规定的任务。
注意:如果规定具体时间，可能并不会执行任务。cronjob资源对象，开发还未完成此功能。
2.添加apiVersion库

[root@master job]# vim /etc/kubernetes/manifests/kube-apiserver.yaml
在yaml文件中command指令下添加
- --runtime-config=batch/v2alpha1=true

重启kubelet服务，重新识别api yaml文件内容即可。
查看api版本库

[root@master job]# kubectl api-versions

注意:此时仍然不能正常运行指定时间的CronJob，这是因为K8s官方在cronjob这个资源对象的支持中还没有完善此功能，还待开发。
跟Job资源一样在cronjob.spec.jobTemplate.spec下同样支持并发Job参数:parallelism，也支持完成Pod的总数参数:completions。