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 的輪詢池