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