Kyma 1.2 Istanbul

Tomasz Papiernik, Technical Writer @Kyma on June 13, 2019

It's about time to sail our ship to Istanbul and see all of the new features and tweaks that come with the 1.2 release. This time around we focused on streamlining the installation flow, providing a simpler way of testing lambda functions, giving more power and flexibility to Kyma Eventing, migrating to a new version of Istio, and providing even more useful documentation.

The highlights of Kyma 1.2 Istanbul include:

See the overview of all changes in this release:

  • Application Connector - Migration to Istio, support for custom headers and query parameters in authentication requests
  • Console - Testing lambda functions through the UI, more configuration options available at the moment of Namespace creation
  • Installation - Local installation with Kyma CLI, Kyma available trough GCP Marketplace, streamlined cluster installation flows
  • Documentation - New configuration, troubleshooting, and Headless CMS metadata documents, tutorial for customizing the Documentation view in the Console UI, testing bundle with sample documentation
  • Eventing - Choosing and configuring a custom messaging middleware, sending custom metadata with published Events, an example for triggering microservices with Events
  • Observability - Early version of Kiali added to Istio
  • Service Mesh - Istio update to version 1.1.6

Read about a known issue for Observability.

CAUTION: Before you upgrade to Kyma 1.2, read the Migration Guide which describes necessary manual actions required by the Event Bus, the Asset Store, and the Application Connector.

From the very beginning of the Kyma project, the Application Connector has been exposed using the NGINX Ingress. After the recent changes in Istio 1.x which included support for client certificates, we decided to migrate to Istio as did the rest of Kyma components. We are proud to announce that the migration is complete and we are already benefiting from a number of advantages including easier maintenance and a smaller number of components in the implementation.

Read this document to learn more about the role Istio plays in the Application Connector.

To facilitate the integration of APIs that require sending additional headers and query parameters with every request to an external system, we allow the developers to provide a custom list of the headers and query parameters when registering an API in the Application Registry. The Proxy service reads this configuration and enriches each call from an API to an external service with the required items.

Read this document to learn more.

Now you can test your lambda functions directly in the Console UI. Use any of the Event samples available in your Namespace or any custom payload to dry–run a function before connecting it to your live system's business events.

Users can now configure more of the important Namespace options when they create it using the UI. The available options include setting memory consumption limits and choosing whether Istio should handle all of the communication between Pods in the Namespace.

Deploying on GKE is now easier than ever as you can get a fully functional Kyma deployment with straight from the GCP Marketplace. Follow this link to find Kyma on the Marketplace, read this document to get detailed installation instructions, and watch this video for a detailed walkthrough. Enjoy!

Our very own Kyma CLI graduated from the Incubator and became an integral part of Kyma with the 1.2 release. From now on you can use simple kyma commands to easily deploy Kyma on your local machine, no matter what OS you're running - all you have to do is install our proprietary CLI tool. The local installation flow is now updated to use the CLI and we are retiring the old installation approach that used custom scripts.

To experience the convenience the Kyma CLI brings to the table, follow our documentation to install Kyma on your machine.

The existing cluster installation flows were significantly simplified. The sed commands and the cluster configuration template file are now gone in favor of a set of kubectl calls. Now you simply set up your cluster, apply the desired configuration with kubectl, and wait for the magic to happen. For more details, see the installation documentation.

After preparing a set of generic configuration documents in the last release, this time around we focused on specific Kyma components. The idea was to create configuration documents that list all configurable parameters from the values.yaml file of each of the components' charts and sub-charts that you can configure with overrides. Not all components have their Configuration documents ready, but you can expect full coverage in the near future.

As we interact with the community, we take note of recurring issues and misunderstandings that affect different components. We decide to gather these cases under the Troubleshooting documentation type to help the users deal with the most common issues easily. The troubleshooting documents are now available for the Service Mesh and the general Kyma topic.

If you've ever had any doubts regarding what the structure of a Markdown document processed by Headless CMS should look like, we come with a solution. See the document describing the required metadata and content of a Markdown file.

We prepared a tutorial that shows how to adjust the Documentation view in the Console UI. Based on it, you create a new Prometheus documentation section that contains Concepts and Guides topics and a set of Markdown subdocuments. Try it on your own.

The testing bundle is now enriched with sample documentation. There are examples of Markdown documents together with OpenAPI and AsyncAPI specifications. See the testing bundle for details on how different document types render in the Console UI.

Out of the box, Kyma comes with NATS Streaming as the default messaging middleware. With this release, we're giving you the tools to choose your own messaging middleware that best fits your needs from the usage, volume, and costs perspective. The only requirement is that the middleware must have Knative eventing-based ClusterChannelProvisioner available. Compatible solutions include Google PubSub, Kafka, and NATSS.

The applications sending Events to Kyma can now send additional context or metadata by sending headers with the ce- prefix, for example, ce-correlation-id. These headers are delivered to the lambda function.

We prepared a self-contained example that shows how to configure an Event trigger for a microservice deployed in Kyma. This is extremely useful for applications written in Java which want to use Events as a trigger.

Early integration of Kiali is available as part of Istio. To enable Kiali, ensure that the monitoring module is installed and set the kiali.enabled parameter to true. The Kiali UI will be accessible under the kiali subdomain. The early integration is based on static user security. To learn how to get the Kiali UI password, see this document.

Kiali is not accessible after installation when enabled as part of the Installer configuration. It should be accessible on Minikube at https://kiali.kyma.local. To access it this way, use the workaround for now and add the kiali prefix to the hosts attribute in the kiali-virtualservice resource:

Click to copy
kubectl -n istio-system edit virtualservices kiali-virtualservice
Click to copy
- kiali.kyma.local

The new release comes with Istio updated to 1.1.6. Previously Kyma used version 1.1.0, but due to a security issue and problems with the Ingress Gateway, we moved to a newer version. The update makes the Service Mesh more secure and stable - the Ingress Gateway issues seen in the previous version that caused port configurations not being applied properly are now resolved.

  • Tags:
  • #release-notes