Kyma Project

Kyma provides two primary interfaces for interaction and management:

1. Kyma dashboard: A web-based administrative UI designed for managing basic Kubernetes resources.
2. Kyma CLI: A command-line interface used to execute Kyma-specific tasks, such as performing installations or upgrades.

The Kyma documentation is built using VitePress and is organized into several key areas:

• .vitepress/: Contains the core configuration, custom themes, global styles, and custom Vue components.
• docs/: The primary content directory, including index.md (the landing page) and external-content/ (aggregated content from other repositories).
• public/: A temporary directory for assets that will be propagated to the website. This folder is managed by move-to-public.sh and should be cleared before each build.
• workflows/: Contains GitHub Actions for automated deployment.

Kyma is a set of Kubernetes-based modular building blocks designed for developing and running enterprise-grade cloud-native applications.

Important Change: Kyma has transitioned from a monolithic installation to a modular architecture. Global Kyma releases are discontinued. Instead, functionality is delivered via individual Kyma modules. This allows you to add or delete specific modules (e.g., Serverless, Istio, API Gateway) without installing the entire Kyma stack. You can use these modules in your own Kubernetes cluster or via the managed SAP BTP Kyma runtime.

The makefiles directory is organized into the following structure:

• docs/: Contains documentation related to the Makefiles.
• docker.mk: A Makefile fragment specifically for Docker-related tasks.
• generic-make-go.mk: A Makefile fragment designed for Go components and their associated Dockerfiles.

├── docs                  # Documentation for Makefiles
├── docker.mk             # Makefile for Docker
└── generic-make-go.mk    # Makefile for Go components and Dockerfiles

Kyma uses a modular approach where you can install only the specific components required for your use case rather than a predefined set.

Each module consists of:

1. A Custom Resource (CR): Holds your desired configuration.
2. An Operator: Reconciles the configuration defined in the Custom Resource to ensure the module is running as specified.

You can add modules at any time, or delete them to free up cluster resources. For specific instructions on installation, uninstallation, or upgrading, refer to the Quick Install or Uninstall/Upgrade guides.

Kyma provides several specialized modules to extend Kubernetes capabilities:

• Serverless: A development platform for running lightweight, scalable Functions.
• System connectivity (Application Connector Manager): Provides endpoints to securely register external application APIs and Events.
• Istio: Handles service-to-service communication and proxying.
• Service Management (BTP Manager): Enables usage of built-in cloud services from providers like GCP, Azure, and AWS.
• API Gateway: Provides secure API exposure.
• Telemetry Manager: Collects and ships telemetry data to observability backends.
• CLI & UI: Tools to connect and manage applications within a Kubernetes cluster.

The generic Makefile uses BUILDPACK_FUNCTIONS to dynamically generate rules.

When a rule is added to MOUNT_TARGETS, the buildpack-mount function creates a wrapper rule. This wrapper rule runs a Docker container, mounts your component's directory as a volume, and then executes the corresponding -local rule inside that container.

Example of a generated rule structure:

resolve:
    @echo make resolve
    @docker run $(DOCKER_INTERACTIVE) \
        -v $(COMPONENT_DIR):$(WORKSPACE_COMPONENT_DIR):delegated \
        $(DOCKER_CREATE_OPTS) make resolve-local

Available functions:

• buildpack-mount: Creates a rule that mounts the component's directory as a volume.
• buildpack-cp-ro: Creates a rule that copies component files to a Docker container.

Kyma provides two primary ways to run logic:

• Function: A serverless code snippet (Node.js or Python) based on the Function custom resource. Functions are executed only when triggered by an event or an API call and do not require manual server management. They can be bound to service instances.
• Microservice: A containerized, always-running unit of code. Unlike Functions, microservices are independently deployable, loosely coupled, and typically communicate via APIs. They remain reachable even as Pods move.

Kyma documentation distinguishes between these two terms:

• Service: Refers specifically to the Kubernetes object used to expose an application running on Pods as a network service.
• service: Refers to a software functionality in a general sense.