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

标签: kubernetes | 发表时间:2016-09-11 01:48 | 作者:
分享到:
出处:http://feisky.xyz/

Kubernetes在设计之初就充分考虑了针对容器的服务发现与负载均衡机制,提供了Service资源,并通过kube-proxy配合cloud provider来适应不同的应用场景。随着kubernetes用户的激增,用户场景的不断丰富,又产生了一些新的负载均衡机制。目前,kubernetes中的负载均衡大致可以分为以下几种机制,每种机制都有其特定的应用场景:

  • Service:直接用Service提供cluster内部的负载均衡,并借助cloud provider提供的LB提供外部访问
  • Ingress Controller:还是用Service提供cluster内部的负载均衡,但是通过自定义LB提供外部访问
  • Service Load Balancer:把load balancer直接跑在容器中,实现Bare Metal的Service Load Balancer
  • Custom Load Balancer:自定义负载均衡,并替代kube-proxy,一般在物理部署Kubernetes时使用,方便接入公司已有的外部服务

Service

Service是对一组提供相同功能的Pods的抽象,并为它们提供一个统一的入口。借助Service,应用可以方便的实现服务发现与负载均衡,并实现应用的零宕机升级。Service通过标签来选取服务后端,一般配合Replication Controller或者Deployment来保证后端容器的正常运行。

Service有三种类型:

  • ClusterIP:默认类型,自动分配一个仅cluster内部可以访问的虚拟IP
  • NodePort:在ClusterIP基础上为Service在每台机器上绑定一个端口,这样就可以通过 <NodeIP>:NodePort来访问改服务
  • LoadBalancer:在NodePort的基础上,借助cloud provider创建一个外部的负载均衡器,并将请求转发到 <NodeIP>:NodePort

另外,也可以讲已有的服务以Service的形式加入到Kubernetes集群中来,只需要在创建Service的时候不指定Label selector,而是在Service创建好后手动为其添加endpoint。

Ingress Controller

Service虽然解决了服务发现和负载均衡的问题,但它在使用上还是有一些限制,比如

- 只支持4层负载均衡,没有7层功能
- 对外访问的时候,NodePort类型需要在外部搭建额外的负载均衡,而LoadBalancer要求kubernetes必须跑在支持的cloud provider上面

Ingress就是为了解决这些限制而引入的新资源,主要用来将服务暴露到cluster外面,并且可以自定义服务的访问策略。比如想要通过负载均衡器实现不同子域名到不同服务的访问:

     
foo.bar.com --| |-> foo.bar.com s1:80
| 178.91.123.132 |
bar.foo.com --| |-> bar.foo.com s2:80

可以这样来定义Ingress:

     
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: test
spec:
rules:
- host: foo.bar.com
http:
paths:
- backend:
serviceName: s1
servicePort: 80
- host: bar.foo.com
http:
paths:
- backend:
serviceName: s2
servicePort: 80

注意Ingress本身并不会自动创建负载均衡器,cluster中需要运行一个ingress controller来根据Ingress的定义来管理负载均衡器。目前社区提供了nginx和gce的参考实现。

Service Load Balancer

在Ingress出现以前,Service Load Balancer是推荐的解决Service局限性的方式。Service Load Balancer将haproxy跑在容器中,并监控service和endpoint的变化,通过容器IP对外提供4层和7层负载均衡服务。

社区提供的Service Load Balancer支持四种负载均衡协议:TCP、HTTP、HTTPS和SSL TERMINATION,并支持ACL访问控制。

Custom Load Balancer

虽然Kubernetes提供了丰富的负载均衡机制,但在实际使用的时候,还是会碰到一些复杂的场景是它不能支持的,比如

  • 接入已有的负载均衡设备
  • 多租户网络情况下,容器网络和主机网络是隔离的,这样 kube-proxy就不能正常工作

这个时候就可以自定义组件,并代替kube-proxy来做负载均衡。基本的思路是监控kubernetes中service和endpoints的变化,并根据这些变化来配置负载均衡器。比如weave flux、nginx plus、kube2haproxy等

参考资料

相关 [kubernetes 服务 发现] 推荐:

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

- - Feisky's Blog
Kubernetes在设计之初就充分考虑了针对容器的服务发现与负载均衡机制,提供了Service资源,并通过kube-proxy配合cloud provider来适应不同的应用场景. 随着kubernetes用户的激增,用户场景的不断丰富,又产生了一些新的负载均衡机制. 目前,kubernetes中的负载均衡大致可以分为以下几种机制,每种机制都有其特定的应用场景:.

喜大普奔:Spark on kubernetes

- - Zlatan Eevee
两个星期前(08/15/2017),spark社区提了一个新的SPIP(Spark Project Improvement Proposals): Spark on Kubernetes: Kubernetes as A Native Cluster Manager,即用k8s管理spark集群. 经过社区2个星期的投票,看上去很快要能合入了.

一篇文章带你了解Kubernetes安装

- - Tony Bai
由于之前在阿里云上部署的 Docker 1.12.2的Swarm集群没能正常展示出其所宣称的Routing mesh和VIP等功能,为了满足项目需要,我们只能转向另外一种容器集群管理和服务编排工具 Kubernetes. 注:之前Docker1.12集群的Routing mesh和VIP功能失效的问题,经过在github上.

[原]Curator服务发现

- - 升华思想 技术高深
一个服务发现系统提供下面几个机制:.  注册它们有用的服务.  定位一个单一特殊服务的实例.  当一个服务改变时发出通知. 3.3.1.1 服务实例. 一个服务实例使用类ServiceInstance作为服务实例类. ServiceInstance有一个名称、id、地址、端口或者ssl端口以及可选负载(用户定义).

服务发现:Zookeeper vs etcd vs Consul

- - 企业架构 - ITeye博客
服务发现:Zookeeper vs etcd vs Consul. 【编者的话】本文对比了Zookeeper、etcd和Consul三种服务发现工具,探讨了最佳的服务发现解决方案,仅供参考. 如果使用预定义的端口,服务越多,发生冲突的可能性越大,毕竟,不可能有两个服务监听同一个端口. 管理一个拥挤的比方说被几百个服务所使用的所有端口的列表,本身就是一个挑战,添加到该列表后,这些服务需要的数据库和数量会日益增多.

基于 Consul 的 Docker Swarm 服务发现

- - IT瘾-dev
基于 Consul 的 Docker Swarm 服务发现. 2017 年 1 月 10 日发布. Docker 是一种新型的虚拟化技术,它的目标在于实现轻量级操作系统的虚拟化. 相比传统的虚拟化方案,Docker. 虚拟化技术有一些很明显的优势:启动容器的速度明显快于传统虚拟化技术,同时创建一台虚拟机占用的资源也要远远小于传统的虚拟技术.

Apach警告Web Server发现拒绝服务漏洞

- coofucoo - Solidot
Apache发出警告,Apache HTTPD Web Server中发现拒绝服务漏洞,受影响的版本包括Apache 1.3分支和Apache 2分支的所有版本. Apache表示将在未来48小时内发布补丁. 名叫Apache Killer的攻击工具上周五发布在Full Disclosure邮件列表.

Architect_019:如何发现微服务?(摘录+整理)

- - 热爱Java ,热爱生活
微服务的实例的网络位置都是动态分配的,而且因为扩展、失效和升级等需求,服务实例会经常动态改变,因此,需要一种更加复杂的服务发现机制. 目前有两大类服务发现模式:客户端发现和服务端发现. 当使用客户端发现模式时,客户端负责决定相应服务实例的网络位置,并且对请求实现负载均衡. 客户端从一个服务注册服务中查询,其中是所有可用服务实例的库.

Marathon 服务发现及负载均衡 marathon-lb

- - 企业架构 - ITeye博客
       从官网摘抄了Mesos-DNS的缺陷,也是选择使用marathon-lb做服务发现和负载均衡的原因.        DNS does not identify service ports, unless you use an SRV query; most apps are not able to use SRV records “out of the box.”.

暗访北京三大电信运营商客户服务,发现十个小问题

- - 付亮的竞争情报应用
 近日,对北京三大运营商官方的实体营业厅、网厅、掌厅(手机客户端)、短信营业厅、客户电话做了一个初步的摸底(不涉及在电商开的网店及微信、微博客户服务). 这里列举发现的部分问题,就不一一列明了,欢迎对号入座. 1、运营商套餐太复杂了,政策变化太快,连营业员也搞不明白. 如果您看到一个合适的优惠套餐,您得拿着宣传页去找营业员,就这,可能有的地方还办不了,或者网厅和实体营业厅政策还不一致.