通知を受け取る

UiPath Automation Suite

UiPath Automation Suite ガイド

トラブルシューティング

このページでは、Automation Suite の設定時に発生する可能性のある問題を修正する方法について説明します。

トラブルシューティング方法


インストール時にサービスをトラブルシューティングする方法


クラスター サーバー ノードの 1 つで次の手順を実行します。

  1. Kubernetes へのアクセス権を取得します。
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
  1. 次のコマンドを使用して、ArgoCD パスワードを取得します。
kubectl get secrets/argocd-admin-password -n argocd --template '{{ .data.password }}' | base64 -d
  1. ArgoCD に接続します。
    a. https://alm.<fqdn>/:443 に移動します。
    b. admin をユーザー名として使用し、手順 2 で取得したパスワードを使用してログインします。

  2. 次のように UiPath サービス アプリケーションを見つけます。
    a. ArgoCD の検索バーで「uipath」と入力します。

    b. 次に、カードをクリックして UiPath アプリケーションを開きます。

    c. 次のエラーを確認します。Application was not synced due to a failed job/pod

    d. 上記のエラーが存在する場合は、以下の手順を実行します。

    e. 赤いひびの入ったハート型のアイコンを探して、同期されていないコンポーネントを見つけます (下図を参照)。

    f. 右端のコンポーネント (通常はポッド) を開いて、[ログ] タブをクリックします。[ログ] には、ポッド障害の原因を示すエラー メッセージが含まれます。

    g. 未解決の設定の問題を解決したら、ホーム ページに戻り、UiPath アプリケーションの [同期] ボタンをクリックします。

 

クラスターをアンインストールする方法


クラスターで実行されている Kubernetes に固有の問題が発生した場合は、rke2 クラスターを直接アンインストールできます。 そのためには、以下の手順に従ってください。

  1. インストール プロファイルに応じて、次のいずれかのコマンドを実行します。
    1.1.オンライン設定では、次のスクリプトをクラスターの各ノードで管理者特権 (つまり、sudo) で実行します。これによりノードがアンインストールされます。
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 オフライン設定では、次のスクリプトをクラスターの各ノードで管理者特権 (つまり、sudo) で実行します。これによりノードがアンインストールされます。

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."
  1. アンインストール後、ノードを再起動します。

🚧

重要

ノードの 1 つをクラスターからアンインストールする場合は、kubectl delete node <node_name> コマンドを実行する必要があります。これにより、クラスターからノードが削除されます。

 

オフライン成果物をクリーンアップしてディスク領域を改善する方法


オフライン インストールを実行する場合、一般に、使用されるオフライン成果物により、大きなディスク サイズが必要になります。

インストールが完了したら、これらのローカル成果物を削除できます。削除できなかった場合、クラスター操作時に不要なディスク容量の圧迫が発生する可能性があります。

次のコマンドを使用して、インストールが実行されたプライマリ サーバーでクリーンアップを実行できます。

  1. 次のコマンドを使用して、podman によってローカル コンテナー ストレージに読み込まれたすべてのイメージを削除します。
podman image rm -af
  1. 次に、フラグ --offline-tmp-folder で使用された一時オフライン フォルダーを削除します。このパラメーターの既定値は /tmp です。
rm -rf /path/to/temp/folder

 

TLS 1.0 および 1.1 を無効化する方法

TLS 1.0 および 1.1 は非推奨です。これらのバージョンをクリーン インストールで有効化するとセキュリティ リスクをもたらす可能性があります。TLS 1.2 以降にアップグレードし、これより古いバージョンはサーバーで有効化しないことを強くお勧めします。

TLS 1.2 をクリーン インストールで有効化するには、次のコマンドを実行します。

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

 

一般的な問題


RHEL 8.4 OS でオフライン インストールを実行できない


説明

RHEL 8.4 をインストールして、podman を必要とするオフライン インストールを実行する場合、次の問題が発生する可能性があります。これらの問題は、podman および一緒にインストールされる OS に固有の問題です。以下の 2 つを参照してください。

潜在的な問題

  • クラスターに以下の両方をインストールすることはできない
    • 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
  • パッケージ cockpit-podman-29-2.module+el8.4.0+10607+f4da7515.noarch には podman >= 1.3.0 が必要であるが、どのプロバイダーもインストールできない
  • ジョブの最適な候補をインストールできない
  • インストール済みパッケージ cockpit-podman-29-2.module+el8.4.0+10607+f4da7515.noarch に関する問題

潜在的な問題

  • パッケージ podman-3.0.1-6.module+el8.4.0+10607+f4da7515.x86_64 には containernetworking-plugins >= 0.8.1-1 が必要であるが、どのプロバイダーもインストールできない
  • 以下の両方をインストールすることはできない
    • 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
  • パッケージ podman-catatonit-3.0.1-6.module+el8.4.0+10607+f4da7515.x86_64 には podman = 3.0.1-6.module+el8.4.0+10607+f4da7515 が必要であるが、どのプロバイダーもインストールできない
  • ジョブの最適な候補をインストールできない
  • インストール済みパッケージ podman-catatonit-3.0.1-6.module+el8.4.0+10607+f4da7515.x86_64 に関する問題
    (コマンド ラインに --allowerasing を追加して競合するパッケージを置き換えるか、--skip-broken を追加してアンインストール可能なパッケージをスキップするか、--nobest を追加して最適な候補パッケージ以外を使用します)

解決策

podman の現在のバージョンを削除して、Automation Suite が必要なバージョンをインストールできるようにする必要があります。

  1. yum remove podman コマンドを使用して、podman の現在のバージョンを削除します。

  2. 現在のバージョンを削除した後、インストーラーを再実行すると、正しいバージョンがインストールされます。

 

バイナリがないため、オフライン インストールが失敗する


説明

オフライン インストール時に、ファブリック ステージで、次のエラー メッセージが表示されて実行が失敗します。

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

解決策

podman 設定 /etc/containers/storage.conf から、mount_program キーを含む行を削除する必要があります。
コメント アウトするのではなく、行を削除してください。

 

サンドボックス イメージを取得できない


説明

次のサンドボックス イメージを取得しようとすると、特定のエラー メッセージが表示されることがあります。index.docker.io/rancher/pause3.2

これは、オフライン インストールで発生します。

解決策

rke2-server または rke2-agent (ポッドがスケジュールされているマシンがサーバーかエージェントかによって異なります) を再起動します。

ポッドがスケジュールされているノードを確認するには、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

 

SQL 接続文字列の検証エラー


説明

次のような、接続文字列に関連するエラーが表示されることがあります。

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

このエラーは、すべての資格情報が正しい場合でも表示されます。接続文字列の検証に失敗しました。

解決策

接続文字列が次の構造を持つことを確認します。

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;

📘

注:

User Id は大文字と小文字を区別します。

 

ポッドが ArgoCD UI に表示されない


説明

ArgoCD UI にポッドが表示されず、アプリケーションおよび対応するデプロイのみが表示されることがあります。詳しくは、次の画像をご覧ください。

17631763

いずれかのデプロイをクリックすると、Unable to load data: EOF というエラーが表示されます。

19201920

解決策

この問題を修正するには、ArgoCD 名前空間からすべての Redis レプリカを削除して、再び戻ってくるのを待ちます。

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

 

オフライン インストールでの証明書の問題


説明

証明書が不明な機関によって署名されているというエラーが表示されることがあります。

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

解決策

rootCA とサーバー証明書の両方が、マシンの信頼されたストアに格納されている必要があります。

調べるには、次のコマンドを実行します。

[[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

指定した証明書が、これらのコマンドの出力に含まれている必要があります。

または、次のコマンドを実行します。

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

出力のサブジェクトの別名に完全修飾ドメイン名があることを確認します。

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

次のように CA 証明書を更新できます。

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

 

バンドルのダウンロード中のエラー


説明

ドキュメントに、バンドルをダウンロードするオプションとして wget が表示されています。サイズが大きいため、接続が中断され、回復しない可能性があります。

解決策

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 エラー


Rook Ceph または Looker ポッドが Init ステートでスタックする

説明

ポッドに PVC をアタッチするのに必要なボリュームがないために、ノードの再起動時に問題が発生すると、Looker または Rook Ceph ポッドが Init ステートでスタックすることがあります。

次のコマンドを実行して、問題が本当に Longhorn に関連しているかを確認します。

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\""))'

Longhorn に関連している場合、このコマンドは問題の影響を受けるポッド名のリストを返します。コマンドから何も返されない場合、問題の原因は別にあります。

解決策

前のコマンドから空でない出力が返された場合は、次のスクリプトを実行して、問題のあるポッドを修正します。

#!/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

 

永続ボリュームを作成できない

説明

Longhorn は正常にインストールされますが、永続ボリュームを作成できません。

解決策

コマンド lsmod | grep <module_name> を使用して、カーネル モジュールがクラスターに正常に読み込まれているかどうかを確認します。
<module_name> を以下の各カーネル モジュールに置き換えます。

  • libiscsi_tcp
  • libiscsi
  • iscsi_tcp
  • scsi_transport_iscsi

欠落しているモジュールを読み込みます。

 

rke2-coredns-rke2-coredns-autoscaler ポッドが CrashLoopBackOff になる


説明

ノードの再起動後に、rke2-coredns-rke2-coredns-autoscaler が CrashLoopBackOff になることがあります。このことは、Automation Suite に影響しません。

解決策

次のコマンドを使用して、CrashLoopBackOff になっている rke2-coredns-rke2-coredns-autoscaler ポッドを削除します。kubectl delete pod <pod name> -n kube-system

 

Redis プローブの障害


説明

ノード ID ファイルが存在しない場合、Redis プローブは失敗することがあります。これは、ポッドがまだブートストラップされていない場合に発生する可能性があります。

この問題を自動的に修正するリカバリー ジョブがあります。このジョブの実行時には、以下の手順を実行しないでください。

Redis Enterprise クラスターが半数以上のノードとの接続を失うと (ノードのエラーまたはネットワーク分断により)、クラスターはクライアント接続への応答を停止します。ポッドも、クラスターへの再参加に失敗します。

解決策

  1. 次のコマンドを使用して、Redis クラスターとデータベースを削除します。
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
  1. ArgoCD UI に移動して、redis-cluster アプリケーションを同期します。

 

RKE2 サーバーの起動に失敗する


説明

サーバーを起動できません。RKE2 が適切に起動しない理由は複数あり、通常はログで確認できます。

解決策

次のコマンドを使用してログを確認します。

journalctl -u rke2-server

考えられる理由 (ログに基づく): クラスター内のラーナー メンバーの数が多すぎる。

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

次の手順を実行します。

  1. 通常の状況では、十分に時間がある場合、ノードはフル メンバーになるはずです。
  2. アンインストール/再インストールのサイクルを試行できます。

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

 

停止されたノードに対してノードのドレインが行われない


説明

クラスター内でノードが停止し、15 分後に対応するポッドが利用可能なノードに再スケジュールされない場合は、次のスクリプトを実行して手動でノードのドレインを行います。

#!/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;

 

Istio ログを有効化する


Istio をデバッグするには、ログを有効化する必要があります。そのためには、以下の手順を実行します。

  1. 次のコマンドを実行して、istio-ingressgateway ポッドを見つけます。ゲートウェイ ポッド名をコピーします。istio-ingressgateway-r4mbx のようになります。
kubectl -n istio-system get pods
  1. 次のコマンドを実行して、ゲートウェイ ポッド シェルを開きます。
kubectl exec -it -n istio-system istio-ingressgateway-r4mbx bash
  1. 次のコマンドを実行して、デバッグ レベルのログを有効化します。
curl -X POST http://localhost:15000/logging?level=debug
  1. サーバー ノードから次のコマンドを実行します。
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

 

UiPath 名前空間でシークレットが見つからない


説明

サービスのインストールに失敗し、kubectl -n uipath get pods のチェックで失敗したポッドが返された場合は、以下の手順を実行します。

解決策

  1. kubectl -n uipath describe pod <pod-name> を確認して、見つからないシークレットを探します。
  2. シークレットが見つからない場合は、資格情報マネージャー ジョブのログを探して、失敗したかどうかを確認します。
  3. 資格情報マネージャー ジョブが失敗し、kubectl get pods -n rook-ceph|grep rook-ceph-tool が複数のポッドを返す場合は、次の操作を実行します。
    a. 実行されていない rook-ceph-tool を削除します。
    b. ArgoCD UI に移動して、sfcore アプリケーションを同期します。
    c. ジョブが完了したら、資格情報マネージャー ジョブのログですべてのシークレットが作成されているかどうかを確認します。
    d. uipath アプリケーションを同期します。

 

移行後にログインできない


説明

この問題は、スタンドアロン製品から Automation Suite への移行に影響することがあります。次のエラー メッセージが表示され、ログインできなくなります。Cannot find client details

解決策

この問題を修正するには、まず uipath アプリを再同期してから、ArgoCD で platform アプリを同期する必要があります。

 

初期インストール後、ArgoCD アプリが Progressing ステートになる


説明

クラスターのステートが helm リポジトリで定義されているステートから逸脱している場合、 argocd はステートを同期しようとし、毎分照合が行われます。この問題が発生すると、ArgoCD アプリは Progressing ステートになります。

解決策

これは、ArgoCD の予期される動作であり、アプリケーションには一切影響しません。

 

Automation Suite で backlog_wait_time を 1 に設定する必要がある


説明

backlog_wait_time1 に設定されていない場合、監査イベントにより、不安定性 (システムのフリーズ) が生じることがあります。
For more details, see this issue description.

解決策

Automation Suite requires backlog_wait_time to be set 1 エラー メッセージが表示されてインストーラーが失敗した場合は、次の手順を実行して backlog_wait_time1 に設定します。

  1. /etc/audit/rules.d/audit.rules ファイルに --backlog_wait_time 1 を追加して、backlog_wait_time1 に設定します。
  2. ノードを再起動します。
  3. ノードで sudo auditctl -s | grep "backlog_wait_time" を実行して、auditctlbacklog_wait_time 値が 1 に設定されているかどうかを確認します。

 

ObjectStore PVC のサイズを変更できない


説明

この問題は、次のエラー メッセージが表示されて objectstore resize-pvc 操作が失敗した場合に発生します。

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

解決策

この問題を修正するには、次の手順に従います。

  1. 次のスクリプトを手動で実行します。
#!/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
  1. objectstore resize-pvc コマンドを再実行します。

 

証明書の更新後のエラー


説明

この問題は、証明書の更新手順が内部で失敗した場合に発生します。Automation Suite または Orchestrator にアクセスできないことがあります。

Error

18131813

解決策

  1. 任意のサーバー ノードから、以下のコマンドを実行します。
export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
export PATH=$PATH:/var/lib/rancher/rke2/bin

kubectl -n uipath rollout restart deployments
  1. 上記のコマンドが成功するまで待機してから、以下のコマンドを実行して前のコマンドのステータスを確認します。
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"

上記のコマンドの実行が完了したら、Automation Suite や Orchestrator にアクセスできます。

 

Unexpected inconsistency; run fsck manually


Automation Suite のインストールまたはアップグレード中に MongoDB ポッドが PVC ポッドにマウントできない場合、次のエラー メッセージが表示されます。
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

11881188

回復の手順

上記のエラーが発生する場合は、次の回復手順に従います。

  1. 次のコマンドを実行して、システムに SSH 接続します。
ssh <user>@<node-ip>
  1. PVC のイベントをチェックし、この問題がファイル エラーによる PVC のマウント エラーに関連していることを確認します。このためには、以下のコマンドを実行します。
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
  1. イベントに示されている PVC ボリュームを確認し、fsck コマンドを実行します。
fsck -a <pvc-volume-name>
Eg - fsck -a /dev/longhorn/pvc-5abe3c8f-7422-44da-9132-92be5641150a
  1. 失敗した MongoDB ポッドを削除して、PVC に適切にマウントします。
kubectl delete pod <pod-name> -n mongodb

 

Missing self-heal-operator and sf-k8-utils repo

説明

This issue causes workloads to go into ImagePullBackOff or ErrImagePull state with the following error:

Failed to pull image "sf-k8-utils-rhel:<tag>": rpc error: code = Unknown desc = failed to pull and unpack image "docker.io/library/sf-k8-utils-rhel:<tag>": failed to resolve reference "docker.io/library/sf-k8-utils-rhel:<tag>": failed to do request: Head "https://localhost:30071/v2/library/sf-k8-utils-rhel/manifests/<tag>?ns=docker.io": dial tcp [::1]:30071: connect: connection refused
OR
Failed to pull image "self-heal-operator:<tag>": rpc error: code = Unknown desc = failed to pull and unpack image "docker.io/library/self-heal-operator:<tag>": failed to resolve reference "docker.io/library/self-heal-operator:<tag>": failed to do request: Head "https://localhost:30071/v2/library/self-heal-operator/manifests/<tag>?ns=docker.io": dial tcp [::1]:30071: connect: connection refused

解決策

To fix this issue, run the following script from all the nodes in the cluster one by one.

Click for the fix_image_project_id.sh script
#!/bin/bash

export KUBECONFIG=${KUBECONFIG:-/etc/rancher/rke2/rke2.yaml}
export PATH=$PATH:/var/lib/rancher/rke2/bin:${SCRIPT_DIR}/Fabric_Installer/bin:/usr/local/bin

function get_docker_registry_url() {
  local rancher_registries_file="/etc/rancher/rke2/registries.yaml"
  config=$(cat < ${rancher_registries_file} | grep -A1 "configs:"|tail -n1| awk '{print $0}'|tr -d ' '|tr -d '"')
  url="${config::-1}"
  echo "${url}"
}

function get_docker_registry_credentials() {
  local key="$1"
  local rancher_registries_file="/etc/rancher/rke2/registries.yaml"
  value=$(cat < ${rancher_registries_file} | grep "$key:" | cut -d: -f2 | xargs)
  echo "${value}"
}

function get_cluster_config() {
  local key=$1
  # the go template if prevents it from printing <no-value> instead of empty strings
  value=$(kubectl get secret service-cluster-configurations \
    -o "go-template={{if index .data \"${key^^}\"}}{{index .data \"${key^^}\"}}{{end}}" \
    -n uipath-infra --ignore-not-found) || true

  echo -n "$(base64 -d <<<"$value")"
}

function update_image_tag() {
    username=$(get_docker_registry_credentials username)
    password=$(get_docker_registry_credentials password)
    url=$(get_docker_registry_url)

    images=(self-heal-operator sf-k8-utils-rhel)
    for image in ${images[@]}; do
        echo "Start checking available $image tag"
        tag=$(curl -u $username:$password -X GET https://${url}/v2/$image/tags/list -k -q -s | jq -rc .tags[0] )
        if [[ "${tag}" != "null" ]]; then
            echo "$image with tag ${tag} found..."
            podman login ${url} --username $username --password $password --tls-verify=false
            podman pull ${url}/${image}:${tag} --tls-verify=false
            podman tag ${url}/${image}:${tag} ${url}/uipath/${image}:${tag}
            podman tag ${url}/${image}:${tag} ${url}/library/${image}:${tag}
            podman push ${url}/uipath/${image}:${tag} --tls-verify=false
            podman push ${url}/library/${image}:${tag} --tls-verify=false
            echo "$image is retag and push to docker registry"
        else
            echo "no tag available for $image"
        fi
    done
}

function validate_rke2_registry_config() {
  local rancher_registries_file="/etc/rancher/rke2/registries.yaml"
  local endpoint_present="false"
  endpoint=$(cat < ${rancher_registries_file} | grep -A2 "docker.io:" | grep -A1 "endpoint:"|tail -n1|xargs)

  if [[ -n "${endpoint}" ]]; then
    endpoint_present="true"
  fi

  echo "${endpoint_present}"
}

function update_rke2_registry_config() {
   local DOCKER_REGISTRY_URL=$(get_docker_registry_url)
   local DOCKER_REGISTRY_LOCAL_USERNAME=$(get_docker_registry_credentials username)
   local DOCKER_REGISTRY_LOCAL_PASSWORD=$(get_docker_registry_credentials password)
   local registriesPath="/etc/rancher/rke2/registries.yaml"
   local DOCKER_REGISTRY_NODEPORT=30071

   echo "Create temp file with name ${registriesPath}_tmp"
   cp -r ${registriesPath} ${registriesPath}_tmp

   echo "Start updating ${registriesPath}"

   cat > "${registriesPath}" <<EOF
mirrors:
  docker-registry.docker-registry.svc.cluster.local:5000:
    endpoint:
      - "https://${DOCKER_REGISTRY_URL}"
  docker.io:
    endpoint:
      - "https://${DOCKER_REGISTRY_URL}"
  ${DOCKER_REGISTRY_URL}:
    endpoint:
      - "https://${DOCKER_REGISTRY_URL}"
configs:
  "localhost:${DOCKER_REGISTRY_NODEPORT}":
    tls:
      insecure_skip_verify: true
    auth:
      username: ${DOCKER_REGISTRY_LOCAL_USERNAME}
      password: ${DOCKER_REGISTRY_LOCAL_PASSWORD}
EOF
}

function is_server_node() {
    [[ "$(systemctl is-enabled rke2-server 2>>/dev/null)" == "enabled" ]] && echo -n "true" && return
    echo "false"
}

function main() {
    local is_server_node=$(is_server_node)
    local install_type=$(get_cluster_config "INSTALL_TYPE")
    if [[ "${install_type}" != "offline" ]]; then
        echo "This script is compatible with only offline cluster. Current cluster install_type=${install_type}"
        exit 0
    fi

    if [[ "${is_server_node}" == "true" ]]; then
        echo "current node is identified as server node. Updating image tag"
        update_image_tag
    else
        echo "current node is identified as agent node."
    fi
    
    rke2_registry_config_is_valid=$(validate_rke2_registry_config)
    if [[ "${rke2_registry_config_is_valid}" == "false" ]]; then
      echo "start updating rke2 config"
      update_rke2_registry_config
      if [[ "${is_server_node}" == "true" ]]; then
        echo "Registry configuration is updated. Restarting service using command: systemctl restart rke2-server"
        systemctl restart rke2-server.service
      else
        echo "Registry configuration is updated. Restarting service using command: systemctl restart rke2-agent"
        systemctl restart rke2-agent.service
      fi
    else
      echo "rke2 config update is not required"
    fi
    
}

main

📘

The fix_image_project_id.sh script restarts the Kubernetes server (rke2 service) and all the workloads running on the nodes.

Running the fix_image_project_id.sh script is required only if you use Automation Suite 2021.10.0, 2021.10.1, 2021.10.2, 2021.10.3, or 2021.10.4.

 

Degraded MongoDB or business applications after cluster restore


説明

Occasionally, after cluster restore/rollback to version 2022.4.x or 2021.10.x, an issue causes MongoDB or business applications (Apps) pods to get stuck in the initial state. This happens because the volume required for attaching the PVC to a pod is missing.

解決策

  1. Verify if the problem is indeed related to MongoDB volume attachment issue:
# fetch all mongodb pods
kubectl -n mongodb get pods 
#describe pods stuck in init state
#kubectl -n mongodb describe pods mongodb-replica-set-<replica index number>
kubectl -n mongodb describe pods mongodb-replica-set-0

If the issue is related to the MongoDB volume attachment, the following events are displayed:

Events:
  Type     Reason              Age                   From                     Message
  ----     ------              ----                  ----                     -------
  Warning  FailedAttachVolume  3m9s (x65 over 133m)  attachdetach-controller  AttachVolume.Attach failed for volume "pvc-66897693-e52d-4b89-aac6-ca0cc5ae9e07" : rpc error: code = Aborted desc = volume pvc-66897693-e52d-4b89-aac6-ca0cc5ae9e07 is not ready for workloads
  Warning  FailedMount         103s (x50 over 112m)  kubelet                  (combined from similar events): Unable to attach or mount volumes: unmounted volumes=[logs-volume], unattached volumes=[hooks mongodb-replica-set-keyfile tls-secret data-volume healthstatus tls-ca kube-api-access-45qcl agent-scripts logs-volume automation-config]: timed out waiting for the condition
  1. Fix the problematic MongoDB pods by running the following script:
Click for the restore_mongodb.sh script
#!/bin/bash

set -eu


FAILED_PVC_LIST=""
STORAGE_CLASS_SINGLE_REPLICA="longhorn-backup-single-replica"
STORAGE_CLASS="longhorn-backup"
LOCAL_RESTORE_PATH="restoredata"
mkdir -p ${LOCAL_RESTORE_PATH}
export LOCAL_RESTORE_PATH="${LOCAL_RESTORE_PATH}"


function delete_pvc_resources(){
  local pv_name=$1
  local volumeattachment_name=$2

  echo "deleting pv & volumes forcefully"
  delete_pv_forcefully "${pv_name}"
  sleep 2
  delete_longhornvolume_forcefully "${pv_name}"
  sleep 2
  if [ -n "${volumeattachment_name}" ]; then
    echo "deleting volumeattachments forcefully"
    delete_volumeattachment_forcefully "${volumeattachment_name}"
    sleep 5
  fi
}

function delete_longhornvolume_forcefully() {
  local pv_name=$1
  
  if ! kubectl -n longhorn-system get volumes.longhorn.io "${pv_name}" >/dev/null 2>&1 ; then
    echo "Volume ${pv_name} not found, skip deletion."
    return
  fi

  kubectl -n longhorn-system delete volumes.longhorn.io "${pv_name}" --grace-period=0 --force &
  local success=0
  local try=0
  local maxtry=10
  while (( try < maxtry )); do
    local result=""
    # update finaluzer field to null
    result=$(kubectl -n longhorn-system get volumes.longhorn.io "${pv_name}" -o=json | jq '.metadata.finalizers = null' | kubectl apply -f -) || true
    echo "${result}"

    result=$(kubectl -n longhorn-system get volumes.longhorn.io "${pv_name}")|| true
    echo "${result}"
    if [[ -z "${result}" ]]; then
      success=1
      break;
    fi
    kubectl -n longhorn-system delete volumes.longhorn.io "${pv_name}" --grace-period=0 --force &
    echo "Waiting to delete volume ${pv_name} ${try}/${maxtry}..."; sleep 10
    try=$(( try + 1 ))
  done

   if [ "${success}" -eq 0 ]; then
    echo "Failed to delete volume ${pv_name}."
  fi

}

function delete_pv_forcefully() {
  local pv_name=$1

  kubectl delete pv "${pv_name}" --grace-period=0 --force &

  local success=0
  local try=0
  local maxtry=10
  while (( try < maxtry )); do
    # update finaluzer field to null
    result=$(kubectl get pv "${pv_name}" -o=json | jq '.metadata.finalizers = null' | kubectl apply -f -) || true
    echo "${result}"

    result=$(kubectl get pv "${pv_name}")|| true
    echo "${result}"
    if [[ -z "${result}" ]]; then
      success=1
      break;
    fi
    kubectl delete pv "${pv_name}" --grace-period=0 --force &
    echo "Waiting to delete pv ${pv_name} ${try}/${maxtry}..."; sleep 10
    try=$(( try + 1 ))
  done

  if [ "${success}" -eq 0 ]; then
    echo "Failed to delete pv ${pv_name}."
  fi
}

function validate_pv_backup_available(){
  local pv_name=$1
  local validate_pv_backup_available_resp=0
  local backup_resp=""
  local resp_status_code=""
  local resp_message=""

  local try=0
  local maxtry=3
  while (( try != maxtry )) ; do
    backup_resp=$(curl --noproxy "*" "${LONGHORN_URL}/v1/backupvolumes/${pv_name}?") || true
    echo "Backup Response: ${backup_resp}"
    if { [ -n "${backup_resp}" ] && [ "${backup_resp}" != " " ]; }; then
      resp_status_code=$(echo "${backup_resp}"| jq -c ".status")
      resp_message=$(echo "${backup_resp}"| jq -c ".message")
      if [[ -n "${resp_status_code}" && "${resp_status_code}" != " " && "${resp_status_code}" != "null" && (( resp_status_code -gt 200 )) ]] ; then
        validate_pv_backup_available_resp=0
      else
        resp_message=$(echo "${backup_resp}"| jq -c ".messages.error")
        if { [ -z "${resp_message}" ] || [ "${resp_message}" = "null" ]; }; then
          echo "PVC Backup is available for ${pv_name}"
          # shellcheck disable=SC2034
          validate_pv_backup_available_resp=1
          break;
        fi
      fi
    fi
    try=$((try+1))
    sleep 10
  done
  export IS_BACKUP_AVAILABLE="${validate_pv_backup_available_resp}"
}

function store_pvc_resources(){
  local pvc_name=$1
  local namespace=$2
  local pv_name=$3
  local volumeattachment_name=$4

  if [[ -n "${volumeattachment_name}" && "${volumeattachment_name}" != " " ]]; then
    result=$(kubectl get volumeattachments "${volumeattachment_name}" -o json > "${LOCAL_RESTORE_PATH}/${volumeattachment_name}".json) || true
    echo "${result}"
  fi

  kubectl get pv "${pv_name}" -o json > "${LOCAL_RESTORE_PATH}/${pv_name}"-pv.json
  kubectl -n longhorn-system get volumes.longhorn.io "${pv_name}" -o json > "${LOCAL_RESTORE_PATH}/${pv_name}"-volume.json
  kubectl get pvc "${pvc_name}" -n "${namespace}" -o json > "${LOCAL_RESTORE_PATH}/${pvc_name}"-pvc.json
}

function wait_pvc_bound() {
  local namespace=$1
  local pvc_name=$2

  try=0
  maxtry=30
  while (( try < maxtry )); do
    local status=""
    status=$(kubectl -n "${namespace}" get pvc "${pvc_name}" -o json| jq -r ".status | select( has(\"phase\")).phase")
    if [[ "${status}"  == "Bound" ]]; then
      echo "PVC ${pvc_name} Bouned successfully."
      break;
    fi
    echo "waiting for PVC to bound...${try}/${maxtry}"; sleep 30
    try=$((try+1))
  done
}

function create_volume() {
  local pv_name=$1
  local backup_path=$2
  local response
  create_volume_status="succeed"
  echo "Creating Volume with PV: ${pv_name} and BackupPath: ${backup_path}"
  local accessmode
  local replicacount
  accessmode=$(< "${LOCAL_RESTORE_PATH}/${pv_name}-volume.json" jq -r ".spec.accessMode")
  replicacount=$(< "${LOCAL_RESTORE_PATH}/${pv_name}-volume.json" jq -r ".spec.numberOfReplicas")

  # create volume from backup pv
  response=$(curl --noproxy "*" "${LONGHORN_URL}/v1/volumes" -H 'Accept: application/json' -H 'Content-Type: application/json;charset=UTF-8' --data-raw "{\"name\":\"${pv_name}\", \"accessMode\":\"${accessmode}\", \"fromBackup\": \"${backup_path}\", \"numberOfReplicas\": ${replicacount}}")

  sleep 5

  if [[ -n "${response}" && "${response}" != "null" && "${response}" != " " && -n $(echo "${response}"|jq -r ".id") ]]; then
  # wait for volume to be detached , max wait 4hr
    local try=0
    local maxtry=480
    local success=0
    while (( try < maxtry ));do
      status=$(kubectl -n longhorn-system get volumes.longhorn.io "${pv_name}"  -o json |jq -r ".status.state") || true
      echo "volume ${pv_name} status: ${status}"
      if [[ "${status}" == "detached" ]]; then
        # update label
        kubectl -n longhorn-system label volumes.longhorn.io/"${pv_name}" recurring-job-group.longhorn.io/uipath-backup=enabled
        success=1
        echo "Volume ready to use"
        break
      fi
      echo "waiting for volume to be ready to use${try}/${maxtry}..."; sleep 30
      restore_status_url="${LONGHORN_URL}/v1/volumes/${pv_name}?action=snapshotList"
      try=$(( try + 1 ))
    done

    if [ "${success}" -eq 0 ]; then
      create_volume_status="failed"
      echo "${pv_name} Volume is not ready to use with status ${status}"
    fi
  else
    create_volume_status="failed"
    kubectl create -f "${LOCAL_RESTORE_PATH}/${pv_name}"-volume.json || true
    echo "${pv_name} Volume creation failed ${response} "
  fi
  echo "${create_volume_status}"
}

function restore_with_backupvolume() {
  local pvc_name=$1
  local namespace=$2
  local pv_name=$3
  local volumeattachment_name=$4
  local backup_path=$5
  create_volume_status="succeed"
  store_pvc_resources "${pvc_name}" "${namespace}" "${pv_name}" "${volumeattachment_name}"
  sleep 5
  delete_pvc_resources "${pv_name}" "${volumeattachment_name}"
  sleep 5
  create_volume "${pv_name}" "${backup_path}"
  sleep 10

  kubectl create -f "${LOCAL_RESTORE_PATH}/${pv_name}"-pv.json
  if [[ -n "${create_volume_status}" && "${create_volume_status}" != "succeed" ]]; then
    echo "Backup volume restore failed for pvc ${pvc_name} in namespace ${namespace}"
    restore_pvc_status="failed"
  else 
    local pvc_uid=""
    pvc_uid=$(kubectl -n "${namespace}" get pvc "${pvc_name}" -o json| jq -r ".metadata.uid")

    # update pv with pvc uid
    kubectl patch pv "${pv_name}" --type json -p "[{\"op\": \"add\", \"path\": \"/spec/claimRef/uid\", \"value\": \"${pvc_uid}\"}]"

    wait_pvc_bound "${namespace}" "${pvc_name}"
    echo "${result}"
  fi
  echo ${restore_pvc_status}
}

function restore_pvc(){
  local pvc_name=$1
  local namespace=$2
  local pv_name=$3
  local volumeattachment_name=$4
  local backup_path=$5
  restore_pvc_status="succeed"
  restore_with_backupvolume "${pvc_name}" "${namespace}" "${pv_name}" "${volumeattachment_name}" "${backup_path}"
  echo ${restore_pvc_status}
  # attach_volume "${pv_name}"
}

function get_backup_list_by_pvname(){
  local pv_name=$1
  local get_backup_list_by_pvname_resp=""
  local backup_list_response=""

  local try=0
  local maxtry=3
  while (( try != maxtry )) ; do

    backup_list_response=$(curl --noproxy "*" "${LONGHORN_URL}/v1/backupvolumes/${pv_name}?action=backupList" -X 'POST' -H 'Content-Length: 0' -H 'Accept: application/json')
    if [[ -n "${backup_list_response}" && "${backup_list_response}" != " " && -n $( echo "${backup_list_response}"|jq ".data" )  && -n $( echo "${backup_list_response}"|jq ".data[]" ) ]]; then
      echo "Backup List Response: ${backup_list_response}"
      # pick first backup data with url non empty
      # shellcheck disable=SC2034
      get_backup_list_by_pvname_resp=$(echo "${backup_list_response}"|jq -c '[.data[]|select(.url | . != null and . != "")][0]')
      break;
    fi
    try=$((try+1))
    sleep 10
  done
  export PV_BACKUP_PATH="${get_backup_list_by_pvname_resp}"
}

function get_pvc_resources() {

  get_pvc_resources_resp=""

  local PVC_NAME=$1
  local PVC_NAMESPACE=$2

  # PV have one to one mapping with PVC
  PV_NAME=$(kubectl -n "${PVC_NAMESPACE}" get pvc "${PVC_NAME}" -o json|jq -r ".spec.volumeName")

  VOLUME_ATTACHMENT_LIST=$(kubectl get volumeattachments -n "${PVC_NAMESPACE}" -o=json|jq -c ".items[]|\
{name: .metadata.name, pvClaimName:.spec.source| select( has (\"persistentVolumeName\")).persistentVolumeName}")

  VOLUME_ATTACHMENT_NAME=""
  for VOLUME_ATTACHMENT in ${VOLUME_ATTACHMENT_LIST};
  do
    PV_CLAIM_NAME=$(echo "${VOLUME_ATTACHMENT}"|jq -r ".pvClaimName")
    if [[ "${PV_NAME}" = "${PV_CLAIM_NAME}" ]]; then
      VOLUME_ATTACHMENT_NAME=$(echo "${VOLUME_ATTACHMENT}"|jq -r ".name")
      break;
    fi
  done

  BACKUP_PATH=""
  validate_pv_backup_available "${PV_NAME}"
  local is_backup_available=${IS_BACKUP_AVAILABLE:- 0}
  unset IS_BACKUP_AVAILABLE

  if [ "${is_backup_available}" -eq 1 ]; then
    echo "Backup is available for PVC ${PVC_NAME}"

    get_backup_list_by_pvname "${PV_NAME}"
    BACKUP_PATH=$(echo "${PV_BACKUP_PATH}"| jq -r ".url")
    unset PV_BACKUP_PATH
  fi

  get_pvc_resources_resp="{\"pvc_name\": \"${PVC_NAME}\", \"pv_name\": \"${PV_NAME}\", \"volumeattachment_name\": \"${VOLUME_ATTACHMENT_NAME}\", \"backup_path\": \"${BACKUP_PATH}\"}"
  echo "${get_pvc_resources_resp}"
}

function scale_ownerreferences() {
  local ownerReferences=$1
  local namespace=$2
  local replicas=$3

  # no operation required
  if [[ -z "${ownerReferences}" || "${ownerReferences}" == "null" ]]; then
    return
  fi

  ownerReferences=$(echo "${ownerReferences}"| jq -c ".[]")
  for ownerReference in ${ownerReferences};
  do
    echo "Owner: ${ownerReference}"
    local resourceKind
    local resourceName
    resourceKind=$(echo "${ownerReference}"| jq -r ".kind")
    resourceName=$(echo "${ownerReference}"| jq -r ".name")

    if kubectl -n "${namespace}" get "${resourceKind}" "${resourceName}" >/dev/null 2>&1; then
      # scale replicas
      kubectl  -n "${namespace}" patch "${resourceKind}" "${resourceName}" --type json -p "[{\"op\": \"replace\", \"path\": \"/spec/members\", \"value\": ${replicas} }]"
    fi
  done
}

function scale_down_statefulset() {
  local statefulset_name=$1
  local namespace=$2
  local ownerReferences=$3

  echo "Start Scale Down statefulset ${statefulset_name} under namespace ${namespace}..."

  # validate and scale down ownerreference
  scale_ownerreferences "${ownerReferences}" "${namespace}" 0

  local try=0
  local maxtry=30
  success=0
  while (( try != maxtry )) ; do
    result=$(kubectl scale statefulset "${statefulset_name}" --replicas=0 -n "${namespace}") || true
    echo "${result}"
    scaledown=$(kubectl get statefulset "${statefulset_name}" -n "${namespace}"|grep 0/0) || true
    if { [ -n "${scaledown}" ] && [ "${scaledown}" != " " ]; }; then
      echo "Statefulset scaled down successfully."
      success=1
      break
    else
      try=$((try+1))
      echo "waiting for the statefulset ${statefulset_name} to scale down...${try}/${maxtry}";sleep 30
    fi
  done

  if [ ${success} -eq 0 ]; then
    echo "Statefulset ${statefulset_name} scaled down failed"
  fi
}

function scale_up_statefulset() {
  local statefulset_name=$1
  local namespace=$2
  local replica=$3
  local ownerReferences=$4

  # Scale up statefulsets using PVCs
  echo "Start Scale Up statefulset ${statefulset_name}..."

  # validate and scale up ownerreference
  scale_ownerreferences "${ownerReferences}" "${namespace}" "${replica}"

  echo "Waiting to scale up statefulset..."

  local try=1
  local maxtry=15
  local success=0
  while (( try != maxtry )) ; do

    kubectl scale statefulset "${statefulset_name}" --replicas="${replica}" -n "${namespace}"
    kubectl get statefulset "${statefulset_name}" -n "${namespace}"

    scaleup=$(kubectl get statefulset "${statefulset_name}" -n "${namespace}"|grep "${replica}"/"${replica}") || true
    if ! { [ -n "${scaleup}" ] && [ "${scaleup}" != " " ]; }; then
      try=$((try+1))
      echo "waiting for the statefulset ${statefulset_name} to scale up...${try}/${maxtry}"; sleep 30
    else
      echo "Statefulset scaled up successfully."
      success=1
      break
    fi
  done

  if [ ${success} -eq 0 ]; then
    echo "Statefulset scaled up failed ${statefulset_name}."
  fi
}

function restore_pvc_attached_to_statefulsets() {
  local namespace
  namespace="${1}"
  local statefulset_list

  # list of all statefulset using PVC
  statefulset_list=$(kubectl get statefulset -n "${namespace}" -o=json | jq -r ".items[] | select(.spec.volumeClaimTemplates).metadata.name")

  for statefulset_name in ${statefulset_list};
  do
    local replica
    local ownerReferences
    local pvc_restore_failed
    local try=0
    local maxtry=5
    local status="notready"
    pvc_restore_failed=""
    restore_pvc_status=""

    # check if statefulset is reday
    while [[ "${status}" == "notready" ]] && (( try < maxtry )); do
      echo "fetch statefulset ${statefulset_name} metadata...  ${try}/${maxtry}"
      try=$(( try + 1 ))
      replica=$(kubectl get statefulset "${statefulset_name}" -n "${namespace}" -o=json | jq -c ".spec.replicas")

      if [[ "${replica}" != 0 ]]; then
        status="ready"
      else
        echo "statefulset ${statefulset_name} replica is not ready. Wait and retry"; sleep 30
      fi
    done

    if [[ "${status}" != "ready" ]]; then
      echo "Failed to restore pvc for Statefulset ${statefulset_name} in namespace ${namespace}. Please retrigger volume restore step."
    fi

    # Fetch ownerReferences and claim name
    ownerReferences=$(kubectl get statefulset "${statefulset_name}" -n "${namespace}" -o=json | jq -c ".metadata.ownerReferences")
    claimTemplatesName=$(kubectl get statefulset "${statefulset_name}" -n "${namespace}" -o=json | jq -c ".spec | select( has (\"volumeClaimTemplates\") ).volumeClaimTemplates[].metadata.name " | xargs)
    
    echo "Scaling down Statefulset ${statefulset_name} with ${replica} under namespace ${namespace}"
    scale_down_statefulset "${statefulset_name}" "${namespace}" "${ownerReferences}"
    for name in ${claimTemplatesName}; do
      local pvc_prefix
      pvc_prefix="${name}-${statefulset_name}"

      for((i=0;i<"${replica}";i++)); do
        local pvc_name
        pvc_name="${pvc_prefix}-${i}"

        pvc_exist=$(kubectl -n "${namespace}" get pvc "${pvc_name}") || true
        if [[ -z "${pvc_exist}" || "${pvc_exist}" == " " ]]; then
          echo "PVC not available for the statefulset ${statefulset_name}, skipping restore."
          continue;
        fi

        local pvc_storageclass
        pvc_storageclass=$(kubectl -n "${namespace}" get pvc "${pvc_name}" -o json| jq -r ".spec.storageClassName")
        if [[ ! ( "${pvc_storageclass}" == "${STORAGE_CLASS}" || "${pvc_storageclass}" == "${STORAGE_CLASS_SINGLE_REPLICA}" ) ]]; then
          echo "backup not available for pvc ${pvc_name}, storageclass: ${pvc_storageclass} "
          continue;
        fi

        # get pv, volumeattachments for pvc
        get_pvc_resources_resp=""
        get_pvc_resources "${pvc_name}" "${namespace}"

        local pv_name
        local volumeattachment_name
        local backup_path
        pv_name=$(echo "${get_pvc_resources_resp}"| jq -r ".pv_name")
        volumeattachment_name=$(echo "${get_pvc_resources_resp}"| jq -r ".volumeattachment_name")
        backup_path=$(echo "${get_pvc_resources_resp}"| jq -r ".backup_path")
        if [[ -z "${backup_path}" || "${backup_path}" == " " || "${backup_path}" == "null" ]]; then
          pvc_restore_failed="error"
          FAILED_PVC_LIST="${FAILED_PVC_LIST},${pv_name}"
          continue;
        fi

        restore_pvc_status="succeed"
        restore_pvc "${pvc_name}" "${namespace}" "${pv_name}" "${volumeattachment_name}" "${backup_path}"
        if [[ -n "${restore_pvc_status}" && "${restore_pvc_status}" != "succeed" ]]; then
          pvc_restore_failed="error"
          FAILED_PVC_LIST="${FAILED_PVC_LIST},${pv_name}"
          continue;
        fi
      done
    done

    sleep 10
    scale_up_statefulset "${statefulset_name}" "${namespace}" "${replica}" "${ownerReferences}"
    sleep 5

    if [[ -n "${pvc_restore_failed}" && "${pvc_restore_failed}" == "error" ]]; then
        echo "Failed to restore pvc for Statefulset ${statefulset_name} in namespace ${namespace}."
    fi    
  done
}

LONGHORN_URL=$(kubectl -n longhorn-system get svc longhorn-backend -o jsonpath="{.spec.clusterIP}"):9500

restore_pvc_attached_to_statefulsets "mongodb"

 

Unhealthy services after cluster restore or rollback

説明


Following a cluster restore or rollback, AI Center, Orchestrator, Platform, Document Understanding or Task Mining might be unhealthy, with the RabbitMQ pod logs showing the following error:

[[email protected] UiPathAutomationSuite]# k -n rabbitmq logs rabbitmq-server-0
2022-10-29 07:38:49.146614+00:00 [info] <0.9223.362> accepting AMQP connection <0.9223.362> (10.42.1.161:37524 -> 10.42.0.228:5672)
2022-10-29 07:38:49.147411+00:00 [info] <0.9223.362> Connection <0.9223.362> (10.42.1.161:37524 -> 10.42.0.228:5672) has a client-provided name: rabbitConnectionFactory#77049094:2100
2022-10-29 07:38:49.147644+00:00 [erro] <0.9223.362> Error on AMQP connection <0.9223.362> (10.42.1.161:37524 -> 10.42.0.228:5672, state: starting):
2022-10-29 07:38:49.147644+00:00 [erro] <0.9223.362> PLAIN login refused: user 'aicenter-service' - invalid credentials
2022-10-29 07:38:49.147922+00:00 [info] <0.9223.362> closing AMQP connection <0.9223.362> (10.42.1.161:37524 -> 10.42.0.228:5672 - rabbitConnectionFactory#77049094:2100)
2022-10-29 07:38:55.818447+00:00 [info] <0.9533.362> accepting AMQP connection <0.9533.362> (10.42.0.198:45032 -> 10.42.0.228:5672)
2022-10-29 07:38:55.821662+00:00 [info] <0.9533.362> Connection <0.9533.362> (10.42.0.198:45032 -> 10.42.0.228:5672) has a client-provided name: rabbitConnectionFactory#2100d047:4057
2022-10-29 07:38:55.822058+00:00 [erro] <0.9533.362> Error on AMQP connection <0.9533.362> (10.42.0.198:45032 -> 10.42.0.228:5672, state: starting):
2022-10-29 07:38:55.822058+00:00 [erro] <0.9533.362> PLAIN login refused: user 'aicenter-service' - invalid credentials
2022-10-29 07:38:55.822447+00:00 [info] <0.9533.362> closing AMQP connection <0.9533.362> (10.42.0.198:45032 -> 10.42.0.228:5672 - rabbitConnectionFactory#2100d047:4057)

解決策

To fix the issue, take the following steps:

  1. Check if some or all RabbitMQ pods are in CrashLoopBackOff state due to the Mnesia table data write issue. If all pods are running, skip to step 2.
If some pods are in CrashLoopBackOff state, click here for instructions.
  1. Identify which RabbitMQ pods are stuck in CrashLoopBackOff state, and check the RabbitMQ CrashLoopBackOff pod logs:
kubectl -n rabbitmq get pods
kubectl -n rabbitmq logs <CrashLoopBackOff-Pod-Name>
  1. Check the output of the previous commands. If the issue is related to the Mnesia table data write, you should see an error message similar to the following:
Mnesia('[email protected]'): ** ERROR ** (could not write core file: eacces)
 ** FATAL ** Failed to merge schema: Bad cookie in table definition rabbit_user_permission: '[email protected]' = {cstruct,rabbit_user_permission,set,[],['[email protected]','[email protected]','[email protected]'],[],[],0,read_write,false,[],[],false,user_permission,[user_vhost,permission],[],[],[],{{1667351034020261908,-576460752303416575,1},'[email protected]'},{{4,0},{'[email protected]',{1667,351040,418694}}}}, '[email protected]' = {cstruct,rabbit_user_permission,set,[],['rab[email protected]'],[],[],0,read_write,false,[],[],false,user_permission,[user_vhost,permission],[],[],[],{{1667372429216834387,-576460752303417087,1},'[email protected]'},{{2,0},[]}}
  1. To fix the issue, take the following steps:
    1. Find the number of RabbitMQ replicas:
      rabbitmqReplicas=$(kubectl -n rabbitmq get rabbitmqcluster rabbitmq -o json | jq -r '.spec.replicas')
    2. Scale down the RabbitMQ replicas:
      kubectl -n rabbitmq patch rabbitmqcluster rabbitmq -p "{\"spec\":{\"replicas\": 0}}" --type=merge
      kubectl -n rabbitmq scale sts rabbitmq-server --replicas=0
    3. Wait until all RabbitMQ pods are terminated:
      kubectl -n rabbitmq get pod
    4. Find and delete the PVC of the RabbitMQ pod that is stuck in CrashLoopBackOff state:
      kubectl -n rabbitmq get pvc
      kubectl -n rabbitmq delete pvc <crashloopbackupoff_pod_pvc_name>
    5. Scale up the RabbitMQ replicas:
      kubectl -n rabbitmq patch rabbitmqcluster rabbitmq -p "{\"spec\":{\"replicas\": $rabbitmqReplicas}}" --type=merge
    6. Check if all RabbitMQ pods are healthy:
      kubectl -n rabbitmq get pod
  1. Delete the users in RabbitMQ:
kubectl -n rabbitmq exec rabbitmq-server-0 -c rabbitmq -- rabbitmqctl  list_users -s --formatter json | jq '.[]|.user' | grep -v default_user | xargs -I{} kubectl -n rabbitmq exec rabbitmq-server-0 -c rabbitmq -- rabbitmqctl delete_user {}
  1. Delete RabbitMQ application secrets in the UiPath namespace:
kubectl -n uipath get secret --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep -i rabbitmq-secret | xargs -I{} kubectl -n uipath delete secret {}
  1. Delete RabbitMQ application secrets in the RabbitMQ namespace:
kubectl -n rabbitmq get secret --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep -i rabbitmq-secret | xargs -I{} kubectl -n rabbitmq delete secret {}
  1. Sync sfcore application via ArgoCD and wait for the sync to complete:
28682868
  1. Perform a rollout restart on all applications in the UiPath namespace:
kubectl -n uipath rollout restart deploy

 

Identity Server の問題

管理ポータルのタイムアウト期間を設定する

インストール前には、ホストレベルおよび組織レベルの管理ポータルでの認証に使用されるトークンの有効期限を更新できません。そのため、ユーザー セッションはタイムアウトしません。

これらのポータルにタイムアウト期間を設定するには、accessTokenLifetime プロパティを更新します。
次の例では、タイムアウト期間を 86400 秒 (24 時間) に設定します。

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

 

Kerberos の問題


kinit: Cannot find KDC for realm while getting initial credentials

説明

このエラーは、インストール中 (Kerberos 認証を有効化している場合) または kerberos-tgt-update cron ジョブの実行中に、UiPath クラスターが Active Directory サーバーに接続して認証用の Kerberos チケットを取得できないときに発生することがあります。

解決策

Active Directory ドメインをチェックし、ドメインが次のように正しく設定されていて、ルーティング可能であることを確認します。

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

このコマンドがルーティング可能な IP アドレスを返さない場合、Kerberos 認証に必要な Active Directory ドメインは正しく設定されていません。

IT 管理者と協力して Active Directory ドメインを DNS サーバーに追加し、このコマンドがルーティング可能な IP アドレスを返すようにする必要があります。

 

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

説明

このエラーは、失敗したジョブのログ内に、services-preinstall-validations-jobkerberos-jobs-triggerkerberos-tgt-update のいずれかのジョブ名で確認できます。

解決策

Active Directory ユーザーがまだ存在していてアクティブで、パスワードが変更されておらず期限切れではなかったことを確認します。必要に応じて、ユーザーのパスワードをリセットして keytab を再生成します。
また、既定の Kerberos Active Directory ユーザー パラメーター <KERB_DEFAULT_USERNAME>HTTP/<Service Fabric FQDN> の形式で指定してください。

 

GSSAPI operation failed with error: An invalid status code was supplied (Client's credentials have been revoked).

説明

このログは、Kerberos を SQL アクセスに使用していて、SQL 接続がサービス内で失敗するときに見つかる可能性があります。同様に、「kinit: Client's credentials have been revoked while getting initial credential」がジョブ名 services-preinstall-validations-jobkerberos-jobs-triggerkerberos-tgt-update のいずれかに表示される可能性があります。

解決策

これは、keytab の生成に使用した Active Directory ユーザー アカウントが無効化されていることが原因である可能性があります。Active Directory ユーザー アカウントを再度有効化すると、問題は修正されます。

 

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

説明

このログは、Kerberos を SQL アクセスに使用していて、SQL 接続がサービス内で失敗するときに見つかる可能性があります。

解決策

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

説明

これは、UiPath クラスターが最新の Kerberos チケットの取得に失敗した場合に発生します。

解決策

問題を特定するには、ログをチェックして、名前が kerberos-tgt-update で始まる失敗したジョブがあるかどうかを確認します。ログで問題を特定したら、このセクションの関連するトラブルシューティング情報を確認してください。

 

SSPI Provider: Server not found in Kerberos database

解決策

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.

 

Orchestrator に関連する問題


CrashLoopBackOff または 1/2 になっている Orchestrator ポッドが複数の再起動で実行されている


説明

CrashLoopBackOff または 1/2 になっている Orchestrator ポッドが複数の再起動で実行されている場合、エラーはオブジェクト ストレージ プロバイダー Ceph の認証キーに関連している可能性があります。

エラーが Ceph に関連しているかどうかを確認するには、次のコマンドを実行します。

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

このコマンドの出力が、次のいずれかのオプションの出力と似ている場合は、追加のコマンドを実行する必要があります。

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

次のコマンドを実行して、障害が Ceph 認証キーに関係しているかどうかを検証します。

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

上記のコマンドの出力に文字列 Error making request with Error Code InvalidAccessKeyId and Http Status Code Forbidden が含まれている場合、障害は Ceph 認証キーに起因しています。

解決策

次のコマンドを使用して、rook-ceph-configure-script-jobcredential-manager のジョブを再実行します。

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

 

Test Manager に関連する問題


Test Manager のライセンスに関する問題


ユーザーが Automation Suite にログイン中にライセンスが割り当てられた場合、Test Manager を開いた際にライセンスの割り当てが検出されないことがあります。

この問題が発生する場合は、以下の手順に従ってください。

  1. Test Manager に移動します。
  2. ポータルからログアウトします。
  3. 再度ログインします。

 

AI Center に関連する問題


AI Center のスキルのデプロイに関する問題

DU モデル スキルのデプロイが、最初のモデルのデプロイ時に断続的に、デプロイのリスト表示の失敗または不明なエラーで失敗することがあります。回避するには、そのモデルを再度デプロイします。1 回目のデプロイ試行時に画像構築のデプロイ作業のほとんどが完了しているため、2 回目のデプロイには時間がかかりません。DU モデルの最初のデプロイには約 1 - 1.5 時間を要しますが、再度デプロイする際は、これより短時間で完了します。

まれに、クラスターのステートが原因で、スキルのデプロイやパッケージのアップロードなどの非同期操作が長時間スタックしてしまうことがあります。DU スキルのデプロイに 2 - 3 時間以上かかる場合は、よりシンプルなモデル (例: TemplateModel) のデプロイを試みてください。シンプルなモデルを使用した場合でもデプロイに 1 時間以上かかる場合は、軽減策として以下のコマンドを使用した AI Center サービスの再起動を実行します。

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

以下のコマンドを使用して検証し、AI Center の pod が復旧されるまで待機します。

kubectl -n uipath get pods | grep ai-*

成功していれば、上記の pod のステートはすべて「Running」になり、コンテナーのステートは「2/2」になるはずです。

 

Document Understanding に関連する問題


Document Understanding が Automation Suite の画面左側のレールにない


説明

Document Understanding が Automation Suite の左側のレールで見つからない場合は、現在 Document Understanding が Automation Suite の独立したアプリケーションではないため、左側のレールに表示されないということをご承知おきください。

解決策

データ マネージャーのコンポーネントは AI Center の一部であるため、AI Center が有効化されていることを確認してください。

また、下記の公開 URL から、フォーム抽出器、インテリジェント フォーム抽出器 (HandwritingRecognition (手書き文字認識) を含む)、インテリジェント キーワード分類器にアクセスしてください。

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

Studio 内でインテリジェント キーワード分類器、フォーム抽出器、インテリジェント フォーム抽出器を使おうとして Your license can not be validated というエラー メッセージが表示される場合、適切なエンドポイントを入力したことを確認するとともに、API キーとして、cloud.uipath.com からのものではなく、Automation Suite インストールのライセンス対象である Document Understanding 用に生成したものを使用してください。

 

データのラベル付けセッションの作成時の失敗ステータス


説明

AI Center のデータ マネージャーでデータのラベル付けセッションを作成できない場合は、次の手順を実行します。

解決策 1

Document Understanding が適切に有効化されていることをダブルチェックします。インストール前に構成ファイルを更新し、documentunderstanding.enabled を True に設定している必要があります。あるいは、下記のようにインストール後に ArgoCD で更新することもできます。

それを行った後、これを無効化し、データのラベル付け機能を使用するテナントで AI Center を無効化するか、新しいテナントを作成する必要があります。

14921492

解決策 2

構成ファイルまたは ArgoCD で Document Understanding が適切に有効化されている場合に、Document Understanding が DefaultTenant で有効化されないことがあります。これにより、データのラベル付けセッションを作成できません。

この問題を修正するには、テナント上の AI Center を無効化にしてから再度有効化します。再度有効化できるようになるまで、数分かかる場合がある点にご注意ください。

 

ML スキルのデプロイ試行時の失敗ステータス


説明

Document Understanding ML Skill を AI Center に正常にデプロイできない場合は、次の解決策を確認してください。

解決策 1

Automation Suite をオフラインでインストールする場合、Document Understanding のバンドルがダウンロードされインストールされていることをダブルチェックしてください。

バンドルには、AI Center の UI を介して ML パッケージをアップロードした後にモデルが AI Center で適切に動作するためのベース イメージ (例: モデル ライブラリ) が含まれます。

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.

解決策 2

オフライン インストールで Document Understanding バンドルをインストールした場合であっても、エラー メッセージ modulenotfounderror: no module named 'ocr.release'; 'ocr' is not a package に加えて、もう 1 つの問題が発生する可能性があります。

AI Center で Document Understanding OCR ML パッケージを作成する場合、その名前に ocr または OCR を使用できないことに注意してください。これらの名前はパッケージ内のフォルダーと競合します。必ず別の名前を選択してください。

解決策 3

Document Understanding モデル スキルのデプロイが、最初のモデルのデプロイ時に断続的に Failed to list deployment または Unknown Error で失敗することがあります。

回避するには、そのモデルを再度デプロイします。1 回目のデプロイ試行時に画像構築のデプロイ作業のほとんどが完了しているため、2 回目のデプロイには時間がかかりません。Document Understanding ML パッケージの最初のデプロイには約 1 - 1.5 時間を要しますが、再度デプロイする際は、これより短時間で完了します。

 

ArgoCD で移行ジョブが失敗する


説明

ArgoCD で Document Understanding の移行ジョブが失敗する。

解決策

Document Understanding を使用するには、SQL サーバーでフルテキスト検索機能が有効化されている必要があります。有効化されていない場合に移行ジョブが ArgoCD で失敗すると、明示的なエラー メッセージが表示されないままインストールに失敗することがあります。

 

インテリジェント フォーム抽出器による手書き文字認識が機能しない


説明

インテリジェント フォーム抽出器による手書き文字認識が機能しない、または動作が遅い。

解決策 1

インテリジェント フォーム抽出器をオフラインで使用している場合、手書き文字機能を ArgoCD でインストールまたは有効化する前に、構成ファイルで有効化済みであることを確認してください。

ダブルチェックするには、ArgoCD > [Document Understanding] > [App details] > du-services.handwritingEnabled に移動し、これを True に設定します。

エアギャップ シナリオでは、これを実行する前に Document Understanding バンドルをインストールする必要があります。こうしないと、ArgoCD の同期が失敗します。

解決策 2

構成ファイルで手書き文字を有効化していても、依然として同じ問題が発生する場合があります。

各コンテナーが手書き文字に使用できる CPU の最大数は既定で 2 であることを覚えておいてください。手書き文字処理のワークロードが大きい場合は、handwriting.max_cpu_per_pod パラメーターの調整が必要になる可能性があります。このパラメーターはインストール前に構成ファイルで更新するか、ArgoCD で更新できます。

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

 

Insights に関連する問題


Insights のホーム ページに移動すると 404 エラーが表示される


まれに、ルーティング エラーが発生し、Insights のホーム ページに 404 が表示されることがあります。このエラーは、ArgoCD で Insights アプリケーションに移動し、仮想サービス insightsprovisioning-vs を削除することで解決できます。この仮想サービスを表示および削除するために [clear filters to show X additional resources] をクリックする必要が生じることがあります。

1 日前に更新


トラブルシューティング


このページでは、Automation Suite の設定時に発生する可能性のある問題を修正する方法について説明します。

改善の提案は、API リファレンスのページでは制限されています

改善を提案できるのは Markdown の本文コンテンツのみであり、API 仕様に行うことはできません。