kubernetes ingress(二) traefik 入门

traefik 的内部架构图以下：

1. 传入请求在endpoints结束，顾名思义，它们是Traefik的网络入口点（侦听端口，SSL，流量重定向......）。
   
2. 而后将流量转发到匹配的frontends。前端定义了从入口点到后端的路由。使用请求字段（主机，路径，标头...）建立路由，而且能够匹配或不匹配请求。而后，frontend将请求发送到后端。
   
3. 后端能够由一个或多个server组成，也能够由负载平衡策略组成。最后，server将请求转发到专用网络中的相应微服务。

Entrypoints

entrypoint 是trafik 的网络入口。能够经过端口，SSL,重定向来定义

[entryPoints]
  [entryPoints.http]
  address = ":80"
    [entryPoints.http.redirect]
    entryPoint = "https"
  [entryPoints.https]
  address = ":443"
    [entryPoints.https.tls]
      [[entryPoints.https.tls.certificates]]
      certFile = "tests/traefik.crt"
      keyFile = "tests/traefik.key"

如上例子，定义了两个entrypoint ，一个http ， 一个https。他们的端口分别是80和443。经过给定证书和key文件来启用ssl，并rewrite全部的http entrypoint的请求到https

frontends

一个frontend 定义了一组规则来决定如何转发到后端的入口。
规则分为两种：Modifiers 和 Matchers

Modifiers

Modifier规则只修改请求，它们对正在作出的路由决策没有任何影响，下列是已经存在的modifier规则：

AddPrefix: /products：为请求URL路径添加前缀
ReplacePath: /serverless-path：替换path，并把老的path添加到X-Replaced-Path头
ReplacePathRegex: ^/api/v2/(.*) /api/$1：

Matchers

Matchers 用来定义是否将特定的请求转发到后端
用，分割的两个规则表示或， 知足之一便可
使用；分割的规则表示与，须要所有知足

Headers: Content-Type, application/json: 经过 Headers 能够添加一个匹配规则来匹配请求头部包含的值。它接受要匹配的键/值对序列。
HeadersRegexp: Content-Type, application/(text|json): 也能够在 Headers 中使用正则表达式。它接受要匹配的键/值对序列，序列内容解析是经过正则匹配的
Host: traefik.io, www.traefik.io: 匹配请求 Host 必需在给定域名列表内。
HostRegexp: traefik.io, {subdomain:[a-z]+}.traefik.io: 添加匹配请求 Host 的正则表达式。 它接受一个以{}包括起来的为空或更多url变量的模版。变量的值能够以一个可选的正则表达式来匹配。
Method: GET, POST, PUT: Method 能够添加一个HTTP请求方法的匹配。它接受要匹配的一个或多个请求方法序列。
Path: /products/, /articles/{category}/{id:[0-9]+}: Path 能够添加一个URL路径的匹配。它接受一个以{}包括起来的为空或更多url变量的模版。
PathStrip: /products/    和 Path 相同，但从请求的URL路径中去掉的给定的前缀。
PathStripRegex: /articles/{category}/{id:[0-9]+}    匹配精确的路径，并在转发到后端前剥离路径，接受一组文字和正则路径
PathPrefix: /products/, /articles/{category}/{id:[0-9]+}    PathPrefix 能够添加一个URL路径前缀的匹配。它匹配给定模版中的完整URL路径前缀。
PathPrefixStrip: /products/    和 PathPrefix 相同，但从请求的URL路径中去掉的给定的前缀。
PathPrefixStripRegex: /articles/{category}/{id:[0-9]+}    匹配路径前缀，并在转发到后端前剥离路径，接受一组文字和正则路径，从trafik 1.3开始，剥离的路径将会传递到X-Forwarded-Prefix 头。
Query: foo=bar, bar=baz    匹配查询对象，接受k=v的格式

使用Host 和Path Matchers时，你必须声明一个任意命名的变量，后跟冒号分隔的正则表达式，例如：/posts/{id:[0-9]+}
例子中的id 并无实际含义， 但你必须定义。
你能够启用passHostHeader变量来转发客户端的Host头到backend，您还能够选择配置passTLSClientCert选项，以将客户端证书到特定header中传递给后端。

PATH MATCHER USAGE GUIDELINES

• 若是您的后端仅侦听确切的路径，请使用Path。例如，Path：/products将匹配/products，但不匹配/products/shoes。
  
• 使用Prefix matcher，若是你的backend监听特定的基础路径但也在子路径处理请求。例如，PathPrefix: /products 将匹配/products 也匹配/products/shoes and /products/shirts。因为是按照原路径转发。所以，后端须要监听/products

• 若是backend 监听的根路径(/),但也须要路由特定的前缀。 请使用Strip,例如PathPrefixStrip: /products， 将匹配/products、/products/shoes、/products/shirts,因为路径被剥离，所以backend 须要在/监听
  若是后端是静态资源服务。它必须返回正确构造的相对URL。
  继续这个例子，后端应该返回/products/shoes/image.png（而不是/images.png，Traefik可能没法与同一个后端关联）。能够经过查询请求中的X-Forwarded-Prefix 头来动态构造url

  规则顺序

  当Modifier 和 Matcher 组合使用时，Matcher 规则将始终在Modifier 规则前生效。
  下面的规则便是Matcher 也是Modifier，所以Matcher 应用在前，Modifier 应用在后

- PathStrip
- PathStripRegex
- PathPrefixStrip
- PathPrefixStripRegex

不管规则配置部分的顺序如何， 修改器将以预约顺序应用

- PathStrip
- PathPrefixStrip
- PathStripRegex
- PathPrefixStripRegex
- AddPrefix
- ReplacePath

优先级

默认状况下，将使用规则长度（以免路径重叠）对路由进行排序（以降序排序）： - PathPrefix：/ foo;主机：foo.com（length == 28）将在PathPrefixStrip以前匹配：/ foobar（length == 23）将在PathPrefix：/ foo，/ bar（length == 20）以前匹配。
优先级值0将被忽略，所以将计算默认值（规则长度）。
能够在frontend 中自定义优先级，自定义的优先级将覆盖规则长度的计算结果
例如：

[frontends]
    [frontends.frontend1]
    backend = "backend1"
    priority = 20
    passHostHeader = true
      [frontends.frontend1.routes.test_1]
      rule = "PathPrefix:/to"
    [frontends.frontend2]
    backend = "backend2"
    passHostHeader = true
      [frontends.frontend2.routes.test_1]
      rule = "PathPrefix:/toto"

frontend1 将首先匹配(20>16)

自定义 headers

能够经过前端配置自定义header，以将header添加到与前端规则匹配的请求或响应中。
这容许将诸如X-Script-Name之类的header添加到请求中，或者将自定义header添加到响应中。

若是自定义header名称与请求或响应的一个header名称相同，则将替换它

例子1：路径/cheese的全部匹配都会将X-Script-Name标头添加到代理请求中，并将X-Custom-Response-Header标头添加到响应中。

[frontends]
  [frontends.frontend1]
  backend = "backend1"
    [frontends.frontend1.headers.customresponseheaders]
    X-Custom-Response-Header = "True"
    [frontends.frontend1.headers.customrequestheaders]
    X-Script-Name = "test"
    [frontends.frontend1.routes.test_1]
    rule = "PathPrefixStrip:/cheese"

Backends

backend负责未来自一个或多个前端的流量负载平衡到一组http服务器。

Servers

只使用url定义server，你也能够经过自定义weight给每个server

Load-balancing

支持两种负载均衡算法：

• wrr:加权轮训

• drr:动态轮训，增长weight 当server 的表现比其余好。也能够回到原来的weight ，当server 发生变化。

  Circuit breakers

  能够在backend 上应用断路器来避免故障服务器上的高负载。初始状态是Standby(待机)。断路器观察统计数据，可是不修改请求。当知足某个条件，断路器进入Tripped(跳闸）状态。它用预约义的代码响应或重定向到另外一个frontend （？），一旦Tripped计时器到期，断路器进入恢复状态并重启全部状态，若是条件不匹配而且恢复计时器到期，断路器将进入Standby状态。
  能够经过如下方式配置：
  Methods：LatencyAtQuantileMS, NetworkErrorRatio, ResponseCodeRatio
  Operators: AND, OR, EQ, NEQ, LT, LE, GT, GE

• NetworkErrorRatio() > 0.5: 监控网络故障率大于0.5超过10秒后，为这个前端平滑切换，断路条件匹配
• LatencyAtQuantileMS(50.0) > 50: 监控延迟超过50ms时断路条件匹配

• ResponseCodeRatio(500, 600, 0, 600) > 0.5: 监控返回 HTTP状态码在[500-600]之间的数量/HTTP状态码在[0-600]之间的数量 的比例大于0.5时，断路条件匹配

Maximum connections

为了主动防止后端因高负载而不堪重负，最大链接限制也能够应用于每一个后端。
能够经过为maxconn.amount和maxconn.extractorfunc指定一个整数值来配置最大链接数，这是一种策略，用于肯定如何对请求进行分类以评估最大链接数。
例子：

[backends]
  [backends.backend1]
    [backends.backend1.maxconn]
       amount = 10
       extractorfunc = "request.host"

backend1 将会返回HTTP CODE 429 Too Many Requests 若是同一主机头的请求已经有10个在处理。
extractorfunc的另外一个可能值是client.ip，它将根据客户端源ip对请求进行分类。
最后，extractorfunc能够获取request.header.ANY_HEADER的值，该值将根据您提供的ANY_HEADER对请求进行分类。

Sticky sessions

两种负载均衡都支持粘性会话。
启用粘性会话时，会在初始请求上设置cookie。默认cookie名称是sha1的缩写，在后续请求中，若是客户端仍然健康，则会将客户端定向到存储在cookie中的后端。若是没有，将分配新的后端。

health check

能够设置健康检查以便从LB的轮训中剔除不健康的后端。如事后端持续返回非2XX 或者 3XX 的状态码。traefik 按期执行Get 请求
经过一个后端的path 和检查周期（执定多久进行一次，默认30s）来定义一个healthcheck。每一个backend必须在5秒内响应健康检查。

默认状况下，使用后端服务器的端口，可是，能够覆盖此端口。 一个恢复的后端返回2XX 和3XX的响应将会被再次添加进Lb 的轮询池