我们知道 kubectl 是直接操作 APIServer 的，所以就相当于把我们的清单提交给了 APIServer，然后集群获取到清单
描述的应用信息后存入到 etcd 数据库中，然后 kube-scheduler 组件发现这个时候有一个 Pod 还没有绑定到节点
上，就会对这个 Pod 进行一系列的调度，把它调度到一个最合适的节点上，然后把这个节点和 Pod 绑定到一起（写回到
etcd），然后节点上的 kubelet 组件这个时候 watch 到有一个 Pod 被分配过来了，就去把这个 Pod 的信息拉取下
来，然后根据描述通过容器运行时把容器创建出来，最后当然同样把 Pod 状态再写回到 etcd 中去，这样就完成了一整个
的创建流程。
我们可以指定新创建的容器和一个已经存在的容器共享一个Network Namespace，在运行容器（假如是Docker容器）
的时候只需要指定#%net=container:目标容器名这个参数就可以了，但是这种模式有一个明显的问题那就是容器的启
动有先后顺序问题，那么Pod是怎么来处理这个问题的呢？那就是加入一个中间容器（没有什么架构是加一个中间件解决不
了的？），这个容器叫做Infra容器，而且这个容器在Pod中永远都是第一个被创建的容器，这样是不是其他容器都加
入到这个Infra容器就可以了，这样就完全实现了Pod中的所有容器都和Infra容器共享同一个Network
Namespace了，如下图所示
创建tocken
kubectl -n kubernetes-dashboard create token admin-user
kubectl get deployment
kubectl get deployment -l chapter=first-app 根据源数据标签去匹配
kubectl get pods -l app=nginx --watch 可以看到pod的滚动更新过程,创建一个新的pod，然后杀掉旧的pod 在创建一个新的pod 交替替换的
kubectl delete -f nginx.yaml
