Skip to main content

Installation

OctoMesh uses Communication Operators to manage distributed computing resources using Kubernetes. The Communication Operators are responsible for managing the lifecycle of a Pool's workloads (Adapters and Applications), including creating, updating, and deleting them.

Prerequisites​

  • An installed Communication Operator on a Kubernetes cluster. The operator is configured (via its OPERATOR__* environment variables / Helm values) with the Communication Controller URI and the message-broker connection it should use — these are properties of the operator instance, not of the individual pool.

Installation of Pool​

We want to install a pool named pool-documentation for tenant meshtest in the namespace pool-documentation.

Step 1: Create a Pool runtime entity​

First, we need to create a pool as runtime entity in the Asset Repository. The pool runtime entity is a System.Communication/Pool object. The following example shows the pool runtime entity for the pool pool-documentation:

$schema: https://schemas.meshmakers.cloud/runtime-model.schema.json
dependencies:
  - System.Communication
entities:
  - rtId: 65d5c447b420da3fb12381bb
    ckTypeId: System.Communication/Pool
    attributes:
      - id: System/Name
        value: pool-documentation

This file can be imported in Refinery Studio under Communication/Pools tab or using octo-cli command line tool using command ImportRt.

Step 2: Create a namespace and secret​

We need to create a secret for the connection to the message broker. The secret pattern is {TenantId}-{PoolRtId}-octo-mesh-connection and is stored in the namespace pool-documentation. The secret contains the username and password for the message broker. Using the pool runtime entity id 65d5c447b420da3fb12381bb from Step 1, the secret name is meshtest-65d5c447b420da3fb12381bb-octo-mesh-connection:

apiVersion: v1
kind: Secret
metadata:
  name: meshtest-65d5c447b420da3fb12381bb-octo-mesh-connection # {TenantId}-{PoolRtId}-octo-mesh-connection
  namespace: pool-documentation # Namespace of the pool, must match the CommunicationPool object's namespace
type: Opaque
data:
  brokerusername: ZGVtbw== # base64 encoded username for message broker
  brokerpassword: ZGVtbw== # base64 encoded password for message broker
note

Every Kubernetes name the operator derives for a pool — the secret name, labels, and (in central mode) the CR name — is built from the pool's runtime entity id (PoolRtId), because runtime entity ids are 24-character hex strings and therefore always valid Kubernetes names, whereas a human-readable pool name may contain characters the API server rejects.

Step 3: Create a CommunicationPool​

Finally, we need to create a CommunicationPool object in the namespace pool-documentation. The spec carries only the tenant identity and the pool's runtime entity id (PoolRtId) — the canonical pool identity from Step 1. The Communication Controller URI and message-broker connection are read from the operator's own configuration, not from the CR:

apiVersion: octo-mesh.meshmakers.io/v1alpha1
kind: CommunicationPool
metadata:
  name: pool-documentation  # Any valid Kubernetes name for the CR
  namespace: pool-documentation # Namespace of the pool, must match the secret's namespace
spec:
  tenantId: "meshtest" # Tenant ID
  poolRtId: "65d5c447b420da3fb12381bb" # rtId of the Pool runtime entity created in Step 1

After deployment of the CommunicationPool object, the Communication Operator will register the pool with the Communication Controller. The pool is now ready to deploy workloads (Adapters and Applications).