The 0.9 release comes with many updates and improvements, as well as some brand new features that make the Kyma experience even smoother. The Kyma-Knative integration has reached its peak and from this release, Knative Eventing is the default eventing mechanism. You can now install Kyma on GKE and AKS clusters using the default DNS solution provided by xip.io. Among many updates and improvements, we developed a new testing framework and updated the entire Monitoring stack. Last but not least, we introduced a brand new component for storing and managing content - the Headless CMS.

The highlights of Kyma 0.9 Florence include:

• Knative-based eventing by default - The eventing mechanism is now based on Knative by default.
• Xip.io wildcard as the default DNS solution - We integrated the xip.io wildcard DNS as the default DNS solution.
• Headless CMS component introduced for the Console UI - We introduced the Headless CMS component that allows you to store and manage content, and expose it through an API.
• Updated Monitoring stack version - We updated the entire Monitoring stack.
• Improved upgrade process - We developed a testing framework that automates checking the state of Kyma components after the upgrade.

See the overview of all changes in this release:

• Application Connector - Connector Service enhancements and extensions
• Console - Console views that display documentation use the new Headless CMS
• Core and Supporting - Kyma Headless CMS as the default solution for handling documentation
• Eventing - Knative Eventing enabled by default, improved security, alerting and monitoring added
• Installation - Xip.io wildcard as the default DNS solution, test runner for the Kyma upgrade
• Monitoring - Monitoring stack upgraded to the latest version
• Security - TLS in Tiller, external bundles repositories with TLS in the Helm Broker, Istio with mutual TLS for the Service Catalog and all Service Brokers
• Service Mesh - Upgrade to Istio 1.1

CAUTION: To ensure the persistence of API services specifications, run the migration script to move successfully from v0.8 to v0.9. Read the Migration Guide for details.

We extended the Application Registry API with the possibility to fetch the generated client certificates. As soon as you register an API secured with the client certificate verification as a security mechanism, you can read this certificate with our API. Read this document for more information.

We extended the TokenRequest functionality and now you can apply details for the tenant name and group name. It allows you to easily manage the token generation process for pairing applications in the central Connector Service. For more details, read this document.

We updated our documentation with the description of the Root CA rotation procedure.

We enhanced the Gateway Service with the extended set of acceptance tests, which increases our confidence in the stability and performance of the component.

We changed the Application Gateway proxy functionality and now the unnecessary headers, such as X-Forwarded-For, are removed while making calls to external solutions. For the full list of removed headers, read this document.

The Documentation UI, which you can access in the Console UI, is now integrated with the Headless CMS. This means you can extend the Documentation view, the one you see after clicking the ? icon, with your custom documentation topics as long as you have your docs written in Markdown and extended with additional metadata. The code snippet below is an example of a ClusterDocsTopic custom resource that will extend the Documentation UI navigation with a new element called Prometheus under a Components heading. After clicking Prometheus, you will see the official Prometheus documentation.

cat <<EOF | kubectl apply -f -
apiVersion: cms.kyma-project.io/v1alpha1
kind: ClusterDocsTopic
metadata:
  labels:
    cms.kyma-project.io/view-context: docs-ui
    cms.kyma-project.io/group-name: components
    cms.kyma-project.io/order: "2"
  name: prometheus
spec:
  displayName: "Prometheus"
  description: "Some docs about Prometheus concepts"
  sources:
    - type: markdown
      name: docs
      mode: package
      url: https://github.com/prometheus/docs/archive/main.zip
      filter: content/docs/concepts
EOF

The Service Catalog-related views now read documentation provided with the new Headless CMS. This means that you can easily provide documentation and specifications for any service that you want to share through the Service Catalog. See the example DocsTopic custom resource for artificial Service Class that exposes Slack APIs:

apiVersion: cms.kyma-project.io/v1alpha1
kind: DocsTopic
metadata:
  name: {$SERVICE_CLASS_ID}
  labels:
    cms.kyma-project.io/view-context: service-catalog
spec:
  displayName: Slack
  description: "Slack documentation"
  sources:
    - type: markdown
      name: markdown-doc
      mode: single
      url: https://raw.githubusercontent.com/slackapi/slack-api-specs/master/README.md
    - type: asyncapi
      name: events-api
      mode: single
      url: https://raw.githubusercontent.com/slackapi/slack-api-specs/master/events-api/slack_events_api_async_v1.json
    - type: openapi
      name: openapi-swagger
      mode: single
      url: https://raw.githubusercontent.com/slackapi/slack-api-specs/master/web-api/slack_web_openapi_v2.json

In Kyma, we value the content-as-code principle. It means that documentation is treated the same as code, as in the end, it is not much different. We decided to go one step further. If content is like code, why not deploy it into the Kubernetes cluster as code as well? If you can easily deploy a service using the Deployment resource, you can do the same with documentation. This is what we implemented - the Headless CMS, based on Kubernetes Custom Resource Definitions, that uses our other component, the Asset Store, for storage.

The Headless CMS itself does not yet deliver any customizable UI interface that could be used to publish a standalone documentation portal. Nevertheless, we already use it in the Console UI. For more details, read the Headless CMS documentation.

You can now extend the Asset Store status sub-resource with additional metadata information for each file created by the controller. To do so, create a separate service that implements REST API and accepts multipart/form-data. One of the use cases for such a service is to extract the front matter metadata provided in any file of the yaml format. See the example AssetStore resource that contains information about the status modification webhook:

apiVersion: assetstore.kyma-project.io/v1alpha2
kind: Asset
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: asset-sample
  namespace: default
spec:
  bucketRef:
    name: test-sample
  source:
    url: https://github.com/kyma-project/kyma/archive/0.8.1.zip
    filter: /docs/service-catalog/docs/
    mode: package
    metadataWebhookService:
    - name: assetstore-asset-metadata-service
      namespace: kyma-system
      endpoint: /v1/extract
      filter: \.md$

To learn more about webhook services, read this document.

With the support of the new metadata webhook, we added a default service to the Asset Store domain. You can use it to extract the front matter metadata provided in any file of the yaml format. We already use this service in the Headless CMS component. For more details, read this document.

Kyma now uses Knative Eventing backed by NATS Streaming by default. This is a big first step towards leveraging Knative Eventing capabilities in the upcoming releases.

Access to NATS Streaming is now restricted only to applications that store and read Events.

We added alerting and monitoring for eventing backing services.

The wildcard DNS provided by xip.io is integrated as the default DNS solution, which means you can now install Kyma on GKE and AKS clusters and create a playground environment even easier. Simply start the installation on your cluster and don't worry about owning a domain or configuring your cluster in a specific way. If you want to spin up a production-ready cluster, the process doesn't change. When you provide your own domain and TLS certificates, the Installer uses them instead of these provided by xip.io. Additionally, all scenarios support Application Connectivity.

We created a test runner and a place for end-to-end upgrade tests executed by Kyma upgrade plan on CI. The framework allows you to prepare the data and run tests against the prepared data. For more information on end-to-end upgrade tests, read this document.

We upgraded the entire Monitoring stack based on the Prometheus operator to the latest version. The upgraded components are Alertmanager v0.16.1, Prometheus Operator v0.29.0, Prometheus v2.7.1, and Grafana v6.0.1.

From this release, communication with Tiller requires a TLS certificate. For developers who install Kyma locally using Minikube, the start-up scripts automatically set certificates for Helm. However, from now on it is mandatory to add the --tls flag to every Helm command.

From now on, on your non-local clusters, you can use only servers with TLS enabled. All incorrect or unsecured URLs will be omitted. You can use unsecured URLs only on your local cluster. For more information, read this document.

We introduced Istio with mutual TLS for the Service Catalog and for all Service Brokers (the Helm Broker, Application Broker, and Azure Broker).

Kyma now uses Istio version 1.1.