ClusterIP、NodePort、LoadBalancer 和 ExternalName

Service 定义

在 Kubernetes 中,由于Pod 是有生命周期的,如果 Pod 重启它的 IP 可能会发生变化以及升级的时候会重建 Pod,我们需要 Service 服务去动态的关联这些 Pod 的 IP 和端口,从而使我们前端用户访问不受后端变更的干扰。

Service 原理

Kubernetes 在创建 Service 时,会根据标签选择器 Label Selector 来寻找 Pod,找到 Pod 后,会建立 Endpoint 映射表,存放 Pod 的端口和 IP 。当 Pod 发生变化时,Endpoint 也会更新它的映射关系,这样 Service 接收前端 Client 请求的时候,就会通过 Endpoint,找到最终需要转发到哪个 Pod 进行访问。Endpoint 和 Service 是同名的,这里的具体实现是靠kube-proxy完成的。

同时,由于 Kubernetes 内部有一个 DNS Server,我们可以在 Pod 容器内以【服务名.命名空间.域名后缀】的方式访问服务名称,这样也不需要固定的 Service IP 了,默认域名后缀是 svc.cluster.local

Kubernetes 的 Service 共有四种类型:ClusterIP、NodePort、LoadBalancer 和 ExternalName。

ClusterIP: 此为默认的 Service 类型,自动分配一个仅 Cluster 内部可以访问的虚拟 IP。

NodePort: 这种类型建立在 ClusterIP 类型之上,其在每个节点的 IP 地址的某静态端口(NodePort)暴露服务,因此,它依然会为 Service 分配集群 IP 地址,并将此作为 NodePort 的路由目标。这种类型的 Servcie 既可如 ClusterIP 一样受到集群内部客户端 Pod 的访问,也会受到集群外部客户端通过套接字 <NodeIP>:<NodePort> 进行的请求。

NodePort 即节点 Port,通常在安装部署 Kubernetes 集群系统时会预留一个 端口范围用于 NodePort,默认为 30000~32767 之间的端口。

LoadBalancer:这种类型建立在 NodePort 类型之上,其通过 cloud provider 提供的负载均衡器将服务暴露到集群外部,因此 LoadBalancer 一样具有 NodePort 和 ClusterIP。简单的说,就是一个 LoadBalancer 类型的 Service 会指向关联至 Kubernetes 集群外部的、切实存在的某个负载均衡设备,该设备通过工作节点之上的 NodePort 向集群内部发送请求流量。

EXternalName:其通过将 Service 映射至由 externalName 字段的内容指定的主机名来暴露服务,此主机名需要被 DNS 服务解析至 CNAME 类型的记录。此种类型并非定义由 Kubernetes 集群提供的服务,而是把集群外部的某服务以 DNS CNAME 记录的方式映射到集群内,从而让集群内的 Pod 资源能够访问外部的 Service 的一种实现方式。因此,这种类型的 Service 没有 CluserIP 和 NodePort,也没有标签选择器用于选择 Pod 资源,因此也不会有 Endpoints 存在。

port

  • port是k8s集群内部访问service的端口(service暴露在Cluster IP上的端口),即通过clusterIP: port可以访问到某个service
nodePort
  • nodePort是外部访问k8s集群中service的端口,通过nodeIP: nodePort可以从外部访问到某个service。

比如外部用户要访问k8s集群中的一个Web应用,那么我们可以配置对应service的type=NodePort,nodePort=30001。其他用户就可以通过浏览器http://node:30001访问到该web服务。而数据库等服务可能不需要被外界访问,只需被内部服务访问即可,那么我们就不必设置service的NodePort

TargetPort
  • targetPort 是pod的端口,从port和nodePort来的流量经过kube-proxy流入到后端pod的targetPort上,最后进入容器。
containerPort
  • containerPort是pod内部容器的端口,targetPort映射到containerPort。
hostPort

这是一种直接定义Pod网络的方式。hostPort是直接将容器的端口与所调度的节点上的端口路由,这样用户就可以通过宿主机的IP加上来访问Pod了,如

这样做有个缺点,因为Pod重新调度的时候该Pod被调度到的宿主机可能会变动,这样就变化了,用户必须自己维护一个Pod与所在宿主机的对应关系。 使用了 hostPort 的容器只能调度到端口不冲突的 Node 上,除非有必要(比如运行一些系统级的 daemon 服务),不建议使用端口映射功能。如果需要对外暴露服务,建议使用 NodePort Service。

总的来说,port和nodePort都是service的端口,前者暴露给集群内客户访问服务,后者暴露给集群外客户访问服务。从这两个端口到来的数据都需要经过反向代理kube-proxy流入后端 pod的targetPod,从而到达pod上的容器内。

Endpoint

创建Service的同时,会自动创建跟Service同名的Endpoints。

Endpoint 是k8s集群中一个资源对象,存储在etcd里面,用来记录一个service对应的所有pod的访问地址。service通过selector和pod建立关联。

Endpoint = Pod IP + Container Port

service配置selector endpoint controller 才会自动创建对应的endpoint 对象,否则是不会生产endpoint 对象

一个service由一组后端的pod组成,这些后端的pod通过service endpoint暴露出来,如果有一个新的pod创建创建出来,且pod的标签名称(label:pod)跟service里面的标签(label selector 的label)一致会自动加入到service的endpoints 里面,如果pod对象终止后,pod 会自动从edponts 中移除。在集群中任意节点 可以使用curl请求service <CLUSTER-IP>:<PORT>

相关推荐
小安运维日记1 天前
Linux云计算 |【第五阶段】CLOUD-DAY8
linux·运维·docker·云计算·k8s·学习方法
少陽君3 天前
k8s Sidecar代理
运维·云原生·容器·kubernetes·k8s
小云小白3 天前
springboot 传统应用程序,适配云原生改造
云原生·系统架构·k8s·springboot
小安运维日记4 天前
Linux云计算 |【第五阶段】CLOUD-DAY7
linux·运维·docker·云计算·k8s·podman
小安运维日记4 天前
Linux云计算 |【第五阶段】CLOUD-DAY9
linux·运维·docker·云计算·k8s·改行学it
Stride Max Zz5 天前
k8s技术全景:架构、应用与优化
云原生·k8s
为什么这亚子5 天前
六、Go语言快速入门之数组和切片
开发语言·后端·python·云原生·golang·kubernetes·k8s
小安运维日记6 天前
Linux云计算 |【第五阶段】CLOUD-DAY10
linux·运维·云计算·k8s·grafana·prometheus
为什么这亚子6 天前
三、k8s快速入门之Kubectl 命令基础操作
云原生·容器·kubernetes·k8s
小安运维日记6 天前
Linux云计算 |【第五阶段】CLOUD-DAY6
linux·运维·服务器·docker·云计算·k8s