1. 说明

• 1.kubernetes中的service主要用于提供网络服务，并实现微服务架构中的几个核心功能：全自动的服务注册、服务发现、服务负载均衡等。
• 2.Service在kubernetes中代表了一组Pod的逻辑集合，为Pod提供了一个统一的访问地址和端口。
• 3.通过service的定义，可以对客户端应用屏蔽后端Pod实例数量及Pod IP地址的变化。
• 4.service能够对客户端的请求通过负载均衡策略转发到后端Pod实例，为客户端应用提供一个稳定的服务访问入口地址。

2. 原理

2.1 服务注册

• 1.创建service时，kubernetes会自动创建与service关联的Endpoints资源对象。
• 2.Endpoints对象用于存储Service对应的后端容器应用访问地址列表，即后端Pod的“IP:Port”列表。
• 3.这是由Endpoints Controller完成的，它负责生成和维护所有Endpoints对象。
• 4.Endpoints Controller会持续监听Service和对应的Pod副本列表的变化，在Pod列表发生变化时，实时更新对应的Service的Endpoints对象。

2.2 服务发现

• 1.Kubernetes提供了两种机制供客户端应用以固定的方式获取后端服务的访问地址：环境变量方式和DNS方式。
• 2.客户端Pod在创建时，系统会自动为其容器运行环境注入集群中所有有效Service的信息。
• 3.同时，能够感知集群的DNS服务器（例如CoreDNS）会监视Kubernetes API中的新Service，并为每个Service创建一组DNS记录。
• 4.客户端应用可以通过这两种方式发现需要访问的Service。

2.3 负载均衡

• 1.从Service虚拟IP到后端Pod的负载均衡机制，是由每个Node上的kube-proxy负责实现的。
• 2.kube-proxy可以通过iptables或IPVS模式来实现流量的转发和负载均衡。
• 3.iptables模式使用Linux netfilter处理流量，无需在用户空间和内核空间之间切换，系统开销较低。
• 4.而IPVS模式使用哈希表作为底层数据结构，在内核空间中生效，因此比iptables模式重定向流量的延迟更低，同步代理规则时性能也更好。

3. Service的类型

3.1 ClusterIP

• 1.这是默认的Service类型。
• 2.ClusterIP类型的Service仅在集群内部可访问，外部应用无法直接访问。
• 3.创建Service时，Kubernetes会为Service分配一个虚拟IP地址（ClusterIP），该IP地址仅在集群内部可访问。

3.2 NodePort

• 1.NodePort类型的Service除了在集群内部可访问之外，还可以通过节点的IP地址和NodePort端口号从外部访问。
• 2.创建Service时，Kubernetes会为Service分配一个NodePort端口号，该端口号在所有节点上都可用。
• 3.外部应用可以通过节点的IP地址和NodePort端口号访问Service。
• 4.但这种方式会在集群内每个节点上都占用一个端口，可能会浪费资源。

3.3 LoadBalancer

• 1.LoadBalancer类型的Service在支持LoadBalancer的公有云环境中使用。
• 2.云提供商会自动为这个Service配置一个负载均衡器，并将流量转发到Service的NodePort上。
• 3.这种方式需要额外的成本，例如云服务商的负载均衡器费用。

3.4 ExternalName

• 1.ExternalName类型的Service将Service的名称映射到一个外部域名，使得集群内部可以通过这个Service名称来访问外部的域名。

4. 使用场景

• 1.内部服务暴露：对于仅在集群内部使用的服务，可以使用ClusterIP类型的Service来暴露。
• 2.外部访问服务：对于需要从外部访问的服务，可以使用NodePort或LoadBalancer类型的Service。NodePort类型适用于小规模集群或测试环境，而LoadBalancer类型则适用于需要高可用性和可扩展性的生产环境。
• 3.引入外部服务：对于集群外部的服务，可以使用ExternalName类型的Service将其引入到集群内部来使用。