Fehlerbehebung

Fehlerbehebung bei Diensten während der Installation

Take the following steps on one of the cluster server nodes:

1. Erhalten Sie Kubernetes-Zugriff.

export KUBECONFIG="/etc/rancher/rke2/rke2.yaml"
export PATH="$PATH:/usr/local/bin:/var/lib/rancher/rke2/bin"

# To validate, execute the following command which should not return an error:
kubectl get nodes

2. Rufen Sie das ArgoCD-Kennwort ab, indem Sie den folgenden Befehl ausführen:

kubectl get secrets/argocd-admin-password -n argocd --template '{{ .data.password }}' | base64 -d

3. Herstellen einer Verbindung mit ArgoCD
   a. Gehen Sie zu https://alm.<fqdn>/:443.
   b. Melden Sie sich an, indem Sie admin als Benutzernamen und das in Schritt 2 erhaltene Kennwort verwenden.

4. Suchen Sie die Anwendung „UiPath Services“ wie folgt:
   a. Geben Sie in die Suchleiste bei ArgoCD uipath ein.
   

   b. Öffnen Sie dann die UiPath-Anwendung, indem Sie auf deren Karte klicken.
   

   c. Sehen Sie nach, ob Folgendes angezeigt wird: Application was not synced due to a failed job/pod („Anwendung wurde wegen eines fehlgeschlagenen Auftrags nicht synchronisiert“).

   d. Wenn der obige Fehler angezeigt wird, führen Sie die folgenden Schritte aus.

   e. Suchen Sie alle nicht synchronisierten Komponenten, indem Sie nach dem roten Gebrochenes-Herz-Symbol suchen, das in der folgenden Abbildung gezeigt wird.
   

   f. Öffnen Sie die Komponente ganz rechts (normalerweise Pods) und klicken Sie auf die Registerkarte Logs. Die Logs (Protokolle) enthalten eine Fehlermeldung, die den Grund für den Pod-Fehler angibt.
   

   g. Sobald Sie noch offene Konfigurationsprobleme behoben haben, kehren Sie zur Startseite zurück und klicken Sie in der UiPath-Anwendung auf die Schaltfläche Synchronisieren.

Deinstallieren des Clusters

If you experience issues specific to Kubernetes running on the cluster, you can directly uninstall the rke2 cluster. To do that, take the following steps:

1. Depending on your installation profile, run one of the following commands:
   1.1. In an online setup, run the following script with elevated privileges, i.e. sudo, on each node of the cluster. This will uninstall the nodes.

service_exists() {
    local n=$1
    if [[ $(systemctl list-units --all -t service --full --no-legend "$n.service" | cut -f1 -d' ') == $n.service ]]; then
        return 0
    else
        return 1
    fi
}
if service_exists rke2-server; then
  systemctl stop rke2-server
  systemctl disable rke2-server
fi
if service_exists rke2-agent; then
  systemctl stop rke2-agent
  systemctl disable rke2-agent
fi
if [ -e /usr/bin/rke2-killall.sh ]
then
    echo "Running rke2-killall.sh"
    /usr/bin/rke2-killall.sh > /dev/null
else
    echo "File not found: rke2-killall.sh"
fi
if [ -e /usr/bin/rke2-uninstall.sh ]
then
    echo "Running rke2-uninstall.sh"
    /usr/bin/rke2-uninstall.sh > /dev/null
else
    echo "File not found: rke2-uninstall.sh"
fi

rm -rfv /etc/rancher/ > /dev/null
rm -rfv /var/lib/rancher/ > /dev/null
rm -rfv /var/lib/rook/ > /dev/null
rm -rfv /var/lib/longhorn/ > /dev/null
findmnt -lo target | grep /var/lib/kubelet/ | xargs umount -l -f
rm -rfv /var/lib/kubelet/ > /dev/null
rm -rfv /datadisk/* > /dev/null
rm -rfv ~/.uipath/* > /dev/null
mkdir -p /var/lib/rancher/rke2/server/db/ && mount -a
rm -rfv /var/lib/rancher/rke2/server/db/* > /dev/null
echo "Uninstall RKE complete."

     1.2 In an offline setup, run the following script with elevated privileges, i.e. sudo, on each node of the cluster. This will uninstall the nodes.

service_exists() {
    local n=$1
    if [[ $(systemctl list-units --all -t service --full --no-legend "$n.service" | cut -f1 -d' ') == $n.service ]]; then
        return 0
    else
        return 1
    fi
}
if service_exists rke2-server; then
  systemctl stop rke2-server
  systemctl disable rke2-server
fi
if service_exists rke2-agent; then
  systemctl stop rke2-agent
  systemctl disable rke2-agent
fi
if [ -e /usr/local/bin/rke2-killall.sh ]
then
  echo "Running rke2-killall.sh"
  /usr/local/bin/rke2-killall.sh > /dev/null
else
  echo "File not found: rke2-killall.sh"
fi
if [ -e /usr/local/bin/rke2-uninstall.sh ]
then
  echo "Running rke2-uninstall.sh"
  /usr/local/bin/rke2-uninstall.sh > /dev/null
else
    echo "File not found: rke2-uninstall.sh"
fi

rm -rfv /etc/rancher/ > /dev/null
rm -rfv /var/lib/rancher/ > /dev/null
rm -rfv /var/lib/rook/ > /dev/null
rm -rfv /var/lib/longhorn/ > /dev/null
findmnt -lo target | grep /var/lib/kubelet/ | xargs umount -l -f
rm -rfv /var/lib/kubelet/ > /dev/null
rm -rfv /datadisk/* > /dev/null
rm -rfv ~/.uipath/* > /dev/null
mkdir -p /var/lib/rancher/rke2/server/db/ && mount -a
rm -rfv /var/lib/rancher/rke2/server/db/* > /dev/null
echo "Uninstall RKE complete."

2. Reboot the node after uninstall.

🚧

Wichtig!

When uninstalling one of the nodes from the cluster, you must run the following command: kubectl delete node <node_name>. This removes the node from the cluster.

Löschen von Offline-Artefakten für mehr Speicherplatz

Wenn Sie eine Offlineinstallation durchführen, benötigen Sie aufgrund der offline verwendeten Artefakte in der Regel eine größere Datenträgergröße.

Sobald die Installation abgeschlossen ist, können Sie diese lokalen Artefakte entfernen. Andernfalls kann während des Cluster-Vorgangs unnötiger Datenträgerdruck entstehen.

Auf dem primären Server, auf dem die Installation durchgeführt wurde, können Sie eine Bereinigung mithilfe der folgenden Befehle durchführen.

1. Löschen Sie mit dem folgenden Befehl alle von podman in den lokalen Containerspeicher geladenen Bilder:

podman image rm -af

2. Entfernen Sie dann den temporären Offlineordner, der mit dem Flag --offline-tmp-folder verwendet wird. Dieser Parameter wird standardmäßig zu /tmp:

rm -rf /path/to/temp/folder

Häufige Probleme

Es kann keine Offlineinstallation auf RHEL 8.4 OS ausgeführt werden.

Beschreibung

Die folgenden Probleme können auftreten, wenn Sie RHEL 8.4 installieren und die Offlineinstallation durchführen, für die Podman erforderlich ist. Diese Probleme treten dann auf, wenn podman und das Betriebssystem gemeinsam installiert werden. Siehe die beiden unten

Mögliches Problem

• Sie können nicht beide auf dem Cluster installieren:
  • podman-1.0.0-8.git921f98f.module+el8.3.0+10171+12421f43.x86_64
  • podman-3.0.1-6.module+el8.4.0+10607+f4da7515.x86_64
• das Paket cockpit-podman-29-2.module+el8.4.0+10607+f4da7515.noarch erfordert podman >= 1.3.0, aber keiner der Anbieter kann installiert werden
• der beste Kandidat für den Auftrag kann nicht installiert werden
• ein Problem mit dem installierten Paket cockpit-podman-29-2.module+el8.4.0+10607+f4da7515.noarch

Mögliches Problem

• das Paket podman-3.0.1-6.module+el8.4.0+10607+f4da7515.x86_64 erfordert containernetworking-plugins >= 0.8.1-1, aber keiner der Anbieter kann installiert werden
• Sie können nicht beide der folgenden installieren:
  • containernetworking-plugins-0.7.4-4.git9ebe139.module+el8.3.0+10171+12421f43.x86_64
  • containernetworking-plugins-0.9.1-1.module+el8.4.0+10607+f4da7515.x86_64
• das Paket podman-catatonit-3.0.1-6.module+el8.4.0+10607+f4da7515.x86_64 erfordert, dass podman = 3.0.1-6.module+el8.4.0+10607+f4da7515, aber keiner der Anbieter kann installiert werden
• der beste Kandidat für den Auftrag kann nicht installiert werden
• ein Problem mit dem installierten Paket podman-catatonit-3.0.1-6.module+el8.4.0+10607+f4da7515.x86_64
  (versuchen Sie, der Befehlszeile --allowerasing hinzuzufügen, um widersprüchliche Pakete zu ersetzen, oder --skip-broken, um deinstallationsfähige Pakete zu überspringen, oder --nobest, um nicht nur die besten Paketkandidaten zu verwenden)

Lösung

Sie müssen die aktuelle Version von podman entfernen und zulassen, dass Automation Suite die erforderliche Version installiert.

1. Entfernen Sie die aktuelle Version von podman mithilfe des Befehls yum remove podman.

2. Führen Sie das Installationsprogramm erneut aus, nachdem Sie die aktuelle Version entfernt haben. Dadurch sollte sich die richtige Version installieren.

Die Offlineinstallation schlägt aufgrund fehlender binärer Dateien fehl

Beschreibung

Während der Offlineinstallation schlägt die Ausführung in der Fabric-Phase mit der folgenden Fehlermeldung fehl:

Error: overlay: can't stat program "/usr/bin/fuse-overlayfs": stat /usr/bin/fuse-overlayfs: no such file or directory

Lösung

Sie müssen die Zeile mit dem Schlüssel mount_program aus der podman-Konfiguration /etc/containers/storage.conf entfernen.
Entfernen Sie die Zeile, anstatt sie auskommentieren.

Fehler beim Abrufen des Sandbox-Abbilds

Beschreibung

Es kann eine spezielle Fehlermeldung erscheinen, wenn Sie versuchen, das folgende Sandbox-Abbild zu erhalten: index.docker.io/rancher/pause3.2

Dies kann bei einer Offlineinstallation passieren.

Lösung

Starten Sie entweder rke2-server oder rke2-agent neu (abhängig davon, ob die Maschine, auf der der Pod geplant ist, ein Server oder ein Agent ist).

Um zu überprüfen, auf welchem Knoten der Pod geplant ist, führen Sie kubectl -n <namespace> get pods -o wide aus.

# If machine is a Master node
systemctl restart rke2-server
# If machine is an Agent Node
systemctl restart rke2-agent

Validierungsfehler bei der SQL-Verbindungszeichenfolge

Beschreibung

Möglicherweise wird bezüglich der Verbindungszeichenfolgen der folgende Fehler angezeigt:

Sqlcmd: Error: Microsoft Driver 17 for SQL Server :
Server—tcp : <connection string>
Login failed for user

Dieser Fehler wird angezeigt, obwohl alle Anmeldeinformationen korrekt sind. Die Validierung der Verbindungszeichenfolge ist fehlgeschlagen.

Lösung

Stellen Sie sicher, dass die Verbindungszeichenfolge die folgende Struktur hat:

Server=<Sql server host name>;User Id=<user_name for sql server>;Password=<Password>;Initial Catalog=<database name>;Persist Security Info=False;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;Max Pool Size=100;

📘

Hinweis:

Bei User Id wird die Groß-/Kleinschreibung beachtet.

Pods werden nicht in der ArgoCD-Benutzeroberfläche angezeigt

Beschreibung

Gelegentlich zeigt die ArgoCD-Benutzeroberfläche keine Pods an, sondern nur Anwendungen und entsprechende Bereitstellungen. Weitere Informationen finden Sie in der folgenden Abbildung:

Wenn Sie auf eine der Bereitstellungen klicken, wird der folgende Fehler angezeigt: Unable to load data: EOF.

Lösung

Sie können dieses Problem beheben, indem Sie alle Redis-Replikate aus dem ArgoCD-Namespace löschen und darauf warten, dass es wieder angezeigt wird.

kubectl -n argocd delete pod argocd-redis-ha-server-0 argocd-redis-ha-server-1 argocd-redis-ha-server-2

# Wait for all 3 pods to come back up
kubectl -n argocd get pods | grep argocd-redis-ha-server

Zertifikatproblem bei der Offlineinstallation

Beschreibung

Möglicherweise wird ein Fehler angezeigt, dass das Zertifikat von einer unbekannten Stelle signiert wurde.

Error: failed to do request: Head "https://sfdev1778654-9f843b23-lb.westeurope.cloudapp.azure.com:30071/v2/helm/audit-service/blobs/sha256:09bffbc520ff000b834fe1a654acd089889b09d22d5cf1129b0edf2d76554892": x509: certificate signed by unknown authority

Lösung

Sowohl die RootCA- als auch die Serverzertifikate müssen sich im vertrauenswürdigen Speicher auf der Maschine befinden.

Führen Sie zur Untersuchung die folgenden Befehle aus:

[[email protected] ~]# find /etc/pki/ca-trust/source{,/anchors} -maxdepth 1 -not -type d -exec ls -1 {} +
/etc/pki/ca-trust/source/anchors/rootCA.crt
/etc/pki/ca-trust/source/anchors/server.crt

Die bereitgestellten Zertifikate müssen in der Ausgabe dieser Befehle erscheinen.

Alternativ können Sie den folgenden Befehl ausführen:

[[email protected] ~]# openssl x509 -in /etc/pki/ca-trust/source/anchors/server.crt -text -noout

Stellen Sie sicher, dass sich der vollqualifizierte Domänenname im alternativen Antragstellernamen der Ausgabe befindet.

X509v3 Subject Alternative Name:
                DNS:sfdev1778654-9f843b23-lb.westeurope.cloudapp.azure.com

Sie können das CA-Zertifikat wie folgt ändern:

[[email protected] ~]# update-ca-trust

Fehler beim Herunterladen des Pakets

Beschreibung

In der Dokumentation wird wget als Option zum Herunterladen der Bundles aufgeführt. Aufgrund der großen Größen wird die Verbindung eventuell und kann nicht wiederhergestellt werden.

Lösung

One way to mitigate this could be to switch to a different download tool, such as azcopy (more information here). Run these commands, while updating the bundle URL to match the desired version/bundle combination.

wget https://aka.ms/downloadazcopy-v10-linux -O azcopy.tar.gz
tar -xvf ./azcopy.tar.gz
azcopy_linux_amd64_10.11.0/azcopy copy https://download.uipath.com/service-fabric/0.0.23-private4/sf-0.0.23-private4.tar.gz /var/tmp/sf.tar.gz --from-to BlobLocal

Longhorn-Fehler

Rook Ceph oder Looker-Pod hängen im Init-Status fest

Beschreibung

Gelegentlich gibt es beim Neustart eines Knotens das Problem, dass der Looker- oder Rook Ceph-Pod im Init-Status festhängt, da das Volume fehlt, das zum Anhängen von PVC an einen Pod erforderlich ist.

Überprüfen Sie, ob das Problem tatsächlich mit Longhorn zusammenhängt, indem Sie den folgenden Befehl ausführen:

kubectl get events -A -o json | jq -r '.items[] | select(.message != null) | select(.message | contains("cannot get resource \"volumeattachments\" in API group \"storage.k8s.io\""))'

Wenn es mit Longhorn in Verbindung steht, sollte dieser Befehl eine Liste von Pod-Namen zurückgeben, die vom Problem betroffen sind. Wenn der Befehl nichts zurückgibt, ist die Ursache des Problems eine andere.

Lösung

Führen Sie das folgende Skript aus, um die problematischen Pods zu beheben, wenn der vorherige Befehl keine leere Ausgabe zurückgibt:

#!/bin/bash


function wait_till_rollout() {
    local namespace=$1
    local object_type=$2
    local deploy=$3

    local try=0
    local maxtry=2
    local status="notready"

    while [[ ${status} == "notready" ]]  && (( try != maxtry )) ; do
        kubectl -n "$namespace" rollout status "$deploy" -w --timeout=600s; 
        # shellcheck disable=SC2181
        if [[ "$?" -ne 0 ]]; 
        then
            status="notready"
            try=$((try+1))
        else
            status="ready"
        fi
    done
    if [[ $status == "notready" ]]; then 
        echo "$deploy of type $object_type failed in namespace $namespace. Plz re-run the script once again to verify that it's not a transient issue !!!"
        exit 1
    fi
}

function fix_pv_deployments() {
    for pod_name in $(kubectl get events -A -o json | jq -r '.items[]  | select(.message | contains("cannot get resource \"volumeattachments\" in API group \"storage.k8s.io\"")) | select(.involvedObject.kind == "Pod") | .involvedObject.name + "/" + .involvedObject.namespace' | sort | uniq)
    do
        POD_NAME=$(echo "${pod_name}" | cut -d '/' -f1)
        NS=$(echo "${pod_name}" | cut -d '/' -f2)
        controller_data=$(kubectl -n "${NS}" get po "${POD_NAME}" -o json | jq -r '[.metadata.ownerReferences[] | select(.controller==true)][0] | .kind + "=" + .name')
        [[ $controller_data == "" ]] && error "Error: Could not determine owner for pod: ${POD_NAME}" && exit 1
        CONTROLLER_KIND=$(echo "${controller_data}" | cut -d'=' -f1)
        CONTROLLER_NAME=$(echo "${controller_data}" | cut -d'=' -f2)
        if [[ $CONTROLLER_KIND == "ReplicaSet" ]]
        then
            controller_data=$(kubectl  -n "${NS}" get "${CONTROLLER_KIND}" "${CONTROLLER_NAME}" -o json | jq -r '[.metadata.ownerReferences[] | select(.controller==true)][0] | .kind + "=" + .name')
            CONTROLLER_KIND=$(echo "${controller_data}" | cut -d'=' -f1)
            CONTROLLER_NAME=$(echo "${controller_data}" | cut -d'=' -f2)

            replicas=$(kubectl -n "${NS}" get "$CONTROLLER_KIND" "$CONTROLLER_NAME" -o json | jq -r '.status.replicas')
            unavailable_replicas=$(kubectl -n "${NS}" get "$CONTROLLER_KIND" "$CONTROLLER_NAME" -o json | jq -r '.status.unavailableReplicas')

            if [ -n "$unavailable_replicas" ]; then 
                available_replicas=$((replicas - unavailable_replicas))
                if [ $available_replicas -eq 0 ]; then
                    kubectl -n "$NS" scale "$CONTROLLER_KIND" "$CONTROLLER_NAME" --replicas=0
                    sleep 15
                    kubectl -n "$NS" scale "$CONTROLLER_KIND" "$CONTROLLER_NAME" --replicas="$replicas"
                    deployment_name="$CONTROLLER_KIND/$CONTROLLER_NAME"
                    wait_till_rollout "$NS" "deploy" "$deployment_name"
                fi 
            fi
        fi
    done
}

fix_pv_deployments

Fehler beim Erstellen persistenter Volumes

Beschreibung

Longhorn wurde erfolgreich installiert, kann jedoch keine persistenten Volumes erstellen.

Lösung

Überprüfen Sie, ob die Kernel-Module erfolgreich in den Cluster geladen wurden, indem Sie den Befehl lsmod | grep <module_name> verwenden.
Ersetzen Sie <module_name> durch jedes der folgenden Kernel-Module:

• libiscsi_tcp
• libiscsi
• iscsi_tcp
• scsi_transport_iscsi

Laden Sie alle fehlenden Module.

Pod „rke2-coredns-rke2-coredns-autoscaler“ in CrashLoopBackOff

Beschreibung

Nach dem Knoten-Neustart wechselt „rke2-coredns-rke2-coredns-autoscaler“ eventuell zu „CrashLoopBackOff“. Dies hat keine Auswirkungen auf die Automation Suite.

Lösung

Löschen Sie den Pod „rke2-coredns-rke2-coredns-autoscaler“, der sich in CrashLoopBackOff befindet mit dem folgenden Befehl: kubectl delete pod <pod name> -n kube-system

Redis-Testfehler

Beschreibung

Der Redis-Test kann fehlschlagen, wenn die Knoten-ID-Datei nicht vorhanden ist. Dies kann passieren, wenn der Pod noch nicht urgeladen ist.

Es gibt einen Wiederherstellungsauftrag, der dieses Problem automatisch behebt. Die folgenden Schritte sollten nicht ausgeführt werden, während der Auftrag ausgeführt wird.

Wenn ein Redis Enterprise-Cluster den Kontakt mit mehr als der Hälfte seiner Knoten verliert (entweder aufgrund fehlgeschlagener Knoten oder Netzwerkaufteilung), dann reagiert der Cluster nicht mehr auf Clientverbindungen. Die Pods können dem Cluster auch nicht erneut zugeordnet werden.

Lösung

1. Löschen Sie den Redis-Cluster und die Datenbank mit den folgenden Befehlen:

kubectl delete redb -n redis-system redis-cluster-db --force --grace-period=0 &
kubectl delete rec -n redis-system redis-cluster --force --grace-period=0 &
kubectl patch redb -n redis-system redis-cluster-db --type=json -p '[{"op":"remove","path":"/metadata/finalizers","value":"finalizer.redisenterprisedatabases.app.redislabs.com"}]'
kubectl patch rec redis-cluster -n redis-system --type=json -p '[{"op":"remove","path":"/metadata/finalizers","value":"redbfinalizer.redisenterpriseclusters.app.redislabs.com"}]'
kubectl delete job redis-cluster-db-job -n redis-system

2. Wechseln Sie zur ArgoCD-Benutzeroberfläche und synchronisieren Sie die Anwendung redis-cluster.

RKE2-Server kann nicht gestartet werden

Beschreibung

Der Server kann nicht gestartet werden. Es gibt verschiedene Gründe, warum RKE2 nicht richtig gestartet wird. Sie finden sie normalerweise in den Protokollen.

Lösung

Überprüfen Sie die Protokolle mit den folgenden Befehlen:

journalctl -u rke2-server

Mögliche Gründe (basierend auf Protokollen): zu viele Lerner-Mitglieder im Cluster

Too many etcd servers are added to the cluster, and there are two learner nodes trying to be promoted. More information here: Runtime reconfiguration.

Führen Sie die folgenden Schritte aus:

1. Unter normalen Umständen sollte der Knoten Vollmitglied werden, wenn ausreichend Zeit gewährt wird.
2. Es kann ein Deinstallationszyklus versucht werden.

Alternatively, this could be caused by a networking problem. Ensure you have configured the machine to enable the necessary ports.

Eine Entleerung tritt bei angehaltenen Knoten nicht auf.

Beschreibung

Wenn ein Knoten in einem Cluster angehalten wird und seine entsprechenden Pods nach 15 Minuten nicht auf verfügbare Knoten umgestellt werden, führen Sie das folgende Skript aus, um den Knoten manuell zu entleeren.

#!/bin/sh

KUBECTL="/usr/local/bin/kubectl"

# Get only nodes which are not drained yet
NOT_READY_NODES=$($KUBECTL get nodes | grep -P 'NotReady(?!,SchedulingDisabled)' | awk '{print $1}' | xargs echo)
# Get only nodes which are still drained
READY_NODES=$($KUBECTL get nodes | grep '\sReady,SchedulingDisabled' | awk '{print $1}' | xargs echo)

echo "Unready nodes that are undrained: $NOT_READY_NODES"
echo "Ready nodes: $READY_NODES"


for node in $NOT_READY_NODES; do
  echo "Node $node not drained yet, draining..."
  $KUBECTL drain --ignore-daemonsets --force --delete-emptydir-data $node
  echo "Done"
done;

for node in $READY_NODES; do
  echo "Node $node still drained, uncordoning..."
  $KUBECTL uncordon $node
  echo "Done"
done;

Aktivieren der Istio-Protokollierung

Um Istio zu debuggen, müssen Sie die Protokollierung aktivieren. Führen Sie dazu die folgenden Schritte aus:

1. Suchen Sie den Pod istio-ingressgateway, indem Sie den folgenden Befehl ausführen. Kopieren Sie den Gateway-Pod-Namen. Er sollte ungefähr so aussehen wie istio-ingressgateway-r4mbx.

kubectl -n istio-system get pods

2. Öffnen Sie die Gateway-Pod-Shell, indem Sie den folgenden Befehl ausführen.

kubectl exec -it -n istio-system istio-ingressgateway-r4mbx bash

3. Aktivieren Sie die Protokollierung auf Debugebene, indem Sie den folgenden Befehl ausführen.

curl -X POST http://localhost:15000/logging?level=debug

4. Run the following command from a server node.

istioctl_bin=$(find /var/lib/rancher/rke2/ -name "istioctl" -type f -perm -u+x   -print -quit)
if [[ -n ${istioctl_bin} ]]
then
echo "istioctl bin found"
  kubectl -n istio-system get cm istio-installer-base -o go-template='{{ index .data "istio-base.yaml" }}'  > istio-base.yaml
  kubectl -n istio-system get cm istio-installer-overlay  -o go-template='{{ index .data "overlay-config.yaml" }}'  > overlay-config.yaml 
  ${istioctl_bin} -i istio-system install -y -f istio-base.yaml -f overlay-config.yaml --set meshConfig.accessLogFile=/dev/stdout --set meshConfig.accessLogEncoding=JSON 
else
  echo "istioctl bin not found"
fi

Secret nicht im UiPath-Namespace gefunden

Beschreibung

Wenn die Installation des Dienstes fehlschlägt und kubectl -n uipath get pods fehlgeschlagene Pods zurückgibt, führen Sie die folgenden Schritte aus.

Lösung

1. Überprüfen Sie kubectl -n uipath describe pod <pod-name> und suchen Sie nach dem nicht gefundenen Secret.
2. Wenn das Secret nicht gefunden wird, suchen Sie nach den Auftragsprotokollen der Anmeldeinformationsverwaltung und sehen Sie nach, ob er fehlgeschlagen ist.
3. Wenn der Auftrag der Anmeldeinformationsverwaltung fehlgeschlagen ist und kubectl get pods -n rook-ceph|grep rook-ceph-tool mehr als einen Pod zurückgibt, gehen Sie wie folgt vor:
   a. Löschen Sie rook-ceph-tool, was nicht ausgeführt wird.
   b. Gehen Sie zur ArgoCD-Benutzeroberfläche und synchronisieren Sie die Anwendung sfcore.
   c. Sobald der Auftrag abgeschlossen ist, überprüfen Sie, ob alle Secrets in den Auftragsprotokollen der Anmeldeinformationsverwaltung erstellt werden.
   d. Synchronisieren Sie jetzt die Anwendung uipath.

Anmeldung nach der Migration nicht mehr möglich

Beschreibung

Ein Problem kann sich auf die Migration von einem eigenständigen Produkt zu Automation Suite auswirken. Es verhindert, dass Sie sich anmelden können, wobei die folgende Fehlermeldung angezeigt wird: Cannot find client details.

Lösung

Um dieses Problem zu beheben, müssen Sie zuerst die Anwendung uipath neu synchronisieren und dann die Anwendung platform in ArgoCD synchronisieren.

Nach der ersten Installation wechselte ArgoCD in den Status „Progressing“.

Beschreibung

Immer wenn der Clusterstatus von dem im Helm-Repository definierten abweicht, versucht argocd, den Zustand zu synchronisieren. Die Abstimmung erfolgt jede Minute. Immer wenn dies der Fall ist, stellen Sie fest, dass sich ArgoCD im Status „Progressing“ befindet.

Lösung

Dies ist das erwartete Verhalten von ArgoCD und wirkt sich nicht auf die Anwendung aus.

Für die Automation Suite muss backlog_wait_time auf „1“ festgelegt sein.

Beschreibung

Prüfungsereignisse können Instabilität verursachen (aufgehängtes System), wenn backlog_wait_time nicht auf 1 festgelegt ist.
For more details, see this issue description.

Lösung

Wenn das Installationsprogramm mit der Fehlermeldung Automation Suite requires backlog_wait_time to be set 1 fehlschlägt („Für Automation Suite muss backlog_wait_time auf 1 festgelegt sein“), führen Sie die folgenden Schritte aus, um backlog_wait_time auf 1 festzulegen.

1. Legen Sie backlog_wait_time auf 1 fest, indem Sie --backlog_wait_time 1 in der Datei /etc/audit/rules.d/audit.rules anhängen.
2. Starten Sie den Knoten neu.
3. Überprüfen Sie, ob der Wert backlog_wait_time für auditctl auf 1 festgelegt ist, indem Sie im Knoten sudo auditctl -s | grep "backlog_wait_time" ausführen.

Fehler beim Ändern der Größe von objectstore PVC

Beschreibung

Dieses Problem tritt auf, wenn der Vorgang objectstore resize-pvc mit dem folgenden Fehler fehlschlägt:

Failed resizing the PVC: <pvc name> in namespace: rook-ceph, ROLLING BACK

Lösung

Führen Sie die folgenden Schritte aus, um dieses Problem zu beheben:

1. Führen Sie das folgende Skript manuell aus:

#!/bin/sh

ROOK_CEPH_OSD_PREPARE=$(kubectl -n rook-ceph get pods | grep rook-ceph-osd-prepare-set | awk '{print $1}')
if [[ -n ${ROOK_CEPH_OSD_PREPARE} ]]; then
    for pod in ${ROOK_CEPH_OSD_PREPARE}; do
    echo "Start deleting rook ceph osd pod $pod .."
    kubectl -n rook-ceph delete pod $pod
    echo "Done"
    done;
fi

2. Führen Sie den Befehl objectstore resize-pvc erneut aus.

Fehler nach der Zertifikatsaktualisierung

Beschreibung

Dieses Problem tritt auf, wenn die Zertifikataktualisierung intern fehlschlägt. Möglicherweise können Sie nicht auf die Automation Suite oder den Orchestrator zugreifen.

Fehler (Error)

Lösung

1. Führen Sie die folgenden Befehle von einem der Serverknoten aus.

export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
export PATH=$PATH:/var/lib/rancher/rke2/bin

kubectl -n uipath rollout restart deployments

2. Warten Sie, bis der obige Befehl erfolgreich ausgeführt wurde und führen Sie dann den folgenden Befehl aus, um den Status des vorherigen Befehls zu überprüfen.

deployments=$(kubectl -n uipath get deployment -o name)
for i in $deployments; 
do 
kubectl -n uipath rollout status "$i" -w --timeout=600s; 
if [[ "$?" -ne 0 ]]; 
then
    echo "$i deployment failed in namespace uipath."
fi
done
echo "All deployments are succeeded in namespace uipath"

Sobald der obige Befehl abgeschlossen wurde, sollten Sie auf die Automation Suite und den Orchestrator zugreifen können

Unexpected inconsistency; run fsck manually

While installing or upgrading Automation Suite, if the MongoDB pods cannot mount to the PVC pods, the following error message is displayed:
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

Recovery steps

If you encounter the error above, follow the recovery steps below:

1. SSH to the system by running the following command:

ssh <user>@<node-ip>

2. Check the events of the PVC and verify that the issue is related to the PVC mount failure due to file error. To do this, run the following command:

export KUBECONFIG=/etc/rancher/rke2/rke2.yaml PATH=$PATH:/var/lib/rancher/rke2/bin:/usr/local/bin
kubectl get events -n mongodb
kubectl get events -n longhorn-system

3. Check the PVC volume mentioned in the event and run the fsck command.

fsck -a <pvc-volume-name>
Eg - fsck -a /dev/longhorn/pvc-5abe3c8f-7422-44da-9132-92be5641150a

4. Delete the failing MongoDB pod to properly mount it to the PVC.

kubectl delete pod <pod-name> -n mongodb

Identity Server issues

Setting a timeout interval for the Management portals

Pre-installation, you cannot update the expiration time for the token used to authenticate to the host- and organization-level Management portals. Therefore user sessions do not time out.

To set a time interval for timeout for these portals, you can update the accessTokenLifetime property.
The below example sets the timeout interval to 86400 seconds (24 hours):

UPDATE [identity].[Clients] SET AccessTokenLifetime = 86400 WHERE ClientName = 'Portal.OpenId'

Kerberos-Probleme

kinit: KDC kann für Realm beim Abrufen der ersten Anmeldeinformationen nicht gefunden werden

Beschreibung

Dieser Fehler kann während der Installation (wenn Sie die Kerberos-Authentifizierung aktiviert haben) oder während der kerberos-tgt-update Cron-Auftragsausführung auftreten, wenn der UiPath Cluster keine Verbindung zum AD-Server herstellen kann, um das Kerberos-Ticket für die Authentifizierung zu erhalten.

Lösung

Überprüfen Sie die AD-Domäne und stellen Sie sicher, dass sie wie folgt korrekt konfiguriert und weiterleitbar ist:

getent ahosts <AD domain> | awk '{print $1}' | sort | uniq

Wenn dieser Befehl keine weiterleitbare IP-Adresse zurückgibt, ist die für die Kerberos-Authentifizierung erforderliche AD-Domäne nicht ordnungsgemäß konfiguriert.

Sie müssen mit den IT-Administratoren zusammenarbeiten, um die AD-Domäne zu Ihrem DNS-Server hinzuzufügen und sicherzustellen, dass dieser Befehl eine weiterleitbare IP-Adresse zurückgibt.

kinit: Keytab contains no suitable keys for *** while getting initial credentials

Beschreibung

Dieser Fehler konnte im Protokoll eines fehlgeschlagenen Auftrags mit einem der folgenden Auftragsnamen gefunden werden: services-preinstall-validations-job, kerberos-jobs-trigger, kerberos-tgt-update.

Lösung

Stellen Sie sicher, dass der AD-Benutzer noch vorhanden ist, aktiv ist und sein Kennwort nicht geändert wurde und nicht abgelaufen ist. Setzen Sie das Kennwort des Benutzers zurück und generieren Sie die Keytab bei Bedarf neu.
Also make sure to provide the default Kerberos AD user parameter <KERB_DEFAULT_USERNAME> in the following format: HTTP/<Service Fabric FQDN>.

Der GSSAPI-Vorgang ist mit Fehler fehlgeschlagen: Es wurde ein ungültiger Statuscode übermittelt (Die Anmeldeinformationen des Clients wurden widerrufen).

Beschreibung

This log could be found when using Kerberos for SQL access, and SQL connection is failing inside services. Similarly, you may see kinit: Client's credentials have been revoked while getting initial credential in one of the following job names: services-preinstall-validations-job, kerberos-jobs-trigger, kerberos-tgt-update.

Lösung

This could be caused by the AD user account used to generate the keytab being disabled. Re-enabling the AD user account should fix the issue.

Die Anmeldung ist für den Benutzer <ADDOMAIN>\<aduser> fehlgeschlagen. Grund: Das Konto ist deaktiviert.

Beschreibung

Dieses Protokoll konnte gefunden werden, wenn Kerberos für den SQL-Zugriff verwendet wird und die SQL-Verbindung innerhalb der Dienste fehlschlägt.

Lösung

This issue could be caused by the AD user losing access to the SQL server. See instructions on how to reconfigure the AD user.

Probleme im Zusammenhang mit dem Orchestrator

Orchestrator-Pod in „CrashLoopBackOff“ oder 1/2 mit mehreren Neustarts

Beschreibung

Wenn der Orchestrator-Pod in „CrashLoopBackOff“ oder „1/2“ mit mehreren Neustarts ausgeführt wird, könnte der Fehler mit den Authentifizierungsschlüsseln für den Objektspeicheranbieter Ceph zusammenhängen.

Um zu überprüfen, ob der Fehler mit Ceph zusammenhängt, führen Sie die folgenden Befehle aus:

kubectl -n uipath get pod -l app.kubernetes.io/component=orchestrator

Wenn die Ausgabe dieses Befehls einer der folgenden Optionen ähnelt, müssen Sie einen zusätzlichen Befehl ausführen.

Option 1:
NAME                            READY   STATUS    RESTARTS   AGE
orchestrator-6dc848b7d5-q5c2q   1/2     Running   2          6m1s

OR 

Option 2
NAME                            READY   STATUS             RESTARTS   AGE
orchestrator-6dc848b7d5-q5c2q   1/2     CrashLoopBackOff   6          16m

Überprüfen Sie, ob der Fehler mit Ceph-Authentifizierungsschlüsseln zusammenhängt, indem Sie den folgenden Befehl ausführen:

kubectl -n uipath logs -l app.kubernetes.io/component=orchestrator | grep 'Error making request with Error Code InvalidAccessKeyId and Http Status Code Forbidden' -o

Wenn die Ausgabe des obigen Befehls die Zeichenfolge Error making request with Error Code InvalidAccessKeyId and Http Status Code Forbidden enthält, ist der Fehler auf die Ceph-Authentifizierungsschlüssel zurückzuführen.

Lösung

Führen Sie die Aufträge rook-ceph-configure-script-job und credential-manager mithilfe der folgenden Befehle erneut aus:

kubectl -n uipath-infra get job "rook-ceph-configure-script-job" -o json | jq 'del(. | .spec.selector, .spec.template.metadata.labels)' | kubectl replace --force -f -
kubectl -n uipath-infra get job "credential-manager-job" -o json | jq 'del(. | .spec.selector, .spec.template.metadata.labels)' | kubectl replace --force -f -
kubectl -n uipath delete pod -l app.kubernetes.io/component=orchestrator

Probleme im Zusammenhang mit dem Test Manager

Lizenzierungsproblem bei Test Manager

Wenn Ihnen eine Lizenz zugewiesen wurde, während Sie angemeldet waren, wird Ihre Lizenzzuweisung möglicherweise beim Öffnen vom Test Manager nicht erkannt.

Führen Sie in diesem Fall die folgenden Schritte aus:

1. Navigieren Sie zum Test Manager.
2. Melden Sie sich vom Portal ab.
3. Melden Sie sich wieder an.

Probleme mit Zusammenhang mit dem AI Center

Probleme bei der Bereitstellung von Fähigkeiten im AI Center

Manchmal können Document Understanding-Modell-Fähigkeits-Bereitstellungen mit „Fehlgeschlagen“ oder „Unbekannter Fehler“ fehlschlagen, wenn das Modell zum ersten Mal bereitgestellt wird. Die Problemumgehung besteht darin, das Modell erneut bereitzustellen. Beim zweiten Mal ist die Bereitstellung schneller, da der größte Teil der Bereitstellungsarbeit in Form der Abbild-Erstellung während des ersten Versuchs erfolgt. DU-Modelle brauchen bei der ersten Bereitstellung etwa 1–1,5 Stunden und sind bei einer erneuten Bereitstellung schneller fertig.

In einem seltenen Szenario können asynchrone Vorgänge wie die Bereitstellung von Fähigkeiten oder der Paket-Upload aufgrund des Cluster-Status lange hängen bleiben. Wenn die Bereitstellung von DU-Fähigkeiten mehr als 2–3 Stunden dauert, versuchen Sie, ein einfacheres Modell bereitzustellen (z. B. TemplateModel). Wenn es bei dem Modell auch mehr als eine Stunde dauert, wird empfohlen, die AI Center-Dienste mit den folgenden Befehlen neu zu starten:

kubectl -n uipath rollout restart deployment ai-deployer-deployment
kubectl -n uipath rollout restart deployment ai-trainer-deployment
kubectl -n uipath rollout restart deployment ai-pkgmanager-deployment
kubectl -n uipath rollout restart deployment ai-helper-deployment
kubectl -n uipath rollout restart deployment ai-appmanager-deployment

Warten Sie, bis die AI Center-Pods gesichert sind, und verifizieren Sie dies mit dem folgenden Befehl:

kubectl -n uipath get pods | grep ai-*

Alle oben genannten Pods sollten sich im Status „Wird ausgeführt“ befinden, wobei der Containerstatus als „2/2“ angezeigt wird.

Probleme im Zusammenhang mit Document Understanding

Document Understanding erscheint nicht auf der linken Leiste der Automation Suite

Beschreibung

Falls Ihnen auffällt, dass Document Understanding nicht auf der linken Leiste der Automation Suite zu finden ist: Beachten Sie, dass Document Understanding derzeit keine separate Anwendung in der Automation Suite ist und daher nicht in der linken Leiste angezeigt wird.

Lösung

Der Data Manager ist Teil des AI Center, also stellen Sie sicher, dass Sie das AI Center aktivieren.

Greifen Sie außerdem auf den Form Extractor, den Intelligent Form Extractor (einschließlich HandwritingRecognition) und den Intelligent Keyword Classifier mit der folgenden öffentlichen URL zu:

<FQDN>/du_/svc/formextractor
<FQDN>/du_/svc/intelligentforms
<FQDN>/du_/svc/intelligentkeywords

Wenn Sie beim Versuch, den Intelligent Keyword Classifier, Form Extractor und Intelligent Form Extractor in Studio zu verwenden, die Fehlermeldung Your license can not be validated erhalten, nehmen Sie auch den API-Schlüssel, den Sie für Document Understanding in der Automation Suite-Installation generiert haben und nicht den von cloud.uipath.com.

Fehlerstatus beim Erstellen einer Datenbeschriftungssitzung

Beschreibung

Wenn Sie keine Datenbeschriftungssitzung auf dem Data Manager im AI Center erstellen können, führen Sie die folgenden Schritte aus.

Lösung 1

Überprüfen Sie, ob Document Understanding ordnungsgemäß aktiviert ist. Sie müssen die Konfigurationsdatei vor der Installation aktualisiert und documentunderstanding.enabled auf „True“ festgelegt haben. Alternativ können Sie sie nach der Installation in ArgoCD wie unten beschrieben anpassen.

Anschließend müssen Sie sie deaktivieren und das AI Center auf dem Mandanten deaktivieren, für den Sie die Data Labeling-Funktion verwenden möchten, oder einen neuen Mandanten erstellen.

Lösung 2

Wenn Document Understanding in der Konfigurationsdatei oder in ArgoCD ordnungsgemäß aktiviert ist, ist Document Understanding manchmal für DefaultTenant nicht aktiviert. Das ist daran zu erkennen, dass keine Datenbeschriftungssitzungen erstellt werden können.

Um dies zu beheben, deaktivieren Sie AI Center auf dem Mandanten und aktivieren Sie es wieder. Beachten Sie, dass Sie möglicherweise einige Minuten warten müssen, bevor Sie es wieder aktivieren können.

Fehlerstatus beim Versuch, eine ML-Fähigkeit bereitzustellen

Beschreibung

Wenn es nicht möglich ist, eine Document Understanding-ML-Fähigkeit im AI Center bereitzustellen, versuchen Sie die folgenden Lösungsansätze.

Lösung 1

Wenn Sie die Automation Suite offline installieren, überprüfen Sie erneut, ob das Document Understanding-Paket heruntergeladen und installiert wurde.

Das Paket enthält das Basis-Abbild für die Modelle (z. B. Modellbibliothek), um nach dem Hochladen der ML-Pakete über die AI Center-Benutzeroberfläche ordnungsgemäß im AI Center ausgeführt zu werden.

For details about installing Document Understanding bundle, please refer to the documentation here and here. To add Document Understanding bundle, please follow the documentation to re-run the Document Understanding bundle installation.

Lösung 2

Auch wenn Sie das Document Understanding-Paket für die Offlineinstallation installiert haben, kann zusammen mit dieser Fehlermeldung ein weiteres Problem auftreten: modulenotfounderror: no module named 'ocr.release'; 'ocr' is not a package.

Beachten Sie beim Erstellen eines Document Understanding-OCR-ML-Pakets im AI Center, dass es nicht ocr oder OCR benannt werden kann, weil das zu einem Konflikt mit einem Ordner im Paket stehen würde. Wählen Sie daher einen anderen Namen.

Lösung 3

Manchmal können Document Understanding-Modell-Fähigkeits-Bereitstellungen mit Failed to list deployment („Listen der Bereitstellung fehlgeschlagen“) oder Unknown Error („Unbekannter Fehler“) fehlschlagen, wenn das Modell zum ersten Mal bereitgestellt wird.

Die Problemumgehung besteht darin, das Modell erneut bereitzustellen. Beim zweiten Mal ist die Bereitstellung schneller, da der größte Teil der Bereitstellungsarbeit in Form der Abbild-Erstellung während des ersten Versuchs erfolgt. Document Understanding-ML-Pakete benötigen bei der ersten Bereitstellung etwa 1–1,5 Stunden. Bei einer erneuten Bereitstellung geht es schneller.

Migrationsauftrag schlägt in ArgoCD fehl

Beschreibung

Migrationsauftrag schlägt für Document Understanding in ArgoCD fehl.

Lösung

Document Understanding erfordert, dass die FullTextSearch-Funktion auf dem SQL-Server aktiviert ist. Andernfalls kann die Installation durch einen fehlerhaften Migrationsauftrag in ArgoCD fehlschlagen, ohne dass eine explizite Fehlermeldung angezeigt wird.

Die Handschrifterkennung mit dem Intelligent Form Extractor funktioniert nicht oder arbeitet zu langsam

Beschreibung

Die Handschrifterkennung mit dem Intelligent Form Extractor funktioniert nicht oder arbeitet zu langsam.

Lösung 1

Wenn Sie Intelligent Form Extractor offline verwenden, stellen Sie sicher, dass Sie die Handschrift in der Konfigurationsdatei vor der Installation aktiviert oder in ArgoCD aktiviert haben.

Um dies zu überprüfen, gehen Sie zu „ArgoCD“ > „Document Understanding“ > „App-Details“ > „du-services.handwritingEnabled“ (legen Sie es auf „True“ fest).

Bei Air-Gap muss zuvor das Document Understanding-Paket installiert werden. Andernfalls schlägt die ArgoCD-Synchronisierung fehl.

Lösung 2

Obwohl die Handschrift in der Konfigurationsdatei aktiviert ist, haben Sie möglicherweise immer noch die gleichen Probleme.

Bitte beachten Sie, dass die maximale Menge an CPUs, die jeder Container für die Handschrift verwenden darf, 2 ist. Möglicherweise müssen Sie den Parameter handwriting.max_cpu_per_pod anpassen, wenn Sie einen größeren Workload für die Handschriftverarbeitung haben. Sie können ihn in der Konfigurationsdatei vor der Installation aktualisieren oder in ArgoCD anpassen.

For more details on how to calculate the parameter value based on your volume, please check the documentation here.

Probleme im Zusammenhang mit Insights

Beim Aufrufen der Insights-Startseite wird ein Fehler 404 angezeigt

In seltenen Fällen kann ein Routing-Fehler auftreten, der zu einer 404er Fehler auf der Insights-Startseite führt. Sie können dies beheben, indem Sie zur Insights-Anwendung in ArgoCD wechseln und den virtuellen Dienst insightsprovisioning-vs löschen. Beachten Sie, dass Sie möglicherweise auf clear filters to show X additional resources klicken müssen, um diesen virtuellen Dienst anzuzeigen und zu löschen.