-
kubernetes支持两种创建资源的方式:
-
用kubectl命令直接创建,比如:kubectl run nginx-deployment --image=nginx1.7.9 --replicas=2,在命令行中通过参数指定资源的属性
-
通过配置文件和kubectl apply创建,创建nginx.yml文件,然后运行命令:kubectl apply -f nginx.yml
-
比较:
- 基于命令的方式:简单,直观,快捷,上手快
- 基于配置文件的方式:配置文件描述了最终要达到的状态,提供了创建资源的模板,能够重复部署,可以像管理代码一样管理部署,适合正式的,跨环境的,规模化部署
-
-
配置文件介绍:
- apiVersion: extensions/v1beta1:apiVersion是当前配置格式的版本
- kind: Deployment:kind是要创建的资源类型,这里是Deployment
- metadata:是该资源的元数据,name是必须的元数据项
- spec:是该Deployment的规格说明
- replicas:指明副本数量,默认为1
- template:定义Pod的模板,这是配置文件的重要部分
- metadata:定义Pod的元数据,至少要定义一个label,label的key和value可以任意指定
- spec:描述Pod的规格,此部分定义Pod中每一个容器的属性,name和image是必须的
-
删除资源:执行kubectl delete deployment nginx-deployment或者kubectl delete -f nginx.yml
-
伸缩:
-
伸缩是指在线增加或减少Pod的副本数
-
Deployment nginx-deployment初始是两个副本,k8s-node1和k8s-node2各跑了一个副本,现在修改nginx.yml文件,将副本数改为5个
-
再次执行kubectl apply,进行应用的部署,然后执行kubectl get pod -o wide查看pod状态,调度器会根据集群的资源和指定的调度策略(如亲和性规则、亲缘关系和反亲缘性)来选择合适的节点分配pod副本
-
三个副本被创建并调度到节点1和节点2上,出于安全考虑,默认配置下kubernetes不会将Pod调度到Master节点上,如果希望将master也当做Node使用,可以执行命令:kubectl taint node k8s-master node-role.kubernetes.io/master- 。如果要回复Master node only状态,执行命令:kubectl taint node k8s-master node-role.kubernetes.io/master=“”:NoSchedule
-
-
Failover:
-
模拟k8s-node2故障,关闭该节点,等待一段时间后,kubernetes会检查到k8s-node2不可用,将k8s-node2上的pod标记为Unknown状态,并在k8s-node1上新创建k8s-node2上的数量的pod,维持副本数不变
-
当k8s-node2恢复后,Unknown的Pod会被创建,不过已经运行的Pod不会重新调度回k8s-node2
-
-
用label控制pod的位置
-
默认配置下,scheduler会将pod调度到所有可用的node,不过如果将有大量磁盘IO的pod部署到配置了SSD的Node,或者Pod需要GPU,需要运行在配置了GPU的节点上,希望将Pod部署到指定的Node上
-
kubernetes通过label来实现这个功能
-
label是key-value对,各种资源都可以设置label,灵活添加各种自定义属性,比如执行命令标注k8s-node1是配置了SSD的节点
-
kubectl label node k8s-node1 disktype=ssd,然后通过kubectl get node --show-labels查看节点的label
-
部署pod到node1:在pod模板中,spec中通过nodeSelector指定将次pod部署到具有label disktypessd的Node上
-
部署Deployment并查看Pod的运行节点,可以看到全部6个副本都运行在node1上
-
删除label disktype命令:kubectl label node k8s-node1 disktype- 这个- 就是删除的意思。不过此时的Pod并不会重新部署,依然在k8s-node1上运行。除非在nginx.yml中删除nodeSelector设置,然后通过kubectl apply重新部署。kubernetes会删除之前的Pod并调度和运行新的Pod
-
-
DaemonSet:
-
Deployment部署的副本Pod会分布在各个Node上,每个Node都可能运行好几个副本,DaemonSet的不同之处在于:每个Node上最多只能运行一个副本
-
DaemonSet的应用场景有:
- 在集群的每个节点上运行存储Daemon,比如glusterd或者ceph分布式存储系统
- 在每个节点上运行日志收集Daemon,比如flunentd或者logstash
- 在每个节点上运行监控Daemon,比如Prometheus Node Exporter或者collectd
-
kubernetes自己就在用DaemonSet运行系统组件,执行命令:kubectl get daemonset --namespace=kube-system
-
查看详细信息:kubectl get pod --namespace=kube-system -o wide
-
因为flannel和kube-proxy属于系统组件,需要在命令行中通过–namespace=kube-system指定namespace指定namespace kube-system,若不指定,则只返回默认namespace default中的资源
-
-
kube-flannel-ds:
-
部署flannel网络的命令:kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml。
-
flannel的DaemonSet就定义在kube-flannel.yml中
-
配置解析
- DaemonSet配置文件的语法和结构与Deployment几乎完全一样,只是将kind设为DaemonSet
- hostNetwork指定Pod直接使用的是Node网络,相当于docker run --network=host
- containers定义了运行flannel服务的两个容器
-
-
kube-proxy:
-
通过命令:kubectl edit daemonset kube-proxy --namespace=kube-system查看配置
-
配置解析:
- kind:DaemonSet指定这是一个DaemonSet类型的资源
- containers定义了kube-proxy的容器
- status是当前DemonSet的运行时状态,这个部分是kubectl edit特有的,
- kubernetes集群中每个当前运行的资源都可以通过kubectl edit查看其配置和运行状态,比如:kubectl edit deployment nginx-deployment
-
-
Job:
-
容器按照持续运行的时间可分为两类,服务类容器,和工作类容器
-
服务类容器通常持续提供服务,需要一直运行,比如HTTP,Server,Daemon等,
-
工作类容器则是一次性任务,比如批处理程序,完成后容器就退出
-
kubernetes的Deployment,ReplicaSet和DaemonSet都用于管理服务类容器,对于工作类容器,使用Job
-
myjob.yam配置解析
- batch/v1是当前Job的apiVersion
- 指明当前资源的类型为Job
- restartPolicy指定什么情况下需要重启容器,对于Job,只能设置为Never或者OnFailure,对于其他controller,比如Deployment,可以设置为Always
- 通过kubectl apply -f myjob.yml启动Job
-
通过kubectl get job 查看Job的状态
-
desired和successful都为1,表示按照预期启动了一个pod,并且已经成功执行,通过kubectl get pod 查看pod的状态
-
因为pod执行完毕后容器已经退出,需要用–show-all才能看到Completed状态的Pod
-
通过kubectl logs可以查看Pod的标准输出
-
-