Kubernetes 中的服务发现与负载均衡

本篇主要是介绍一下服务发现及kubernetes中是如何实现服务发现的。

什么是服务发现

我们整天说服务发现、服务发现，那到底什么是服务发现呢？

简单说服务发现解决的就是： “你在哪？你还好吗？” 的问题。 放到我们的平时的服务中来讲的话就是服务A要调用服务B，那A服务要知道B在哪里，可不可用这类问题。

其实，平时我们经常会用一些服务发现的东西，只是我们不叫它服务发现这种高大上的名字罢了。看看下面这些技术是不是你都了解。

这里再举个例子来说明下服务发现这一概念。

我们最初使用的服务发现方式就是纯手工，我们要访问对端的应用或者服务时我们直接指定其IP+Port就可以了（如上图右侧第一种情况）。当后端有多个应用或服务时，我们把这些应用的IP:Port都配置到配置文件里面或者在程序里面轮训访问也都是可以的（如上图右侧第二种情况）。但是如果其中的一个或者多个节点挂了会怎么办呢？是不是还需要我们手动去改配置，这样很麻烦，且效率低下。为了解决这个问题，程序员们想通过程序的方式来将这一过程自动化，也就产生了像 DNS、LVS、Nginx 等这些服务发现技术，很大程度上替代了运维人员的双手，提高了效率（如上图右侧第三种情况）。

以上这些都是我们当前经常使用的服务发现方式，那么在 kubernetes 平台中是如何来提供服务发现机制的呢 ?

kubernetes 中的服务发现

为了更好的了解 kubernetes 中服务发现机制，我们先简单描述一下当前常用的 kubernetes 网络部署方式。

服务发现的基础是网络、网络方案不同对应的上层服务发现和负载均衡策略可能就不同

我们今天基于Flannel组件实现的大二层网络来描述 kubernetes 中的服务发现和负载均衡。Flannel 网络模型如下：

网络内各个 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