一张关系图让你理解K8s中的概念，Pod、Service、Job等到底有啥关系

查看原文得到更好阅读体验。

刚开始接触K8s的同窗可能都会以为有必定的学习难度，扑面而来的各类概念究竟是什么。好比，如何提供一个服务给别人，我是应该用Pod仍是用Deployment来运行个人应用等，在接下来的文章中，但愿可以解答你的这些疑惑。

Kubernetes能够看作云原生时代的操做系统，统一管理下层的基础设施，如计算资源、网络资源、存储资源等等。将集群中存在的各类复杂关系抽象成各类API资源，以统一的方式暴露出各类接口，也便于将来的扩展以及开发团队根据本身的须要定制。所以，咱们能够看到在K8s中Docker仅仅是容器运行时的一个实现而已，只要遵照它的约定，其实是能够替换为适合的其余容器技术的。基于这样的设计思路，理清各类API对象的做用和关系就变得很重要了，只有理解了才能正确地使用K8s，接下来咱们就经过一张关系图一点点的来讲明。

经过Pod终结单容器的蛮荒时代

在接触K8s以前，大多人首先要接触到的就是Docker。咱们获得一个容器的镜像以后，要把应用运行起来最简单的方式就是docker run的命令。然而在实际的生产环境中，不多仅靠一个单容器就可以知足。好比，一个Web前端的应用，可能还得依赖后端的一个容器服务；后端的容器可能须要数据库服务；后端的服务须要多副本等等场景。在这些假想的场景中，比较真实的需求就是这些容器应用须要共享同一个网络栈，同一个存储卷等，还有它们的生命周期如何管理调度。这个时候，仅仅依靠容器没法解决这个问题，咱们第一个选手Pod就闪亮登场了。

Pod 内共享配置

有了Pod以后，同一个Pod内的容器能够共享不少信息，也可能须要读取同一份配置。好比Pod内有两个容器须要访问同一个数据库，那么咱们能够把相关的配置信息写到ConfigMap里。那若是还有一些比较敏感的信息的话，就须要放到Secret对象中，它实际上是一个保存在 Etcd 里的键值对数据。这样，你把 Credential 信息以 Secret 的方式存在 Etcd 里，Kubernetes 就会在你指定的 Pod（好比，Web 应用的 Pod）启动时，自动把 Secret 里的数据以 Volume 的方式挂载到容器里。

任务和定时任务

有了Pod以后，事情就变得更清晰了。在集群内，咱们可能会有多种形式的要求。好比，咱们可能但愿一个应用天天固定时间运行或者只容许运行一次，可能但愿某个应用以守护进程的方式运行。在K8s里，天然也有方案来解决这些问题。
首先来看定时任务的需求，假设个人系统内有一个全网信息排行榜展现，要求天天须要在凌晨0点的时候更新一次。这个需求在K8s里就能够用CronJob来搞定。而若是仅仅须要执行一次的任务，那就直接使用Job对象就能够了。

默默工做的DaemonSet

再接下来，可能须要以守护进程的方式运行一个应用。好比，我想要在后台进行日志的收集。这个时候DaemonSet就派上了用场，它会保证在全部的目标节点上运行一个Pod的副本。在这期间，若是有新的Node加入到K8s集群中的话，它也会自动完成调度，在新的机器上运行一个Pod副本。所以，前面说的监控、日志等任务很适合用DaemonSet的方式执

Deployment管理Pod

说完DaemonSet，下一个重点Deployment来了。前面说过容器之间的关联关系、共享资源等问题须要处理，从而引入了Pod。对于Pod，也是一样的问题须要解决，只不太高了一个抽象层次罢了。由于面临Pod的生命周期管理、调度、多副本等问题须要解决，聪明的设计者引入了Deployment。它能够根据咱们的需求（好比经过标签）将Pod调度到目标机器上，调度完成以后，它还会继续帮咱们继续监控容器是否在正确运行，一旦出现问题，会马上告诉咱们Pod的运行不正常以及寻找可能的解决方案，好比目标节点不可用的时候它能够快速地调度到别的机器上去。另外，若是须要对应用扩容提高响应能力的时候，经过Deployment能够快速地进行扩展。

在实际的工做中，Deployment并非直接控制着Pod的，中间实际上还有一个ReplicaSet，可是在这里为了简化理解过程，能够先忽略。

提供容器服务

前面的内容主要是围绕着Pod自身的运行调度管理，下面面临的问题是解决如何将服务提供给第三方的问题。

• 对内提供服务

首先要解决的是将服务提供给同一个集群内的其余服务使用。可能刚入门的同窗会问为何咱们不能直接使用Pod的IP呢？缘由是这样，前面也说过Pod是会被管理调度的，可能被调度到不一样的机器上，同时生命周期也可能会发生变化。这致使一个应用的IP可能会随时发生变化，那么直接使用Pod的IP天然是不合理的。
针对这个问题K8s提供了Service对象来解决。

可是，并非说Service就有一个固定的IP。并且，它和Pod IP还有很不同的地方。Pod的网络是K8s在物理机上创建了一层Overlay Network实现的，并且在网卡上可以看到这个网络的地址。可是Service是一个彻底虚拟的网络层，并不会存在于任何网络设备上。它经过修改集群内部的路由规则，仅对集群内部有效。Deploment建立好应用以后，再为它生成一个Service对象。接下来就能够经过Service的域名访问到服务，形式是<Service Name>.<NameSpace>，好比你有为Deployment的应用建立了一个名为portal的Service在默认的命名空间，那么集群内想要经过Http访问这个应用，就可使用http://portal.default。这个域名仅在集群内有效，由于是内部的一个DNS负责解析。

• 对外提供服务

说完如何给内部提供服务之后，剩下的就是如何给外部提供服务了。在K8s里把这个叫作Ingress，正如其名，它是集群的入口。好比咱们的集群Web应用想要让用户可以访问，那必然要在Ingress入口上增长一条解析记录。这一点，熟悉像Nginx的朋友应该比较容易理解，事实上Nginx Ingress也是K8s生态中的一个成员。

关于Ingress的使用，在以前我曾写过一篇使用Traefik做为Ingress的文章，咱们能够经过Traefik实现为须要暴露的服务提供负载均衡、自动签发Https证书、限流等不少功能，若是有兴趣能够点击查看。