Kubernetes之Controller认识

Kubernetes核心技术之Controller

什么是Controller

Controllern不像Pod,是虚拟出来的概念，Controller是实际存在的，是k8s在集群上管理和运行容器的对象

Pod和Controller的关系

Pod是通过Controller实现应用的运维，比如伸缩、滚动升级等等

Pod和Controller是如何取得联系

Pod和Controller之间是通过labei标签建立联系

yaml文件字段说明

比较全面的yaml的文件字段说明

有状态应用部署&无状态应用部署

• 在上面的总结中，我们通过deployment部署了很多无状态的pod,以及演示了一下基操玩法，下面我们来了解一下有状态部署

• 无状态部署的特点

  1. 认为所有pod都是一样的

  2. 没有部署先后顺序之分

  3. 不用考虑在那个节点node执行

  4. 随意进行伸缩和扩展

• 有状态部署的特点

  1. 以上因素全在考虑范围内

  2. 让每一个pod都独立，保持pod启动顺序的先后性以及唯一性（通过唯一的网络标识符&持久储存等手段保证）

无状态应用部署（Deployment）

第一步导出yaml文件

• kubectl create deployment web1 --image=nginx --dry-run -o yaml > web1.yaml

然后我们会得到一个web1.yaml文件如下所示

第二部使用yaml部署应用

• kubectl apply -f web1.yaml

然后我们一直等待，等待他运行成功

• 

第三部对外发布(暴露端口)

• kubectl expose deployment web1 --port=80 --type=NodePort --target-port=80 --name=web1 -o yaml > web1Expose.yaml

然后我们可以看到一个部署文件：web1Expose.yaml

我们将其部署，将Nginx应用进行发布，进行端口暴露

• kubectl apply -f web1Expose.yaml

• kubectl get pods,svc

• 

• 这个时候已经发布成功，我们可以通过三个节点，只要是30339端口即可访问Nginx服务

应用升级

下面我们初始化一下环境，将刚刚部署的pod删掉，先删pod ,再删Deployment

• kubectl get pods 　　

  • kubectl delete pod podName

• kubectl get deployments

  • kubectl delete deployment depName

• 修改刚刚我们导出的web1.yaml文件

  • 副本数量修正为2

  • Nginx的镜像指定版本为1.14

• 使用yaml部署应用

  • kubectl apply -f web1.yaml

  • 然后我们去诸多node节点查看相应的镜像版本信息

    • 

应用升级（过程分析）

• 从刚刚我们的操作中，我们部署了两台版本为1.14的Nginx,现在我们要对其进行升级到1.15

• kubectl set image deployment web1 nginx=nginx:1.15

  • 

• 我们可以查看升级状态

  • kubectl rollout status deployment 应用名称

    • 

• 过程分析：升级过程中为什么对外暴露的服务不会停止

应用版本回滚

• 就是刚刚查看是否升级成功的命名把status改成history即可查看所有版本信息

  • kubectl rollout history deployment web1.

    • 

• 版本回滚到上一个版本

  • kubectl rollout undo deployment web1

  • 

• 版本回滚到指定版本

  • kubectl rollout undo deployment web1 --to-reversion=2

  • 

应用的弹性伸缩

就使用我们刚刚部署的Nginx做列子，我们对其副本伸缩

• kubectl scale deployment web1 --replicas=10

  • 

无状态应用部署应用场景

• 部署无状态应用

• 管理Pod和副本ReplicaSet数量

• 部署，滚动升级等功能

web服务、微服务部署等

有状态应用部署（StatefulSet）

• 想要部署有状态的应用的基本前提

  1. 无头Service，clusterIp: none

  2. kind 指定值为StatefulSet

web3.yaml [提取码：vayv ]

• 我们来看看这个web3.yaml

• 部署这个web3.yaml，如下所示

  • clusterIP为none，表示这是一个无头service

deployment和StatefulSet的不同

• 唯一的区别就是StatefulSet部署是有身份，有唯一标识符的

  • StatefulSet会生成一个唯一标识符：主机名 + 按照一定规则生成的域名 拼接而成唯一标识

  • 格式：主机名称.service名称.名称空间.svc.cluster.local

  • 比如：nginx-statefulset-o.nginx.default.svc.cluster.local

守护进程部署（DaemonSet）

• 所谓守护进程就是一直在后台运行的进程，大部分是在系统启动时就被引导执行，在系统关闭才杀掉的进程，生命周期比较长。

现在我们要部署一个守护进程

• 实现在每个node节点上运行一个pod,该pod定义为守护进程，即使是新加入的节点node，也得运行该pod

• 演示方式：在每个node节点上安装一个数据采集工具，实现数据采集

查看资源编排文件yaml

daemonSetTest.yaml [提取码: 6666 ]

• 初始化我们的看k8s环境,依次删除以下所有信息(以下是四条命令，不是一条)

  • kubectl delete pod / deployment / service / statefulset -all

• 初始化环境如下所示

  

• 查看我们的daemonSetTest.yaml

部署资源编排文件

• 从上面的资源编排文件到部署后查看pods信息我们可以得到以下信息

  1. 我们没有指定副本数量，标准就是守护进程每个node节点都会指定

  2. 我们只有两个节点，所以只有两个pod

  3. 守护进程不用发布为一个Service,即可执行

进入pod内部核实数据

• 刚刚我们将采集数据存放于: /tmp/log/

• 我们进入pod,查看指定目录下是否有日志文件

  • kubectl exec -it podName bash

  

• 可以看到日志数据都寄存于此

部署一次性任务&定时任务

部署一次性任务（job）

查看资源编排文件：job.yaml [提取码：6666]

部署这个pod后，因为我们指定了command属性的值，就会执行后面的脚本，进行计算并打印圆周率的后2000位

• 我们直接部署这个yaml，耗时较久，镜像有点大

• 可以看到这个一次性任务已经是完成状态标识Complated，查看日志数据呢

  • kubectl logs podName

• 查看所有一次性任务列表

  • kubectl get jobs

• 删除一次性任务历史

  • kubectl delete -f job.yaml

    

部署定时任务(cronJob)

查看资源编排文件，cronJob.yaml [提取码：6666]

• 我们直接部署这个yaml

  • kubectl apply -f cronjob.yaml

    

  • 然后我们也可以删除该定时任务

    

.