这篇文章开始讲一讲k8s中的namespace和pod，每篇文章写的内容没有很多，但是都是我要写的。
物理集群 VS 虚拟集群
不要被我这个小标题吓到了，这只是我自己的理解。所谓的物理集群指的是k8s运行的底层依赖物理环境，但是虚拟集群我认为则是namespace的功劳。
因为一个k8s集群可能有不同的业务，每个业务都需要放在一个单独的集群环境中，因此可以通过namespace进行分隔。
并且通过namespace我们可以给不同的虚拟集群分配不同的资源，确保每个业务都能够得到合理的资源，这里的资源指的是cpu、内存等。
默认已经有default、kube-public、kube-node-lease（用于master监视节点发送de心跳）、kube-system这几个命名空间，可以看到kube-system命名空间已经运行了多个pod了。
每个pod创建的时候都需要指定命名空间，否则默认是default命名空间，当然这是可以修改的。
pod内的容器类型
其实pod是一组容器的集合，或者说是一组容器的逻辑抽象，而不是实体。在pod中有pause容器，和pod的生命周期绑定。
pod的pause容器
pause为其他子容器提供共享的linux命名空间，比如共享的网络命名空间，这样容器间就可以通过本地就行互相访问。
写到这，好困！虽然是看着之前记录的笔记写的。
除了pause容器之外，还有init类型容器，sidecar并置容器。
主要是通过功能和作用来区分的：
init容器--k8s会先启动所有的init容器，按yml文件定义顺序一一启动，init容器成功退出才会启动下一个init容器或者主容器。
当然也有init容器启动失败的，那么就会根据spec.contaniers.restartPolicy重启策略来决定，Always表示不断重启，Never则会在重启失败的时候标记pod失败。
sidecar容器--Sidecar 和主容器通过 `localhost`直接通信（如主容器访问 Sidecar 的端口）。这其实就是前面提到的共享的网络空间
Kubernetes 不强制约束容器角色，而是通过共享资源（网络、存储卷）和协作逻辑实现功能。
也就是说sidecar容器并不是通过yml文件中的字段表明的，而是从作用上认定的。
静态pod--由kubelet管理的pod，而不是由api-server管理的，也就是说通过kubectl客户端命令工具通过api-server是无法讲该静态pod删除的，也不能创建静态pod，但是通过静态pod的镜像能够看到。
etcd还是会保存静态pod的状态的，还有配置。不过备份etcd数据库并不能还原静态节点，因为定义静态节点的yml文件并不归etcd管。而是由kubelet定期扫描manifests文件夹，进而创建或者删除静态pod。
这种设计主要用于集群引导、控制平面组件部署或特定节点的本地化服务。
下一节讲讲k8s中的控制器，请持续关注。