Kubectl-Bereitstellung

Wenden Sie die Manifestdateien für die Implementierung des Dynamic Engine Ökosystems an.

Dies ist die klassische Methode zur Bereitstellung von Dynamic Engine-Diensten. Im Gegensatz zu Helm ist bei Kubectl keine benutzerdefinierte Bereitstellungskonfiguration möglich.

Tipp: Info über Helm und Kubectl:

Es sind zwei Optionen für die Bereitstellung Ihres Dynamic Engine-Öksystems.

Wenn Sie Helm wählen, überspringen Sie diesen Abschnitt und wechseln Sie zu (Empfohlen) Helm-Bereitstellung.
Wenn Sie den ausgewählten Bereitstellungstyp für Ihr Dynamic Engine und seine Umgebung ändern möchten, wechseln Sie zu Ändern des Bereitstellungstyps eines Dynamic Engine.

Das Upgrade von Kubernetes-Manifesten zu Helm-Diagrammen wird für bereits bereitgestellte Dynamic Engine-Dienste nicht unterstützt.

Vorbereitungen

Sie müssen mindestens eine Dynamic Engine-Umgebung Ihrer Engine zugewiesen, den Bereitstellungstyp Kubectl ausgewählt und die ZIP-Datei heruntergeladen haben. Anweisungen zu dieser Vorgehensweise finden Sie unter Zuweisen einer Umgebung zu einer Dynamic Engine.

Prozedur

Entzippen Sie die zuvor heruntergeladene Datei.
Führen Sie in Ihrem Kubernetes-Terminal die folgenden Befehle in der hier gezeigten Reihenfolge aus, um die Dynamic Engine-Instanz einzurichten:
1. ```
kubectl apply -f custom-resource-definitions.yaml
```
  Mit dieser Manifestdatei werden zwei benutzerdefinierte Kubernetes-Ressourcendefinitionen in Ihrem Cluster erstellt: dynamicengines.apps.qlik.com für Dynamic Engine-Ressourcen und dynamicengineenvs.apps.qlik.com für Dynamic Engine-Umgebungsressourcen.
2. ```
kubectl apply -f resources.yaml
```
  Mit dieser Manifestdatei werden die Dynamic Engine-Ressourcen erstellt, um Ihren Cluster zu registrieren, Ihre Dynamic Engine zu implementieren und die Engine ihrer logischen Entität in Talend Management Console zuzuweisen. Diese Ressourcen behören zu einer Art DynamicEngine.
3. Am Ende der zweiten Ausführung führen Sie folgenden Befehl aus, um die Implementierung zu überprüfen:
```
kubectl wait --for=condition=Ready pod -l 'app.qlik.com/owned-by' --timeout 10m -A 
```
  Mit diesem Befehl wird die Bereitschaft aller Pods mit der Bezeichnung app.qlik.com/owned-by über alle Namespaces hinweg verifiziert.
  
  Wenn die Implementierung erfolgreich war, wird eine Antwort wie die Folgende angezeigt:
```
pod/dynamic-engine-operator-799bb96687-rfm2g condition met
                           pod/dpe-data-service-route-deployer-74b7f566c-lrl99 condition met
                           pod/dpe-di-job-deployer-5cff46b6-x5t85 condition met
                           pod/dpe-di-job-restore-orphans-5f57f5f86f-d9vpb condition met
                           pod/dpe-engine-config-manager-956d5d7b9-7krcn condition met
                           pod/dpe-job-controller-66fd596588-7x5w5 condition met
                           pod/dpe-log-collector-7dd9499c8-dnvrn condition met      
```
  Diese Ausgabe bestätigt, dass alle für Dynamic Engine und ihre Umgebung erforderlichen Pods bereit sind.
Nach dem erfolgreichen Abschluss wird der Status der logischen Dynamic Engine-Entität in Talend Management Console aktiv.

Wenn Sie in Erfahrung bringen müssen, was genau in Ihrem Kubernetes-Cluster installiert wurde, gehen Sie zu Ihrer Kubernetes-Maschine und führen Sie die in dieser offiziellen Kubernetes-Dokumentation erläuterten Befehle aus.
Führen Sie den folgenden Befehl aus, um die Umgebungen einzurichten. In diesem Beispiel wurde nur eine Umgebung erstellt und zugewiesen.
```
kubectl apply -f resources-<environment_id>.yaml
```
InformationshinweisTipp:
Wenn die Engine mit mehreren Umgebungen verknüpft ist, benötigen Sie diese ID, um die korrekte Datei zu identifizieren.
Es gibt zwei Methoden zum Finden der Umgebungs-ID:
- Öffnen Sie in Talend Management Console die Detailseite der zu löschenden Umgebung. Die ID wird in der URL angezeigt. In der folgenden URL beispielsweise:
  https://app.eu.cloud.talend.com/tmc/environments/dynamic-engine-environments/66f2c0bb3e063d3518122259/overview
  Das Segment 66f2c0bb3e063d3518122259 ist die Umgebungs-ID.
- Verwenden Sie den Befehl:
  kubectl get dynamicengineenvs.qlik.com
  Damit wird der Ressourcenname oder der Namespace-Name zurückgegeben, in dem die ID enthalten ist. Beispiel: qlik-processing-env-66f2c0bb3e063d3518122259.
Am Ende der Ausführung führen Sie folgenden Befehl aus, um die Implementierung zu überprüfen:
```
kubectl wait --for=condition=RUNNING=true --all dynamicengineenvs --timeout 300s
```
300 Sekunden lang sucht dieser Befehl nach allen Ressourcen der Art DynamicEngineEnv. Wenn eine Antwort wie die Folgende angezeigt wird, bestätigt dies, dass die Engine-Umgebung erfolgreich implementiert wurde:
```
dynamicengineenvs.qlik.com/qlik-processing-env-66f2c0bb3e063d3518122259 condition met
```
In dieser Antwort lautet der Name der überwachten Ressource qlik-processing-env-664b0bbd6c6f5522732e055d. Der Name wird auch als Namespace-Name verwendet und gruppiert alle Dienste, die der Dynamic Engine-Umgebungsressource zugeordnet sind.

Optional: Wenn Sie die obige Bestätigung nicht erhalten haben, weist die Implementierung Probleme auf. Führen Sie den folgenden Befehl aus, um das Objekt „serviceStatus“ der Umgebungsressource zu prüfen:

kubectl get dynamicengineenvs qlik-processing-env-664b0bbd6c6f5522732e055d -o json | jq -r '.status'

In diesem Befehl stellt dynamicengineenvs die Art benutzerdefinierter Ressourcen dar, die Dynamic Engine-Umgebungen vorbehalten ist, und wie im vorherigen Beispiel ist qlik-processing-env-664b0bbd6c6f5522732e055d der Ressourcen- und der Namespace-Name der Umgebung.

Die folgende Meldung zeigt ein Beispiel des Fehlers für den Dienst „di-job-deployer“ im Objekt „serviceStatus“. Das Feld „jobErrorMessage“ enthält weitere Details über den Fehler, der während der Implementierung beobachtet wurde, und gibt an, dass das erwartete Diagramm helm nicht gefunden wurde.

Beachten Sie, dass im folgenden Beispiel einige Zeilen übersprungen wurden.

{
                           "conditions": [
                           {
                           "lastTransitionTime": "2024-05-30T13:05:25Z",
                           "message": "Service is not deployed",
                           "reason": "Deployment_not_found",
                           "status": "True",
                           "type": "NOT_DEPLOYED"
                           }
                           ],
                           "serviceStatus": {
                           ...
                           "di-job-deployer": {
                           "conditions": [
                           ...
                           {
                           "lastTransitionTime": "2024-05-30T13:06:39Z",
                           "message": "Service is in error",
                           "reason": "Pod_failed",
                           "status": "False",
                           "type": "IN_ERROR"
                           }
                           ],
                           "creationDate": "2024-05-30T13:05:25Z",
                           "jobErrorMessage": "Error: release: not found\nUpgrading...\nupgrade 
                           result: Release \"di-job-deployer-92d6e127-e070-4264-a9e8-00adbbbfbc03\" does not exist. 
                           Installing it now.\nError: failed to download 
                           ...
                           \nError: failed to download 
                           \"https://artifactory.datapwn.com/artifactory/tlnd-helm-ce-dev/dpe-di-job-deployer-2.0.0.tgz\
                           "\nexit_code: 1\n",
                           "jobStatus": "FAILED",
                           "lastUpdateDate": "2024-05-30T13:01:52Z"
                           },
                           ...
                           }
                           }
                           }

Wenden Sie sich in diesem Fall an das Supportteam, um die Manifestdatei der Dynamic Engine-Umgebung prüfen zu lassen. Wenn Sie dazu angewiesen werden, heben Sie die Zuweisung der Umgebung auf und weisen Sie sie erneut zu, um eine neue Manifestdatei zu generieren.

Ergebnisse

Nachdem dies erfolgreich durchgeführt wurde, sind die Dynamic Engine-Umgebungsdienste in Ihrem Cluster installiert und stellen eine Verbindung zur Dynamic Engine her.

In Talend Management Console ändert sich der Status dieser Umgebung zu Ready (Bereit), was bestätigt, dass sie zum Ausführen von Tasks oder Plänen bereit ist.

Wenn die Manifestimplementierung fehlschlägt oder die Dynamic Engine-Dienste von der Dynamic Engine getrennt werden, ändert sich der Status zu Not ready (Nicht bereit).

Nächste Maßnahme

Da die Dynamic Engine erfolgreich auf Ihrem Kubernetes-Cluster implementiert, mit Talend Management Console verbunden und einer Dynamic Engine-Umgebung zugewiesen wurde, ist sie bereit, Jobtasks oder Pläne auszuführen, wie Sie dies üblicherweise auf Standard-Engines tun. Detaillierte Informationen zum Hinzufügen von Tasks in einer Dynamic Engine-Umgebung zur Ausführung finden Sie unter Hinzufügen von Tasks zu Dynamic Engine-Umgebungen.

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