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可以将应用从集群中删除掉
