Service Discovery and Load Balancing in Kubernetes

This article mainly introduces service discovery and how to implement service discovery in kubernetes.

What is service discovery

We talk about service discovery and service discovery all day long, but what exactly is service discovery?

Simply put, service discovery solves the problem of: "Where are you? Are you okay?". In terms of our usual services, service A needs to call service B, and service A needs to know where B is, whether it can be used.

In fact, we often use some service discovery things, but we don't call it the high-level name of service discovery. See if you know any of these techniques below.

Here is another example to illustrate the concept of service discovery.

The service discovery method we used at first was purely manual. When we want to access the application or service of the opposite end, we can directly specify its IP+Port (as shown in the first case on the right side of the figure above). When there are multiple applications or services in the backend, it is also possible to configure the IP:Port of these applications into the configuration file or to rotate the access in the program (as shown in the second case on the right side of the figure above). But what if one or more of the nodes are down? Do we still need to manually change the configuration, which is very troublesome and inefficient. In order to solve this problem, programmers want to automate this process through programs, and they have produced service discovery technologies such as DNS, LVS, Nginx, etc., which largely replace the hands of operation and maintenance personnel and improve the Efficiency (as shown in the third case on the right side of the figure above).

The above are the service discovery methods that we often use at present, so how does the kubernetes platform provide a service discovery mechanism?

service discovery in kubernetes

In order to better understand the service discovery mechanism in kubernetes, let's briefly describe the currently commonly used kubernetes network deployment methods.

The basis of service discovery is that the upper-layer service discovery and load balancing strategies corresponding to different network and network solutions may be different

Today we describe the service discovery and load balancing in kubernetes based on the large layer 2 network implemented by the Flannel component. The Flannel network model is as follows:

网络内各个 pod 都会有自己的IP,且和其它 pod 都不冲突、独占。这些 pod 通过 flannel 隧道是互通的。了解这点对于后面理解 kubernetes 中的服务发现是非常重要的。

回到 kubernetes 的服务发现,Kubernetes在设计之初就充分考虑了针对容器的服务发现与负载均衡机制。

对于 kubernetes 而言它的服务发现分为两种:

  1. 对内的,也即集群内部pod、service之间的访问(或者理解成东西向访问);
  2. 对外的,也即外网对集群内部的pod和service的访问(或者理解成南北向访问)。

下面我们就分这两种情况分析一下:

在 kubernetes 中,对内服务发现的端无非就是 pod 或者 service。因此也就存在以下几种情况的服务发现需求:

  • pod 访问 pod
  • pod 访问 service

对外服务发现的端就是外部访问端和内部的 pod 或者 service 了:

  • 外部访问内部的 pod 或者 service

了解更多 service 的知识看 这里

对内的服务发现

pod 访问 pod

在上面我们介绍 kubernetes 网络时说过,每个pod都有自己的独占IP,这些 pod(IP)之间网络是畅通的,所以它们之间是可以直接根据ip:port访问。

pod 访问 service

先看一下 service 的概念及与 pod 的关系:

从这里我们可以知道, service 是 pod 的一个逻辑集合,代表 pod 集合与其它服务进行交互,进行请求的分发和负载均衡。针对不同的场景给出了四种 service:

此时,我们 从且只能从 kubernetes node 节点,使用 clusterIp 和 port 就可以访问 service 里的服务了。

此时,我们从 任意 kubernetes node 节点 和 非 kubernetes node 节点,只要和 kubernetes node 正常通信的机器,都可以访问service的服务。

还有一种方式是通过 kube-dns ,同步服务名字实现服务的访问

对外的服务发现

服务对外访问方式的话,有上面三种。其中 Service LoadBalancer 是 ingress Controller 方案的过渡方案

因为,是过渡方案这里就不多介绍,直接看 ingress Controller

最后是 Custom LoadBalancer

目前 kubernetes 提供了以上几种方案,具体怎么用还要结合公司实际业务情况,这里没有展开。

 

http://www.tuicool.com/articles/iqqM7vY

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326487299&siteId=291194637