k8s(5)—— Pod控制器

Pod控制器目录：

一、ReplicaSet

• 1、ReplicaSet简介
• 2、实验环境的创建
• 3、创建ReplicaSet控制器
• 4、扩容
• 5、rs只控制文件中定义的标签的名称

二、Deployment控制器

• 1、Deployment简介
• 2、清空实验环境
• 3、创建 Deployment
• 4、拉伸
• 5、更新 Deployment
• 6、回滚 Deployment   

三、DaemonSet控制器

• 1、DaemonSet简介
• 2、实验准备
• 3、创建DaemonSet控制器

四、Job控制器

• 1、实验环境的部署
• 2、创建Job控制器

五、CronJob控制器

• 1、CronJob的简介
• 2、创建CronJob、测试

官网信息：https://kubernetes.io/zh/docs/concepts/containers/

 

 

一、ReplicaSet

• 1、ReplicaSet简介
• 2、实验环境的创建
• 3、创建ReplicaSet控制器
• 4、扩容
• 5、rs只控制文件中定义的标签的名称

1、ReplicaSet简介

ReplicaSet 是下一代的 Replication Controller。 ReplicaSet 和 Replication Controller 的唯一区别是选择器的支持。ReplicaSet 支持新的基于集合的选择器需求，这在标签用户指南中有描述。而 Replication Controller 仅支持基于相等选择器的需求。

怎样使用 ReplicaSet

大多数支持 Replication Controllers 的kubectl命令也支持 ReplicaSets。但rolling-update 命令是个例外。如果您想要滚动更新功能请考虑使用 Deployment。rolling-update 命令是必需的，而 Deployment 是声明性的，因此我们建议通过 rollout命令使用 Deployment。

虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制。 当您使用 Deployment 时，您不必担心还要管理它们创建的 ReplicaSet。Deployment 会拥有并管理它们的 ReplicaSet。
什么时候使用 ReplicaSet

ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。 然而，Deployment 是一个更高级的概念，它管理 ReplicaSet，并向 Pod 提供声明式的更新以及许多其他有用的功能。 因此，我们建议使用 Deployment 而不是直接使用 ReplicaSet，除非需要自定义更新业务流程或根本不需要更新。

这实际上意味着，我们可能永远不需要操作 ReplicaSet 对象：而是使用 Deployment，并在 spec 部分定义应用。

与所有其他 Kubernetes API 对象一样，ReplicaSet 也需要 apiVersion、kind、和 metadata 字段。有关使用清单的一般信息，参见 使用 kubectl 管理对象。

Deployment 是一个高级 API 对象，它以 kubectl rolling-update 的方式更新其底层副本集及其Pod。 如果您需要滚动更新功能，建议使用 Deployment，因为 Deployment 与 kubectl rolling-update 不同的是：它是声明式的、服务器端的、并且具有其他特性。 有关使用 Deployment 来运行无状态应用的更多信息，请参阅 使用 Deployment 运行无状态应用。
裸 Pod

与用户直接创建 Pod 的情况不同，ReplicaSet 会替换那些由于某些原因被删除或被终止的 Pod，例如在节点故障或破坏性的节点维护（如内核升级）的情况下。 因为这个好处，我们建议您使用 ReplicaSet，即使应用程序只需要一个 Pod。 想像一下，ReplicaSet 类似于进程监视器，只不过它在多个节点上监视多个 Pod，而不是在单个节点上监视单个进程。 ReplicaSet 将本地容器重启的任务委托给了节点上的某个代理（例如，Kubelet 或 Docker）去完成对于管理那些提供主机级别功能（如主机监控和主机日志）的容器，就要用DaemonSet 而不用 ReplicaSet。 这些 Pod 的寿命与主机寿命有关：这些 Pod 需要先于主机上的其他 Pod 运行，并且在机器准备重新启动/关闭时安全地终止

官网链接：https://kubernetes.io/zh/docs/concepts/workloads/controllers/

正文：

再官网上查看相关的文档

、

1、实验环境的创建 ：

1.1、在私有仓库的管理节点上搜索myapp镜像（管理节点上事先配有阿里云的镜像加速器）

1.2、拉取myapp

1.3、关于myapp的测试

myapp是一个测试软件

[root@reg ~]# docker run -d --name vm1 ikubernetes/myapp:v1      ##运行mypp容器
ee9be03318e354caf3717dc3f0e1ff28b6a594d9900773c8909b535fa1e1715d
[root@reg ~]#
[root@reg ~]# docker inspect vm1                                  ##查看vm1的信息

[

测试：

 2、创建ReplicaSet控制器
 

[kubeadm@server1 ~]$ \vi rs-example.yaml        ##复制粘贴的时候格式对

apiVersion: apps/v1                  ##控制器的版本
kind: ReplicaSet                     ##控制器的类型 
metadata:
  name: replicaset-example           ##控制器的名称
spec:
  replicas: 3                        ##副本数为3这些pod由集群自动取分配给哪个节点 
  selector:
    matchLabels:
      app: nginx                     ##标签
  template:                          ##模板
    metadata:                        ##pod数据类型
      labels:
        app: nginx                   ##标签
    spec:
      containers:                    ##pod容器
      - name: myapp                  ##名称
        image: myapp                 ##镜像

2.2、测试：

[kubeadm@server1 ~]$ kubectl create -f rs-example.yaml         ##创建并管理副本
 
[kubeadm@server1 ~]$ kubectl get pod                           ##查看pod副本
NAME                       READY   STATUS    RESTARTS   AGE
replicaset-example-7fp87   1/1     Running   0          2m1s
replicaset-example-krp4s   1/1     Running   0          2m
replicaset-example-pcwc9   1/1     Running   0          2m
[kubeadm@server1 ~]$


[kubeadm@server1 ~]$ kubectl get pod -o wide       ## 每个pod对应一个网络和节点

curl 10.244.1.23/hostname.html                      ##访问到的是对应的ip

2.3、每个pod对应一个网络和一个节点

（通过IP可以访问dao myapp的版本号）

3、扩容

只需修改文件中副本的个数

apiVersion: apps/v1                  ##控制器的版本
kind: ReplicaSet                     ##控制器的类型
metadata:
  name: replicaset-example           ##控制器的名称
spec:
  replicas: 6                        ##副本数为6这些pod由集群自动取分配给哪个节点
  selector:
    matchLabels:
      app: nginx                     ##标签
  template:                          ##模板
    metadata:                        ##pod数据类型
      labels:
        app: nginx                   ##标签
    spec:
      containers:                    ##pod容器
      - name: myapp                  ##名称
        image: myapp                 ##镜像


测试：
[kubeadm@server1 ~]$ kubectl apply -f rs-example.yaml
[kubeadm@server1 ~]$ kubectl get pod

3.2、测试

4、rs只控制文件中定义的标签的名称

修改标签后管理器不再被管理被修改的pod

修改标签之后发现会生成7个副本  因为rs控制器会根据文件中所写的副本的个数来维护副本的个数保持不变
rs控制器的作用是在工作时 发现pod发生故障回及时的生成新的pod

4.1、改标签

[kubeadm@server1 ~]$ kubectl get pod --show-lables  ##查看标签的信息
[kubeadm@server1 ~]$ kubectl lable pod  replicaset-example.Svtzp app=apache  --overwrite          ##更改标签 

4.2、测试：

[kubeadm@server1 ~]$ kubectl delete pod  --all    ##删除所有的pod

（因为rs控制器会根据文件中所写的副本的个数来维护副本的个数保持不变
rs控制器的作用是在工作时 发现pod发生故障回及时的生成新的pod  因为rs无法识别修改后的标签所以无法识别维护）

二、Deployment控制器

• 1、Deployment简介
• 2、清空实验环境
• 3、创建 Deployment
• 4、拉伸
• 5、更新 Deployment
• 6、回滚 Deployment   

1、Deployment简介

一个 Deployment 控制器为 Pods和 ReplicaSets提供描述性的更新方式。

描述 Deployment 中的 _desired state_，并且 Deployment 控制器以受控速率更改实际状态，以达到期望状态。可以定义 Deployments 以创建新的 ReplicaSets ，或删除现有 Deployments ，并通过新的 Deployments 使用其所有资源。

    不要管理 Deployment 拥有的 ReplicaSets 。如果存在下面未介绍的用例，请考虑在主 Kubernetes 仓库中提出 issue。

 deployment工作原理：创建nginx-deployment控制号 —————> 再去创建（rs）号 ————> 再创建3个pod副本

2、清除上一个实验的环境信息

[kubeadm@server1 ~]$ kubectl get rs        ##查看rs的策略
 No resources found in default namespace.
[kubeadm@server1 ~]$

3、创建Deployment控制器

[kubeadm@server1 ~]$ vim deployment-example.yaml

apiVersion: apps/v1                  ##控制器的版本
kind: Deployment                    ##控制器的类型
metadata:
  name: nginx-deployment            ##控制器的名称
spec:
  replicas: 3                       ##副本数为3这些pod由集群自动取分配给哪个节点
  selector:
    matchLabels:
      app: nginx                     ##标签
  template:                          ##模板
    metadata:                        ##pod数据类型
      labels:
        app: nginx                   ##标签
    spec:
      containers:                    ##pod容器
      - name: myapp                  ##名称
        image: myapp                 ##镜像（名称要和仓库里的镜像名称相同）
        ports:                       ##端口
        - containerPort: 80          ##监听的端口名称

 

3.2、测试：

[kubeadm@server1 ~]$ kubectl apply -f deployment-example.yaml       ## 应用
deployment.apps/nginx-deployment create

也可以用
[kubeadm@server1 ~]$ kubectl create -f deployment-example.yaml  （apply更好）

3.3、查看相关的配置信息

[kubeadm@server1 ~]$ kubectl get pod -o wide    ##查看pod对应的节点和网络信息

4、拉伸

4.1、在原来的基础上新添加3个pod

4.2、测试：

（在原来的基础上新增3个）

原来的：

4.3、访问：

4.4、查看生成pod的日志

Name:         nginx-deployment-74748dcf96-vbplx
Namespace:    default
Priority:     0
Node:         server1/172.25.6.1
Start Time:   Tue, 25 Feb 2020 21:17:25 -0500
Labels:       app=nginx
              pod-template-hash=74748dcf96
Annotations:  <none>
Status:       Running
IP:           10.244.0.28
IPs:
  IP:           10.244.0.28
Controlled By:  ReplicaSet/nginx-deployment-74748dcf96
Containers:
  myapp:
    Container ID:   docker://d6e75c840ce7ac63209b5169185abb55241533ef73fafa7d0b50d49d681e693a
    Image:          myapp
    Image ID:       docker-pullable://myapp@sha256:9eeca44ba2d410e54fccc54cbe9c021802aa8b9836a0bcf3d3229354e4c8870e
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Tue, 25 Feb 2020 21:17:41 -0500
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-ddbmj (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  default-token-ddbmj:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-ddbmj
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason     Age        From               Message
  ----    ------     ----       ----               -------
  Normal  Scheduled  <unknown>  default-scheduler  Successfully assigned default/nginx-deployment-74748dcf96-vbplx to server1
  Normal  Pulling    4m11s      kubelet, server1   Pulling image "myapp"
  Normal  Pulled     4m11s      kubelet, server1   Successfully pulled image "myapp"
  Normal  Created    4m7s       kubelet, server1   Created container myapp
  Normal  Started    4m4s       kubelet, server1   Started container myapp

5、滚动更新
在文件中修改要更新的镜像的名称即可
更新原理 ：删除掉之前的pod信息再重新生成的新的rs以及新的pod   但是不删除原来的rs信息

更新的原理图 ：

5.1、在私有仓库的管理节点上：

在阿里云上拉取镜像

5.2、上传myapp：v2镜像

5.3、更新

修改文件中镜像的名称

5.4、测试：

（之前的pod被删除重新生成了新的pod）

5.5、更新只删除之前的v1的pod但是步删除v1的rs

[kubeadm@server1 ~]$ kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-74748dcf96   0         0         0       42m        ##原来的rs信息
nginx-deployment-fb67c55fb    6         6         6       14m        ##新建的rs信息
[kubeadm@server1 ~]$

6、回滚：

原理：在文件中把镜像修改成之前的版本号、原先的rs还在回滚直接创建pod

[kubeadm@server1 ~]$ kubectl rollout history deployment nginx-deployment     ##查看历史记录
deployment.apps/nginx-deployment
REVISION  CHANGE-CAUSE
1         <none>                                     ##none的原因时之前的更新的命令后没有加--record
2         <none>

验证：
[kubeadm@server1 ~]$ kubectl scale deployment nginx-deployment --replicas=3 --record
[kubeadm@server1 ~]$ kubectl rollout history deployment nginx-deployment
deployment.apps/nginx-deployment
REVISION  CHANGE-CAUSE
2         <none>
3         kubectl scale deployment nginx-deployment --replicas=3 --record=true

6.2、测试 ：

查看版本信息

6.3、查看回滚的记录

6.4、回滚记录的创建

[kubeadm@server1 ~]$ kubectl set image --help

回滚并记录到v2版本
[kubeadm@server1 ~]$ kubectl set image deployment nginx-deployment myapp=myapp:v2 --record
deployment.apps/nginx-deployment image updated


保留原先的rs是为了方便回滚

查看回滚的历史记录
[kubeadm@server1 ~]$ kubectl rollout history deployment nginx-deployment
deployment.apps/nginx-deployment
REVISION  CHANGE-CAUSE
3         kubectl scale deployment nginx-deployment --replicas=3 --record=true
4         kubectl set image deployment nginx-deployment myapp=myapp:v2 --record=true

用文件的方式不能查看历史记录

6.5、查看rs的工作版本

6.6、查看回滚历史记录

三、DaemonSet控制器

• 1、DaemonSet简介
• 2、实验准备
• 3、创建DaemonSet控制器

1、DaemonSet简介

DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时， 也会为他们新增一个 Pod 。当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

DaemonSet 的一些典型用法：

    在每个节点上运行集群存储 DaemonSet，例如 glusterd、ceph。
    在每个节点上运行日志收集 DaemonSet，例如 fluentd、logstash。
    在每个节点上运行监控 DaemonSet，例如 Prometheus Node Exporter、Flowmill、Sysdig 代理、collectd、Dynatrace OneAgent、AppDynamics 代理、Datadog 代理、New Relic 代理、Ganglia gmond 或者 Instana 代理。

一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用。

一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求。

和其它所有 Kubernetes 配置一样，DaemonSet 需要 apiVersion、kind 和 metadata 字段。有关配置文件的基本信息，详见文档 部署应用、配置容器 和 使用 kubectl 进行对象管理。

官网地址：https://kubernetes.io/zh/docs/concepts/workloads/controllers/daemonset/

2、实验准备：

在私有仓库的控制节点上上传实验需要用到的镜像 、

1.1、搜索镜像

2.2、在阿里云上拉取镜像

2.3、上传镜像

3、创建DaemonSet控制器

配置文件：

apiVersion: apps/v1                       ##版本号
kind: DaemonSet                           ##服务的名称
metadata:
  name: daemonset-example                 ##数据的名称
spec:
  selector:
    matchLabels:
      name: daemonset-example
  template:
    metadata:
      labels:
        name: daemonset-example
    spec:
      containers:                         
      - name: zabbix-agent                ##容器的名称  
        image: zabbix-agent               ##镜像的名称

3.2、测试：

（每个节点上只跑一个副本）

在文件中并没有说明 要跑多少个   但是控制器回控制每个节点只跑一个pod  daemonset 类型的控制器一般应用在监控、日志采集、存储方面的比较多

[kubeadm@server1 ~]$ kubectl get pod -o wide
NAME                      READY   STATUS    RESTARTS   AGE   IP            NODE      NOMINATED NODE   READINESS GATES
daemonset-example-5xwgw   1/1     Running   0          48m   10.244.0.36   server1   <none>           <none>
daemonset-example-fbd26   1/1     Running   0          48m   10.244.2.29   server3   <none>           <none>
daemonset-example-rlqcm   1/1     Running   0          48m   10.244.1.36   server4   <none>           <none>

四、Job控制器

Jobs控制器是一次性的 只跑一次跑完就结束，通常用在计算数据方面比较广泛

• 1、实验环境的部署
• 2、创建Job控制器

1、实验环境配置：

在私有仓库的管理节点上 搜索perl镜像

1.2、拉取镜像

1.3、上传镜像：

 

官网链接：https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

2、创建Job控制器

2.1、配置文件：

[kubeadm@server1 ~]$ \vi job.yaml   ##f复制官网信息
apiVersion: batch/v1                    ##版本
kind: Job                               ##控制器类型
metadata:
  name: pi                              ##圆周率的名称
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl                     ##镜像
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]     ##圆周率的计算代码
      restartPolicy: Never                                                ##跑完就结束
  backoffLimit: 4                                                         ##报错4次后自动退出

2.2、测试：

2.3、查看日志:

2.4、查看job运行的日志（圆周率计算结果）

五、CronJob控制器

• 1、CronJob的简介
• 2、创建CronJob、测试

1、CronJob的简介

CronJob控制器常用在周期化的任务定义号时间后 用于常规的数据监控等

Cron Job 创建基于时间调度的 Jobs。

一个 CronJob 对象就像 crontab (cron table) 文件中的一行。它用 Cron 格式进行编写，并周期性地在给定的调度时间执行 Job。

注意： 所有 CronJob 的 schedule: 时间都是基于初始 Job 的主控节点的时区。

为 CronJob 资源创建清单时，请确保创建的名称不超过 52 个字符。这是因为 CronJob 控制器将自动在提供的作业名称后附加 11 个字符，并且存在一个限制，即作业名称的最大长度不能超过 63 个字符。

有关创建和使用 CronJob 的说明及规范文件的示例，请参见使用 CronJob 运行自动化任务。

• CronJob 限制

CronJob 限制

CronJob 创建 Job 对象，每个 Job 的执行次数大约为一次。 我们之所以说 “大约”，是因为在某些情况下，可能会创建两个 Job，或者不会创建任何 Job。 我们试图使这些情况尽量少发生，但不能完全杜绝。因此，Job 应该是 _幂等的_。

如果 startingDeadlineSeconds 设置为很大的数值或未设置（默认），并且 concurrencyPolicy 设置为 Allow，则作业将始终至少运行一次。

对于每个 CronJob，CronJob 控制器 检查从上一次调度的时间点到现在所错过了调度次数。如果错过的调度次数超过 100 次，那么它就不会启动这个任务，并记录这个错误:

Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.

需要注意的是，如果 startingDeadlineSeconds 字段非空，则控制器会统计从 startingDeadlineSeconds 设置的值到现在而不是从上一个计划时间到现在错过了多少次 Job。例如，如果 startingDeadlineSeconds 是 200，则控制器会统计在过去 200 秒中错过了多少次 Job。

如果未能在调度时间内创建 CronJob，则计为错过。例如，如果 concurrencyPolicy 被设置为 Forbid，并且当前有一个调度仍在运行的情况下，试图调度的 CronJob 将被计算为错过。

例如，假设一个 CronJob 被设置为 08:30:00 准时开始，它的 startingDeadlineSeconds 字段被设置为 10，如果在 08:29:00 时将 CronJob 控制器的时间改为 08:42:00，Job 将不会启动。 如果觉得晚些开始比没有启动好，那请设置一个较长的 startingDeadlineSeconds。

为了进一步阐述这个概念，假设将 CronJob 设置为从 08:30:00 开始每隔一分钟创建一个新的 Job，并将其 startingDeadlineSeconds 字段设置为 200 秒。 如果 CronJob 控制器恰好在与上一个示例相同的时间段（08:29:00 到 10:21:00）停机，则 Job 仍将从 10:22:00 开始。造成这种情况的原因是控制器现在检查在最近 200 秒（即 3 个错过的调度）中发生了多少次错过的 Job 调度，而不是从现在为止的最后一个调度时间开始。

CronJob 仅负责创建与其调度时间相匹配的 Job，而 Job 又负责管理其代表的 Pod。

 

2 、配置文件信息
 

 vim cronjob.yaml
apiVersion: batch/v1beta1                    ##版本
kind: CronJob                                ##控制器
metadata:  
  name: cronjob-example                      ##圆周率的名称
spec:
  schedule: "* * * * *"                      ##分时日月周
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: cronjob                   
            image: busybox
            args:
            - /bin/sh                                   ##指定命令
            - -c
            - date; echo Hello from k8s cluster         ##写入要输出语句
          restartPolicy: OnFailure                      ##非0退出

2.2、测试：

[kubeadm@server1 ~]$ kubectl create -f cronjob.yaml
cronjob.batch/cronjob-example created


[kubeadm@server1 ~]$ kubectl get cronjobs.batch
NAME              SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
cronjob-example   * * * * *   False     0        30s             98s
[kubeadm@server1 ~]$


[kubeadm@server1 ~]$ kubectl get pod
NAME                               READY   STATUS              RESTARTS   AGE
cronjob-example-1582736520-s6m6p   0/1     Completed           0          2m
cronjob-example-1582736580-tcmfd   0/1     Completed           0          60s
cronjob-example-1582736640-5sjj4   0/1     ContainerCreating   0          8s
[kubeadm@server1 ~]$


[kubeadm@server1 ~]$ kubectl describe pod cronjob-example     ##查看日志

2.3、查看日志：

2.4、查看运行的结果：

总结：pod控制器在pod的部署中起到很多的作用要熟悉各个控制器之间的关联和区别