Zum Hauptinhalt springen

Installation

OctoMesh verwendet Communication Operators, um verteilte Rechenressourcen mithilfe von Kubernetes zu verwalten. Die Communication Operators sind für die Verwaltung des Lebenszyklus der Workloads eines Deployment Sites (Adapter und Applications) verantwortlich, einschließlich deren Erstellung, Aktualisierung und Löschung.

Voraussetzungen​

  • Ein installierter Communication Operator auf einem Kubernetes-Cluster. Der Operator wird über seine OPERATOR__*-Umgebungsvariablen bzw. Helm-Werte mit der Communication-Controller-URI und der zu verwendenden Message-Broker-Verbindung konfiguriert — das sind Eigenschaften der Operator-Instanz, nicht des einzelnen Deployment Sites.

Installation eines Deployment Sites​

Wir wollen einen Deployment Site namens site-documentation für den Tenant meshtest im Namespace site-documentation installieren.

Schritt 1: Deployment-Site-Runtime-Entität anlegen​

Zuerst legen wir den Deployment Site als Runtime-Entität im Asset Repository an. Die Runtime-Entität ist ein System.Communication/DeploymentSite-Objekt. Das folgende Beispiel zeigt die Runtime-Entität für site-documentation:

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

Diese Datei kann in Refinery Studio unter dem Tab Communication/Deployment Sites oder mit dem Kommandozeilenwerkzeug octo-cli über den Befehl ImportRt importiert werden.

CK-Typ umbenannt in System.Communication 4.0.0

Aus System.Communication/Pool wurde System.Communication/DeploymentSite, und die Assoziationsrolle zwischen Workload und Site änderte sich von Manages / ManagedBy zu Hosts / HostedBy. Bestehende Entitäten werden durch die Migration 3.35.0 → 4.0.0 konvertiert: rtId, Well-Known-Name und Attributwerte bleiben erhalten, nur die CK-Typ-ID ändert sich. Runtime-Modelle, die gegen die alte Typ-ID geschrieben wurden, müssen angepasst werden.

Schritt 2: Namespace und Secret anlegen​

Wir müssen ein Secret für die Verbindung zum Message Broker anlegen. Das Namensmuster des Secrets ist {TenantId}-{DeploymentSiteRtId}-octo-mesh-connection; es liegt im Namespace site-documentation. Das Secret enthält Benutzername und Passwort für den Message Broker. Mit der Runtime-Entitäts-ID 65d5c447b420da3fb12381bb aus Schritt 1 lautet der Secret-Name meshtest-65d5c447b420da3fb12381bb-octo-mesh-connection:

apiVersion: v1
kind: Secret
metadata:
  name: meshtest-65d5c447b420da3fb12381bb-octo-mesh-connection # {TenantId}-{DeploymentSiteRtId}-octo-mesh-connection
  namespace: site-documentation # Namespace des Deployment Sites, muss mit dem Namespace des DeploymentSite-Objekts übereinstimmen
type: Opaque
data:
  brokerusername: ZGVtbw== # base64-kodierter Benutzername für den Message Broker
  brokerpassword: ZGVtbw== # base64-kodiertes Passwort für den Message Broker
hinweis

Jeder Kubernetes-Name, den der Operator für einen Deployment Site ableitet — Secret-Name, Labels und (im zentralen Modus) der CR-Name — wird aus der Runtime-Entitäts-ID des Sites (DeploymentSiteRtId) gebildet. Runtime-Entitäts-IDs sind 24-stellige Hex-Strings und damit immer gültige Kubernetes-Namen, während ein menschenlesbarer Site-Name Zeichen enthalten kann, die der API-Server ablehnt.

Schritt 3: DeploymentSite-Custom-Resource anlegen​

Zuletzt legen wir ein DeploymentSite-Objekt im Namespace site-documentation an. Die Spec trägt nur die Tenant-Identität und die Runtime-Entitäts-ID des Sites (deploymentSiteRtId) — die kanonische Identität aus Schritt 1. Die Communication-Controller-URI und die Message-Broker-Verbindung werden aus der Konfiguration des Operators gelesen, nicht aus der CR:

apiVersion: octo-mesh.meshmakers.io/v1
kind: DeploymentSite
metadata:
  name: site-documentation  # Beliebiger gültiger Kubernetes-Name für die CR
  namespace: site-documentation # Namespace des Deployment Sites, muss mit dem Namespace des Secrets übereinstimmen
spec:
  tenantId: "meshtest" # Tenant-ID
  deploymentSiteRtId: "65d5c447b420da3fb12381bb" # rtId der in Schritt 1 angelegten DeploymentSite-Runtime-Entität

Nach dem Deployment des DeploymentSite-Objekts registriert der Communication Operator den Site beim Communication Controller. Der Deployment Site ist nun bereit, Workloads (Adapter und Applications) bereitzustellen.

Upgrade von einer Version vor System.Communication 4.0.0

Die Custom Resource hieß CommunicationPool (communicationpools.octo-mesh.meshmakers.io, API-Version v1alpha1), ihr Spec-Feld poolRtId. Es gibt keine In-Place-Konvertierung: Die alte CRD wird entfernt und die neue installiert, wodurch die bestehenden Custom Resources mitgelöscht werden. Legen Sie die Deployment Sites danach neu an — der Communication Controller hält jeden Site als Runtime-Entität, ein erneutes Deployment aus Refinery Studio oder per octo-cli genügt.

Die alte CRD trägt helm.sh/resource-policy: keep, ein Helm-Upgrade entfernt sie also nicht. Löschen Sie sie explizit:

kubectl delete crd communicationpools.octo-mesh.meshmakers.io

Die Helm-Werte zur Konfiguration des Operators wurden in derselben Version umbenannt: operator.autoManagePools → operator.autoManageDeploymentSites, operator.poolNamespace → operator.deploymentSiteNamespace, operator.defaultPoolName → operator.defaultDeploymentSiteName.