Skip to content
No description, website, or topics provided.
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.

Devoxx UK 2019 - Knative demo


  1. Create GKE cluster fronted by DNS *
  2. Update docker-secret.yaml with Docker Hub credentials.
  3. kubectl apply -f setup to create secret with Docker Hub credentials associated with build-bot service account.
  4. Install kaniko build template kubectl apply -f
  5. Follow the setup instructions in the GCP Pub/Sub Knative sample.


Deploy Knative service

  1. helloworld.go is a simple Go web server. Note the use of PORT passed in by Knative.
  2. It has been built with Dockerfile and pushed to Docker Hub at dcurrie/helloworld-go:latest.
  3. service.yaml defines a Knative service which specifies the Docker image in its configuration along with an environment variable that is output in the response.
  4. kubectl apply -f service.yaml
  5. curl should return v1: Hello World!.

Deploy a second revision of the service

  1. Change v1 to v2 in service.yaml and re-apply.
  2. curl should now return v2: Hello World!. A new revision of the service has been created and, because we are using runLatest in the service definition, requests are automatically routed to the new revision once it has become available.


Unlike, say, a Function-as-a-Service platform, container instances are expected to handle multiple requests and, by default, handle concurrent requests.

  1. By default, the number of pods for a revision scales down to zero. This can be great as it means old revisions to which traffic is no longer being routed don't cost anything. It may not be desirable though if traffic is the container for a service takes time to become ready. Add the annotation "2" and re-apply the service.yaml.
  2. kubectl get pod should now show two pods for the latest revision.
  3. By default, auto-scaling is triggered based on a target maximum concurrency of 100. We'll lower that target to make triggering a scaling decision easier. Remove the minScale annotation and add the annotation "1" and re-apply the service.yaml.
  4. We'll use hey to drive some load. Run hey -z 10s -c 100 && kubectl get pods. Although the default averaging window is 60 seconds, when the concurrency breaches double the target then the auto-scaler enters panic mode and starts scaling up the number of instances so you should see additional pods.

Manual blue-green deployment

  1. Execute kubectl get revision and note the name of the revision for the latest generation.
  2. In service.yaml, change runLatest to release and v2 to v3. Add a revisions stanza under release which lists the latest revision noted in the previous step.
  3. curl should still return v2: Hello World!.
  4. Execute kubectl get revision and note the name of the revision for the third generation.
  5. Add the new revision into service.yaml under the existing one. Then add a rolloutPercent: 0 as a sibling of the revisions element. Apply the updated YAML. 1.curl is still returning v2: Hello World!.
  6. Although no default traffic is being routed to the new service revision, it is now tagged candidate and is available via curl
  7. Increase the rollout percentage to 50 and re-apply.
  8. Run curl repeatedly and note that the workload is now balanced across the two revisions.
  9. Remove the rolloutPercent and the old revision and re-apply.
  10. Run curl repeatedly and you should now only see the latest version.


  1. kubectl delete -f service.yaml


  1. Take a look at service-with-build.yaml. It adds a build configuration that points to the GitHub repo containing this application. It also specifies a service account configured with Docker Hub credentials and a Kaniko build template.
  2. Retrieve the build template with kubectl get buildtemplate kaniko -o yaml. Note how it takes the image name as a parameter. This template only contains a single step which specifies the kaniko executor image that will build an image and push it to a registry.
  3. Apply the service configuration with kubectl apply -f service-with-build.yaml.
  4. Watch the pods with kubectl get pods -w.
  5. Note that the build pod contains three init containers. Two are always injected: one to set up credentials (e.g. mounting in the Docker and/or Git credentials) and the second to check out the source from Git. These are followed by a container for each step in the build. They are run as init containers so that execute sequentially.
  6. Once the build has complete, the service will be deployed.
  7. Run curl


  1. Create eventing source with kubectl apply -f gcp-pubsub-source.yaml.
  2. Create the trigger to subscribe with kubectl apply -f trigger.yaml.
  3. Publish a message gcloud pubsub topics publish devoxx --message "Devoxx"
  4. Look at the logs for the application and note that it has been driven by the message.
  5. Look at helloworld.go again to see how it handles the event.


  1. kubectl delete -f service-with-build.yaml
  2. kubectl delete -f trigger.yaml
  3. kubectl delete -f gcp-pubsub-source.yaml
You can’t perform that action at this time.