14 K8S 之对外访问容器服务
Pod 对象的 IP 地址仅在集群内可达,它们无法直接接收来自集群外部客户端的请求流量,尽管它们的服务可达性不受工作节点边界的约束,但依然受制于集群边界。不考虑通过 Service 资源进行服务暴露的情况下,服务于集群外部的客户端的常用方式有两种:一种是在其运行的节点上进行端口映射,由节点 IP 和选定的协议端口向 Pod 内的应用容器进行 DNAT 转发;另一种是让 Pod 共享其所在的工作节点的网络名称空间,应用进程将直接监听工作节点 IP 地址和协议端口。
任何在非本地回环接口 lo 上监听的端口都可直接通过 Pod 网络被请求。从这个角度来说,容器端口只是信息性数据,它仅为集群用户提供了一个快速了解相关 Pod 对象的可访问端口的途径,但显式指定容器的服务端口可额外为其赋予一个名称以方便按名称调用。定义容器端口的 ports 字段的值是一个列表,由一到多个端口对象组成,它的常用嵌套字段有如下:
containerPort <integer>:必选字段,指定在 Pod 对象的 IP 地址上暴露的容器端口,有效范围为(0,65536);使用时,需要指定为容器应用程序需要监听的端口。
name <string>:当前端口的名称标识,必须符合 IANA_SVC_NAME 规范且在当前 Pod 内要具有唯一性;此端口名可被 Service 资源按名调用。
protocol <string>:端口相关的协议,其值仅支持 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 对象。
版权声明: 本文为 InfoQ 作者【穿过生命散发芬芳】的原创文章。
原文链接:【http://xie.infoq.cn/article/3a4947698a4e3bc76fb818a68】。文章转载请联系作者。
评论