Pod本质上是共享Network、IPC和UTS名称空间以及存储资源的容器集合，我们可以把每个Pod对象想象成一个逻辑主机，它类似于现实世界中的物理主机或虚拟机，而运行于同一个Pod对象中多个进程则类似于物理机或虚拟机上独立运行的进程，不同的是，Pod中各进程运行于彼此隔离的容器中，并于各容器间共享网络和存储两种关键资源。

Service是由基于匹配规则在集群中挑选出的一组Pod对象的集合、访问这组Pod集合的固定IP地址，以及对请求进行调度的方法等功能所构成的一种API资源类型，是Pod资源的代理和负载均衡器。Service匹配Pod对象的规则可用“标签选择器”进行体现，并根据标签来过滤符合条件的资源对象。

Kubernetes使用定制的DNS服务为这类需求提供了自动的服务注册和服务发现功能。CoreDNS附件会为集群中的每个Service对象（包括DNS服务自身）生成唯一的DNS名称标识，以及相应的DNS资源记录，服务的DNS名称遵循标准的svc.namespace.svc.cluster-domain格式。

除非出于管理目的有意调整，Service资源的名称和ClusterIP在其整个生命周期内都不会发生变动。

控制器是支撑Kubernetes声明式API的关键组件，它持续监视对API Server上的API对象的添加、更新和删除等更改操作，并在发生此类事件时执行目标对象相应的业务逻辑，从而将客户端的管理指令转为对象管理所需要的真正的操作过程。简单来说，一个具体的控制器对象是一个控制循环程序，它在单个API对象上创建一个控制循环以确保该对象的状态符合预期。

Kubernetes的网络中存在4种主要类型的通信：同一Pod内的容器间通信、各Pod彼此间通信、Pod与Service间的通信以及集群外部的流量与Service间的通信。

节点网络：各主机（Master和Node）自身所属的网络，相关IP地址配置在节点的网络接口，用于各主机之间的通信，例如Master与各Node间的通信。此地址配置在Kubernetes集群构建之前，它并不能由Kubernetes管理，需要管理员在集群构建之前就自行确定其地址配置及管理方式。

Pod网络：Pod对象所属的网络，相关地址配置在Pod网络接口，用于各Pod间的通信。Pod网络是一种虚拟网络，需要通过传统的kubenet网络插件或新式的CNI网络插件实现，常见的实现机制有Overlay和Underlay两种。

Service网络：一个虚拟网络，相关地址不会配置在任何主机或Pod的网络接口之上，而是通过Node上的kube-proxy配置为节点的iptables或ipvs规则，进而将发往此地址的所有流量调度至Service后端的各Pod对象之上；Service网络在Kubernetes集群创建时予以指定，而各Service的地址则在用户创建Service时予以动态配置。

kubernetes集群上的服务大致可分为两种：API Server和服务类应用，它们的客户端要么来自集群内的其他Pod，要么来自集群外部的用户或应用程序。前一种通信通常发生在Pod网络和Service网络之上的东西向流量；而后一种通信，尤其是访问运行于Pod中的服务类应用的南北向流量，则需要先经由集群边界进入集群内部的网络中，即由节点网络到达Service网络和Pod网络。

Service在协议栈的TCP层完成调度，而Ingress则是基于HTTP/HTTPS协议的边缘路由。