Back to top
Components

Console

Overview

The Console is a web-based administrative UI for Kyma. It allows you to administer the Kyma functionality and manage the basic Kubernetes resources.

The Console uses the Luigi framework to extend the UI functionality with custom micro front-ends and bring more functionality to the existing UI. You can define the micro front-ends using dedicated CustomResourceDefinitions (CRDs).

Use the following CRs to modify the Console UI:

  • The MicroFrontend custom resource allows you to plug in micro front-ends for a specific Namespace.
  • The ClusterMicroFrontend custom resource allows you to plug in micro front-ends for the entire Cluster.
  • The BackendModule custom resource allows you to enable UI API Layer modules.

UI extensibility

The Kyma Console UI uses the Luigi framework to allow you to seamlessly extend the UI content with custom micro front-ends.

Console UI interaction with micro front-ends

When rendering the navigation, the Kyma Console UI calls a dedicated API endpoint to check if there are any micro front-ends defined in the current context. The current context comprises the current Namespace and all global cluster micro front-ends. All the defined micro front-ends and cluster micro front-ends are mapped to the navigation model as navigation nodes with remote viewUrls. When you click the navigation node, the system loads the content of the micro front-end into the content area of the Console. At the same time, the Console sends the current context data to the micro front-end to ensure it is initialized properly.

Micro front-end

A micro front-end is a standalone web application which is developed, tested and deployed independently from the Kyma Console application. It uses the Luigi Client library to ensure proper communication with the Console application. When you implement and deploy a micro front-end, you can plug it to the Kyma Console as a UI extension using dedicated CustomResourceDefinitions.

Luigi Client

The Luigi Client enables communication between the micro front-end and the Console application. Include Luigi Client in the micro front-end's codebase as an npm dependency.

npm i @kyma-project/luigi-client

It helps to read the context data that is sent by the Console when the user activates the micro front-end in the UI. Use the following example to read the context data:

LuigiClient.addInitListener((data)=>{
    // do stuff with the context data
});

The Luigi Client facilitates communication between the micro front-end and the Console. Use the Luigi Client API to request the Console to navigate from the micro front-end to any other route available in the application:

LuigiClient.linkManager().navigate('/targetRoute', null, true)

For API details, see Luigi Client API documentation.

Add a micro front-end

Use the CustomResourceDefinitions to extend the Console functionality and configure different scopes for your micro front-ends.

Micro front-end for a specific Namespace

You can define a micro front-end visible only in the context of a specific Namespace.

Here you can find a sample micro front-end entity using the namespace metadata attribute to enable the micro front-end only for the production Namespace.

Using this yaml file in your Kyma cluster results in a Tractors Overview micro front-end navigation node displayed under the Hardware category. It is available only in the production Namespace.

MF-one-namespace

Cluster-wide micro front-end

You can define a cluster-wide micro front-end available for all Namespaces in the side navigation.

Here you can find a sample ClusterMicroFrontend entity using the namespace value for the placement attribute to make the micro front-end available for all Namespaces in the cluster.

Using this yaml file in your Kyma cluster results in a Tractors Overview micro front-end navigation node displayed under the Hardware category. It is available for every Namespace in your cluster.

Cluster-wide micro front-end for the administration section

You can define a cluster micro front-end visible in the Administration section of the Console.

Here you can find a sample of such ClusterMicroFrontend entity using the cluster value for placement attribute to ensure the micro front-end is visible in the Administration section.

CMF-admin-section

UI API Layer

The UI API Layer is a backend service which provides an API for all views of the Console UI. This service consumes the Kubernetes API and exposes a simplified GraphQL API to allow frontends to perform Kubernetes resource operations.

Cache

For GraphQL queries, the UI API Layer uses caching which is based on Informers from the Kubernetes Go client. There are separate cache stores for every Kubernetes resource. The stores are synchronized when the service starts. After cache synchronization, a single connection with the Kubernetes API server is established and any event related to one of the observed resources updates the given cache store. This logic ensures that cache stores are always up-to-date without sending multiple requests to the Kubernetes API server.

Modularization

The UI API Layer consists of the Kubernetes resource logic and cache for different domains, such as the Service Catalog, Application, or Kubeless. The UI API Layer introduces modularization changes which are based on toggling modules while the server is running. The enabled module sychronizes cache for its resource and enables the module's logic for all server requests. If you disable a given module, every GraphQL query, mutation, and subscription related to this module returns an error.

The UI API Layer module pluggability is hidden behind a feature toggle. It is not enabled by default because the Console UI still requires resiliency improvements to ensure no errors occur when a certain Kyma component is not installed.

To enable this functionality, run the following command:

kubectl set env deployment/core-ui-api MODULE_PLUGGABILITY=true -n kyma-system

These are the available UI API Layer pluggable modules which contain the GraphQL resolver logic, where:

  • apicontroller relates to the API Controller.
  • authentication relates to IDP Presets.
  • application relates to the Application Connector.
  • content relates to the documentation.
  • kubeless relates to serverless.
  • servicecatalog relates to the Service Catalog, including Service Classes, Service Instances, and Service Bindings.
  • servicecatalogaddons relates to the Service Catalog add-ons, such as ServiceBindingUsage, and UsageKinds.

To enable a given module, install a proper Kyma component. It includes the BackendModule custom resource definition with the same name as the name of a given module.

MicroFrontend

The microfrontend.ui.kyma-project.io CustomResourceDefinition (CRD) is a detailed description of the kind of data and the format used to extend the Kyma Console. It allows to extend the Console for the specific Namespace. To get the up-to-date CRD and show the output in the yaml format, run this command:

kubectl get crd microfrontends.ui.kyma-project.io -o yaml

Sample custom resource

This is a sample CR that extends the Console.

apiVersion: ui.kyma-project.io/v1alpha1
kind: MicroFrontend
metadata:
  name: sample-microfrontend
  namespace: production
spec:
  version: 0.0.1
  category: Sample Category
  viewBaseUrl: https://sample-microfrontend-url.com
  navigationNodes:
    - label: Sample List
      navigationPath: items
      viewUrl: /
    - label: Details
      navigationPath: items/:id
      showInNavigation: false
      viewUrl: /:id

This table lists all the possible parameters of a given resource together with their descriptions:

Field Mandatory? Description
metadata.name YES Specifies the name of the CR.
metadata.namespace YES Specifies the target Namespace for the CR.
spec.version NO Specifies the version of the micro front-end.
spec.category NO Specifies the category name under which the micro front-end appears in the navigation.
spec.viewBaseUrl YES Specifies the address of the micro front-end. The address has to begin with https://.
spec.navigationNodes YES The list of navigation nodes specified for the micro front-end.
spec.navigationNodes.label YES Specifies the name used to display the micro front-end's node in the Console UI.
spec.navigationNodes.navigationPath NO Specifies the path used for routing within the Console.
spec.navigationNodes.viewUrl NO Specifies the URL used to display the content of a micro front-end.
spec.navigationNodes.showInNavigation NO The Boolean that specifies if the micro front-end's node is visible in the navigation or not.

ClusterMicroFrontend

The clustermicrofrontend.ui.kyma-project.io CustomResourceDefinition (CRD) is a detailed description of the kind of data and the format used to extend the Kyma Console. It allows to extend the Console for the entire Cluster. To get the up-to-date CRD and show the output in the yaml format, run this command:

kubectl get crd clustermicrofrontends.ui.kyma-project.io -o yaml

Sample custom resource

This is a sample CR that extends the Console.

apiVersion: ui.kyma-project.io/v1alpha1
kind: ClusterMicroFrontend
metadata:
  name: sample-microfrontend
spec:
  version: 0.0.1
  category: category-name
  viewBaseUrl: https://sample-microfrontend-url.com
  placement: cluster
  navigationNodes:
    - label: Sample List
      navigationPath: items
      viewUrl: /
    - label: Details
      navigationPath: items/:id
      showInNavigation: false
      viewUrl: /:id

This table lists all the possible parameters of a given resource together with their descriptions:

Field Mandatory? Description
metadata.name YES Specifies the name of the CR.
spec.version NO Specifies the version of the cluster micro front-end.
spec.category NO Defines the category name under which the cluster micro front-end appears in the navigation.
spec.viewBaseUrl YES Specifies the address of the cluster micro front-end. The address has to begin with https://.
spec.placement NO Specifies if the cluster micro front-end should be visible in the Namespace navigation or settings navigation. The placement value has to be either namespace or cluster.
spec.navigationNodes YES The list of navigation nodes specified for the cluster micro front-end.
spec.navigationNodes.label YES Specifies the name used to display the cluster micro front-end's node in the Console UI.
spec.navigationNodes.navigationPath NO Specifies the path that is used for routing within the Console.
spec.navigationNodes.viewUrl NO Specifies the URL used to display the content of the cluster micro-front end.
spec.navigationNodes.showInNavigation NO The Boolean that specifies if the cluster micro front-end's node is visible in the navigation or not.

BackendModule

The BackendModule CustomResourceDefinition (CRD) is a detailed description of the kind of data and the format used to enable UI API Layer modules.

To get the up-to-date CRD and show the output in the yaml format, run this command:

kubectl get crd backendmodules.ui.kyma-project.io -o yaml

Sample custom resource

This is a sample CR that enables the servicecatalog module in the UI API Layer:

apiVersion: ui.kyma-project.io/v1alpha1
kind: BackendModule
metadata:
  name: servicecatalog

Custom resource parameters

This table lists all the possible parameters of a given resource together with their descriptions:

Parameter Mandatory Description
metadata.name YES Specifies the name of the CR. It must be the same as the name of a given UI API Layer module.

These components use this CR:

Component Description
UI API Layer The component reacts to every action of adding or deleting the BackendModule custom resource and enables or disables a given UI API Layer module accordingly.