Bereitstellen von Dynamic Engine mit vorhandenen PersistentVolumeClaims

Konfigurieren Sie die Dynamic Engine Helm Charts, um vorhandene PersistentVolumeClaims nach Namen zu referenzieren, statt dynamische StorageClass-Bereitstellung zu verwenden.

Vorbereitungen

Die benutzerdefinierten Ressourcendefinitionen dynamic-engine-crd müssen mit dem Helm-Chart oci://ghcr.io/talend/helm/dynamic-engine-crd installiert worden sein. Führen Sie andernfalls die folgenden Befehle für die Installation aus:
1. Suchen Sie die zu verwendende Diagrammversion:
  - Führen Sie den folgenden Helm-Befehl aus:
    helm show chart oci://ghcr.io/talend/helm/dynamic-engine-crd --version <engine_version>
  - Sehen Sie die Version direkt über Talend Management Console ein oder suchen Sie im Dynamic Engine Änderungs-Log nach der in Ihrer Dynamic Engine-Version enthaltenen Diagrammversion.
  - Verwenden Sie einen API-Aufruf an den Dynamic Engine-Versionsendpunkt.
2. Führen Sie den folgenden Befehl aus, um das Helm-Chart einer bestimmten Version zu installieren:
```
helm install dynamic-engine-crd oci://ghcr.io/talend/helm/dynamic-engine-crd --version <helm_chart_version>
```
  Ersetzen Sie <helm_chart_version> durch die Chart-Version, die von Ihrer Dynamic Engine-Version unterstützt wird.
  Wenn die Version nicht angegeben wird, installieren Sie die neueste verfügbare dynamic-engine-crd-Diagrammversion.
Die drei PersistentVolumeClaim-Ressourcen (job-data, archive und custom-resources) werden im Status Bound (Gebunden) im Umgebungs-Namespace erstellt. Wenn Sie docker-registry verwenden, muss der docker-registry-Claim sich ebenfalls im Status Bound (Gebunden) im Engine-Namespace befinden.

Warum und wann dieser Vorgang ausgeführt wird

Verwenden Sie dieses Verfahren, wenn bereits Speicher in Ihrem Cluster bereitgestellt ist, z. B. nach dem Einrichten von EKS mit Amazon S3 (siehe Einrichten von Amazon EKS mit S3) oder einem anderen vorab bereitgestellten Speichersystem. In diesem Modell werden die Dynamic Engine Helm Charts zur Bereitstellungszeit an benannte PersistentVolumeClaims gebunden, statt Speicher von einer StorageClass anzufordern. Dies ist das statische Bereitstellungsmodell. Weitere Informationen zum dynamischen Bereitstellungsmodell, in dem Kubernetes automatisch Volumes aus einer StorageClass erstellt, finden Sie unter Bereitstellung einer Speicherklasse, die auf Dynamic Engine-Umgebungsdienste spezialisiert ist.

Sowohl das Dynamic Engine Chart (für das eingebettete Registrierungs-Volume) als auch das Dynamic Engine Umgebungs-Chart (für die drei Verarbeitungs-Volumes) müssen getrennt konfiguriert werden.

Prozedur

Legen Sie die Umgebungsvariablen für Ihre Bereitstellung fest:

export DYNAMIC_ENGINE_VERSION=<your-dynamic-engine-version>
export DYNAMIC_ENGINE_ID=<your-dynamic-engine-id>
export DYNAMIC_ENGINE_ENVIRONMENT_ID=<your-dynamic-engine-environment-id>

Ersetzen Sie die Platzhalterwerte durch die tatsächliche Dynamic Engine-Version, Engine-ID und Umgebungs-ID.

Überprüfen Sie, dass die erforderlichen PersistentVolumes und PersistentVolumeClaims vorhanden sind und sich im Status Bound (Gebunden) befinden:

kubectl get pv

Bestätigen Sie, dass die Ausgabe die erwarteten Volumes mit dem Status Bound (Gebunden) und den korrekten Claim-Namespaces auflistet. Beispiel:

NAME               CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM
docker-registry    1200Gi     RWX            Retain           Bound    qlik-dynamic-engine/docker-registry
archive            1200Gi     RWX            Retain           Bound    qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID/archive
custom-resources   1200Gi     RWX            Retain           Bound    qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID/custom-resources
job-data           1200Gi     RWX            Retain           Bound    qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID/job-data

Anmerkung: Der Kapazitätswert 1200Gi ist für die Kubernetes API erforderlich, wird aber nicht erzwungen. Für von S3 gestützte Volumes wird die tatsächliche Speicherkapazität vom S3-Bucket bestimmt, nicht von diesem Feld.

Dynamic Engine-Chart konfigurieren und bereitstellen

Erstellen Sie eine benutzerdefinierte Wertedatei für das Dynamic Engine-Chart und geben Sie den docker-registry-Claim-Namen an:

cat <<EOF > $DYNAMIC_ENGINE_ID-custom-set-static-pvc-values.yaml
configuration:
  dockerRegistry:
    persistence:
      existingClaim: docker-registry
EOF

Stellen Sie die Dynamic Engine unter Verwendung der Basiswertedatei und der benutzerdefinierten Wertedatei bereit:

helm upgrade --install dynamic-engine-$DYNAMIC_ENGINE_ID \
  -n qlik-dynamic-engine \
  -f $DYNAMIC_ENGINE_ID-values.yaml \
  -f $DYNAMIC_ENGINE_ID-custom-set-static-pvc-values.yaml \
  oci://ghcr.io/talend/helm/dynamic-engine \
  --version $DYNAMIC_ENGINE_VERSION

Dynamic Engine-Umgebungs-Chart konfigurieren und bereitstellen

Erstellen Sie eine benutzerdefinierte Wertedatei für das Dynamic Engine-Umgebungs-Vhart und geben Sie die Namen der drei Verarbeitungs-Volume-Claims an:
```
cat <<EOF > $DYNAMIC_ENGINE_ENVIRONMENT_ID-custom-set-static-pvc-values.yaml
configuration:
  persistence:
    persistentVolumeClaims:
      job_data:
        persistentVolumeClaimName: job-data
      archive:
        persistentVolumeClaimName: archive
      custom_resources:
        persistentVolumeClaimName: custom-resources
EOF
```
InformationshinweisAnmerkung: Für die Helm Chart API sind Unterstriche für die persistentVolumeClaims-Schlüssel (job_data, custom_resources) erforderlich. Die entsprechenden PersistentVolumeClaim-Namen verwenden Bindestriche (job-data, custom-resources). Diese Asymmetrie ist beabsichtigt.

Stellen Sie die Dynamic Engine-Umgebung unter Verwendung der Basiswertedatei und der benutzerdefinierten Wertedatei bereit:

helm upgrade --install dynamic-engine-environment-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
  -n qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
  -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-values.yaml \
  -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-custom-set-static-pvc-values.yaml \
  oci://ghcr.io/talend/helm/dynamic-engine-environment \
  --version $DYNAMIC_ENGINE_VERSION

Ergebnisse

Dynamic Engine und ihre Umgebung werden jetzt mit den vorhandenen PersistentVolumeClaims ausgeführt. Bestätigen Sie, dass der docker-registry-Pod im qlik-dynamic-engine-Namespace und der dpe-di-job-deployer-Pod im qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID-Namespace ausgeführt werden.

Nächste Maßnahme

Führen Sie die folgenden Befehle aus, um zu bestätigen, dass die Pods in beiden Namespaces ausgeführt werden:

kubectl get pods -n qlik-dynamic-engine
kubectl get pods -n qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID

Hat diese Seite Ihnen geholfen?

Wenn Sie ein Problem mit dieser Seite oder ihrem Inhalt feststellen, sei es ein Tippfehler, ein ausgelassener Schritt oder ein technischer Fehler, informieren Sie uns bitte!

Geben Sie hier Ihr Feedback ab