Fehlerbehebung
Fehlerbehebung bei Diensten während der Installation
Take the following steps on one of the cluster server nodes:
- 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
- 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
-
Herstellen einer Verbindung mit ArgoCD
a. Gehen Sie zuhttps://alm.<fqdn>/:443
.
b. Melden Sie sich an, indem Sieadmin
als Benutzernamen und das in Schritt 2 erhaltene Kennwort verwenden. -
Suchen Sie die Anwendung „UiPath Services“ wie folgt:
a. Geben Sie in die Suchleiste bei ArgoCDuipath
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:
- 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."
- 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.
- Löschen Sie mit dem folgenden Befehl alle von podman in den lokalen Containerspeicher geladenen Bilder:
podman image rm -af
- 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
erfordertpodman
>=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
erfordertcontainernetworking-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, dasspodman
=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.
-
Entfernen Sie die aktuelle Version von podman mithilfe des Befehls
yum remove podman
. -
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
- 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
- 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:
- Unter normalen Umständen sollte der Knoten Vollmitglied werden, wenn ausreichend Zeit gewährt wird.
- 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:
- 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 wieistio-ingressgateway-r4mbx
.
kubectl -n istio-system get pods
- Öffnen Sie die Gateway-Pod-Shell, indem Sie den folgenden Befehl ausführen.
kubectl exec -it -n istio-system istio-ingressgateway-r4mbx bash
- Aktivieren Sie die Protokollierung auf Debugebene, indem Sie den folgenden Befehl ausführen.
curl -X POST http://localhost:15000/logging?level=debug
- 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
- Überprüfen Sie
kubectl -n uipath describe pod <pod-name>
und suchen Sie nach dem nicht gefundenen Secret. - Wenn das Secret nicht gefunden wird, suchen Sie nach den Auftragsprotokollen der Anmeldeinformationsverwaltung und sehen Sie nach, ob er fehlgeschlagen ist.
- 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 Sierook-ceph-tool
, was nicht ausgeführt wird.
b. Gehen Sie zur ArgoCD-Benutzeroberfläche und synchronisieren Sie die Anwendungsfcore
.
c. Sobald der Auftrag abgeschlossen ist, überprüfen Sie, ob alle Secrets in den Auftragsprotokollen der Anmeldeinformationsverwaltung erstellt werden.
d. Synchronisieren Sie jetzt die Anwendunguipath
.
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.
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.
- Legen Sie
backlog_wait_time
auf1
fest, indem Sie--backlog_wait_time 1
in der Datei/etc/audit/rules.d/audit.rules
anhängen. - Starten Sie den Knoten neu.
- Überprüfen Sie, ob der Wert
backlog_wait_time
fürauditctl
auf1
festgelegt ist, indem Sie im Knotensudo 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:
- 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
- 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
- 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
- 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:
- SSH to the system by running the following command:
ssh <user>@<node-ip>
- 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
- 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
- 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.
<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:
- Navigieren Sie zum Test Manager.
- Melden Sie sich vom Portal ab.
- 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.
Updated 12 days ago