Kubernetes 集群中ingress使用Traefik反向代理

1、Traefik 介绍

在日常工作中,我们经常使用 Nginx、Apache 等工具作为反向代理、负载均衡,而 Træfik 是一个为了让部署微服务更加便捷而诞生的 HTTP 反向代理、负载均衡工具。它支持多种后台 (Docker、Swarm、Kubernetes、Mesos、Consul、Etcd…) 来自动、动态的刷新配置文件,以实现快速地服务发现。在 Kubernetes 集群中使用,可以完全替代 ngxin + Ingress Controller,快速实现服务的暴漏。

引用 Traefik 官网文档 中的一张图片,可以简要说明一下什么是 Traefik。

从上图可以看出,在我们日常业务开发中,我们会部署一系列微服务,外部网络要通过 domainpath、负载均衡等转发到后端私有网络中,微服务之所以称为微,是因为它是动态变化的,它会经常被增加、删除、干掉或者被更新。而且传统的反向代理对服务动态变化的支持不是很方便,也就是服务变更后,我们不是很容易立马改变配置和热加载。traefik 的出现就是为了解决这个问题,它可以时刻监听服务注册或服务编排 API,随时感知后端服务变化,自动重新更改配置并热重新加载,期间服务不会暂停或停止,这对于用户来说是无感知的。

Traefik 还有很多特性如下:

  • 速度快
  • 不需要安装其他依赖,使用 GO 语言编译可执行文件
  • 支持最小化官方 Docker 镜像
  • 支持多种后台,如 Docker, Swarm mode, Kubernetes, Marathon, Consul, Etcd, Rancher, Amazon ECS 等等
  • 支持 REST API
  • 配置文件热重载,不需要重启进程
  • 支持自动熔断功能
  • 支持轮训、负载均衡
  • 提供简洁的 UI 界面
  • 支持 Websocket, HTTP/2, GRPC
  • 自动更新 HTTPS 证书
  • 支持高可用集群模式

使用 Traefik 和Nginx + Ingress Controller有什么区别呢?简单点说吧,在 Kubernetes 中使用 nginx 作为前端负载均衡,通过 Ingress Controller 不断的跟 Kubernetes API 交互,实时获取后端 Service、Pod 等的变化,然后动态更新 Nginx 配置,并刷新使配置生效,来达到服务自动发现的目的,而 Traefik 本身设计的就能够实时跟 Kubernetes API 交互,感知后端 Service、Pod 等的变化,自动更新配置并热重载。大体上差不多,但是 Traefik 更快速更方便,同时支持更多的特性,使反向代理、负载均衡更直接更高效。

2、部署 Traefik

在 Kubernetes 上部署 Traefik 很简单,只需 Yaml 创建一下即可。github

traefik/examples/k8s/ 这个目录下就是示例 Traefik 启动所需要的 yaml 文件,Traefik 提供了适配各个类型服务编排的部署方式,kubernetes 启动方式支持 Deployment 和 DaemonSet,二选一都可以。参考github

kubectl apply -f traefik-deployment.yaml -f traefik-rbac.yaml
[root@master traefik]# kubectl get pods -n kube-system
traefik-ingress-controller-6f6d87769d-chmtq   1/1       Running   0          5m

此时 Traefik 已经启动成功了,它同时启动了 80 和 8080 端口,80 对应的服务端口,8080 对应的 UI 端口,我们可以通过查看服务暴漏端口号浏览器访问下了提供的 UI 界面。

[root@master traefik]# kubectl get svc -n kube-system|grep trae
traefik-ingress-service   NodePort    10.96.220.106   <none>        80:30748/TCP,8080:31703/TCP   2m

访问 http://<node_ip>:<node_port>/dashboard/#/,这里我使用的是 Master IP,如:http://192.168.0.25:31703/dashboard/#/

如图部署成功。

4、部署 Traefik UI

从上边可以看到 Traefik 提供了一套简洁的 UI 供我们使用,是由 Angular JS 编写的,它是以 Ingress 方式暴露服务的。

[root@master ~]# kubectl create -f https://raw.githubusercontent.com/fungitive/kubernetes/master/traefik/ui.yaml
service "traefik-web-ui" created
ingress "traefik-web-ui" created
[root@master ~]# kubectl get service -n kube-system |grep trae
traefik-ingress-service   NodePort    10.96.220.106    <none>        80:30748/TCP,8080:31703/TCP   15m
traefik-web-ui            ClusterIP   10.103.100.186   <none>        80/TCP                        2m

此时,我们不需要刷新浏览器 UI 界面,就可以看到 traefik-ui.k8s/ 已经显示出来了,速度很快,用户无感知。

5、部署自定义 Ingress

现在我们自定义一个 Ingress 来实现服务暴漏。基于域名访问虚拟主机的 Ingress 配置,Yaml 文件如下。

[root@master traefik]# vi ingress-tomcat.yaml 
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: tomcat-ingress-traefik
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "traefik"
spec:
  rules:
  - host: tomcattest.cn
    http:
      paths:
      - path:
        backend:
          serviceName: tomcat-test
          servicePort: 8080

[root@master traefik]# kubectl apply -f ingress-tomcat.yaml
ingress.extensions/tomcat-ingress-traefik created

[root@master traefik]# kubectl get ingress
NAME                     HOSTS           ADDRESS   PORTS     AGE
tomcat-ingress-traefik   tomcattest.cn             80        1m

再看一下 UI 页面,立马更新过来,可以看到刚刚配置的tomcattest.cn。

6、部分特性说明

6.1 自动熔断

在集群中,当某一个服务大量出现请求错误,或者请求响应时间过久,或者返回500+错误状态码时,我们希望可以主动剔除该服务,也就是不在将请求转发到该服务上,而这一个过程是自动完成,不需要人工执行。Traefik 通过配置很容易就能帮我们实现,Traefik 可以通过定义策略来主动熔断服务。

  • NetworkErrorRatio() > 0.5:监测服务错误率达到50%时,熔断。
  • LatencyAtQuantileMS(50.0) > 50:监测延时大于50ms时,熔断。
  • ResponseCodeRatio(500, 600, 0, 600) > 0.5:监测返回状态码为[500-600]在[0-600]区间占比超过50%时,熔断。

6.2 负载均衡策略

Traefik 提供两种负载均衡策略支持。一种是 wrr(加权轮训调度算法),一种是 drr(动态加权循环调度算法)。

从上边截图右侧我们看到提示 Load Balancer: wrr,默认的策略为根据权重轮训调度,从图上可以看出,新创建的 service 权重都是一样为 1,这样的话,请求会平均分给每个服务,但是这样很多时候会出现资源分配不均衡的问题,比如由于集群中每个机器配置不一样,而且服务消耗不一样,假设 A 资源使用率已经很高,而 B 属于空闲状态,如果还是均摊到每个服务的话,会加重 A 的负荷,这时候因该有一种策略能够主动识别并分担更多流量到 B 才对。

drr 就更加智能,它是一种动态加权轮训调度方式,它会记录一段时间内转发到 A 的请求数,跟转发到 B 的请求数对比,转发数量多,说明处理速度快,响应时间快。如果 A 处理请求速度比 B 快,那么就会调整 A 的权重,接下来的一段时间,就会转发更多请求给 A,相应的 B 的转发就少一些。整个过程都在不断的调整权重,实现请求的合理分配,从而达到资源使用最大化。

参考资料

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券