Swooosh… wow that was fast - the first half of 2022 is over already, and we’re at Kyma release 2.4! We hope this summery update finds you well; maybe you’re going through your wardrobe and packing for vacation right now? No matter if you’re already sipping a cocktail on the beach or busy planning your vacation, find some time to read our hot news. To name just a few of the improvements and updates that we packed into this release, Eventing got a new backend and Serverless supports a new runtime. We’ve also finalized our spring cleaning and completely removed Service Catalog and Rafter. The Application Connectivity and Observability components have been adjusted accordingly.

See the overview of all changes in this release:

• Application Connectivity - Application Gateway support for mTLS-OAuth
• Eventing - Introduced NATS JetStream as the default Eventing backend
• Serverless - Added support to NodeJS 16, improved scheduling of Function build jobs
• Service Management - Service Catalog removed, PodPreset deprecation note
• Service Mesh - Istio upgraded to 1.14.1
• Observability - Kiali upgraded to 1.51.1

We introduced support for mTLS OAuth-secured APIs in Application Gateway. You can now configure your Application CRs so that Application Gateway fetches the OAuth token with the help of a TLS certificate as a credential. To learn how to do that, see Register an OAuth 2.0 mTLS-secured API.

With Kyma 2.4, we changed the NATS eventing backend to use NATS JetStream instead of just Core NATS. This updated backend improves the delivery guarantees from previously AT-MOST-ONCE to now AT-LEAST-ONCE. To facilitate this change, the NATS cluster now relies on backing storage by default.

With Kyma 2.4, you have a new Serverless runtime available – NodeJS 16. This new runtime not only brings a new version of NodeJS but also new versions of bundled OpenTelemetry SDK. All this enhances the development experience for NodeJS developers and improves the traceability of the requests handled by your NodeJS functions.

We have fixed the resource configuration for some of the Kyma components to reduce their CPU overcommitment. Additionally, we have removed the fixed requirements for computation resources for Function build jobs. With those changes, Function build jobs have better conditions to be scheduled, and your Functions won't be stuck in the building phase.

With Kyma 1.23, we announced the deprecation of Service Catalog. Now in Kyma 2.4, we completely removed it. That's why in the 2.4 release, the following Service Catalog-related components are no longer installed as part of Kyma:

• Service Catalog

• Helm Broker

• Application Broker

• Application Operator

• Service Binding Usage Controller

• Rafter

Note that your Service Catalog resources will not be migrated to any other solution. As mentioned in the Service Catalog deprecation update, we recommend you to use service operators for Service Management in Kyma.

If you already switched to another solution and want to remove the obsolete CRDs from your cluster, run Service Catalog cleanup script provided in the Migration Guide after you upgrade from Kyma 2.3 to 2.4.

Service Catalog removal also affects Application Connectivity. We removed some components that interacted with Service Catalog, which means that Application Operator and Application Broker are no longer installed on new clusters. This also means that on fresh clusters, or after executing the migration script we provide, the old Application flow will no longer be present, and you will need to use the new way of connecting the external Systems.

Due to the Service Catalog removal, Kyma will stop managing PodPresets by the end of October, 2022. Make sure to migrate your resources until then.

Once the PodPresets are removed, the Secrets consumed by your existing Pods will only last until the restart. Upon the next Pods creation, the auto-injecting mechanism will be gone and you will have to mount the Secrets using these solutions:

• Mounting Secrets to Kyma Functions
• Mounting Secrets to Kubernetes Deployments (using either volume or environment variable mounting)

Mounting Secret data to Kyma Function ensures that the data is preserved in the Function despite the configuration changes you may provide in the future. In this method, all Secret keys become environment variables. You can provide them to your Function using Kyma Dashboard: 1. In Kyma Dashboard, go to the Functions view and select a Function. 2. In the Environment Variables section, click Add Environment Variable. 3. Select Secret Variable and provide the required details.

This adds the env property with environment variables to the Function's specification:

env:
  - name: Email
    valueFrom:
      secretKeyRef:
        key: Email
        name: test-secret
  - name: Name
    valueFrom:
      secretKeyRef:
        key: Name
        name: test-secret

Alternatively, you can add the env property by editing the Function's specification directly.

You can also mount Secrets to Kubernetes Deployments using either volume or environment variable mounting.

• Follow these steps to mount your Secrets to Kubernetes Deployments using volumes:

  1. Add the volumes property with your Secret data to the spec.template.spec.volumes property of your Deployment:

     Click to copy

     volumes:
     - name: volume-with-secret-data
       secret:
         secretName: test-secret
         optional: false

  2. Add volumeMounts to the spec.template.spec.containers[] property of every container in which you want to consume a given Secret:

     Click to copy

     volumeMounts:
       - name: volume-with-secret-data
         mountPath: "/secret/data"
         readOnly: true

• You can also mount Secrets to Kubernetes Deployments using environment variables:

  • In the Deployment's spec.template.spec.containers[] property, add envFrom to every container in which you want to consume a Secret:
    Click to copy

    envFrom:
      - secretRef:
        name: test-secret

  • If you want to configure environment variables, add env to the spec.template.spec.containers[] property to every container in which you want to consume a Secret. See the example:
    Click to copy

      env:
    - name: EMAIL-FROM-SECRET
      valueFrom:
        secretKeyRef:
          name: test-secret
          key: Email
          optional: false
    - name: PASSWORD-FROM-SECRET
      valueFrom:
        secretKeyRef:
          name: test-secret
          key: Password
          optional: false
    - name: NAME-FROM-SECRET
      valueFrom:
        secretKeyRef:
          name: test-secret
          key: Name
          optional: true

In this release, we upgraded Istio from 1.13.2 to 1.14.1. For more details, read the official Istio 1.14.1 release notes.

To ensure compatibility after the Istio upgrade to v1.14, we upgraded Kiali to 1.51.1. It contains name changes of most Kiali resources, so we added Kiali cleanup script to delete old resources after the upgrade.