diff --git a/config/nav.yml b/config/nav.yml index d1f5c84dd..aa053749c 100644 --- 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/ - diff --git a/config/redirects.yml b/config/redirects.yml index 7047c23d5..d6ee003a3 100644 --- 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 - - diff --git a/docs/developer/serving/traffic-management.md b/docs/developer/serving/traffic-management.md new file mode 100644 index 000000000..e536e09b6 --- /dev/null +++ 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 --traffic = +``` + +Where: + +- `` is the name of the Knative Service that you are configuring traffic routing for. +- `` is the name of the revision that you want to configure to receive a percentage of traffic. +- `` is the percentage of traffic that you want to send to the revision specified by ``. + +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 -o=jsonpath='{.status.latestCreatedRevisionName}' + ``` + + Where `` 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: + namespace: default + spec: + traffic: + - revisionName: + percent: 100 # All traffic goes to this revision + ``` + + Where; + + - `` is the name you choose for your route. + - `` 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 + ``` + + Where `` 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 -o=jsonpath='{.status.latestCreatedRevisionName}' + ``` + + Where `` 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: + namespace: default + spec: + traffic: + - revisionName: + percent: 100 # All traffic is still being routed to the first revision + - revisionName: + 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 --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: + namespace: default + spec: + traffic: + - revisionName: + percent: 50 + - revisionName: + 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: + namespace: default + spec: + traffic: + - revisionName: + percent: 0 + - revisionName: + 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. + + +1. Visit the URL of the first Revision to verify that no more traffic is being sent to the old version of the app. + + diff --git a/docs/serving/samples/blue-green-deployment.md b/docs/serving/samples/blue-green-deployment.md deleted file mode 100644 index 77c9ba721..000000000 --- a/docs/serving/samples/blue-green-deployment.md +++ /dev/null @@ -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 -``` diff --git a/docs/serving/samples/rest-api-go/README.md b/docs/serving/samples/rest-api-go/README.md index e3f416049..56bbbf396 100644 --- a/docs/serving/samples/rest-api-go/README.md +++ b/docs/serving/samples/rest-api-go/README.md @@ -37,12 +37,12 @@ This sample uses Docker for both building and pushing. To build and push to a container registry using Docker: -1. From the `knative-docs` directory, run the following command to set your +1. From the `knative-docs` directory, run the following command to set your container registry endpoint as an environment variable. - + This sample uses [Google Container Registry (GCR)](https://cloud.google.com/container-registry/): - + ```bash export REPO="gcr.io/" ``` @@ -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: diff --git a/docs/serving/samples/traffic-splitting/README.md b/docs/serving/samples/traffic-splitting/README.md deleted file mode 100644 index bf72e3fc5..000000000 --- a/docs/serving/samples/traffic-splitting/README.md +++ /dev/null @@ -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 -``` diff --git a/docs/serving/samples/traffic-splitting/release_sample.yaml b/docs/serving/samples/traffic-splitting/release_sample.yaml deleted file mode 100644 index b0578d180..000000000 --- a/docs/serving/samples/traffic-splitting/release_sample.yaml +++ /dev/null @@ -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 diff --git a/docs/serving/samples/traffic-splitting/split_sample.yaml b/docs/serving/samples/traffic-splitting/split_sample.yaml deleted file mode 100644 index a499f70c7..000000000 --- a/docs/serving/samples/traffic-splitting/split_sample.yaml +++ /dev/null @@ -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 diff --git a/docs/serving/samples/traffic-splitting/updated_sample.yaml b/docs/serving/samples/traffic-splitting/updated_sample.yaml deleted file mode 100644 index 1f971a862..000000000 --- a/docs/serving/samples/traffic-splitting/updated_sample.yaml +++ /dev/null @@ -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