本文共 3210 字,大约阅读时间需要 10 分钟。
Kubernetes在设计之初就充分考虑了针对容器的服务发现与负载均衡机制,提供了Service资源,并通过kube-proxy配合cloud provider来适应不同的应用场景。随着kubernetes用户的激增,用户场景的不断丰富,产生了一些新的负载均衡机制。
Service是对一组提供相同功能的Pods的抽象,并为它们提供一个统一的入口。借助Service,应用可以方便的实现服务发现与负载均衡,并实现应用的零宕机升级。Service通过标签来选取服务后端,一般配合Replication Controller或者Deployment来保证后端容器的正常运行。
目前 kubernetes 共有三种服务暴露的方式:
LoadBlancer Service是kubernetes深度结合云平台的一个组件;当使LoadBlancer Service暴露服务时,实际上是通过向底层云平台申请创建一个负载均衡器来向外暴露服务;目前LoadBlancer Service支持的云平台已经相对完善,比如国外的GCE、DigitalOcean,国内的 阿里云,私有云 OpenStack 等等,由于LoadBlancer Service深度结合了云平台,所以只能在一些云平台上来使用。
NodePort Service,实质上就是通过在集群的每个node上暴露一个端口,然后将这个端口映射到某个具体的service来实现的,虽然每个node的端口有很多(默认的取值范围是 30000-32767),但是由于安全性和易用性(服务多了就乱了,还有端口冲突问题)实际使用可能并不多。
Ingress可以实现使用等开源的反向代理负载均衡器实现对外暴露服务,可以理解Ingress就是用于配置域名转发,在nginx中就类似upstream,它与ingress-controller结合使用,通过ingress-controller监控到pod及service的变化,动态地将ingress中的转发信息写到诸如nginx、apache、haproxy等组件中实现方向代理和负载均衡。
Ingress 是一个规则的集合,它允许集群外的流量通过一定的规则到达集群内的 Service 。如下图:
Ingress三个组件:
反向代理负载均衡器,即常见的负载均衡软件,如 nginx、Haproxy 等。
Ingress Controller 与 kubernetes API 进行交互,实时的感知后端 service、pod 等变化, Ingress Controller 再结合下文的 Ingress 生成配置,然后更新反向代理负载均衡器,并刷新其配置,实现动态服务发现与更新。
Ingress是规则集合;定义了域名与Kubernetes的service的对应关系;这个规则将与 Ingress Controller 结合, Ingress Controller 将其动态写入到负载均衡器配置中,从而实现整体的服务发现和负载均衡。
Træfɪk 是一个为了让部署微服务更加便捷而诞生的现代HTTP反向代理、负载均衡工具。 它支持多种后台来自动化、动态的应用它的配置文件设置。
Traefik 可以与Kubernetes的API进行交互,每当Kubernetes使用Ingress对微服务进行添加、移除、或更新都会被感知,并且可以自动生成它们的配置文件。 指向到你服务的路由将会被直接创建出来。
前端为两台LVS服务器,通过keepalive实现负载集群高可用以及虚拟IP,实现外部流量的四层负载,以及作为Kubernetes集群服务访问的入口。LVS负载均衡采用DR模式提高集群的处理速度。
后端三台服务器组成Kubernetes集群,每台节点使用hostPort 的方式部署traefik容器,traefik监听节点的80端口,前端LVS负载均衡监听后端三台Kubernetes节点的80端口将外部访问负载分担至traefik。
然后由Traefik进行七层负载均衡,可以实现基于域名或访问目录等来实现映射与负载,将访问流量映射至Kubernetes Service并通过Service负载至最终业务POD所在的容器。
组网拓扑如下:
apiVersion: extensions/v1beta1kind: Deploymentmetadata: name: wordpress-svc labels: app: wordpress-svcspec: replicas: 3 strategy: type: Recreate template: metadata: labels: app: wordpress-svc tier: frontend spec: containers: - image: "192.168.18.250:5002/library/wordpress:4.4-apache" name: wordpress-svc ports: - containerPort: 80
apiVersion: v1kind: Servicemetadata: name: wordpress-svc labels: app: wordpress-svcspec: ports: - port: 8912 targetPort: 80 selector: app: wordpress-svc
apiVersion: extensions/v1beta1kind: Ingressmetadata: name: wordpress-ingspec: rules: - host: wordpress.example.com http: paths: - path: / backend: serviceName: wordpress-svc servicePort: 8912
1.所有应用实现域名方式访问,相对IP+端口的访问方式,提高了访问的便捷性与可维护性。
2.简化应用发布的操作流程,域名与服务实现了自动更新与配置,只需定义ingress与添加外部DNS条目两步操作,即可完成应用的对外发布,减少操作流程,提高维护效率。
1.集群内部的服务转发与负载应对大规模访问流量,存在性能瓶颈,还有优化空间。
2.暂时无法实现LVS与Traefik的弹性伸缩与自动扩容。
本文转自中文社区-
转载地址:http://hihna.baihongyu.com/