Skip to content

Expose and manage Kubernetes Custom Resource Definitions (Operators) in a Kubernetes Cluster

Intended Audience: OpenSlice Service Designers

OpenSlice is capable of exposing Kubernetes Resources and Definitions as Service Specifications.

Use OpenSlice to expose Kubernetes resources in service catalogs and deploy them in complex scenarios (service bundles) involving also other systems:

  • Include external resources, e.g. RAN controllers
  • Combine designed services
  • Control the lifecycle of services and pass values from one service to another

Awareness for CRDs and CRs in cluster

OpenSlice keeps its Resource Inventory in sync with all CRDs/CRs of the managed cluster(s), including changes made outside OpenSlice; see CRIDGE.

Expose CRDs as Service Specifications in OpenSlice catalogs

A CRD by default is exposed as a Resource Specification

To ensure unique names across the clusters that OpenSlice can manage, the name of a CRD is constructed as follows:

Kind @ ApiGroup/version @ ContextCluster @ masterURL

For example you might see resource Specifications like:

  • Application@argoproj.io/v1alpha1@kubernetes@https://10.10.10.144:6443/
  • IPAddressPool@metallb.io/v1beta1@kubernetes@https://10.10.10.144:6443/
  • Provider@pkg.crossplane.io/v1@kubernetes@https://10.10.10.144:6443/

All attributes of the CRD are translated into characteristics

The following specific characteristics are added (see Mapping the CR lifecycle for their meaning):

- _CR_SPEC: Used for providing the json Custom Resource description to apply
- _CR_CHECK_FIELD: Used for providing the field that need to be checked for the resource status
# Resource status (inventory / pool bookkeeping)
- _CR_CHECKVAL_STANDBY
- _CR_CHECKVAL_ALARM
- _CR_CHECKVAL_AVAILABLE
- _CR_CHECKVAL_RESERVED
- _CR_CHECKVAL_UNKNOWN
- _CR_CHECKVAL_SUSPENDED
# Resource state (ITU-T X.731) and health
- _CR_CHECKVAL_ADMINSTATE_LOCKED
- _CR_CHECKVAL_ADMINSTATE_UNLOCKED
- _CR_CHECKVAL_ADMINSTATE_SHUTDOWN
- _CR_CHECKVAL_OPERSTATE_ENABLE
- _CR_CHECKVAL_OPERSTATE_DISABLE
- _CR_CHECKVAL_USAGESTATE_IDLE
- _CR_CHECKVAL_USAGESTATE_ACTIVE
- _CR_CHECKVAL_USAGESTATE_BUSY
- _CR_CHECKVAL_HEALTH_UP
- _CR_CHECKVAL_HEALTH_PENDING
- _CR_CHECKVAL_HEALTH_DOWN
- _CR_CHECKVAL_HEALTH_HELD
- _CR_CHECKVAL_HEALTH_GONE

  1. Create a new Service Specification and use this Resource Specification in Resource Specification Relationships. Then the Service Specification is saved as ResourceFacingServiceSpecification.

    1.1. At this stage, you can give values to _CR_SPEC, _CR_CHECK_FIELD and any of the _CR_CHECKVAL_* characteristics listed above. In most cases, setting _CR_CHECK_FIELD and the _CR_CHECKVAL_HEALTH_* values is enough (see Mapping the CR lifecycle).

    1.2. You can now create LCM rules if you wish

  2. Create a new Service Specification and use the Resource Facing Service Specification in Service Specification Relationships. Then the Service Specification is saved as CustomerFacingServiceSpecification.

    2.1. At this stage, you can create Customer Facing characteristics and map them to the related ResourceFacingServiceSpecification's ones.

    2.2. You can create LCM rules for this new Service Specification

    2.3. You can expose configurable values for users to configure during service order

img06.png

Service Orchestration and CRDs/CRs

OSOM - OpenSlice Service Orchestrator, checks the presence of attribute _CR_SPEC at the RFS to make a request for a CR deployment.

  • _CR_SPEC is a JSON or YAML string that is used for the request
    • It is similar to what one will do with e.g. a kubectl apply
    • There are tools to translate a yaml file to a json

LCM rules can be used to change attributes of this yaml/json file, before sending this for orchestration

Mapping the CR lifecycle that is defined in the CRD with the OpenSlice (TMF-based) resource Lifecycle

The _CR_CHECK_FIELD and _CR_CHECKVAL_* characteristics instrument OpenSlice services to manage and reflect the lifecycle of a kubernetes resource to OpenSlice's (TMF based) lifecycle

_CR_CHECK_FIELD is the name of the CR field that OpenSlice monitors (e.g. status.status). The _CR_CHECKVAL_* characteristics map the CR specific values of that field onto two separate aspects of the TMF resource:

Resource state and health (ITU-T X.731) - drives the service lifecycle

The operationalState and administrativeState of the resource are what OpenSlice uses to decide the state of the service the resource supports.

Characteristic Effect on the TMF resource
_CR_CHECKVAL_HEALTH_UP operationalState=ENABLE, administrativeState=UNLOCKED
_CR_CHECKVAL_HEALTH_DOWN operationalState=DISABLE, administrativeState=UNLOCKED (in service, but not working)
_CR_CHECKVAL_HEALTH_HELD operationalState=ENABLE, administrativeState=LOCKED
_CR_CHECKVAL_HEALTH_GONE operationalState=DISABLE, administrativeState=SHUTDOWN
_CR_CHECKVAL_HEALTH_PENDING nothing is set (state not known yet; the service is neither promoted nor demoted)
_CR_CHECKVAL_OPERSTATE_ENABLE / _DISABLE operationalState
_CR_CHECKVAL_ADMINSTATE_LOCKED / _UNLOCKED / _SHUTDOWN administrativeState
_CR_CHECKVAL_USAGESTATE_IDLE / _ACTIVE / _BUSY usageState (informational; does not affect the service state)

Rules:

  • Health always wins. If the observed value matches a _CR_CHECKVAL_HEALTH_* value, the individual _CR_CHECKVAL_OPERSTATE_* / _CR_CHECKVAL_ADMINSTATE_* / _CR_CHECKVAL_USAGESTATE_* mappings are ignored. They are used only when no health value matches.
  • A CR that is deleted from the cluster always results in operationalState=DISABLE and administrativeState=SHUTDOWN.
  • If nothing matches, both attributes stay unset, which reads as pending.

Resource status - inventory / pool bookkeeping only

Characteristic Effect on the TMF resource (org.etsi.osl.tmf.ri639.model.ResourceStatusType)
_CR_CHECKVAL_STANDBY resourceStatus=STANDBY
_CR_CHECKVAL_ALARM resourceStatus=ALARM
_CR_CHECKVAL_AVAILABLE resourceStatus=AVAILABLE
_CR_CHECKVAL_RESERVED resourceStatus=RESERVED
_CR_CHECKVAL_UNKNOWN resourceStatus=UNKNOWN
_CR_CHECKVAL_SUSPENDED resourceStatus=SUSPENDED

The resourceStatus no longer decides the health of the resource. Use it for inventory and pool purposes only.

Migration note: Before 2026Q4, Service Specifications that relied only on _CR_CHECKVAL_AVAILABLE to mark a service as ACTIVE must also set _CR_CHECKVAL_HEALTH_UP to the same value so as to retain the same behaviour (e.g. CALCULATED in the Calculator example).

Note: Adding these characteristics bumped the Resource Specification versions of the CRDs and CRs to 0.0.4 and 0.0.5 respectively.

Probe further