Rohn

Blog:博客园 个人
参考:Service | Kubernetes、《Kubernetes进阶实战》

有了 Workload,我们可以方便地管理多实例的应用,但是要想能够方便地访问应用,我们还需要一个类似于 负载均衡 的资源来分发请求,在 kubernetes 中,有两个资源负责这个功能,分别是 Service 以及 Ingress。其中 Service 主要负责集群内部的访问,而 Ingress 主要负责来自集群外部的访问。

Kubernetes Service从逻辑上代表了一组Pod(通常称为微服务),具体是哪些Pod则是由label来挑选的(selector)。Service有自己的IP,而且这个IP是不变的。客户端只需要访问Service的IP,Kubernetes则负责建立和维护Service与Pod的映射关系。无论后端Pod如何变化,对客户端不会有任何影响,因为Service没有变。

举个例子,考虑一个图片处理后端,它运行了 3 个副本。这些副本是可互换的 —— 前端不需要关心它们调用了哪个后端副本。 然而组成这一组后端程序的 Pod 实际上可能会发生变化, 前端客户端不应该也没必要知道,而且也不需要跟踪这一组后端的状态。

Service 定义的抽象能够解耦这种关联。

Service类型

Service有4种类型:

  • ClusterIP:通过集群的内部 IP 暴露服务,选择该值时服务只能够在集群内部访问。 这也是默认的 ServiceType
  • NodePort:通过每个节点上的 IP 和静态端口(NodePort)暴露服务。 NodePort 服务会路由到自动创建的 ClusterIP 服务。 通过请求 <节点 IP>:<节点端口>,你可以从集群的外部访问一个 NodePort 服务。
  • LoadBalancer:使用云提供商的负载均衡器向外部暴露服务。 外部负载均衡器可以将流量路由到自动创建的 NodePort 服务和 ClusterIP 服务上。
  • ExternalName:通过返回 CNAME 和对应值,可以将服务映射到 externalName 字段的内容(例如,foo.bar.example.com)。 无需创建任何类型代理。

总体来说,若需要将Service资源发布至集群外部,应该将其配置为NodePort或Load-Balancer类型,而若要把外部的服务发布于集群内部供Pod对象使用,则需要定义一个ExternalName类型的Service资源,只是这种类型的实现要依赖于v1.7及更高版本的Kubernetes。

相关文章: