Traefik目前的最新版本是 v2.0.2，截止該版本，要實現灰度發佈、流量複製這些高級功能，只能通過File Provider來實現。

灰度發佈我們有時候也會稱爲金絲雀發佈（Canary），主要就是讓一部分測試的服務也參與到線上去，經過測試觀察看是否符號上線要求。

發佈架構概述

canary deployment(灰度發佈 NGINX服務)

比如現在有兩個名爲 appv1 和 appv2 的 Nginx 服務，我們希望通過 Traefik 來控制我們的流量，將 34 的流量路由到 appv1，1/4 的流量路由到 appv2 去，這個時候就可以利用 Traefik2.0 中提供的帶權重的輪詢（WRR）來實現該功能，首先在 Kubernetes 集羣中部署上面的兩個服務。

NGINX-server1服務的資源清單

appv1.yaml

NGINX-server2服務的資源清單

appv1.yaml

直接創建上面兩個服務：

ConfigMap 開啓Provider

由於 WRR 這個功能目前只支持File Provider，所以我們需要開啓該 Provider 才能使用，這裏需要注意的是由於需要開啓File Provider，所以我們需要提供一個文件用於該 Provider 的配置，我們這裏是用在 Kubernetes 集羣中的，所以可以通過一個 ConfigMap 對象，將配置文件內容掛載到 Traefik 的 Pod 中去，如下所示，我們通過將一個名爲 traefik-dynamic-conf 的 ConfigMap 對象掛載到了/config目錄下面去，然後通過--providers.file.filename參數指定配置文件開啓File Provider，另外添加- --providers.file.watch=true參數可以讓 Traefik 動態更新配置：

完整的 YAML 文件可以前往 https://github.com/cnych/kubeapp/tree/master/traefik2/canary 獲取。

創建對應的 ConfigMap 對象

上面是開啓File Provide的配置，接下來需要創建對應的 ConfigMap 對象，首先創建一個名爲traefik-dynamic.toml的文件，內容如下所示：

上面這個配置文件就是我們需要配置的灰度發佈的規則

創建一個名爲Router0的路由，在Web這個入口點上面監聽Host=nginx.chuanzhi.com這樣的請求，將請求路由給名爲app的服務，而該服務則將請求路由給了appv1這個服務，權重爲 3，另外一部分請求路由給了appv2這個服務，權重爲 1，也就是有 34 的請求會被路由http://appv1/這個真實的服務上，這個地址也就是我們 Kubernetes 集羣中的 appv1 這個 Service 對象的 FQDN 地址，當然我們也可以用全路徑（http://appv1.kube-system.svc.cluster.local:80）表示，因爲都在kube-system這個命名空間下面，所以直接用服務名也是可以的，同樣的另外的 14 請求會被路由到http://appv2/這個真實的服務上。

現在通過上面的配置文件來創建對應的 ConfigMap 對象：

創建完成後，再更新 Traefik2.0，就可以將配置文件通過 ConfigMap 掛載到 Traefik Pod 的/config/traefik-dynamic.toml路徑下面去了。

測試及日誌分析

然後將域名nginx.chuanzhi.com解析到 Traefik 所在的 Pod，這個時候我們打開兩個終端，分別去觀察 appv1 和 appv2 兩個應用的日誌。

在瀏覽器中連續訪問nginx.chuanzhi.com4 次，我們可以觀察到 appv1 這應用會收到 3 次請求，而 appv2 這個應用只收到 1 次請求，符合上面我們的3:1的權重配置。

traefik2 wrr demo

不知道是否是 Traefik 的 BUG，同時將 KubernetesCRD Provider 和 File Provider 開啓的時候，識別不了 File Provider 中的配置，該問題還有待驗證。

在2.0.4 版本中測試通過支持crd 方式 金絲雀部署如下：

這種配置方式支持k8s的service服務發現