kubectl是直接操作APTServer的,所以就相当于我们的清单提交给APIServer,然后集群获取到清单描述的应用信息后存入etcd数据库中,然后kube-scheduler组件发现一有一个pod还没绑定到节点上,就会对这个pod进行一系列的调度,把他调度到一个合适的节点上,这个合适可以是pod上约束也可以是node约束,后面讲。
调度好后,把这个节点和pod绑定到一起,回写etcd,然后节点上的kubelet组件这个时候watch到一个pod被分配过来了,就去吧这个pod的信息拉取下来,然后根据描述通过容器运行时,可以使docker也可以是其他的,把容器创建起来,最后当然同样吧pod状态写回etcd,完成创建流程。
apiVersion: apps/v1 //头部信息 kind: Deployment metadata: name: nginx-deploy
labels: chapter: first-app //标签 spec: selector: //选择器 matchLabels: app: nginx
//此处需要跟pod模板相同 replicas: 2 //副本数量 template: //pod模板 metadata: labels: app:
nginx spec: containers: - name : nginx image: nginx:latest //指定容器镜像名 ports: -
containerPort: 80 //容器内部端口
kubectl get pods 查看pod
此时修改replicas就会想象pod的副本数量,yaml第一次生成显示create,提交变更configured
看到集群上按照replicas:value的数量,生产pod,而整个资源清单文件对应到kubernetes中就是一个API Object
API对象,我们按照这些对象的要求填充上对应的属性后,提交给kubernetes集群,就可以为我们创建出对应的资源对象,比如我们这里定义的是一个deployment类型的API对象。
kubectl get deploy
deployment这个资源对象就是用于定义多个副本应用的对象,而且还支持对每个副本进行滚动更新,另外就是我们刚才提到的replicas:4
而这个deployment定义的副本pod具体是什么样的,是通过下面的pod模板来定义的,就是template下面定义的,这个template定义pod中只有一个名nginx的容器,容器使用的镜像是nginx:1.7.9,容器监听的端口是80,另外我们还为pod添加了一个app:nginx这样的label标签。
selector: matchLables: app: nginx
deployment来管理那些pod,所以这个地方需要和pod模板中的label标签保持一致,这个label标签保持一致,这个label标签之前我们也可提到是
到这里我们就完成了我们的第一个应用的容器化部署,但是往往我们在部署应用的过程中会遇到问题
修改了镜像的版本
kubectl describe pod #podname
我们可以看到很多这个pod的详细信息,比如调度的节点,状态,ip等。kubernetes创建资源对象的过程中,对该对象的一些重要操作,都会被记录在这个对象的enents里面,可以通过kubectl
describe指令查看对应的结果。nginx:latest后,重新 kubectl apply -f
左侧
kubectl get pod -l app=nginx --watch //夯住
右侧更新yaml文件,就可以看见pod的更新过程,可以看到更新过程是先terminating-pending-containercreating,这就是我们所说的滚动更新,滚动更新对于我们的应用持续提供服务是非常重要的手段。
kubelet delete -f yaml可以将应用从集群中删除掉