In Knative Serving whenever you change Configuration of the Service, it creates a new Revision which is a point-in-time snapshot of code. It also creates a new Route and the new Revision will start receiving traffic.
To see how Knative reacts to configuration changes, let's change the environment variable the container reads.
Create a service-v2.yaml file that changes TARGET
value to v2
.
Note that the image is still pointing to v1
version. Apply the change:
kubectl apply -f service-v2.yaml
Now, you should see a new pod and a revision is created for the configuration change:
kubectl get pod,configuration,revision,route
NAME READY STATUS RESTARTS
pod/helloworld-c4pmt-deployment-7fdb5c5dc9-p2hr6 3/3 Running 0
pod/helloworld-vkvjt-deployment-7d7d9c9fdd-r27v8 3/3 Running 0
NAME configuration.serving.knative.dev/helloworld
NAME
revision.serving.knative.dev/helloworld-c4pmt
revision.serving.knative.dev/helloworld-vkvjt
NAME
route.serving.knative.dev/helloworld
Test that the route is also updated and prints out v2
:
curl http://helloworld.default.$ISTIO_INGRESS.xip.io
Hello v2
Configuration changes are not limited to environment variables. For example, a new container image would also trigger a new revision and traffic routed to that revision.
To see this in action, change your main file to say 'Bye' instead of 'Hello':
-
C# Startup.cs
await context.Response.WriteAsync($"Bye {target}\n");
-
Python app.py
return f'Bye {target}\n'
Build and push the Docker image tagging with v3
. Replace {username}
with your actual Docker Hub username:
docker build -t {username}/helloworld:v3 .
docker push {username}/helloworld:v3
Once the container image is pushed, create a service-v3.yaml file that changes TARGET
value to v3
but more importantly, it refers to the new image with tag v3
.
Apply the change:
kubectl apply -f service-v3.yaml
Test that the route is updated to v3
with the new container. It prints not only v3
(from env variable) but also says Bye (from container):
curl http://helloworld.default.$ISTIO_INGRESS.xip.io
Bye v3