#3349: Updated traffic management docs, blue/green deployment (#3825)

* 3349: Updated traffic management docs, blue/green deployment * fix nav and redirects * add CLI command * fix mkdocs issues * additional examples
2021-07-07 09:12:18 -05:00 · 2021-07-07 09:12:18 -05:00 · 54290e2318
parent be72eae9bb
commit 54290e2318
9 changed files with 238 additions and 571 deletions
--- a/config/nav.yml
+++ b/config/nav.yml
@ -67,6 +67,7 @@ nav:
            - Configuring private Services: developer/serving/services/private-services.md
            - Configuring custom domains: developer/serving/services/custom-domains.md
            - Configure resource requests and limits: developer/serving/services/configure-requests-limits-services.md
          - Traffic management: developer/serving/traffic-management.md
          - Troubleshooting:
            - Debugging application issues: developer/serving/troubleshooting/debugging-application-issues.md
        - Knative Eventing:
@ -123,7 +124,6 @@ nav:
        - Converting a Kubernetes Deployment to a Knative Service: serving/convert-deployment-to-knative-service.md
      - Code samples:
        - Overview: serving/samples/README.md
        - Routing and managing traffic: serving/samples/blue-green-deployment.md
        - Cloud Events apps:
          - Overview: serving/samples/cloudevents/README.md
          - .NET: serving/samples/cloudevents/cloudevents-dotnet/README.md
@ -152,7 +152,6 @@ nav:
        - RESTful service - Go: serving/samples/rest-api-go/README.md
        - Secrets - Go: serving/samples/secrets-go/README.md
        - Tag Header Based Routing: serving/samples/tag-header-based-routing/README.md
        - Traffic splitting: serving/samples/traffic-splitting/README.md
    # Eventing
    - Knative Eventing:
      - Overview: eventing/README.md
@ -239,4 +238,3 @@ nav:
      - kn plugins: client/kn-plugins.md
    - "Join the Community ➠": /community/
    - "Read the Blog ➠": /blog/
--- a/config/redirects.yml
+++ b/config/redirects.yml
@ -1,6 +1,8 @@
 plugins:
  redirects:
    redirect_maps:
      serving/samples/blue-green-deployment.md: developer/serving/traffic-management.md
      serving/samples/traffic-splitting/README.md: developer/serving/traffic-management.md
      admin/install/install-eventing-with-yaml.md: admin/install/eventing/install-eventing-with-yaml.md
      admin/install/install-serving-with-yaml.md: admin/install/serving/install-serving-with-yaml.md
      client/connecting-kn-to-your-cluster/index.md: client/README.md
@ -77,5 +79,3 @@ plugins:
      upgrade/index.md: admin/upgrade/README.md
      upgrade/upgrade-installation-with-operator.md: admin/upgrade/upgrade-installation-with-operator.md
      upgrade/upgrade-installation.md: admin/upgrade/upgrade-installation.md
--- a/docs/developer/serving/traffic-management.md
+++ b/docs/developer/serving/traffic-management.md
@ -0,0 +1,232 @@
 # Traffic management
 You can manage traffic routing to different Revisions of a Knative Service by modifying the `traffic` spec of the Service resource.
 When you create a Knative Service, it does not have any default `traffic` spec settings. By setting the `traffic` spec, you can split traffic over any number of fixed Revisions, or send traffic to the latest Revision by setting `latestRevision: true` in the spec for a Service.
 ## Traffic routing examples
 The following example shows a `traffic` spec where 100% of traffic is routed to the `latestRevision` of the Service. Under `status` you can see the name of the latest Revision that `latestRevision` was resolved to:
 ```yaml
 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
 ```
 The following example shows a `traffic` spec where 100% of traffic is routed to the `current` Revision, and the name of that Revision is specified as `example-service-1`. The latest ready Revision is kept available, even though no traffic is being routed to it:
 ```yaml
 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
 ```
 The following example shows how the list of Revisions in the `traffic` spec can be extended so that traffic is split between multiple Revisions. This example sends 50% of traffic to the `current` Revision, `example-service-1`, and 50% of traffic to the `candidate` Revision, `example-service-2`:
 ```yaml
 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
 ```
 ## Routing and managing traffic by using the Knative CLI
 You can use the following `kn` CLI command to split traffic between revisions:
 ```bash
 kn service update <service-name> --traffic <revision-name>=<percent>
 ```
 Where:
 - `<service-name>` is the name of the Knative Service that you are configuring traffic routing for.
 - `<revision-name>` is the name of the revision that you want to configure to receive a percentage of traffic.
 - `<percent>` is the percentage of traffic that you want to send to the revision specified by `<revision-name>`.
 For example, to split traffic for a Service named `example`, by sending 80% of traffic to the Revision `green` and 20% of traffic to the Revision `blue`, you could run the following command:
 ```bash
 kn service update example-service --traffic green=80 --traffic blue=20
 ```
 It is also possible to add tags to Revisions and then split traffic according to the tags you have set:
 ```bash
 kn service update example --tag green=revision-0001 --tag blue=@latest
 ```
 The `@latest` tag means that `blue` resolves to the latest Revision of the Service. The following example sends 80% of traffic to the latest Revision and 20% to a Revision named `v1`.
 ```bash
 kn service update example-service --traffic @latest=80 --traffic v1=20
 ```
 ## Routing and managing traffic with blue/green deployment
 You can safely reroute traffic from a live version of an application to a new version by using a [blue/green deployment strategy](https://en.wikipedia.org/wiki/Blue-green_deployment).
 ### Procedure
 1. Create and deploy an app as a Knative Service.
 1. Find the name of the first Revision that was created when you deployed the Service, by running the command:
    ```bash
    kubectl get configurations <service-name> -o=jsonpath='{.status.latestCreatedRevisionName}'
    ```
    Where `<service-name>` is the name of the Service that you have deployed.
 1. Define a Route to send inbound traffic to the Revision.
    ***Example Route***
    ```yaml
    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
    ```
    Where;
    - `<route-name>` is the name you choose for your route.
    - `<first-revision-name>` is the name of the initial Revision from the previous step.
 1. Verify that you can view your app at the URL output you get from using the following command:
    ```bash
    kubectl get route <route-name>
    ```
    Where `<route-name>` is the name of the Route you created in the previous step.
 1. Deploy a second Revision of your app by modifying at least one field in the `template` spec of the Service resource. For example, you can modify the `image` of the Service, or an `env` environment variable.
 1. Redeploy the Service by applying the updated Service resource. You can do this by applying the Service YAML file or by using the `kn service update` command if you have installed the `kn` CLI.
 1. Find the name of the second, latest Revision that was created when you redeployed the Service, by running the command:
    ```bash
    kubectl get configurations <service-name> -o=jsonpath='{.status.latestCreatedRevisionName}'
    ```
    Where `<service-name>` is the name of the Service that you have redeployed.
    At this point, both the first and second Revisions of the Service are deployed and running.
 1. Update your existing Route to create a new, test endpoint for the second Revision, while still sending all other traffic to the first Revision.
    ***Example of updated Route***
    ```yaml
    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
    ```
    Once you redeploy this Route by reapplying the YAML resource, the second Revision of the app is now staged.
    No traffic is routed to the second Revision at the main URL, and Knative creates a new Route named `v2` for testing the newly deployed Revision.
 1. Get the URL of the new Route for the second Revision, by running the command:
    ```bash
    kubectl get route <route-name> --output jsonpath="{.status.traffic[*].url}"
    ```
    You can use this URL to validate that the new version of the app is behaving as expected before you route any traffic to it.
 1. Update your existing Route resource again, so that 50% of traffic is being sent to the first Revision, and 50% is being sent to the second Revision:
    ***Example of updated Route***
    ```yaml
    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
    ```
 1. Once you are ready to route all traffic to the new version of the app, update the Route again to send 100% of traffic to the second Revision:
    ***Example of updated Route***
    ```yaml
    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
    ```
    !!! tip
        You can remove the first Revision instead of setting it to 0% of traffic if you do not plan to roll back the Revision. Non-routeable Revision objects are then garbage-collected.
    <!--TODO: ADD GARBAGE COLLECTION DOCS-->
 1. Visit the URL of the first Revision to verify that no more traffic is being sent to the old version of the app.
 <!-- TODO: Add docs about autoscaling and named routes, e.g. explain v2 properly above-->
--- a/docs/serving/samples/blue-green-deployment.md
+++ b/docs/serving/samples/blue-green-deployment.md
@ -1,279 +0,0 @@
 ---
 title: "Routing and managing traffic with blue/green deployment"
 linkTitle: "Routing and managing traffic"
 weight:
 type: "docs"
 ---
 # Routing and managing traffic with blue/green deployment
 This sample demonstrates updating an application to a new version using a
 blue/green traffic routing pattern. With Knative, you can safely reroute traffic
 from a live version of an application to a new version by changing the routing
 configuration.
 ## Before you begin
 You need:
 - A Kubernetes cluster with [Knative installed](../../install/).
 - (Optional) [A custom domain configured](../using-a-custom-domain.md) for use
  with Knative.
 Note: The source code for the gcr.io/knative-samples/knative-route-demo image
 that is used in this sample, is located at
 https://github.com/mchmarny/knative-route-demo.
 ## Deploying Revision 1 (Blue)
 We'll be deploying an image of a sample application that displays the text "App
 v1" on a blue background.
 First, create a new file called `blue-green-demo-config.yaml`and copy this into
 it:
 ```yaml
 apiVersion: serving.knative.dev/v1
 kind: Configuration
 metadata:
  name: blue-green-demo
  namespace: default
 spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/knative-route-demo:blue # The URL to the sample app docker image
          env:
            - name: T_VERSION
              value: "blue"
 ```
 Save the file, then deploy the configuration to your cluster:
 ```bash
 kubectl apply --filename blue-green-demo-config.yaml
 configuration "blue-green-demo" configured
 ```
 This will deploy the initial revision of the sample application. Before we can
 route traffic to this application we need to know the name of the initial
 revision which was just created. Using `kubectl` you can get it with the
 following command:
 ```bash
 kubectl get configurations blue-green-demo -o=jsonpath='{.status.latestCreatedRevisionName}'
 ```
 The command above will return the name of the revision, it will be similar to
 `blue-green-demo-lcfrd`. In the rest of this document we will use this revision
 name, but yours will be different.
 To route inbound traffic to it, we need to define a route. Create a new file
 called `blue-green-demo-route.yaml` and copy the following YAML manifest into it
 (do not forget to edit the revision name):
 ```yaml
 apiVersion: serving.knative.dev/v1
 kind: Route
 metadata:
  name: blue-green-demo # The name of our route; appears in the URL to access the app
  namespace: default # The namespace we're working in; also appears in the URL to access the app
 spec:
  traffic:
    - revisionName: blue-green-demo-lcfrd
      percent: 100 # All traffic goes to this revision
 ```
 Save the file, then apply the route to your cluster:
 ```bash
 kubectl apply --filename blue-green-demo-route.yaml
 route "blue-green-demo" configured
 ```
 You'll now be able to view the sample app at the URL shown by:
 ```
 kubectl get route blue-green-demo
 ```
 ## Deploying Revision 2 (Green)
 Revision 2 of the sample application will display the text "App v2" on a green
 background. To create the new revision, we'll edit our existing configuration in
 `blue-green-demo-config.yaml` with an updated image and environment variables:
 ```yaml
 apiVersion: serving.knative.dev/v1
 kind: Configuration
 metadata:
  name: blue-green-demo # Configuration name is unchanged, since we're updating an existing Configuration
  namespace: default
 spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/knative-route-demo:green # URL to the new version of the sample app docker image
          env:
            - name: T_VERSION
              value: "green" # Updated value for the T_VERSION environment variable
 ```
 Save the file, then apply the updated configuration to your cluster:
 ```bash
 kubectl apply --filename blue-green-demo-config.yaml
 configuration "blue-green-demo" configured
 ```
 Find the name of the second revision with the following command:
 ```bash
 kubectl get configurations blue-green-demo -o=jsonpath='{.status.latestCreatedRevisionName}'
 ```
 In the rest of this document we will assume that the second revision is called
 `blue-green-demo-m9548`, however yours will differ. Make sure to use the correct
 name of the second revision in the manifests that follow.
 At this point, the first revision (`blue-green-demo-lcfrd`) and the second
 revision (`blue-green-demo-m9548`) will both be deployed and running. We can
 update our existing route to create a new (test) endpoint for the second
 revision while still sending all other traffic to the first revision. Edit
 `blue-green-demo-route.yaml`:
 ```yaml
 apiVersion: serving.knative.dev/v1
 kind: Route
 metadata:
  name: blue-green-demo # Route name is unchanged, since we're updating an existing Route
  namespace: default
 spec:
  traffic:
    - revisionName: blue-green-demo-lcfrd
      percent: 100 # All traffic still going to the first revision
    - revisionName: blue-green-demo-m9548
      percent: 0 # 0% of traffic routed to the second revision
      tag: v2 # A named route
 ```
 Save the file, then apply the updated route to your cluster:
 ```bash
 kubectl apply --filename blue-green-demo-route.yaml
 route "blue-green-demo" configured
 ```
 Revision 2 of the app is staged at this point. That means:
 - No traffic will be routed to revision 2 at the main URL,
  `http://blue-green-demo.default.[YOUR_CUSTOM_DOMAIN].com`
 - Knative creates a new route named v2 for testing the newly deployed version.
  The URL of this can be seen in the status section of your Route.
 ```bash
 kubectl get route blue-green-demo --output jsonpath="{.status.traffic[*].url}"
 ```
 This allows you to validate that the new version of the app is behaving as
 expected before switching any traffic over to it.
 ## Migrating traffic to the new revision
 We'll once again update our existing route to begin shifting traffic away from
 the first revision and toward the second. Edit `blue-green-demo-route.yaml`:
 ```yaml
 apiVersion: serving.knative.dev/v1
 kind: Route
 metadata:
  name: blue-green-demo # Updating our existing route
  namespace: default
 spec:
  traffic:
    - revisionName: blue-green-demo-lcfrd
      percent: 50 # Updating the percentage from 100 to 50
    - revisionName: blue-green-demo-m9548
      percent: 50 # Updating the percentage from 0 to 50
      tag: v2
 ```
 Save the file, then apply the updated route to your cluster:
 ```bash
 kubectl apply --filename blue-green-demo-route.yaml
 route "blue-green-demo" configured
 ```
 Refresh the original route
 (`http://blue-green-demo.default.[YOUR_CUSTOM_DOMAIN].com`) a few times to see that
 some traffic now goes to version 2 of the app.
 > Note: This sample shows a 50/50 split to assure you don't have to refresh too
 > much, but it's recommended to start with 1-2% of traffic in a production
 > environment
 ## Rerouting all traffic to the new version
 Lastly, we'll update our existing route to finally shift all traffic to the
 second revision. Edit `blue-green-demo-route.yaml`:
 ```yaml
 apiVersion: serving.knative.dev/v1
 kind: Route
 metadata:
  name: blue-green-demo # Updating our existing route
  namespace: default
 spec:
  traffic:
    - revisionName: blue-green-demo-lcfrd
      percent: 0
      tag: v1 # Adding a new named route for v1
    - revisionName: blue-green-demo-m9548
      percent: 100
      # Named route for v2 has been removed, since we don't need it anymore
 ```
 > Note: You can remove the first revision blue-green-demo-lcfrd instead of 0% of traffic
 > when you will not roll back the revision anymore.
 > Then the non-routeable revision object will be garbage collected.
 Save the file, then apply the updated route to your cluster:
 ```bash
 kubectl apply --filename blue-green-demo-route.yaml
 route "blue-green-demo" configured
 ```
 Refresh the original route
 (`http://blue-green-demo.default.[YOUR_CUSTOM_DOMAIN].com`) a few times to verify
 that no traffic is being routed to v1 of the app.
 We added a named route to v1 of the app, so you can now access it at the URL
 listed in the traffic block of the status section. To get the URL, enter the
 following command:
 ```bash
 kubectl get route blue-green-demo --output jsonpath="{.status.traffic[*].url}"
 ```
 With all inbound traffic being directed to the second revision of the
 application, Knative will soon scale the first revision down to 0 running pods
 and the blue/green deployment can be considered complete. Using the named `v1`
 route will reactivate a pod to serve any occasional requests intended
 specifically for the initial revision.
 ## Cleaning up
 To delete the sample app, enter the following commands:
 ```
 kubectl delete route blue-green-demo
 kubectl delete configuration blue-green-demo
 ```
--- a/docs/serving/samples/rest-api-go/README.md
+++ b/docs/serving/samples/rest-api-go/README.md
@ -202,12 +202,6 @@ and then you run `curl` commands to send request with your stock symbol.
      Response: `stock price for ticker FAKE is 0.00`
 ## Next Steps
 The [traffic splitting example](../traffic-splitting/) continues from
 here to walk you through how to create new Revisions and then use traffic
 splitting between those Revisions.
 ## Clean Up
 To clean up the sample Service:
--- a/docs/serving/samples/traffic-splitting/README.md
+++ b/docs/serving/samples/traffic-splitting/README.md
@ -1,155 +0,0 @@
 # Simple Traffic Splitting Between Revisions
 This samples builds off of the [Creating a RESTful Service](../rest-api-go)
 sample to illustrate updating a Service to create a new Revision as well as
 splitting traffic between the two created Revisions.
 ## Prerequisites
 1. Complete the Service creation steps in [Creating a RESTful Service](../rest-api-go).
 1. Move into the docs directory:
    ```bash
    cd $GOPATH/src/github.com/knative/docs
    ```
 ## Using the `traffic:` block
 The service was originally created without a `traffic:` block, which means that
 it will automatically deploy the latest updates as they become ready. To split
 traffic between multiple Revisions, we will start to use a customized `traffic:`
 block. The `traffic:` block enables users to split traffic over any number of
 fixed Revisions, or the floating "latest revision" for the Service. It also
 enables users to name the specific sub-routes, so that they can be directly
 addressed for qualification or debugging.
 The first thing we will do is look at the traffic block that was defaulted for
 us in the previous sample:
 1. Fetch the state of the Service, and note the `traffic:` block that will run
   the latest ready revision, each time we update our template. Also note that
   under `status:` we see a specific `revisionName:` here, which is what it has
   resolved to (in this case the name we asked for).
    ```yaml
    kubectl get ksvc -oyaml stock-service-example
    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: stock-service-example
      ...
    spec:
      template: ... # A defaulted version of what we provided.
      traffic:
      - latestRevision: true
        percent: 100
    status:
      ...
      traffic:
      - percent: 100
        revisionName: stock-service-example-first
    ```
 1. The `release_sample.yaml` in this directory overwrites the defaulted traffic
   block with a block that fixes traffic to the revision
   `stock-service-example-first`, while keeping the latest ready revision
   available via the sub-route "latest".
    ```bash
    kubectl apply -f docs/serving/samples/traffic-splitting/release_sample.yaml
    ```
 1. The `spec` of the Service should now show our `traffic` block with the
   Revision name we specified above.
    ```bash
    kubectl get ksvc stock-service-example --output yaml
    ```
 ## Updating the Service
 This section describes how to create a new Revision by updating your Service.
 A new Revision is created every time a value in the `template` section of the
 Service `spec` is updated. The `updated_sample.yaml` in this folder changes the
 environment variable `RESOURCE` from `stock` to `share`. Applying this change
 will result in a new Revision.
 For comparison, you can diff the `release_sample.yaml` with the
 `updated_sample.yaml`.
    ```bash
    diff serving/samples/traffic-splitting/release_sample.yaml \
    serving/samples/traffic-splitting/updated_sample.yaml
    ```
 1.  Execute the command below to update Service, resulting in a new Revision.
    ```bash
    kubectl apply --filename docs/serving/samples/traffic-splitting/updated_sample.yaml
    ```
 1. With our `traffic` block, traffic will _not_ shift to the new Revision
   automatically. However, it will be available via the URL associated with our
   `latest` sub-route. This can be verified through the Service status, by
   finding the entry of `status.traffic` for `latest`:
    ```bash
    kubectl get ksvc stock-service-example --output yaml
    ```
 1. The readiness of the Service can be verified through the Service Conditions.
   When the Service conditions report it is ready again, you can access the new
   Revision using the same method as found in the previous sample using the
   Service hostname found above.
    ```bash
    # Replace "latest" with whichever tag for which we want the hostname.
    export LATEST_HOSTNAME=`kubectl get ksvc stock-service-example --output jsonpath="{.status.traffic[?(@.tag=='latest')].url}" | cut -d'/' -f 3`
    curl --header "Host: ${LATEST_HOSTNAME}" http://${INGRESS_IP}
    ```
    - Visiting the Service's domain will still hit the original Revision, since we
      configured it to receive 100% of our main traffic (you can also use the
      `current` sub-route).
    ```bash
    curl --header "Host:${SERVICE_HOSTNAME}" http://${INGRESS_IP}
    ```
 ## Traffic Splitting
 Updating the service to split traffic between the two revisions is done by
 extending our `traffic` list, and splitting the `percent` across them.
 1.  Execute the command below to update Service, resulting in a 50/50 traffic
    split.
    ```bash
    kubectl apply -f docs/serving/samples/traffic-splitting/split_sample.yaml
    ```
 1. Verify the deployment by checking the service status:
    ```bash
    kubectl get ksvc --output yaml
    ```
 1. Once updated, `curl` requests to the base domain should result in responses
   split evenly between `Welcome to the share app!` and
   `Welcome to the stock app!`.
    ```bash
    curl --header "Host:${SERVICE_HOSTNAME}" http://${INGRESS_IP}
    ```
 ## Clean Up
 To clean up the sample service, run the command:
 ```bash
 kubectl delete -f docs/serving/samples/traffic-splitting/split_sample.yaml
 ```
--- a/docs/serving/samples/traffic-splitting/release_sample.yaml
+++ b/docs/serving/samples/traffic-splitting/release_sample.yaml
@ -1,40 +0,0 @@
 # Copyright 2019 The Knative Authors
 #
 # Licensed under the Apache License, Version 2.0 (the "License");
 # you may not use this file except in compliance with the License.
 # You may obtain a copy of the License at
 #
 #     https://www.apache.org/licenses/LICENSE-2.0
 #
 # Unless required by applicable law or agreed to in writing, software
 # distributed under the License is distributed on an "AS IS" BASIS,
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 # See the License for the specific language governing permissions and
 # limitations under the License.
 apiVersion: serving.knative.dev/v1
 kind: Service
 metadata:
  name: stock-service-example
  namespace: default
 spec:
  template:
    metadata:
      name: stock-service-example-first
    spec:
      containers:
      - image: ${REPO}/rest-api-go
        env:
          - name: RESOURCE
            value: stock
        readinessProbe:
          httpGet:
            path: /
          initialDelaySeconds: 0
  traffic:
  - tag: current
    revisionName: stock-service-example-first
    percent: 100
  - tag: latest
    latestRevision: true
    percent: 0
--- a/docs/serving/samples/traffic-splitting/split_sample.yaml
+++ b/docs/serving/samples/traffic-splitting/split_sample.yaml
@ -1,43 +0,0 @@
 # Copyright 2019 The Knative Authors
 #
 # Licensed under the Apache License, Version 2.0 (the "License");
 # you may not use this file except in compliance with the License.
 # You may obtain a copy of the License at
 #
 #     https://www.apache.org/licenses/LICENSE-2.0
 #
 # Unless required by applicable law or agreed to in writing, software
 # distributed under the License is distributed on an "AS IS" BASIS,
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 # See the License for the specific language governing permissions and
 # limitations under the License.
 apiVersion: serving.knative.dev/v1
 kind: Service
 metadata:
  name: stock-service-example
  namespace: default
 spec:
  template:
    metadata:
      name: stock-service-example-second
    spec:
      containers:
      - image: ${REPO}/rest-api-go
        env:
          - name: RESOURCE
            value: share
        readinessProbe:
          httpGet:
            path: /
          initialDelaySeconds: 0
  traffic:
  - tag: current
    revisionName: stock-service-example-first
    percent: 50
  - tag: candidate
    revisionName: stock-service-example-second
    percent: 50
  - tag: latest
    latestRevision: true
    percent: 0
--- a/docs/serving/samples/traffic-splitting/updated_sample.yaml
+++ b/docs/serving/samples/traffic-splitting/updated_sample.yaml
@ -1,40 +0,0 @@
 # Copyright 2019 The Knative Authors
 #
 # Licensed under the Apache License, Version 2.0 (the "License");
 # you may not use this file except in compliance with the License.
 # You may obtain a copy of the License at
 #
 #     https://www.apache.org/licenses/LICENSE-2.0
 #
 # Unless required by applicable law or agreed to in writing, software
 # distributed under the License is distributed on an "AS IS" BASIS,
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 # See the License for the specific language governing permissions and
 # limitations under the License.
 apiVersion: serving.knative.dev/v1
 kind: Service
 metadata:
  name: stock-service-example
  namespace: default
 spec:
  template:
    metadata:
      name: stock-service-example-second
    spec:
      containers:
      - image: ${REPO}/rest-api-go
        env:
          - name: RESOURCE
            value: share
        readinessProbe:
          httpGet:
            path: /
          initialDelaySeconds: 0
  traffic:
  - tag: current
    revisionName: stock-service-example-first
    percent: 100
  - tag: latest
    latestRevision: true
    percent: 0