Knative v0.5 introduces the Trigger and Broker objects into the Eventing architecture
The Knative team is back with the release of v0.5 that brings some rather important updates for eventing as well as a number of other improvements. Let’s have a look.
Knative is back with another release.
While the team strives to deliver more frequent and predictable releases that bring smaller and incremental features, Knative v0.5 comes with some updates for eventing as well as a number of other improvements.
Let’s have a quick look at what’s new in the 0.5 release.
Eventing – The new release introduces the Trigger and Broker objects into the Eventing architecture which aims to help developers build robust, complex, event-driven systems more easily. Here’s how they work:
- Trigger: No longer need to manually provision transport for events and route them to downstream knative services. Now you can simply define an event trigger that selects the source events and sends them to the consuming service.
- Broker: Serves as the central events hub to which all messages are sent. Write services or configure Sources that emit events to the Broker, which handles the rest.
- New event Source: Support for the Kafka event source.
Autoscaling – In order to make autoscaling under a variety of workloads a smoother and more efficient motion, Knative v0.5 features an expansion of autoscaling metrics that were added for additional visibility over time-frames.
Core API – You no longer need to guess how to target one fork of your traffic split since named sub-routes now surface their URLs in the status of Service and Route resources. What’s more, several of the default values populated by the webhook are now configurable through a new ConfigMap called config-defaults.
Networking – Numerous bug fixes and improvements on the overall cold-starts for gRPC services as well as further improvements for client default authority header handling.
Still not sure what are the benefits of serverless computing or what exactly is Knative and what features are still in development?
We talked to Evan Anderson, Senior Staff Software Engineer at Google and he is here to give you an introduction into the new shiny serverless tooling based on Kubernetes as well as the benefits and the downsides of serverless computing and why it is such a big topic at the moment.
Knative implements a change-tracked server-side workflow where each deployment and configuration change results in a new server-side Revision. Revisions allow easy canary and rollback of production changes and were part of our initial design process based on experience with App Engine. Every Knative Revision is backed by a standard Kubernetes Deployment and an Istio VirtualService, so we deliver a lot of functionality out of the box. Further, we integrate with systems like Prometheus, Zipkin, and ELK to collect observability information, which can be a challenge in serverless environments.
Check out the full interview here.