Basics of Traffic Splitting
What are some common traffic splitting use-cases?
Splitting traffic is useful for a number of very common modern infrastructure needs, such as blue/green deployments and . Bringing these industry standards to bear on Kubernetes is as simple as a single CLI command on Knative or YAML tweak, let’s see how!
A new Revision gets created each and every time you make changes to the configuration of your Knative Service. When splitting traffic, Knative splits traffic between different Revisions of your Knative Service.
What exactly is a Revision?
You can think of a Revision snapshot-in-time of application code and configuration.
Instead of update the environment variable TARGET
on your Knative Service hello
to greet “Knative” instead.
knYAML
Deploy the updated version of your Knative Service by running the command:
As before, kn
prints out some helpful information to the CLI.
Expected output
Service 'hello' created to latest revision 'hello-00002' is available at URL:
http://hello.default.${LOADBALANCER_IP}.sslip.io
Edit your existing
hello.yaml
file to contain the following:---
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: hello
spec:
template:
containers:
- image: gcr.io/knative-samples/helloworld-go
ports:
- containerPort: 8080
env:
- name: TARGET
-
kubectl apply -f hello.yaml
Expected output
service.serving.knative.dev/hello configured
Note that since we are updating an existing Knative Service hello
, the URL doesn’t change, but our new Revision should have the new name hello-00002
.
To see the change, access the Knative Service again on your browser or use curl
in your terminal:
echo "Accessing URL $(kn service describe hello -o url)"
curl "$(kn service describe hello -o url)"
Expected output
Splitting Traffic
You may at this point be wondering, “where did ‘Hello World!’ go?” Remember, Revisions are an immutable snapshot-in-time of application code and configuration, so your old hello-00001
Revision is still available to you.
We can easily see a list of our existing Revisions with the kn
or kubectl
CLI.
knkubectl
View a list of revisions by running the command:
kn revisions list
Expected output
NAME SERVICE TRAFFIC TAGS GENERATION AGE CONDITIONS READY REASON
hello-00002 hello 100% 2 30s 3 OK / 4 True
hello-00001 hello 1 5m 3 OK / 4 True
View a list of Revisions by running the command:
kubectl get revisions
Expected output
hello-00001 hello 1 True 0 0
hello-00002 hello 2 True 0 0
When you create a new Revision of a Knative Service, Knative defaults to directing 100% of traffic to this latest Revision. We can change this default behavior by specifying how much traffic we want each of our Revisions to receive.
Lets split traffic between our two Revisions:
knYAML
Run the command:
kn service update hello \
--traffic hello-00001=50 \
--traffic @latest=50
Add the
traffic
section to the bottom of your existinghello.yaml
file:Apply the YAML by running the command:
kubectl apply -f hello.yaml
Info
@latest
will always point to our “latest” Revision which, at the moment, is hello-00002
.
To verify that the traffic split has configured correctly, list the revisions again by running the command:
kn revisions list
Expected output
NAME SERVICE TRAFFIC TAGS GENERATION AGE CONDITIONS READY REASON
hello-00002 hello 50% 2 10m 3 OK / 4 True
hello-00001 hello 50% 1 36m 3 OK / 4 True
Access your Knative Service multiple times in your browser to see the different output being served by each Revision.
echo "Accessing URL $(kn service describe hello -o url)"
curl "$(kn service describe hello -o url)"
Expected output
Hello Knative!
Hello World!
Hello Knative!