具体怎么部署Pod里面的容器，是按照我们项目的特性和资源的分配进行合理选择的。
pause容器：
Pause容器 全称infrastucture container（又叫infra）基础容器，作为init pod存在，其他pod都会从pause 容器中fork出来，这个容器对于Pod来说是必备的
一个Pod中的应用容器共享同一个资源：
PID命名空间：Pod中的不同应用程序可以看到其他的应用程序的进程ID
网络命名空间：Pod中的多个容器能够访问同一个IP和端口范围
IPC命名空间：Pod的多个容器能够使用，SystemV IPC或POSIX消息队列进行通信
UTS命名空间：Pod中的多个容器共享一个主机名；Volumes（共享存储卷）
Pod中的各个容器可以访问在Pod级别定义的Volumes
在上图中如果没有pause容器，我们的Nginx和Ghost，Pod内的容器想要彼此通信的话，都需要使用自己的IP地址和端口，才可以彼此进行访问，如果有pause容器，对于整个Pod来说，我们可以看做一个整体，也就是我们的Nginx和Ghost直接使用localhost就可以进行访问了，他们唯一不同的就只是端口，这里面可能看着觉得比较简单，但其实是使用了很多网络底层的东西才实现的，感兴趣的小伙伴可以自行了解一下。
Service(服务)
在 Kubernetes 中，每个Pod都会被分配一个单独的IP地址，但是Pod和Pod之间，是无法直接进行交互的，如果想要进行网络通信，必须要通过另外一个组件才能交流，也就是我们的 Service
Service 是服务的意思，在K8S中Service主要工作就是将多个不同主机上的Pod，通过Service进行连通，让Pod和Pod之间可以正常的通信
我们可以把Service看做一个域名，而相同服务的Pod集群就是不同的ip地址，Service 是通过 Label Selector 来进行定义的。
Service 拥有一个指定的名字，类似于域名这种，并且它还拥有一个虚拟的IP地址和端口号，只能内网进行访问，如果Service想要进行外网访问或提供外网服务，需要指定公共的IP和NodePort或者外部的负载均衡器。
使用NodePort提供外部访问，只需要在每个Node上打开一个主机的真实端口，这样就可以通过Node的客户端访问到内部的Service。
Label(标签)
Label 一般以 kv的方式附件在各种对象上，Label 是一个说明性的标签，它有着很重要的作用，我们在部署容器的时候，在哪些Pod进行操作，都需要根据Label进行查找和筛选，我们可以理解Label是每一个Pod的别名，只有取了名称，作为K8S的Master主节点才能找到对应的Pod进行操作。
Replication Controller(复制控制器)
存在Master主节点上，这个兄弟的作用主要是对Pod的数量进行监控，比如我们在下面的节点中我们需要三个相同属性的Pod，但是目前只有两个，当Replication Controller看到只有两个的时候，就会自动帮助我们按照我们制定的规则创建一个额外的副本，放到我们的节点中。
Replication Controller还可以对Pod进行实时监控，当我们某一个Pod它失去了响应，这个Pod就会被剔除，如果我们需要，Replication Controller会自动创建一个新的
Kubernetes通过RC中定义的Lable筛选出对应的Pod实例，并实时监控其状态和数量，如果实例数量少于定义的副本数量（Replicas），则会根据RC中定义的Pod模板来创建一个新的Pod，然后将此Pod调度到合适的Node上启动运行，直到Pod实例数量达到预定目标。
K8S的总体架构
Kubernetes将集群中的机器划分为一个Master节点和一群工作节点（Node）
Master节点上运行着集群管理相关的一组进程etcd、API Server、Controller Manager、Scheduler，后三个组件构成了Kubernetes的总控中心，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，并且全都是自动完成。
Node上运行kubelet、kube-proxy、docker三个组件，是真正支持K8S的技术方案。负责对本节点上的Pod的生命周期进行管理，以及实现服务代理的功能。
用户通过 Kubectl提交一个创建 Replication Controller请求，这个请求通过 API Server 写入 etcd 中，这个时候Controller Manager通过 API Server的监听到了创建的命名，经过它认真仔细的分析以后，发现当前集群里面居然还没有对应的Pod实例，赶紧根据Replication Controller模板定义造一个Pod对象，再通 过Api Server 写到我们 etcd 里面
到下面，如果被Scheduler发现了，好家伙不告诉我？？？，无业游民，这家伙一看就不是一个好人啊，它就会立即运行一个复杂的调度流程，为这个新的Pod选一个可以落户的Node，总算有个身份了，真是让人操心，然后通过 API Server 将这个结果也写到etcd中，随后，我们的 Node上运行的小管家Kubelet进程通过 API Server 检测到这个 新生的小宝宝——“Pod”，就会按照它，就会按照这个小宝宝的特性，启动这个Pod并任劳任怨的负责它的下半生，直到Pod的生命结束。
然后我们通过Kubectl提交一个新的映射到这个Pod的Service的创建请求，Controller Manager会通过Label标签查询到相关联的Pod实例，生成Service的Endpoints的信息，并通过 API Server 写入到etcd中，接下来，所有Node上运行的Proxy进程通过 Api Server 查询并监听Service对象与其对应的Endpoints信息，建立一个软件方式的负载均衡器来实现Service访问到后端Pod的流量转发功能。
kube-proxy： 是一个代理，充当这多主机通信的代理人，前面我们讲过Service实现了跨主机、跨容器之间的网络通信，在技术上就是通过kube-proxy来实现的，service是在逻辑上对Pod进行了分组，底层是通过kube-proxy进行通信的
kubelet： 用于执行K8S的命令，也是K8S的核心命令，用于执行K8S的相关指令，负责当前Node节点上的Pod的创建、修改、监控、删除等生命周期管理，同时Kubelet定时“上报”本Node的状态信息到API Server里
etcd： 用于持久化存储集群中所有的资源对象，API Server提供了操作 etcd的封装接口API，这些API基本上都是对资源对象的操作和监听资源变化的接口
API Server ： 提供资源对象的操作入口，其他组件都需要通过它提供操作的API来操作资源数据，通过对相关的资源数据“全量查询”+ “变化监听”，可以实时的完成相关的业务功能。
Scheduler ： 调度器，负责Pod在集群节点中的调度分配。
Controller Manager： 集群内部管理控制中心，主要是实现 Kubernetes集群的故障检测和恢复的自动化工作。比如Pod的复制和移除，Endpoints对象的创建和更新，Node的发现、管理和状态监控等等都是由 Controller Manager完成。
总结
到这里K8S的基本情况我们就讲解完毕了，有喜欢的小伙伴记得 点赞关注，相比如Docker来说K8S有着更成熟的功能，经过谷歌大量实践的产物，是一个比较成熟和完善的系统。
关于K8S大家有什么想要了解或者疑问的地方欢迎大家留言告诉我。
我是牧小农，一个卑微的打工人，如果觉得文中的内容对你有帮助，记得一键三连，你们的三连是小农最大的动力。
—— 怕什么真理无穷，进一步 有进一步的欢喜，大家加油~
