快速入门Kubernetes(K8S)——资源控制器

上篇文章给大家介绍了快速入门Kubernetes(K8S)——资源清单本篇文章给大家讲解下关于资源控制器相关的内容，编写不易（对你有帮助的话一键三连）看完可以掌握一内容:

了解什么是控制器
常见的控制器类型
案例部署
job案例讲解

一、什么是控制器

Kubernetes 中内建了很多 controller（控制器），这些相当于一个状态机，用来控制 Pod 的具体状态和行为

二、控制器类型

ReplicationController 和 ReplicaSet
Deployment
DaemonSet
StateFulSet
Job/CronJob
Horizontal Pod Autoscaling

由于理论部分之前在第一篇文章中已经发过来我这边就不在重新说一遍了，不会的小伙可以查看之前的文章 like，那我们下面分别实操一下 Deployment、DaemonSet 、JobCronJob

2.1RS部署测试

Kubernetes 官方建议使用 RS（ReplicaSet ）替代 RC （ReplicationController ）进行部署，RS 跟 RC 没有本质的不同，只是名字不一样，并且 RS 支持集合式的 selector

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
 name: frontend
spec:
 replicas: 3
 selector:
  matchLabels:
   tier: frontend
 template:
  metadata:
   labels:
    tier: frontend
  spec:
   containers:
   - name: myapp
     image: hub.dashujulaoge.com/library/myapp:v1
     env:
     - name: GET_HOSTS_FROM
       value: dns
     ports:
     - containerPort: 80

创建并执行查看

# 通过yaml 文件创建pod
kubectl  create -f rs.yaml
# 查看pod运行情况
[root@k8s-master01 ~]# kubectl get pod
NAME                               READY   STATUS    RESTARTS   AGE
frontend-4cfcf                     1/1     Running   0          4m33s
frontend-jmlhx                     1/1     Running   0          4m33s
frontend-k5sv9                     1/1     Running   0          4m33s
# 修改LABELS 状态查看运行结果 没有修改之前
[root@k8s-master01 ~]# kubectl get pod --show-labels
NAME                               READY   STATUS    RESTARTS   AGE     LABELS
frontend-jmlhx                     1/1     Running   0          7m46s   tier=frontend
frontend-k5sv9                     1/1     Running   0          7m46s   tier=frontend
frontend-vmbmm                     1/1     Running   0          31s     tier=frontend
# 修改 
kubectl label pod frontend-4cfcf  tier=frontend1  --overwrite=true

[root@k8s-master01 ~]# kubectl get pod --show-labels
NAME                               READY   STATUS    RESTARTS   AGE     LABELS
frontend-4cfcf                     1/1     Running   0          7m46s   tier=frontend1
frontend-jmlhx                     1/1     Running   0          7m46s   tier=frontend
frontend-k5sv9                     1/1     Running   0          7m46s   tier=frontend
frontend-vmbmm                     1/1     Running   0          31s     tier=frontend
# 发现出现了4个pod 原因是 我们设置了replicas=3 当我们修改了一个frontend 时候系统发下只有有个名字叫frontend了所以系统有会启动一个pod，删除rs也是同理。

2.2 RS 与 Deployment 的关联

2.3部署一个Nginx 应用

apiVersion: apps/v1     #Api接口版本
kind: Deployment        #定义控制器
metadata:
 name: nginx-deployment #deployment名称
spec:
 replicas: 3            #在具体参数信息spec下，只指定了副本数量，还需要指定副本标签与 Deployment控制器进行匹配
 selector:
  matchLables:
    app: nginx-deployment
 template:
   metadata:
     labels:
       app: nginx-deployment
   spec:
     containers:
       - name: nginx-deployment
         image: nginx:1.7.9
         ports:
           - containerPort: 80

执行创建命令

[root@k8s-master01 ~]# kubectl apply -f deployment.yaml --record

扩容

kubectl scale deployment nginx-deployment --replicas 10

如果集群支持 horizontal pod autoscaling 的话，还可以为Deployment设置自动扩展

kubectl autoscale deployment nginx-deployment --min=10--max=15--cpu-percent=80

更新镜像

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

回滚

kubectl rollout undo deployment/nginx-deployment

2.4更新策略

Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的。默认的，它会确保至少有比期望的Pod数量少一个是up状态（最多一个不可用）

Deployment 同时也可以确保只创建出超过期望数量的一定数量的 Pod。默认的，它会确保最多比期望的Pod数量多一个的 Pod 是 up 的（最多1个 surge ）

未来的 Kuberentes 版本中，将从1-1变成25%-25%

kubectl describe deployments

2.5 Rollover（多个rollout并行）

假如您创建了一个有5个niginx:1.7.9 replica的 Deployment，但是当还只有3个nginx:1.7.9的 replica 创建出来的时候您就开始更新含有5个nginx:1.9.1 replica 的 Deployment。在这种情况下，Deployment 会立即杀掉已创建的3个nginx:1.7.9的 Pod，并开始创建nginx:1.9.1的 Pod。它不会等到所有的5个nginx:1.7.9的Pod 都创建完成后才开始改变航道

2.6 回退 Deployment

kubectl set image deployment/nginx-deployment nginx=nginx:1.91
kubectl rollout status deployments nginx-deployment
kubectl get pods
kubectl rollout history deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment --to-revision=2 ## 可以使用 --revision参数指定
某个历史版本
kubectl rollout pause deployment/nginx-deployment ## 暂停 deployment 的更新

您可以用kubectl rollout status命令查看 Deployment 是否完成。如果 rollout 成功完成，kubectl rolloutstatus将返回一个0值的 Exit Code

$ kubectl rollout status deploy/nginx
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx" successfully rolled out
$ echo $?
0

2.7 清理 Policy

您可以通过设置.spec.revisonHistoryLimit项来指定 deployment 最多保留多少 revision 历史记录。默认的会保留所有的 revision；如果将该项设置为0，Deployment 就不允许回退了

三、DaemonSet

运行集群存储 daemon，例如在每个 Node 上运行 glusterd 、 ceph
在每个 Node 上运行日志收集 daemon，例如 fluentd 、 logstash
在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、 collectd 、Datadog 代理、 New Relic 代理，或 Ganglia gmond

3.1创建 yaml文件进行测试

apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: deamonset-example
 labels:
  app: daemonset
spec:
 selector:
  matchLabels:
   name: deamonset-example
 template:
  metadata:
   labels:
    name: deamonset-example
  spec:
   containers:
    - name: daemonset-example
      image: wangyanglinux/myapp:v1

四、Job

Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束

特殊说明：

spec.template格式同Pod
RestartPolicy仅支持Never或OnFailure
单个Pod时，默认Pod成功运行后Job即结束
.spec.completions标志Job结束需要成功运行的Pod个数，默认为1
.spec.parallelism 标志并行运行的Pod的个数，默认为1
spec.activeDeadlineSeconds 标志失败Pod的重试最大时间，超过这个时间不会继续重试

4.1 创建yaml 文件进行测试

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

4.2 CronJob

Cron Job管理基于时间的 Job，即：

在给定时间点只运行一次
周期性地在给定时间点运行

使用条件：当前使用的 Kubernetes 集群，版本 >= 1.8（对 CronJob）

典型的用法如下所示：

在给定的时间点调度 Job 运行
创建周期性运行的 Job，例如：数据库备份、发送邮件

4.3 CronJob Spec

.spec.schedule:调度，必需字段，指定任务运行周期，格式同 Cron
.spec.jobTemplate:Job 模板，必需字段，指定需要运行的任务，格式同 Job
Job 模板，必需字段，指定需要运行的任务，格式同 Job:Job 模板，必需字段，指定需要运行的任务，格式同 Job
.spec.concurrencyPolicy:并发策略，该字段也是可选的。它指定了如何处理被 Cron Job 创建的 Job 的并发执行。只允许指定下面策略中的一种：
- Allow允许并发运行
- 允许并发运行:禁止并发运行，如果前一个还没有完成，则直接跳过下一个
- Replace:取消当前正在运行的 Job，用一个新的来替换

注意，当前策略只能应用于同一个 Cron Job 创建的 Job。如果存在多个 Cron Job，它们创建的 Job 之间总是允许并发运行

spec.suspend:挂起，该字段也是可选的。如果设置为true，后续所有执行都会被挂起。它对已经开始执行的 Job 不起作用。默认值为false。
.spec.successfulJobsHistoryLimit和.spec.failedJobsHistoryLimit历史限制，是可选的字段。它们指定了可以保留多少完成和失败的 Job。默认情况下，它们分别设置为3和1。设置限制的值为0，相关类型的 Job 完成后将不会被保留。

4.4创建yaml文件进行测试

apiVersion: batch/v1beta1
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

五、粉丝福利及软件获取

有的小伙伴刚开始学习k8s的没有目标，不知道该怎么学，以及k8s有哪些内容该怎么学。我在这里为大家准备了一个学习流程图感兴趣的小伙伴可以进行获取 微信搜索【大数据老哥】回复【k8s学习流程图】即可获取。
在这里插入图片描述
其他福利

微信公众号搜索【大数据老哥】可以获取 200个为你定制的简历模板、大数据面试题、企业面试题…等等。