Ahoy, mateys! We're calling at the port again to load up with a fresh portion of new features, improvements, and upgrades, but also to unload stuff that we no longer need on this journey and that's been slowing us down. Support for Kubernetes 1.21, a new alpha option for the deploy command, support for non-alphanumeric characters in event types, upgrade of the whole Monitoring component, and Istio refactoring are just some of those things that we happily bring aboard. Read on to find out more about this Kyma 2.1 ship!

CAUTION: Before upgrading to Kyma 2.1, read the Migration Guide.

See the overview of all changes in this release:

• General - Support for Kubernetes 1.21.
• CLI - Dry-run option for the deploy command in alpha, specifying components with downloadURL and version, generating schema for Function manifests, support for Gardener cluster hibernation, provisioning commands for GKE, AKS, and AWS removed
• Eventing - Support for non-alphanumeric characters in event types
• Observability - Kiali and Jaeger upgraded, Monitoring upgraded, Grafana dashboards improved, the alertmanager chart revamped, Logging chart updated and Loki improved
• Serverless - Node.js 12 deprecated
• Service Mesh - FIPS distroless Istio images provided by Solo, Istio refactored and upgraded to 1.12.3

With release 2.1, we now officially support and test against Kubernetes 1.21.

With this release, a new dry-run option was added to the deploy command. It lets you trial-run the YAMLs for your Kubernetes resources and see what the output would be if they were deployed. Mind that for now, the option is in the alpha version. It cannot be used yet to apply a full Kyma installation, as the components having custom installation routines (such as Istio) are not included in the generated manifests. See the Kyma CLI documentation for more details.

Another addition to the deploy command is an extension to the --component flag. Previously you could specify the name and namespace for the component. Now you can also specify the two additional parameters: downloadURL and version. Again, refer to the CLI documentation for more details.

We improved the development experience for Functions developers. We added schema generation for the config.yaml manifests. This, when combined with dedicated plugins in your IDE, helps you avoid mistakes via validation and autocompletion.

• If you use the VSCode IDE to develop Function code, just use the --vscode option when generating the Function project:
  Click to copy

  kyma init function --vscode

  This command creates the .vscode folder, which contains the schema for config.yaml. Install the YAML plugin in your IDE and VSCode will automatically pick it up for validation and autocompletion.

• If you just want to generate the schema, use the following command:

  Click to copy

  kyma get schema serverless

  This will print out the JSON schema so that you can import it in your preferred IDE.

Starting with Kyma 2.1, it is now possible to specify a hibernation schedule for a Kyma cluster which was created using the kyma provision gardener command. To do so, specify a hibernation schedule by providing cron expressions for the start and end of the hibernation, and the timezone on which to base the schedule:

kyma provision gardener gcp -n my-cluster -p my-project -c /path/to/credentials.yaml -s gcp-secret --hibernation-start="00 18 * * 1,2,3,4,5" hibernation-end="00 09 * * 1,2,3,4,5" hibernation-location="Europe/Berlin" 

By default, all Gardener clusters have hibernation scheduled for weekdays at 6pm (18:00) in the Europe/Berlin timezone.

With this release, we removed the support for provisioning Kyma clusters on the GKE, AWS, and AKS hyperscalers. Provisioning of a cluster via Gardener or k3d is still possible.

The naming in event types comes with certain restrictions. Previously, we only supported ASCII alphanumeric characters from the range [a-zA-Z0-9]+. If your name contained an unsupported character, the event sending was failed.

Starting from this release, we no longer fail sending such events. Instead, the unsupported characters are automatically dropped from events sent to Kyma and also from event types specified in the Subscription CRD.

Read about the event names and Subscription CRD in more detail.

With Kyma 2.1, the Kiali and Jaeger components were updated to the following recent versions:

• Kiali 1.44
• Jaeger 1.30.0

Speaking of upgrades, the different components of the Monitoring area also got one. While doing that, we felt inspired and updated the used Helm chart, too, and adapted it to the upstream charts. The components were upgraded to the following versions:

• Node-exporter 1.3.1
• Kube-state-metrics 2.3.0
• Prometheus 2.32.1
• Prometheus Operator 0.53.1
• Alertmanager 0.23.0
• Pushgateway 1.4.2
• Grafana 7.5.15
• Oauth2 Proxy 7.2.1

As the kube-state-metrics component got a major upgrade to version 2.x, some metrics were restructured.

The following table shows how the metrics were affected:

Furthermore, the envoy_ metrics exposed by the Istio sidecar running with every workload are not collected by default anymore. However, we continue to collect the more relevant istio_ metrics, which are used in the Istio-specific dashboards. It turned out that the envoy_ metrics were helpful only in advanced troubleshooting scenarios and introduced too big a cardinality of the metrics, resulting in big resource consumption. Still, you can enable them optionally. See #issue 13659 for more details.

Several improvements were applied to the dashboards that come with Grafana in Kyma:

• The Loki dashboard was improved by adding a new top section with the most relevant metrics displayed.
• All dashboards were adjusted to the metric changes coming with the major upgrade of kube-state-metrics.
• The dashboards tagged as kubernetes-mixins were updated to the latest available version from the community.
• node-exporter and Prometheus dashboards were replaced by the version provided by the community.
• The Kyma frontends and backends dashboards were removed, as they had no additional value to the existing dashboards.
• The Kyma Controllers dashboards were revamped to have relevant reconciliation metrics included, and they were rolled out to all Kyma controllers.

The Kyma alertmanager chart, which is a sub-chart of the Monitoring component, was refactored more heavily. Mainly, we tried to remove customizations that were in contrast to the available community chart, to simplify future updates.

With that, the following changes were applied:

• The dedicated configuration options for VictorOps were removed. Use the typical options for configuration of notification channels instead.
• New alert rules were added:
  • AlertmanagerFailedToSendAlerts
  • AlertmanagerClusterFailedToSendAlerts
  • AlertmanagerClusterFailedToSendAlerts Warning
  • AlertmanagerClusterDown
  • AlertmanagerClusterCrashlooping
  • ConfigReloaderSidecarErrors
  • KubeStateMetricsShardingMismatch
  • KubeStateMetricsShardsMissing
  • KubeAPITerminatedRequests
  • NodeFileDescriptorLimit
  • PrometheusLabelLimitHit
  • PrometheusTargetSyncFailure
  • PrometheusOperatorSyncFailed
• The following alert rules were renamed:
  • AggregatedAPIDown → KubeAggregatedAPIDown
  • AggregatedAPIErrors → KubeAggregatedAPIErrors

We updated the Logging component to the latest available FluentBit version, 1.8.13. Furthermore, the label map for the Loki integration was improved:

• Previously, we had the Kubernetes app label mapped to the Loki app label. Now, on top of that, we also mapped the label app.kubernetes.io/name to the Loki app label.
• We mapped the label app.kubernetes.io/component to the Loki component label.
• We removed the release and serverless.kyma-project.io/uuid labels to improve the chunk size handling in Loki.

Moreover, besides having data retention by time, we introduced a new sidecar taking care of data retention by size. With that, Loki will not crash anymore when reaching the volume size limit. Oldest data is deleted first.

The base image for Node.js 12 will be maintained only until April 2022. Thus, following the recommendations from Node.js, we are planning to remove Node.js 12 from the list of supported runtimes soon. This basically means that Node.js 12-based Functions will continue to work, but you won’t be able to create a new Function on this runtime or edit an existing Function to run on it.

For now, we recommend that you re-configure all your Node.js 12 Functions to run on the Node.js 14 runtime.

With Kyma 2.1, both Istio control plane and data plane now use distroless images compliant with Federal Information Processing Standards (FIPS). Solo provides the FIPS-certified images. To learn more, read about Distroless FIPS-compliant Istio.

With this release, we upgraded Istio from 1.11.4 to 1.12.3. For more details on the introduced changes, read the official Istio 1.12.3 release notes.

With Kyma 2.1, we improved the Istio component, splitting it into two charts: istio (previously istio-configuration) and istio-resources. The Istio component, with the istio chart, is now solely responsible for pure Istio installation. The istio-resources chart includes Kyma-specific configuration, and it is not a prerequisite for Kyma.