kuberenetes控制器(管理Pod)
kuberenetes控制器(管理Pod)
在K8S中去管理pod的任务是由控制器(controllers)去做的，控制器又称为工作负载(workload)，有了控制器才能更好的对服务进行编排，有五个比较重要的控制器，如下。
- Deployment
- StatefulSet
- DaemonSet
- Job
- CronJob
下面会分别介绍，先看看Pod与控制器的关系。
Pod 与控制器的关系
首先控制器是在集群上管理和运行容器的对象，也就是管理Pod的，第二控制与pod关联是通过标签(label-selector)进行关联，通过控制器去管理Pod会实现更多流啤的功能，像是什么弹性伸缩升级滚动更新之类的，都是在控制器层面实现的。
Deployment部署无状态应用
使用Deployment,这个控制器创建了nginx，这种算是无状态的应用，像是nginx根本不用去考虑分配到那个节点或容器IP是多少，所以Deployment适用于部署无状态的应用，他能管理Pod和ReplicaSet
[root@k8s01 yml]# kubectl get replicasets.apps
NAME DESIRED CURRENT READY AGE
nginx-dd6b5d745 3 3 3 3d5h
[root@k8s01 yml]#
ReplicaSet这对于用于来说，这是一个隐藏的控制器，用作管理Pod副本数的，我预期的状态是创建三个副本，可以看一下上文的配置文件，如果有一个pod挂掉了他就会再启动一个pod，会确保有三个在运行，deployment是管理replicasets&pod的，replicasets也做版本的管理，之前我们使用kubectl rollout回滚到上一个版本就是依靠的replicasets。
所以总结一下就是deployment能管理Pod和ReplicaSet、具有上线部署、副本设定、滚动更新、回滚等功能，下面编辑一下nginx-deployment的配置文件
[root@k8s01 yml]# kubectl edit deployments.apps nginx
spec:
progressDeadlineSeconds: 600
replicas: 3 #设置副本数
revisionHistoryLimit: 10
selector:
matchLabels:
run: nginx #标签选择器，pod与控制器关联
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate # 滚动更新策略，默认滚动更新
查看回滚版本，也是replicasets来做的。
[root@k8s01 yml]# kubectl rollout history deployment nginx
deployment.apps/nginx
REVISION CHANGE-CAUSE
1 <none>
[root@k8s01 yml]#
支持声明式更新，例如想更新某一个字段，他就会更新某一个字段，例如更新image字段，deployments比较适合Web服务，之前部署用的就是deployments。
有状态和无状态服务区别
刚刚上面提到了deployment部署的是无状态服务，还有一种服务是有状态服务，这俩服务有啥区别，下面分别看一下。
无状态服务概述
deployment认为所有的Pod都是一样的，也就是这些。
[root@k8s01 yml]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-dd6b5d745-6z8lx 1/1 Running 5 3d5h
nginx-dd6b5d745-cv4t8 1/1 Running 4 3d5h
nginx-dd6b5d745-tgh5c 1/1 Running 5 3d5h
[root@k8s01 yml]#
这三个副本都是一模一样的，都是使用同一个镜像去启动的，里面的数据也是完全一样的，属于是对等关系，而且他们的启动顺序也是没有任何规律，先启动哪个都无所谓，对我应用部署没有任何影响，也不用考虑pod在哪个node运行，更不用也不用考虑Pod:IP是什么，所以你可以随意扩容和缩容。
有状态服务概述
举一个最简单的例子，例如我现在需要使用三个zookeeper做一个集群，集群最低要求要有三个zookeeper实例，每个容器都设置的一个名为ZOO_MY_ID 的全局变量，而且这个值各个容器之间都不一样，有三个容器，我设置的分别是{1..3}，各个节点地址都是用的zoo{1..3}，这算是唯一的网络标识符，容器挂了重启这个标识符是不变的，但是我那个zookeeper没有挂载数据卷，其实还要有持久存储。
像是这种服务你就不能随意的扩容和缩减了，需要有序进行了，包括扩展删除终止滚动更新服务，像是这种就算有状态服务了，每个实例之间属于不对等关系，各个容器之间有些参数不一致，或是挂载的数据卷源/位置不一致，你不可以随意的扩容或缩减这些服务，否则就会有问题，在K8S中，要实现这种服务就要使用StatefulSet了。
headless service
想知道StatefulSet具体是怎么实现的，要从一个服务谈起，也就是headless service，称为无头服务，回忆一下之前的Service，它是一组pod的访问策略，提供负载均衡和服务发现，访问这个Service他会帮你把请求转发到某个Pod，也就是这个东西，这是之前创建的。
[root@k8s01 yml]# kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 10d
nginx-service NodePort 10.0.0.180 <none> 80:30010/TCP 3d21h
[root@k8s01 yml]#
类型NodePort，无头服务也是使用了Service，不过在定义的时候不需要CLUSTER-IP了，直接会绑定具体Pod的IP，上面就是一个常规的Service，他关联了三个标签为nginx的Pod，且提供了一个统一的入口，IP为10.0.0.180，你访问这个IP：port他会帮你把请求转发到后端Pod，也就是这里。
[root@k8s01 yml]# kubectl get endpoints nginx-service
NAME ENDPOINTS AGE
nginx-service 10.244.0.38:80,10.244.1.100:80,10.244.1.101:80 3d22h
[root@k8s01 yml]#
再来看headless service，和常规的稍微有点区别，他会将CLUSTER-IP置位none
[root@k8s01 yml]# cat headless-service.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
和正常创建Service的区别就是clusterip为none，默认clusterIP是启用的，现在制定为none了就是不为这个Service分配一个clusterip了，创建一下看效果。
[root@k8s01 yml]# kubectl create -f headless-service.yaml
service/nginx created
[root@k8s01 yml]# kubectl get services nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx ClusterIP None <none> 80/TCP 6s
[root@k8s01 yml]#
可以看到CLUSTER-IP为None了，他没有具体的IP，这种情况下主要用的就是DNS访问了，他保证了唯一的网络标识符，使用IP无法保证你这个pod挂掉重启后永远都是使用这个IP，所以这就是利用了DNS保证了网络唯一标识符的，我们之前部署过了coredns，下面开始部署有状态服务。
部署有状态应用
SatefulSet是部署有状态应用，解决Pod独立生命周期，保持Pod顺序和唯一性。稳定，唯一的网络标识符，持久存储。有序，优雅的部署和扩展，删除和终止。有序，滚动升级
[root@k8s01 yml]# kubectl delete -f headless-service.yaml
service "nginx" deleted
[root@k8s01 yml]# kubectl delete -f deployment.yaml
deployment.apps "nginx-deployment" deleted
[root@k8s01 yml]# kubectl delete -f services.yaml
service "nginx-service" deleted
[root@k8s01 yml]# cat nginx-headless.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: nginx
spec:
selector:
matchLabels:
app: nginx
serviceName: "nginx"
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
name: nginx
我把Service和StatefulSet写到了一起，StatefulSet和deployment有差别的地方就是StatefulSet有个serviceName，他是用来关联上面无头service的，上面无头Service的名称就是nginx，直接用这个文件进行部署，部署完之后看一下所创建的StatefulSet和Service。
[root@k8s01 yml]# kubectl create -f nginx-headless.yaml
service/nginx created
statefulset.apps/nginx created
[root@k8s01 yml]# kubectl get services nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx ClusterIP None <none> 80/TCP 14s
[root@k8s01 yml]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-0 1/1 Running 0 53s
nginx-1 1/1 Running 0 36s
nginx-2 1/1 Running 0 20s
[root@k8s01 yml]#
创建好了，现在了解一下唯一的网络标识是怎么来的，就是上图NAME那一行的名称，这就是一个固定的DNS名称了，而且会有有序编号，现在随便启动一个镜像去测试一下。
[root@k8s01 yml]# kubectl run -it --image=busybox:1.28.4 --rm --restart=Never sh
If you don't see a command prompt, try pressing enter.
/ #
/ # for i in 0 1 2;do nslookup nginx-$i.nginx;done
Server: 10.0.0.2
Address 1: 10.0.0.2 kube-dns.kube-system.svc.cluster.local
Name: nginx-0.nginx
Address 1: 10.244.1.102 nginx-0.nginx.default.svc.cluster.local
Server: 10.0.0.2
Address 1: 10.0.0.2 kube-dns.kube-system.svc.cluster.local
Name: nginx-1.nginx
Address 1: 10.244.0.39 nginx-1.nginx.default.svc.cluster.local
Server: 10.0.0.2
Address 1: 10.0.0.2 kube-dns.kube-system.svc.cluster.local
Name: nginx-2.nginx
Address 1: 10.244.1.103 nginx-2.nginx.default.svc.cluster.local
/ # pod "sh" deleted
[root@k8s01 yml]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-0 1/1 Running 0 9m19s 10.244.1.102 k8s03 <none> <none>
nginx-1 1/1 Running 0 9m2s 10.244.0.39 k8s02 <none> <none>
nginx-2 1/1 Running 0 8m46s 10.244.1.103 k8s03 <none> <none>
[root@k8s01 yml]#
没什么问题， pod名称后需要加上Service的名称才能解析到，这就是一个Pod有一个唯一的域名，这是个固定的，并且解析到自身的IP，所以，总结一下。
StatefulSet和deployment的主要区别就是StatefulSet是有身份的，这个身份有三要素，分别是有自己的域名、主机名、存储(PVC)，每一个Pod都有一个唯一的主机名，看一下是什么就知道了。
[root@k8s01 yml]# for i in {0,1,2};do kubectl exec nginx-$i hostname;done
nginx-0
nginx-1
nginx-2
[root@k8s01 yml]#
DaemonSet
这个比较好理解，他会在你每一个Node上运行一个Pod，新加入的Node也会自动运行一个Pod，比较适合运行采集器之类的东西
[root@k8s01 yml]# cat daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: filebeat
spec:
selector:
matchLabels:
app: filebeat
template:
metadata:
labels:
app: filebeat
spec:
containers:
- name: filebeat
image: nginx:latest
volumeMounts:
- mountPath: /log
name: varlog
volumes:
- name: varlog
hostPath:
path: /var/log
type: Directory
[root@k8s01 yml]#
使用了nginx的镜像，你就把他当成filebeat，这东西是干嘛的应该都了解过，上面把宿主机的/var/log目录挂在到了容器的/log，上面提到了这个类型会在所有的Node节点都启动一个的pod，所以你可以理解为该Pod可以收集宿主机日志，通过filebeat读取挂载目录的日志推到logstash||elasticsearch中
[root@k8s01 yml]# kubectl create -f daemonset.yaml
daemonset.apps/filebeat created
[root@k8s01 yml]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
filebeat-5sfvj 1/1 Running 0 26s 10.244.0.46 k8s02 <none> <none>
filebeat-q5f7c 1/1 Running 0 26s 10.244.2.60 k8s05 <none> <none>
filebeat-zcl56 1/1 Running 0 26s 10.244.1.104 k8s03 <none> <none>
可以看到每个节点都有一个在运行，下面去Pod里看看宿主机的东西是否被挂载到Pod，挂载到了就没问题
[root@k8s01 yml]# kubectl exec -it filebeat-5sfvj /bin/bash
root@filebeat-5sfvj:/# ls -l /log/
total 5468
drwxr-xr-x. 2 root root 204 May 1 05:24 anaconda
drwx------. 2 root root 23 May 1 05:24 audit
-rw-------. 1 root root 0 Jun 5 03:19 boot.log
-rw------- 1 root root 78724 Jun 2 02:50 boot.log-20200602
-rw------- 1 root root 9076 Jun 3 08:06 boot.log-20200603
-rw------- 1 root root 37533 Jun 5 03:19 boot.log-20200605
-rw-------. 1 root voice 0 May 1 05:22 btmp
drwxr-xr-x 2 root root 4096 Jun 5 08:44 containers
-rw-------. 1 root root 294625 Jun 5 08:46 cron
-rw-r--r-- 1 root root 122195 Jun 5 02:58 dmesg
-rw-r--r-- 1 root root 122185 Jun 5 02:42 dmesg.old
-rw-r--r--. 1 root root 1842 May 1 05:27 firewalld
-rw-r--r--. 1 root root 193 May 1 05:21 grubby_prune_debug
-rw-r--r--. 1 root root 292000 Jun 5 06:13 lastlog
-rw-------. 1 root root 153548 Jun 5 08:46 maillog
-rw-------. 1 root root 4517207 Jun 5 08:46 messages
drwxr-xr-x 7 root root 4096 Jun 5 08:43 pods
drwxr-xr-x. 2 root root 6 May 1 05:24 rhsm
drwxr-xr-x. 2 root root 91 Jun 5 02:42 sa
-rw-------. 1 root root 51606 Jun 5 08:24 secure
-rw-------. 1 root root 0 May 1 05:22 spooler
-rw-------. 1 root root 0 May 1 05:21 tallylog
drwxr-xr-x. 2 root root 23 May 1 05:24 tuned
-rw-r--r--. 1 root root 21390 Jun 5 02:58 vmware-vgauthsvc.log.0
-rw-r--r--. 1 root root 27822 Jun 5 06:05 vmware-vmsvc.log
-rw-rw-r--. 1 root voice 41472 Jun 5 08:24 wtmp
-rw-------. 1 root root 4262 Jun 1 09:35 yum.log
root@filebeat-5sfvj:/#
没问题，使用场景就是这样，将来使用filebeat就可以直接采集这个目录下的日志文件了
Job与CronJob
Job分为普通任务(Job)和定时任务(CronJob)，普通任务是一次性执行的，定时任务就是有计划的去执行，下面分别去了解一下。
Job
也就是普通任务，下面是一个例子，在官网扒过来的。
[root@k8s01 yml]# cat job.yaml
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
使用perl镜像启动一个容器，运行一条命令去计算，这个不用深入了解，重启策略为Never，表示容器退出码为0的情况下从不重启，backoffLimit设置重试的次数，如果这个任务执行失败了怎么办，现在定义了4，如果失败了他会帮你重试4次，为毛要有这个？上面提到了Never表示容器退出码为0的情况下从不重启，如果退出状态码非0还是会重启，如果四次退出码都是0，也就是到达了backoffLimit的限制，他就不会再重启了，默认是6，下面创建一下。
[root@k8s01 yml]# kubectl create -f job.yml
job.batch/pi created
[root@k8s01 yml]# kubectl get jobs.batch
NAME COMPLETIONS DURATION AGE
pi 1/1 3m17s 3m22s
[root@k8s01 yml]# kubectl get pod pi-k2zvd
NAME READY STATUS RESTARTS AGE
pi-k2zvd 0/1 Completed 0 3m25s
[root@k8s01 yml]#
可以看到pod的状态为Completed了，说明他执行完命令后正常关闭了，关闭后他不会被删除，自行删除吧，所以这个job比较适合临时跑一个任务，跑完之后就退出了，不再执行了。
CronJob
定时任务，像crontab一样，基于时间去调度，用来做备份还是蛮不错的，下面一个例子，也是在官方扒过来的，顺便改了改。
[root@k8s01 yml]# cat cronjob.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: opesn
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: opesn
image: centos:latest
command: ["bash","-c","date; echo opesn"]
restartPolicy: OnFailure
[root@k8s01 yml]#
schedule为时间表达式，和crontab的表达式写法是一样的，所以这个就是一分钟一次，重启策略为OnFailure，如果容器异常退出就会重启.
[root@k8s01 yml]# kubectl create -f cronjob.yaml
cronjob.batch/opesn created
[root@k8s01 yml]# kubectl get cronjobs.batch opesn
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
opesn */1 * * * * False 1 17s 59s
[root@k8s01 yml]# kubectl get pod
NAME READY STATUS RESTARTS AGE
opesn-1591347900-492v4 0/1 ContainerCreating 0 17s
[root@k8s01 yml]# kubectl logs opesn-1591347900-492v4
Fri Jun 5 09:05:22 UTC 2020
opesn
[root@k8s01 yml]#
[root@k8s01 yml]# kubectl get pod
NAME READY STATUS RESTARTS AGE
opesn-1591347900-492v4 0/1 Completed 0 107s
opesn-1591347960-4fn49 0/1 Completed 0 47s
[root@k8s01 yml]# kubectl logs opesn-1591347960-4fn49
Fri Jun 5 09:06:21 UTC 2020
opesn
[root@k8s01 yml]#
[root@k8s01 yml]# kubectl get pod
NAME READY STATUS RESTARTS AGE
opesn-1591347900-492v4 0/1 Completed 0 2m36s
opesn-1591347960-4fn49 0/1 Completed 0 96s
opesn-1591348020-4fs92 0/1 Completed 0 36s
[root@k8s01 yml]# kubectl logs opesn-1591348020-4fs92
Fri Jun 5 09:07:21 UTC 2020
opesn
[root@k8s01 yml]#
就是这种效果，创建成功后每分钟执行一次，历史默认保留三次
