We've been working as busy bees to present to you Kyma 2.8. We packed this release with upgrades, updates, and improvements, as well as some changes to prepare the ground for the features to come. For example, we introduced support for response rewriting in Application Gateway, and improved Secret rotation for LogPipelines, but there's much more!

While we get back to beeing busy with what's next, you go and explore what we've prepared for you.

See the overview of all changes in this release:

• API Gateway - exposing workloads in multiple Namespaces with one APIRule
• Application Connectivity - response rewriting and updated status codes in Application Gateway
• Observability - component updates, improved Secret rotation support for LogPipelines, Kiali deprecation
• Security - upgrade to Istio 1.15.0, istio-init container replaced with Istio CNI plugin
• Serverless - Serverless engine switched to OTLP

This Kyma release comes with an update to the APIRule CR that lets you expose and secure services in multiple Namespaces. Now it’s possible to specify the service Namespace either on the spec.service level or individually for each service in spec.rules. This new field is optional. If you do not specify it, the default APIRule Namespace is used.

For more details, see the APIRule CR documentation. Check out also our new tutorial on how to expose workloads in multiple Namespaces with a single APIRule definition.

From this release, Application Gateway in Kyma supports redirects for the HTTP requests in which the URL host remains unchanged.

With this functionality, the HTTP client has the option to resolve redirects within the scope of the same API. If so configured, the HTTP client that originally called Application Gateway follows redirects through the Gateway, passing authorization, custom headers, URL parameters, and the body.

For more details, see Application Gateway details.

In this release, we also updated the HTTP status codes that Application Gateway returns in the following cases:

• When the Application specified in the path does not exist.
• When the Application, service or entry is not passed in the path.
• When a call to target API times out.

For more details, see Status codes for errors returned by Application Gateway.

In preparation for the bigger changes planned in the Tracing area, we updated the Jaeger stack to version 1.37, and enabled OTLP support.

At the same time, the Serverless engine switched to OTLP as well, and is ready for the awesome future.

In this release, we also updated the Prometheus node-exporter to version 1.4.0, and kube-state-metrics to version 2.6.0.

For more details, see the release notes for node-exporter and kube-state-metrics.

Yet another update that we made in this release is bumping Fluent Bit to version 1.9.9.

We also improved Secret rotation support for LogPipelines. A rotated Secret is now detected instantly.

NOTE: Mind that with Kyma 2.6, the Fluent Bit part of the Logging component was replaced by the new Telemetry component. This Fluent Bit part will be removed with the next Kyma release. If you have not adopted the change yet, do so now.

The Kyma Observability feature was shifted in the direction of integration and openness to enable enterprise-grade qualities based on external services. See the blog post on Observability strategy for more details. As a consequence, Kiali will be removed in Kyma 2.10. See the blog post on Kiali deprecation.

Worry not, though, as you can still integrate it on your own. We've got you covered, and we've prepared a tutorial on how to install custom Kiali in Kyma.

In this Kyma release, Istio was upgraded to version 1.15.0.

For more details on the changes, read the official Istio 1.15.0 release notes.

Breaking changes

This Kyma version introduces the Istio CNI plugin. The plugin replaces the istio-init container, and it provides the same networking functionality, but it doesn't require Istio users to have elevated Kubernetes RBAC permission.

To learn more, read about the Istio CNI plugin.

If initContainers starting in a Pod with sidecar injection enabled need to have networking capabilities, you must follow one of the these migration guides:

• Set the UID of the initContainer to 1337 using runAsUser. 1337 is the UID used by the sidecar proxy. The traffic sent by this UID is not captured by the Istio's iptables rule. Application container traffic is captured as usual.
• Set the traffic.sidecar.istio.io/excludeOutboundIPRanges annotation to disable. It disables redirecting traffic to any CIDRs that the init containers communicate with.
• Set the traffic.sidecar.istio.io/excludeOutboundPorts annotation to disable. It disables redirecting traffic to the specific outbound ports that the initContainers use.

Following the changes in Observability and opening new OTLP-compliant endpoints in Jaeger, the Serverless engine now configures Functions to send trace data to this new endpoint. Functions built before releasing Kyma 2.8 will continue sending trace data to the previous endpoint.

For more information, see the Environment variables in Serverless.