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. Navigate to https://alm.<fqdn>/:443
   b. Login using admin as the username and the password obtained at Step 2.

4. Suchen Sie die Anwendung „UiPath Services“ wie folgt:
   a. Using the search bar provided in ArgoCD, type in uipath.
   

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

   c. Check for the following: Application was not synced due to a failed job/pod.

   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. Then remove the temporary offline folder, used with the flag --offline-tmp-folder. This parameter defaults to /tmp:

rm -rf /path/to/temp/folder

How to disable TLS 1.0 and 1.1

TLS 1.0 and 1.1 are deprecated, and enabling these versions in a clean installationcan pose a security risk. You are strongly recommended to upgrade to TLS 1.2 or above instead of enabling lower versions on the server.

To enable TLS 1.2 in a clean installation, run the following command:

kubectl -n istio-system patch gateway main-gateway --type=json \
    -p='[{ "op": "replace", "path": "/spec/servers/0/tls/minProtocolVersion", "value": "TLSV1_2"}]'

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
• Paket cockpit-podman-29-2.module+el8.4.0+10607+f4da7515.noarch requires podman >= 1.3.0, but none of the providers can be installed
• der beste Kandidat für den Auftrag kann nicht installiert werden
• problem with installed package cockpit-podman-29-2.module+el8.4.0+10607+f4da7515.noarch

Mögliches Problem

• Paket podman-3.0.1-6.module+el8.4.0+10607+f4da7515.x86_64 requires containernetworking-plugins >= 0.8.1-1, but none of the providers can be installed
• 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
• Paket podman-catatonit-3.0.1-6.module+el8.4.0+10607+f4da7515.x86_64 requires podman = 3.0.1-6.module+el8.4.0+10607+f4da7515, but none of the providers can be installed
• der beste Kandidat für den Auftrag kann nicht installiert werden
• problem with installed package podman-catatonit-3.0.1-6.module+el8.4.0+10607+f4da7515.x86_64
  (try to add --allowerasing to command line to replace conflicting packages or --skip-broken to skip uninstallable packages or --nobest to use not only best candidate packages)

Lösung

You need to remove the current version of podman and allow Automation Suite to install the required version.

1. Remove the current version of podman using the yum remove podman command.

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

You need to remove the line containing the mount_program key from the podman configuration /etc/containers/storage.conf.
Entfernen Sie die Zeile, anstatt sie auskommentieren.

Fehler beim Abrufen des Sandbox-Abbilds

Beschreibung

You can receive an error message specific when trying to get the following sandbox image: index.docker.io/rancher/pause3.2

Dies kann bei einer Offlineinstallation passieren.

Lösung

Restart either rke2-server oder rke2-agent (depending on whether the machine that the pod is scheduled on is either a server or an agent).

To check which node the pod is scheduled on, run kubectl -n <namespace> get pods -o wide.

# 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:

When clicking on any of the deployments, the following error is displayed: 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

The documentation lists wget as an option for downloading the bundles. Because of the large sizes, the connection may be interrupted and not recover.

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

Verify if the kernel modules are successfully loaded in the cluster by using the command lsmod | grep <module_name>.
Ersetzen (Replace) <module_name> with each of the kernel modules below:

• 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

Delete the rke2-coredns-rke2-coredns-autoscaler pod that is in CrashLoopBackOff using the following command: 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. Find the istio-ingressgateway pod by running the following command. Copy the gateway pod name. It should be something like 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

If service installation fails, and checking kubectl -n uipath get pods returns failed pods, take the following steps.

Lösung

1. Prüfen (Check) kubectl -n uipath describe pod <pod-name> and look for secret not found.
2. Wenn das Secret nicht gefunden wird, suchen Sie nach den Auftragsprotokollen der Anmeldeinformationsverwaltung und sehen Sie nach, ob er fehlgeschlagen ist.
3. If the credential manager job failed and kubectl get pods -n rook-ceph|grep rook-ceph-tool returns more than one pod, do the following:
   a. delete rook-ceph-tool that is not running.
   b. go to ArgoCD UI and sync sfcore appllication.
   c. Sobald der Auftrag abgeschlossen ist, überprüfen Sie, ob alle Secrets in den Auftragsprotokollen der Anmeldeinformationsverwaltung erstellt werden.
   d. Now sync uipath application.

Anmeldung nach der Migration nicht mehr möglich

Beschreibung

An issue might affect the migration from a standalone product to Automation Suite. It prevents you from logging in, with the following error message being displayed: Cannot find client details.

Lösung

To fix this problem, you need to re-sync uipath app first, and then sync platform app in ArgoCD.

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

Beschreibung

Whenever the cluster state deviates from what has been defined in the helm repository, argocd tries to sync the state and reconciliation happens every minute. Whenever this happens, you can notice that the ArgoCD app is in progressing state.

Lösung

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

Automation Suite requires backlog_wait_time to be set 1

Beschreibung

Audit events can cause instability (system freeze) if backlog_wait_time is not set to 1.
For more details, see this issue description.

Lösung

If the installer fails with the Automation Suite requires backlog_wait_time to be set 1 error message, take the following steps to set backlog_wait_time to 1.

1. Set (Satz) backlog_wait_time to 1 by appending --backlog_wait_time 1 in the /etc/audit/rules.d/audit.rules file.
2. Starten Sie den Knoten neu.
3. Validate if backlog_wait_time value is set to 1 for auditctl by running sudo auditctl -s | grep "backlog_wait_time" in the node.

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

Beschreibung

This issue occurs when the objectstore resize-pvc operation fails with the following error:

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. Rerun the objectstore resize-pvc command.

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

This error might occur during installation (if you have Kerberos authentication enabled) or during the kerberos-tgt-update cron job execution when the UiPath cluster cannot connect to the AD server to obtain the Kerberos ticket for authentication.

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

This error could be found in the log of a failed job, with one of the following job names: 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.

Login failed for user <ADDOMAIN>\<aduser>. Reason: The account is disabled.

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.

Alarm received for failed kerberos-tgt-update job

Beschreibung

This happens if the uipath cluster failed to retrieve the latest Kerberos ticket.

Lösung

To find the issue, check the log for a failed job whose name starts with kerberos-tgt-update. After you've identified the problem in the log, check the related troubleshooting information in this section.

SSPI Provider: Server not found in Kerberos database

Lösung

Make sure that the correct SPN records are set up in the AD domain controller for the SQL server. For instructions, see SPN formats in the Microsoft SQL Server documentation.

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

If the output of the above command contains the string Error making request with Error Code InvalidAccessKeyId and Http Status Code Forbidden, the failure is due to the Ceph authentication keys.

Lösung

Rerun the rook-ceph-configure-script-job and credential-manager jobs using the following commands:

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

If you get the Your license can not be validated error message when trying to use Intelligent Keyword Classifier, Form Extractor and Intelligent Form Extractor in Studio, besides making sure you have input the right endpoint, please also take the API key that you generated for Document Understanding under License in the Automation Suite install, and not from 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

Please double-check if Document Understanding is properly enabled. You should have updated the configuration file before the installation and set documentunderstanding.enabled to True, or you could update it in ArgoCD post-installation as below.

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

Even if you have installed the Document Understanding bundle for offline installation, another issue might occur along with this error message: 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

Sometimes, intermittently, Document Understanding Model Skill Deployments can fail with Failed to list deployment oder Unknown Error when deploying the model for the first time.

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.

Please know that the default for the maximum amount of CPUs each container is allowed to use for handwriting is 2. You may need to adjust handwriting.max_cpu_per_pod parameter if you have a larger handwriting processing workload. You could update it in the configuration file before installation or update it in ArgoCD.

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.