2019独角兽企业重金招聘Python工程师标准>>> 
本篇主要是介绍一下服务发现及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 而言它的服务发现分为两种：
- 对内的，也即集群内部pod、service之间的访问（或者理解成东西向访问）；
- 对外的，也即外网对集群内部的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