流量管理

您可以透過修改服務資源的 traffic 規格，來管理流量路由到 Knative 服務的不同修訂版本。

當您建立 Knative 服務時，它沒有任何預設的 traffic 規格設定。透過設定 traffic 規格，您可以將流量分散到任意數量的固定修訂版本，或者透過在服務的規格中設定 latestRevision: true，將流量傳送到最新的修訂版本。

使用標籤建立目標 URL

在以下範例中，規格定義了一個名為 tag 的屬性

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - percent: 0
    revisionName: example-service-1
    tag: staging
  - percent: 40
    revisionName: example-service-2
  - percent: 60
    revisionName: example-service-3

當 tag 屬性應用於路由時，會建立特定流量目標的位址。

在此範例中，您可以透過存取 staging-<路由名稱>.<命名空間>.<網域> 來存取 staging 目標。example-service-2 和 example-service-3 的目標只能使用主路由 <路由名稱>.<命名空間>.<網域> 來存取。

當流量目標被標記時，會為該服務建立一個新的 Kubernetes 服務，以便其他服務可以在叢集內存取它。在先前的範例中，將在相同的命名空間中建立一個名為 staging-<路由名稱> 的新 Kubernetes 服務。此服務可以透過應用標籤 networking.knative.dev/visibility 並將值設為 cluster-local 來覆蓋此特定路由的能見度。有關如何限制特定路由的能見度的更多資訊，請參閱關於私有服務的文件。

流量路由範例

以下範例顯示 traffic 規格，其中 100% 的流量路由到服務的 latestRevision。在 status 下，您可以看到 latestRevision 解析到的最新修訂版本的名稱

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - latestRevision: true
    percent: 100
status:
  ...
  traffic:
  - percent: 100
    revisionName: example-service-1

以下範例顯示 traffic 規格，其中 100% 的流量路由到 current 修訂版本，並且該修訂版本的名稱指定為 example-service-1。即使沒有流量路由到它，最新的就緒修訂版本也會保持可用

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - tag: current
    revisionName: example-service-1
    percent: 100
  - tag: latest
    latestRevision: true
    percent: 0

以下範例顯示如何擴展 traffic 規格中的修訂版本列表，以便在多個修訂版本之間分配流量。此範例將 50% 的流量傳送到 current 修訂版本 example-service-1，並將 50% 的流量傳送到 candidate 修訂版本 example-service-2

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - tag: current
    revisionName: example-service-1
    percent: 50
  - tag: candidate
    revisionName: example-service-2
    percent: 50
  - tag: latest
    latestRevision: true
    percent: 0

使用 Knative CLI 路由和管理流量

您可以使用以下 kn CLI 命令來分割修訂版本之間的流量

kn service update <service-name> --traffic <revision-name>=<percent>

其中

• <服務名稱> 是您要設定流量路由的 Knative 服務的名稱。
• <修訂版本名稱> 是您要設定接收一定百分比流量的修訂版本的名稱。
• <百分比> 是您要傳送到 <修訂版本名稱> 所指定修訂版本的流量百分比。

例如，要分割名為 example 的服務的流量，將 80% 的流量傳送到修訂版本 green，並將 20% 的流量傳送到修訂版本 blue，您可以執行以下命令

kn service update example-service --traffic green=80 --traffic blue=20

也可以將標籤新增至修訂版本，然後根據您設定的標籤來分割流量

kn service update example --tag revision-0001=green --tag @latest=blue

@latest 標籤表示 blue 解析為服務的最新修訂版本。以下範例將 80% 的流量傳送到最新的修訂版本，並將 20% 的流量傳送到名為 v1 的修訂版本。

kn service update example-service --traffic @latest=80 --traffic v1=20

使用藍綠部署路由和管理流量

您可以透過使用藍綠部署策略，安全地將流量從應用程式的線上版本重新路由到新版本。

步驟

1. 建立應用程式並將其部署為 Knative 服務。

2. 透過執行以下命令，找到您部署服務時建立的第一個修訂版本的名稱

   kubectl get configurations <service-name> -o=jsonpath='{.status.latestCreatedRevisionName}'
   

   其中 <服務名稱> 是您已部署的服務的名稱。

3. 定義一個路由，將傳入流量傳送到修訂版本。

   路由範例

   apiVersion: serving.knative.dev/v1
   kind: Route
   metadata:
     name: <route-name>
     namespace: default
   spec:
     traffic:
       - revisionName: <first-revision-name>
         percent: 100 # All traffic goes to this revision
   

   其中：

   • <路由名稱> 是您為路由選擇的名稱。
   • <第一個修訂版本名稱> 是上一步中初始修訂版本的名稱。

4. 確認您可以使用以下命令取得的 URL 檢視您的應用程式

   kubectl get route <route-name>
   

   其中 <路由名稱> 是您在上一步中建立的路由的名稱。

5. 透過修改服務資源 template 規格中的至少一個欄位，部署應用程式的第二個修訂版本。例如，您可以修改服務的 image 或 env 環境變數。

6. 透過應用更新的服務資源來重新部署服務。您可以透過應用服務 YAML 檔案或使用 kn service update 命令（如果您已安裝 kn CLI）來執行此操作。

7. 透過執行以下命令，找到您重新部署服務時建立的第二個最新修訂版本的名稱

   kubectl get configurations <service-name> -o=jsonpath='{.status.latestCreatedRevisionName}'
   

   其中 <服務名稱> 是您已重新部署的服務的名稱。

   此時，服務的第一個和第二個修訂版本都已部署並正在執行。

8. 更新您現有的路由，為第二個修訂版本建立一個新的測試端點，同時仍將所有其他流量傳送到第一個修訂版本。

   更新後路由的範例

   apiVersion: serving.knative.dev/v1
   kind: Route
   metadata:
     name: <route-name>
     namespace: default
   spec:
     traffic:
       - revisionName: <first-revision-name>
         percent: 100 # All traffic is still being routed to the first revision
       - revisionName: <second-revision-name>
         percent: 0 # 0% of traffic routed to the second revision
         tag: v2 # A named route
   

   一旦您透過重新應用 YAML 資源來重新部署此路由，應用程式的第二個修訂版本現在就已暫存。

   沒有流量路由到主 URL 上的第二個修訂版本，並且 Knative 會建立一個名為 v2 的新路由，用於測試新部署的修訂版本。

9. 透過執行以下命令，取得第二個修訂版本的新路由的 URL

   kubectl get route <route-name> --output jsonpath="{.status.traffic[*].url}"
   

   您可以使用此 URL 來驗證新版本的應用程式是否如預期般運作，然後再將任何流量路由到它。

10. 再次更新您現有的路由資源，使 50% 的流量傳送到第一個修訂版本，50% 的流量傳送到第二個修訂版本

    更新後路由的範例

    apiVersion: serving.knative.dev/v1
    kind: Route
    metadata:
      name: <route-name>
      namespace: default
    spec:
      traffic:
        - revisionName: <first-revision-name>
          percent: 50
        - revisionName: <second-revision-name>
          percent: 50
          tag: v2
    

11. 當您準備將所有流量路由到新版本的應用程式時，再次更新路由以將 100% 的流量傳送到第二個修訂版本

    更新後路由的範例

    apiVersion: serving.knative.dev/v1
    kind: Route
    metadata:
      name: <route-name>
      namespace: default
    spec:
      traffic:
        - revisionName: <first-revision-name>
          percent: 0
        - revisionName: <second-revision-name>
          percent: 100
          tag: v2
    

    提示

    如果您不打算回滾修訂版本，您可以移除第一個修訂版本，而不是將其設定為 0% 的流量。然後，無法路由的修訂版本物件會被垃圾回收。

12. 造訪第一個修訂版本的 URL，以驗證不再有流量傳送到舊版本的應用程式。