Core Concepts

Multi-cloud multi-layer orchestration

OSM is a production-quality E2E Network Service Orchestrator (E2E NSO) for telco services, capable of modelling and automating real telco-grade services across multiple cloud environments and infrastructure types. OSM manages resources spanning virtual machines, containers, physical network functions, and Kubernetes clusters — all from a single unified control plane.

OSM operates across multiple layers:

  • Infrastructure layer — Provisioning and lifecycle management of Kubernetes clusters across public clouds (Azure, AWS, GCP) and private clouds (OpenStack).

  • Platform layer — Management of software components and add-ons that run on top of Kubernetes clusters (via Profiles, OKAs, and KSUs).

  • Service layer — Orchestration of network services and VNFs, including their interconnection and lifecycle (Day-0, Day-1, Day-2 operations).

This multi-layer approach allows OSM to abstract away the differences between cloud providers and infrastructure types, offering a consistent interface for operators.

Model-driven approach in OSM

OSM uses a model-driven approach to describe all managed resources. This means that every resource — from a VNF to a Kubernetes cluster — is described by a formal model that defines its properties, relationships, and lifecycle operations.

For NFV resources, OSM uses YANG-based information models aligned with ETSI NFV SOL006. These models describe VNF Descriptors (VNFD), NS Descriptors (NSD), and Network Slice Templates (NST) in a vendor-neutral, infrastructure-agnostic way.

For cloud-native resources, OSM uses Kubernetes Resource Models (KRM) and declarative intent-based models (OKA blueprints) that describe the desired state of applications and infrastructure. The system continuously reconciles the actual state with the desired state stored in Git.

The model-driven approach has four key benefits:

  1. Infrastructure-agnostic — The same model can be used to deploy a VNF or application across different VIM types or cloud providers.

  2. Unified northbound interface (NBI) — A single SOL005-based REST API provides access to all lifecycle operations regardless of the underlying technology.

  3. Multi-domain Network Services — A Network Service can span virtual, physical, and transport domains using the same model.

  4. Network Slice management — OSM can act as a Slice Manager, coordinating multiple Network Services as a single manageable entity.

NFV MANO and OSM

Network Functions

A Network Function (NF) is a functional block within a network infrastructure that has well-defined external interfaces and well-defined functional behavior. OSM manages three types:

  • Virtual Network Functions (VNFs) — Software-only functions running in virtual machines or containers on top of a VIM/NFVI.

  • Physical Network Functions (PNFs) — Hardware appliances providing network functions (modelled but not lifecycle-managed by OSM).

  • Hybrid Network Functions (HNFs) — Combinations of virtual and physical elements.

VNFs are packaged as VNF Packages containing the VNF Descriptor (VNFD) and any associated artefacts (VM images, configuration scripts, Helm charts).

Network Services

A Network Service (NS) is a composition of one or more Network Functions connected by virtual links, delivering an end-to-end service. OSM orchestrates the full lifecycle of an NS:

  • Day-0 — Initial instantiation: deploying VMs/containers and establishing virtual links between them.

  • Day-1 — Initial configuration: running configuration primitives on the deployed VNFs (using Juju charms or Helm charts).

  • Day-2 — Ongoing operations: scaling, healing, upgrading, and monitoring the NS during its active lifetime.

Network Services are described by NS Descriptors (NSD) and packaged as NS Packages.

Virtualized Infrastructure Managers (VIMs)

A VIM is the entity responsible for controlling and managing the NFVI compute, storage, and network resources. OSM supports a wide range of VIM types:

  • OpenStack — The primary open-source cloud platform for deploying VM-based VNFs.

  • Microsoft Azure, AWS, GCP — Major public cloud providers, supported both for VM-based VNFs and managed Kubernetes clusters.

  • VMware vCloud Director — Commercial VIM for enterprise environments.

  • OpenVIM — A lightweight reference VIM included with OSM for testing.

VIM accounts are registered in OSM and used when instantiating VNFs and Network Services. OSM talks to the VIM API to create virtual machines, virtual links, and security groups on behalf of the NS.

The declarative framework in OSM via GitOps

Since Release SIXTEEN, OSM offers a declarative framework for managing cloud-native resources — Kubernetes clusters, software applications, and their configurations — following a GitOps model. This is the recommended approach for all Kubernetes-oriented operations.

Introduction to GitOps

GitOps is an operational model where the desired state of infrastructure and applications is stored in Git repositories. A GitOps engine continuously compares the actual state of the system with the desired state in Git and automatically reconciles any differences.

In OSM, every operation that creates, updates, or deletes a cloud-native resource results in a commit to one of OSM’s managed Git repositories. FluxCD then detects the commit and applies the changes to the target cluster. This provides:

  • Version control — Every change is tracked in Git history.

  • Auditability — Full audit trail of who changed what and when.

  • Rollback — Reverting to a previous state is as simple as a Git revert.

  • Consistency — The same desired state is enforced continuously, preventing configuration drift.

Kubernetes clusters

OSM manages the full lifecycle of Kubernetes clusters — creation, upgrading, scaling, and deletion — across supported cloud providers. Each cluster is registered in OSM as a cluster resource tied to a VIM/Cloud account.

Management cluster and workload clusters

OSM uses a two-tier cluster model:

  • Management cluster — A dedicated Kubernetes cluster where OSM itself is deployed, along with the GitOps tooling (ArgoWorkflows, FluxCD). The management cluster is responsible for executing lifecycle operations and committing desired state to Git.

  • Workload clusters — The Kubernetes clusters provisioned and managed by OSM where applications actually run. Each workload cluster is synchronized by FluxCD from the fleet-osm Git repository.

Profiles

A Profile is a named grouping of software components (KSUs) that should be deployed to a set of Kubernetes clusters. Profiles allow operators to define a consistent software baseline — for example, a set of cluster add-ons, monitoring agents, or platform services — and deploy it uniformly across many clusters in a single operation.

Profiles are stored in the sw-catalog-osm Git repository and referenced by clusters in the fleet-osm repository.

OKA

An OKA (OSM Kubernetes Application) is a reusable blueprint for a Kubernetes application component. It encapsulates:

  • Manifests — The base Kubernetes resources (from raw YAML or Helm charts).

  • Templates (Flux Kustomizations) — Overlays that customize the manifests for different deployment contexts.

OKAs are the unit of reuse in OSM’s application catalogue. They are instantiated as KSUs when deployed to a cluster. Examples include applications for namespace creation, Jenkins, or any Helm-based workload.

KSU

A KSU (Kubernetes Software Unit) is the minimal unit of desired state that OSM syncs to a workload cluster via Git. A KSU is created by instantiating an OKA blueprint with specific parameters (target cluster, configuration values, etc.) and committing the resulting manifests to the fleet-osm repository.

FluxCD on the workload cluster detects the new or updated manifests and applies them, ensuring the actual cluster state matches the desired state.

App

An App is a higher-level abstraction in OSM that groups multiple related KSUs into a single deployable unit. Apps allow operators to model complex multi-component applications — where components may have dependencies and ordering requirements — and manage them as a single entity. OSM ensures that app components are deployed in the correct order (e.g., cluster add-ons before application workloads).

Git repositories and FluxCD

OSM uses two dedicated Git repositories to store the desired state of managed resources:

  • sw-catalog-osm — The software catalog repository. Contains OKA blueprints, Profile definitions, and reusable component templates.

  • fleet-osm — The fleet repository. Contains per-cluster deployment specifications: which KSUs are assigned to which clusters, their configuration, and their HelmRelease resources.

FluxCD is the GitOps engine running on each cluster (management and workload). It watches the relevant Git repository and continuously reconciles the cluster state with the committed manifests. When OSM commits a change to fleet-osm, FluxCD detects it and applies it to the target cluster — no manual kubectl apply is needed.

This separation between the software catalog and the fleet repository allows OSM to maintain a clean boundary between reusable component definitions (catalog) and instance-specific deployments (fleet).

Continuous reconciliation

OSM’s declarative framework is built on a continuous reconciliation loop. Rather than executing one-off imperative commands, the system continuously compares the actual state of the cluster with the desired state stored in Git and adjusts as needed:

  1. Observe — FluxCD and ArgoWorkflows monitor the current state of all managed resources in the cluster.

  2. Calculate diff — The system compares the current state with the desired state committed to the Git repository.

  3. Adjust — Any divergence is corrected automatically: missing resources are created, modified resources are updated, and unexpected resources can be pruned.

This loop runs continuously, meaning that manual changes to the cluster are automatically reverted to match the Git state, and any transient failure is retried until the desired state is reached.

Blueprint types

OSM provides two types of blueprints for packaging and reusing cloud-native applications:

OKA Packages

An OKA Package is a simple, self-contained blueprint for a single Kubernetes application component. It is the right choice when:

  • The application is a single workload (one Helm chart or a set of Kubernetes manifests).

  • Customisation needs are straightforward (overlays and simple parameter substitution).

  • The component will be reused independently across many clusters or profiles.

OKA Packages consist of two folders: manifests/ (the base resources) and templates/ (Flux Kustomizations that apply overlays). When instantiated, an OKA Package becomes a KSU in the target cluster.

App Packages

An App Package is a full-flexibility blueprint for complex, multi-component applications. It is the right choice when:

  • The application has multiple interdependent components with deployment ordering requirements.

  • Advanced transformations are needed (custom KRM functions written in Nushell).

  • Components have optional or conditional parts (traits).

  • The application requires coordination across several KSUs.

App Packages support a richer model than OKA Packages: components, traits, and transformations can be composed to describe arbitrarily complex applications while keeping the deployment definition declarative and reproducible.

App Instance Model

When an App Package is deployed, OSM creates an App Instance with the following hierarchical structure:

  • App Instance — The top-level entity representing a deployed application. It groups all resources belonging to a single logical application and provides a single handle for lifecycle operations (create, update, delete).

    • KSU Instances — One KSU Instance is created per component in the App Package. Each KSU Instance represents the desired state of one application component committed to the fleet-osm Git repository.

      • Bricks — The finest-grained resource units within a KSU. Bricks are the individual Kubernetes resources (Deployments, Services, ConfigMaps, etc.) that make up a KSU Instance. FluxCD applies Bricks to the target cluster.

This model enables OSM to manage the full lifecycle of a complex application as a single entity while maintaining fine-grained visibility and control over each individual component and resource.

NF Catalog

The NF Catalog is a public, standardised library of reusable OKA and App blueprints contributed by the OSM community. It provides ready-to-use packages for common network functions and Kubernetes applications, validated against OSM’s declarative framework.

Operators can browse the NF Catalog and deploy any blueprint to their clusters in a single operation — either directly as a KSU or as part of a Profile assigned to a fleet of clusters. The catalog lowers the barrier to adopting new network functions by eliminating the need to author blueprints from scratch.

OSM Catalog packages are available in the osm-packages GitLab repository.