knative
/
docs
mirror of https://github.com/knative/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

#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
This commit is contained in:
Ashleigh Brennan 2021-07-07 09:12:18 -05:00 committed by GitHub
parent be72eae9bb
commit 54290e2318
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
9 changed files with 238 additions and 571 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
config/nav.yml
View File

@ -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/

4
config/redirects.yml
View File

@ -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

232
docs/developer/serving/traffic-management.md Normal file
View File

@ -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-->

279
docs/serving/samples/blue-green-deployment.md
View File

@ -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
```

12
docs/serving/samples/rest-api-go/README.md
View File

@ -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/<YOUR_PROJECT_ID>"
```
@ -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:

155
docs/serving/samples/traffic-splitting/README.md
View File

@ -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
```

40
docs/serving/samples/traffic-splitting/release_sample.yaml
View File

@ -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

43
docs/serving/samples/traffic-splitting/split_sample.yaml
View File

@ -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

40
docs/serving/samples/traffic-splitting/updated_sample.yaml
View File

@ -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