Kubernetes 中常见服务发现模式比较与实践-JavaScript中文网-JavaScript教程资源分享门户

前言

在云原生时代，容器化应用开发已经成为了趋势，而 Kubernetes 作为容器编排的事实标准，对于服务发现也提供了完善的支持。服务发现是分布式系统中至关重要的一环，Kubernetes 中也有很多的实现方案。在本文中，我们将会探讨 Kubernetes 中比较常见的服务发现模式，并介绍其优缺点以及实现方法。

传统服务发现

首先，我们需要了解传统的服务发现模式。在传统的服务发现中，我们可以使用 DNS，负载均衡器，直接硬编码等方式来进行服务发现。下面我们来简单介绍一下这些方式。

DNS

在传统架构中，DNS 通常被用来做服务发现和负载均衡。以 DNS 方式做服务发现，一般服务都会在启动时向 DNS 注册自己的 IP 和名称，以便服务消费者能够通过 DNS 找到对应的服务。DNS 服务启动后鉴权机制处理完成，就维护了一个以服务名为 key，IP 地址为 value 的映射表。当消费者需要对服务调用时，会首先映射服务名到对应的 IP 地址，然后才能发起请求。

负载均衡器

负载均衡器的主要作用是将多台服务器组成一个集群，然后将请求分发到集群中的某一个节点上，以实现负载均衡的目的。如果使用传统的硬件负载均衡，需要事先配置负载均衡器，使用虚拟 IP 地址返回给客户端，客户端通过 DNS 解析获得 IP 地址后再通过 HTTP 请求访问。需要注意的是，传统的硬件负载均衡器通常只支持 TCP 和 UDP 协议，因此无法处理 HTTP 中的一些元数据，比如路由、请求头等等。

直接硬编码

直接硬编码是一种最简单的服务发现方式，开发者需要在代码中直接写明要调用的服务的 IP 地址。这种方式的主要问题是可维护性和灵活性差，因为 IP 地址可能会随着应用部署的改变而改变，而代码中的 IP 地址在变更时也需要相应地修改。

Kubernetes 中的服务发现

上一节中我们介绍了传统的服务发现方式，下面我们来介绍 Kubernetes 中的服务发现实现。

Kubernetes DNS

Kubernetes 提供了一个自己的 DNS 解析服务，通过它我们可以把服务名指向后端服务的 IP 地址和端口。在 Kubernetes 集群中，每个节点都自动配有一个 kubelet DNS 程序，它将负责 DNS 解析请求，该 DNS 程序在启动时会与 Kubernetes API Server 进行通信，获取当前集群中所有服务的信息，最终构建一个包含所有服务名和对应 IP 的 DNS 服务。当某个服务注册时，DNS 服务将会对当前注册服务的名称添加一个后缀。例如，如果我们创建了名为 "my-service" 的服务，那么我们可以通过 DNS 服务的地址 my-service.default.svc.cluster.local 来进行访问。

Kubernetes DNS 的优点在于支持多种服务发现机制，能够通过 DNS 名来访问服务，因此可以在需要时进行动态扩缩容。同时，DNS 解析请求可以自动在 Kubernetes 内容器网络中完成，因此具有较高的安全性和可靠性。不过其缺点也很明显，DNS 解析较慢，且不支持 HTTP 元数据等高级路由，因此仅适用于一些简单的服务场景。

Kubernetes Service

Kubernetes Service 可以理解为反向代理层，它可以暴露 Pod 副本集的一个 IP 和端口，通过这个 IP 和端口来代理访问容器中的实例。每个 Service 资源都有一个 ClusterIP(集群 IP) ,通过这个 IP，其他应用组件能够进行访问服务。

相比于 DNS，Kubernetes Service 更为灵活，也更加适合于一些复杂的应用场景。Service 可以根据 selector 筛选出满足条件的 Pod 并且将它们组成一个虚拟服务，从而形成一个逻辑上的集群，以优化服务的负载均衡。如下代码：

-- -------------------- ---- -------
----------- --
----- -------
---------
  ----- ----------
-----
  ---------
    ---- -----
  ------
  - ----- ----
    --------- ---
    ----- --
    ----------- ----