kubenetes-服务发现和负载均衡
一、服务发布
kubenetes把服务发布至集群内部或者外部，服务的三种不同类型：
- ClusterlP
- NodePort
- LoadBalancer
ClusterIP是发布至集群内部的一个虚拟IP,通过负载均衡技术转发到不同的pod中。
NodePort解决的是集群外部访问的问题，用户可能不能访问pod ip，但是可以访问Node ip，通过nodeIP:nodePort方式提供给外部流量访问。
LoadBalancer类型需要和外部负载均衡设备做交互，需要特定的controller来支撑。
二、服务发现
- 微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构，服务之间通过轻量机制进行通信，这时候必然引入一个服务注册发现问题，也就是说服务提供方要注册通告服务地址，服务的调用方要能发现目标服务。
- 同时服务提供方一般以集群方式提供服务，也就引入了负载均衡和健康检查问题。
2.1 集中式LB服务发现
集中式LB方案实现简单，在LB上也容易做集中式的访问控制，这一方案目前还是业界主流。
集中式LB的主要问题是单点问题，所以服务调用流量都经过LB,当服务数量和调用量大的时候，LB容易成为瓶颈，且LB一旦发生故障，对整个系统的影响将是灾难性的。
集中式LB在消费者和服务提供方之间增加了一跳，有一定性能开销。
2.2 客户端LB服务发现
客户端LB是一种分布式模式，LB和服务发现能力被分散到每一个服务消费者的进程内部，同时服务消费方和服务提供方之间是直接调用，没有额外开销，性能比较好。该方案以客户库（Client Library）的方式集成到服务调用方进程里头，如果企业内有多种不同的语言栈，就要配合开发多种不同的客户端，有一定的研发和维护成本。
一旦客户端跟随服务调用方发布到生产环境中，后续如果要对客户库进行升级，势必要求服务调用方修改代码并重新发布，所以该方案的升级推广有不小的阻力。
2.3 客户端独立LB进程服务发现
客户端独立LB进程也是一种分布式方案，没有单点问题，一个LB进程挂了只影响该主机上的服务调用方。
服务调用方和LB之间是进程间调用，性能好。
简化了服务调用方，不需要为不同语言开发客户库，LB的升级不需要服务调用方改代码。
不足是部署较复杂，环节多，出错调试排查问题不方便。
三、负载均衡
3.1 互联网架构发展历程
3.2 网络包格式
所谓的负载均衡技术，就是在网络包上修改转化技术，比如将目标ip和port进行修改。在链路层修改目标MAC地址，就是链路层的负载均衡，也叫7层负载均衡。在传输层和网络层修改目标ip和port，就是传输层和网络层的负载均衡，统称4层负载均衡。
3.3 负载均衡技术概览
3.3.1 网络地址转换
3.3.2 隧道技术
负载均衡中常用的隧道技术是IP over IP，其原理是保持原始数据包IP头不变，在IP头外层增加额外的IP包头后转发给上游服务器。
上游服务器接收IP数据包，解开外层IP包头后，剩下的是原始数据包。
同样的，原始数据包中的目标IP地址要配置在上游服务器中，上游服务器处理完数据请求以后，响应包通过网关直接返回给客户端。
Overlay中的VXLAN就是一种隧道技术。
3.4 DNS负载均衡
DNS负载均衡技术的实现原理是在DNS服务器中为同一个域名配置多个IP地址，在应答DNS查询时，DNS服务器通过算法返回其中一个IP，将客户端的访问引导到不同的机器上去，使得不同的客户端访问不同的服务器，从而达到负载均衡的目的。
严格来说，DNS服务器只是做域名解析，并没有承接请求流量。
DNS域名解析需要注意TTL问题，TTL记录了一个DNS记录在缓存中的有效时间，即多长时间后缓存将过期并需要重新查询。