2019–06–19 Update: This post has been moved to knative.dev/blog
Once again, we are excited to announce updates to Knative. The v0.4 release continues to respond to ongoing direct feedback from the growing number of deployments. In each release, Knative implements these learnings based on new use-cases that are now being addressed with our platform.
The areas where we received the most feedback were: configuration and secret management.
As Knative maintains its predictable release cadence, the ability to preserve the settings from your previous installation (e.g. domain) became even more important. So, in the v0.4 release, Knative now preserves previously set ConfigMap values during the update process. Starting with subsequent releases, users should be able to simply apply the latest knative/serving release and continue using their previous settings.
With regards to secret management, Knative users have frequently asked for more flexibility with Secrets (for confidential data) and ConfigMaps (for non-confidential data). To address that need, Knative has now added support for mounting Secrets and ConfigMaps as volumes.
Another area where we had a lot of feedback almost since the initial release of Knative was the need for additional network protocol support besides basic HTTP. I’m happy to say that with the v0.4 release Knative now also supports both HTTP2 and gRPC for ports named h2c. There are still some challenges with streaming RPC during cold-starts so we look forward to your feedback.
Additionally, Knative also now supports the ability to upgrade an inbound HTTP connection for WebSockets. This change involved plumbing through various layers of serving infrastructure, including activator and Istio VirtualService, so we are happy to finally land this often requested feature in Knative.
As with previous releases, Knative autoscaling continues to be an area of focus. The v0.4 release is no different, and once again, it improves on cold-start times by immediately scaling up when the autoscaler gets stats from activator. This reduces the latency when Knative must activate a previously scaled-to-zero workload. Additionally, the Serving activator also now throttles traffic it sends to scaled to zero pods to avoid overloading a single pod during initial large bursts of traffic.
As we indicated in the previous release, starting with the v0.4 release, Knative removes the customized Istio IngressGateway to enhance support for multiple versions of Istio and to reduce the number of needed load balancers. Users upgrading from the v0.3 release will need to reconfigure their DNS to point to the IP address exposed by istio-ingressgateway before upgrading, and remove the knative-ingressgateway Service and Deployment.
Finally, the v0.4 release of Knative serving adds an option to change the default ClusterIngress controller in the config-network ConfigMap from Istio if another controller is necessary.
In Eventing, the in-memory channel is now buffering events in memory rather than acting as a proxy. This change improves efficiency and throughput of event sources by reducing client blocking.