--昨夜西风凋碧树,独上高楼,望尽天涯路
-
Deployment
部署一个应用,配置文件如下:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-yml
spec:
replicas: 2
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx
通过kubectl apply -f nginx.yml运行:
通过kubectl get pod -o wide查看,已经在两个node节点上运行了pod。
1)弹性伸缩
修改配置文件如下:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-yml
spec:
replicas: 6
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx
目前是两个node节点上各运行一个副本,修改运行副本数后再次执行kubectl apply:
此时已将在原来的基础上动态的增加了4个副本在两个节点上。再次修改配置文件中的replicas为3,执行kubectl apply发现:
可以看到两个副本被删除。
2)Failove
通过在node2虚拟机上执行halt -h模拟node2宕机:
在master上查看node和Pod,发现原先只想在node2上面的两个副本已经标价为Unknown,并且在node1上面生成了两个副本:
重启node2之后再次查看pod发现,Unknown的Pod会被删除,运行在node1的副本不会调度货到node2:
3)label
默认情况下,Scheduler会将Pod调度到所有可用的Node。有时候我们需要根据host的配置以及性能需要将不同的Pod部署到不同的Node
Kubernetes通过label来实现这个功能。label是key-value对,各种资源都可以设置label,灵活添加各种自定义属性。
通过kubectl label node 给node添加label;通过kubectl get node --show-labels查看节点的label
查看node的label发现label已经添加到node中,下面编辑配置文件指定label,运行应用:
此时所有的Pod都部署到了label为cputype=niubi的node节点上
通过kubectl label node 192.168.46.191 cputype-来删除node上面的label(删除label之后部署的副本并不会重新分配,必须修改配置文件,重新kubectl apply才会重新部署Pod):
-
DaemonSet
Deployment部署的Pod会分布在各个Node上,并且每个Node可以同事运行好几个副本。DaemonSet则是每个Node上最多只能运行一个副本
DaemonSet的典型应用场景有:
1)在集群的每个节点上运行存储Daemon,比如glusterd或ceph
2)在每个节点上运行日志收集Daemon,比如flunentd或logstash
3)在每个节点上运行监控Daemon,比如Prometheus Node Exporter或collectd
kubernetes的网络组件flannel实际上就是通过DaemonSet运行的
通过kubectl get daemonset --namespace=kube-system查看:
通过 kubectl edit daemonset kube-flannel-ds --namespace=kube-system查看系统namespace下的kube-flannel-ds的配置文件发现kind类型为DaemonSet:
-
Job
容器按照持续运行的时间可分为两类:服务类容器和工作类容器 。
服务类容器通常持续提供服务,需要一直运行,例如Nginx,数据库。
工作类容器是一次性任务,例如批处理程序,完成后程序就退出。
Kubernetes的Deployment、ReplicaSet和DaemonSet都用于管理服务类容器;Job管理工作类容器。
编写一个kind为job的配置文件(restartPolicy指定什么情况下需要重启容器。对于Job,只能设置为Never或者OnFailure。对于其他controller,可以设置为Always):
kubectl apply该Job:
查看运行Job的信息,发现STATUS已经为completed
通过kubectl logs查看运行中Pod的日志
删除Job:
Job失败后的情况:
修改yml配置文件,引入一个错误之后:
运行应用,并且查看发现SUCCESS数目为0以及STATUS为ContainerCannotRun:
但是为什么kubectl get pod会看到这么多失败的Pod呢?
由于第一个Pod启动时,容器失败退出,根据restartPolicy:Never,此失败容器不会被重启,但Job DESIRED的Pod是1,目前SUCCESSF为0,不满足,所以Job会不断重启新的Pod直到SUCCESS为1。
修改配置文件中的restartPolicy为OnFailure,再启动应用:
查看发现,成功数为0,STATUS为RunContainerError,并且正在不断重启
Job的并行性:
当需要同时运行多个Pod,提高Job的执行效率的时候。可以通过parallelism设置:
apiVersion: batch/v1
kind: Job
metadata:
name: job
spec:
parallelism: 2
template:
metadata:
name: job
spec:
containers:
- name: busybox
image: busybox
command: ["echo", "我是要成为海贼王的男人"]
restartPolicy: OnFailure
设置并行数量为2,执行:
Job一共启动了两个Pod,而且AGE相同,并行运行
还可以通过completions设置Job的总数,每次运行两个Pod,直到6个Pod完成:
定时Job:
Kubernetes的CronJob提供了定时任务的功能,配置文件如下
schedule指定每分钟启动一次,jobTemplate定义Job的模板
apiVersion: batch/v2alpha1
kind: CronJob
metadata:
name: cronJob
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: cronJob
image: busybox
command: ["echo", "我是要成为海贼王的男人"]
restartPolicy: OnFailure
运行发现:
这是由于Kubernetes默认没有开启CronJob,修改kube-apiserver的配置文件/etc/kubernetes/apiserver,kube-apiserver本身也是一个Pod,在启动参数中加上--runtime-config=batch/v2alpha1=true
通过 systemctl restart kube-apiserver重启kube-apiservber,通过kubectl api-versions查看发现已经添加:
再次运行,发现报错:
这是由于配置文件中的name不允许出现大写字母,修改配置文件:
再次启动并查看:
发现每隔一分钟启动一个定时任务,查看log: