Pod对象的IP地址仅在集群内可达，它们无法直接接收来自集群外部客户端的请求流量，尽管它们的服务可达性不受工作节点边界的约束，但依然受制于集群边界。不考虑通过Service资源进行服务暴露的情况下，服务于集群外部的客户端的常用方式有两种：一种是在其运行的节点上进行端口映射，由节点IP和选定的协议端口向Pod内的应用容器进行DNAT转发；另一种是让Pod共享其所在的工作节点的网络名称空间，应用进程将直接监听工作节点IP地址和协议端口。

任何在非本地回环接口lo上监听的端口都可直接通过Pod网络被请求。从这个角度来说，容器端口只是信息性数据，它仅为集群用户提供了一个快速了解相关Pod对象的可访问端口的途径，但显式指定容器的服务端口可额外为其赋予一个名称以方便按名称调用。定义容器端口的ports字段的值是一个列表，由一到多个端口对象组成，它的常用嵌套字段有如下：

containerPort ：必选字段，指定在Pod对象的IP地址上暴露的容器端口，有效范围为(0,65536)；使用时，需要指定为容器应用程序需要监听的端口。

name ：当前端口的名称标识，必须符合IANA_SVC_NAME规范且在当前Pod内要具有唯一性；此端口名可被Service资源按名调用。

protocol ：端口相关的协议，其值仅支持TCP、SCTP或UDP三者之一，默认为TCP。

hostPort与NodePort类型的Service对象暴露端口的方式不同，NodePort是通过所有节点暴露容器服务，而hostPort则能经由Pod对象所在节点的IP地址进行。但Pod对象绑定的工作节点都由调度器根据其调度机制确定，除非人为地指示调度器将其绑定到指定的工作节点，否则多数情况下其目标节点都难以预测。

由kubeadm部署的Kubernetes集群中的kube-apiserver、kube-controller-manager、kube-scheduler，以及kube-proxy和kube-flannel等通常运行于所在节点的名称空间中，执行系统级的管理任务。网络名称空间是Pod级别的属性，用户配置的Pod对象，仅需要设置其spec.hostNetwork的属性为true即可创建共享节点网络名称空间的Pod对象。