服务发现

服务发现模式提供了一个稳定的端点，在这个端点上，服务的客户端可以访问提供服务的实例。为此，Kubernetes提供了多种机制，这取决于服务消费者和生产者是位于集群上还是不在集群上。

背景

部署在Kubernetes上的应用程序很少独立存在，它们必须与集群内的其他服务或集群外的系统交互。内部发起的交互通常通过轮询消费者执行:应用程序在启动后或之后连接到另一个系统并开始发送和接收数据。典型的例子是，在Pod中运行的应用程序到达文件服务器并开始使用文件，或连接到消息代理并开始接收或发送消息，或连接到关系数据库或键值存储并开始读写数据。最常见的形式是来自集群或外部系统中的其他pod的传入HTTP连接。在这些情况下，服务消费者需要一种机制来发现由调度器动态放置的Pods，这些Pods有时可以弹性伸缩。 也就是微服务间的服务交互如何处理。其中包含微服务中不同服务间的服务发现以及应用级别的服务发现- ingress。

综述

k8s集群内部的服务发现机制

1.环境变量的设置，自动注入.

2.DNS查找发现服务

kubectl get endpoints app_name/service_name Kubernetes运行一个DNS服务器，所有pod都是自动配置使用的。此外，当一个新的服务被创建时，它会自动获得一个新的DNS条目，所有的Pods都可以开始使用。假设客户端知道它想要访问的服务的名称，它可以通过一个完全限定的域名(FQDN)到达服务，比如random-generator.default.svc.cluster.local。这里，random-generator是服务的名称，default是命名空间的名称，svc表示它是一个服务资源和集群。Local是特定于集群的后缀。如果需要，可以省略集群后缀，当从同一个名称空间访问服务时，也可以省略名称空间。 DNS发现机制没有基于环境变量的机制的缺点，因为DNS服务器允许在定义一个服务时将所有服务查询到所有的Pods。但是，如果端口号不是标准的或服务使用者不知道，您可能仍然需要使用环境变量来查找要使用的端口号。

内部服务访问外部服务

当我们创建一个带有选择器的服务时，Kubernetes会在端点资源列表中跟踪匹配和准备服务的Pods列表。例如12-1，你可以使用kubectl get endpoint random-generator检查代表服务创建的所有端点。我们也可以将连接重定向到外部IP地址和端口，而不是将连接重定向到集群内的pod。我们可以通过省略Service的选择器定义并手动创建端点资源来实现，如例12-3所示。 我们定义一个与服务同名的端点资源，并且包含目标ip和端口。

外部服务访问内部服务

1.Node port

2.Load Balance

ingress

Ingress不是一种服务类型，而是一个单独的Kubernetes资源，它位于Services前面，充当智能路由器和集群的入口点。Ingress通常通过外部可访问的url、负载均衡、SSL终止和基于名称的虚拟主机提供基于http的服务访问，但也有其他专门的Ingress实现。跟load balance相比，Ingress的使用来自于重用单个外部负载均衡器和IP来为多个服务提供服务，并降低基础设施成本。