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

Automation Suite ではログが生成されるので、インストールエラーをトラブルシューティングする必要がある場合は、いつでもこのログを検索できます。インストール中に発生する問題の詳細はすべて、install-uipath.sh スクリプトを含むディレクトリに保存されたログファイルで確認できます。インストーラーを実行するたびに、install-$(date +'%Y-%m-%dT%H_%M_%S').log の命名規則に則った新しいログファイルが生成されます。このログファイルは、インストールに関連する問題が発生した際にはいつでも確認できます。
If you want to troubleshoot post-installation errors, use the Support Bundle tool.

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

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

Kubernetes へのアクセス権を取得します。

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

on agent nodes:
export KUBECONFIG="/var/lib/rancher/rke2/agent/kubelet.kubeconfig"
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

次のコマンドを使用して、ArgoCD パスワードを取得します。

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

ArgoCD に接続します。
a. https://alm.<fqdn>/:443 に移動します。
b. admin をユーザー名として使用し、手順 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.オンライン設定では、次のスクリプトをクラスターの各ノードで管理者特権 (つまり、sudo) で実行します。これによりノードがアンインストールされます。

function remove_rke2_entry_from_exclude() {
  local current_exclude_list new_exclude_list
  YUM_CONF_FILE=$1
  if [[ ! -s "${YUM_CONF_FILE}" ]];
  then
    # File is empty
    return
  fi
  current_exclude_list=$(grep 'exclude=' "${YUM_CONF_FILE}" | tail -1)
  if echo "$current_exclude_list" | grep -q 'rke2-*';
  then
    if [[ -w ${YUM_CONF_FILE} ]];
    then
      new_exclude_list=$(printf '%s\n' "${current_exclude_list//rke2-* /}")
      new_exclude_list=$(printf '%s\n' "${new_exclude_list//rke2-*,/}")
      new_exclude_list=$(printf '%s\n' "${new_exclude_list//rke2-\*/}")
      sed -i "/exclude=.*rke2-\*/d" "${YUM_CONF_FILE}"
      echo "${new_exclude_list}" >> "${YUM_CONF_FILE}"
    else
      error "${YUM_CONF_FILE} file is readonly and contains rke2-* under package exclusion. Please remove the entry for AS to work."
    fi
  fi
}

function enable_rke2_package_upgrade() {
  remove_rke2_entry_from_exclude /etc/dnf/dnf.conf
  remove_rke2_entry_from_exclude /etc/yum.conf
}

enable_rke2_package_upgrade

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

crontab -l > backupcron
sed -i '/backupjob/d' backupcron > /dev/null
crontab backupcron > /dev/null
rm -rf backupcron > /dev/null
rm -rfv /usr/bin/backupjob > /dev/null
rm -rfv /etc/rancher/ > /dev/null
rm -rfv /var/lib/rook/ > /dev/null
rm -rfv /var/lib/longhorn/ > /dev/null
rm -rfv /var/lib/rancher/rke2/server/db/* > /dev/null
umount -l -f /var/lib/rancher/rke2/server/db > /dev/null 2>&1 || true
rm -rfv /var/lib/rancher/* > /dev/null
umount -l -f /var/lib/rancher
rm -rfv /var/lib/rancher/* > /dev/null
while ! rm -rfv /var/lib/kubelet/* > /dev/null; do
  findmnt --list   --submounts  -n -o TARGET  --target /var/lib/kubelet | grep '/var/lib/kubelet/plugins'  | xargs -r umount -f -l
  sleep 5
done
umount -l -f /var/lib/kubelet
rm -rfv /var/lib/kubelet/* > /dev/null
rm -rfv /datadisk/* > /dev/null
umount -l -f /datadisk
rm -rfv /datadisk/* > /dev/null
rm -rfv ~/.uipath/* > /dev/null
mount /var/lib/rancher
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) で実行します。これによりノードがアンインストールされます。

function remove_rke2_entry_from_exclude() {
  local current_exclude_list new_exclude_list
  YUM_CONF_FILE=$1
  if [[ ! -s "${YUM_CONF_FILE}" ]];
  then
    # File is empty
    return
  fi
  current_exclude_list=$(grep 'exclude=' "${YUM_CONF_FILE}" | tail -1)
  if echo "$current_exclude_list" | grep -q 'rke2-*';
  then
    if [[ -w ${YUM_CONF_FILE} ]];
    then
      new_exclude_list=$(printf '%s\n' "${current_exclude_list//rke2-* /}")
      new_exclude_list=$(printf '%s\n' "${new_exclude_list//rke2-*,/}")
      new_exclude_list=$(printf '%s\n' "${new_exclude_list//rke2-\*/}")
      sed -i "/exclude=.*rke2-\*/d" "${YUM_CONF_FILE}"
      echo "${new_exclude_list}" >> "${YUM_CONF_FILE}"
    else
      error "${YUM_CONF_FILE} file is readonly and contains rke2-* under package exclusion. Please remove the entry for AS to work."
    fi
  fi
}

function enable_rke2_package_upgrade() {
  remove_rke2_entry_from_exclude /etc/dnf/dnf.conf
  remove_rke2_entry_from_exclude /etc/yum.conf
}

enable_rke2_package_upgrade

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

crontab -l > backupcron
sed -i '/backupjob/d' backupcron > /dev/null
crontab backupcron > /dev/null
rm -rf backupcron > /dev/null
rm -rfv /usr/bin/backupjob > /dev/null
rm -rfv /etc/rancher/ > /dev/null
rm -rfv /var/lib/rook/ > /dev/null
rm -rfv /var/lib/longhorn/ > /dev/null
rm -rfv /var/lib/rancher/rke2/server/db/* > /dev/null
umount -l -f /var/lib/rancher/rke2/server/db > /dev/null 2>&1 || true
rm -rfv /var/lib/rancher/* > /dev/null
umount -l -f /var/lib/rancher
rm -rfv /var/lib/rancher/* > /dev/null
while ! rm -rfv /var/lib/kubelet/* > /dev/null; do
  findmnt --list   --submounts  -n -o TARGET  --target /var/lib/kubelet | grep '/var/lib/kubelet/plugins'  | xargs -r umount -f -l
  sleep 5
done
umount -l -f /var/lib/kubelet
rm -rfv /var/lib/kubelet/* > /dev/null
rm -rfv /datadisk/* > /dev/null
umount -l -f /datadisk
rm -rfv /datadisk/* > /dev/null
rm -rfv ~/.uipath/* > /dev/null
mount /var/lib/rancher
mkdir -p /var/lib/rancher/rke2/server/db/ && mount -a
rm -rfv /var/lib/rancher/rke2/server/db/* > /dev/null
echo "Uninstall RKE complete."

Clean up the OSD disk:

for osddisk in $(find /dev/uipath/ceph -maxdepth 1 -mindepth 1 -type l); do
  devName=$(basename "${osddisk}")
  devPath="/dev/${devName}"
  sgdisk --zap-all "${devPath}"
  dd if=/dev/zero of="${devPath}" bs=1M count=100 oflag=direct,dsync
  blkdiscard "${devPath}"
done
ls /dev/mapper/ceph-* | xargs -I% -- dmsetup remove %  
rm -rf /dev/ceph-*
rm -rf /etc/udev/rules.d/99-ceph-raw-osd.rules

3, Reboot the node after uninstall.

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

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

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

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

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

次のコマンドを使用して、podman によってローカルコンテナーストレージに読み込まれたすべてのイメージを削除します。

podman image rm -af

次に、フラグ --offline-tmp-folder で使用された一時オフラインフォルダーを削除します。このパラメーターの既定値は /tmp です。

rm -rf /path/to/temp/folder

一般的な問題

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 が必要なバージョンをインストールできるようにする必要があります。

yum remove podman コマンドを使用して、podman の現在のバージョンを削除します。
現在のバージョンを削除した後、インストーラーを再実行すると、正しいバージョンがインストールされます。

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

説明

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

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

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

解決策

この問題を修正するには、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 とサーバー証明書の両方が、マシンの信頼されたストアに格納されている必要があります。

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

[root@server0 ~]# 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

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

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

[root@server0 ~]# 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 証明書を更新できます。

[root@server0 ~]# 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

StatefulSet ボリュームアタッチエラー

RabbitMQ または cattle-monitoring-system 内のポッドや、その他の StatefulSet ポッドが init ステートでスタックしています。

説明

ノードの電源障害時やアップグレード時に問題が発生すると、ポッドに PVC をアタッチするのに必要なボリュームがないために、RabbitMQ または cattle-monitoring-system 内のポッドが init ステートでスタックすることがあります。

次のコマンドを実行して、問題が本当に StatefulSet ボリュームのアタッチに関連しているかを確認します。

kubectl -n <namespace> describe pod <pod-name> | grep "cannot get resource \"volumeattachments\" in API group \" storage.k8s.io\""

StatefulSet ボリュームのアタッチに関連している場合、エラーメッセージが表示されます。

解決策

この問題を修正するには、ノードを再起動します。

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

説明

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

解決策

次のコマンドを使用して、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

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.

次の手順を実行します。

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

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 をデバッグするには、ログを有効化する必要があります。そのためには、以下の手順を実行します。

次のコマンドを実行して、istio-ingressgateway ポッドを見つけます。ゲートウェイポッド名をコピーします。istio-ingressgateway-r4mbx のようになります。

kubectl -n istio-system get pods

次のコマンドを実行して、ゲートウェイポッドシェルを開きます。

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

次のコマンドを実行して、デバッグレベルのログを有効化します。

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

サーバーノードから次のコマンドを実行します。

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 のチェックで失敗したポッドが返された場合は、以下の手順を実行します。

解決策

kubectl -n uipath describe pod <pod-name> を確認して、見つからないシークレットを探します。
シークレットが見つからない場合は、資格情報マネージャージョブのログを探して、失敗したかどうかを確認します。
資格情報マネージャージョブが失敗し、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 へのログインに失敗した

説明

管理者パスワードを使用している場合に ArgoCD へのログイン、またはインストーラーが失敗することがあります。次のエラーメッセージが表示されます。

解決策

この問題を修正するには、パスワードを入力し、bcrypt のパスワードを作成して、次のセクションで説明するコマンドを実行します。

password="<enter_your_password>"
bcryptPassword=<generate bcrypt password using link https://www.browserling.com/tools/bcrypt >

# Enter your bcrypt password and run below command
kubectl -n argocd patch secret argocd-secret \
  -p '{"stringData": {
    "admin.password": "<enter you bcryptPassword here>",
    "admin.passwordMtime": "'$(date +%FT%T%Z)'"
  }}'

# Run below commands
argocdInitialAdminSecretPresent=$(kubectl -n argocd get secret argocd-initial-admin-secret --ignore-not-found )
if [[ -n ${argocdInitialAdminSecretPresent} ]]; then
   echo "Start updating argocd-initial-admin-secret"
   kubectl -n argocd patch secret argocd-initial-admin-secret \
   -p "{
      \"stringData\": {
         \"password\": \"$password\"
      }
   }"
fi

argocAdminSecretName=$(kubectl -n argocd get secret argocd-admin-password --ignore-not-found )
if [[ -n ${argocAdminSecretName} ]]; then
   echo "Start updating argocd-admin-password"
   kubectl -n argocd patch secret argocd-admin-password \
   -p "{
      \"stringData\": {
         \"password\": \"$password\"
      }
   }"
fi

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

説明

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

解決策

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

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

説明

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

解決策

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

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

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

説明

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

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

解決策

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

次のスクリプトを手動で実行します。

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

objectstore resize-pvc コマンドを再実行します。

PVC resize does not heal Ceph

説明

If Ceph is unhealthy due to out-of-storage issues, Objectstore PVC resize does not heal it.

解決策

To speed up the Ceph recovery in a non-HA cluster, run the following command:

function set_ceph_pool_config_non_ha() {
  # Return if HA 
  [[ "$(kubectl -n rook-ceph get cephobjectstore rook-ceph  -o jsonpath='{.spec.dataPool.replicated.size}')" -eq 1 ]] || return
  # Set pool size and min_size
  kubectl -n "rook-ceph" exec deploy/rook-ceph-tools – ceph osd pool set  "device_health_metrics" "size" "1" --yes-i-really-mean-it || true
  kubectl -n "rook-ceph" exec deploy/rook-ceph-tools – ceph osd pool set  "device_health_metrics" "min_size" "1" --yes-i-really-mean-it || true
}

object-store (rook-ceph) にデータをアップロード/ダウンロードできない

説明

この問題は、配置グループ (PG) の不整合のために、object-store のステートが degraded ステートになっている場合に発生する可能性があります。
次のコマンドを実行して、問題が本当に rook-ceph の PG の不整合に関連しているかを確認します。

export KUBECONFIG=/etc/rancher/rke2/rke2.yaml PATH=$PATH:/var/lib/rancher/rke2/bin
ROOK_CEPH_TOOLS=$(kubectl -n rook-ceph get pods | grep rook-ceph-tools)
kubectl -n rook-ceph exec -it $ROOK_CEPH_TOOLS -- ceph status

問題が rook-ceph の PG の不整合に関連している場合は、出力に次のメッセージが含まれます。

....
....
Possible data damage: X pgs inconsistent
....
....
X active+clean+inconsistent
....
....

解決策

不整合な PG を修復するには、次の手順を実行します。

rook-ceph ツールを実行します。

kubectl -n rook-ceph exec -it $ROOK_CEPH_TOOLS -- sh

rook-ceph のガベージコレクタープロセスをトリガーします。プロセスが完了するまで待ちます。

radosgw-admin gc process

active+clean+inconsistent PG のリストを見つけます。

ceph health detail
# output of this command be like
# ....
# pg <pg-id> is active+clean+inconsistent, acting ..
# pg <pg-id> is active+clean+inconsistent, acting ..
# ....
#

詳細スクラブを一度に 1 つの PG でトリガーします。PG のサイズによっては、このコマンドの実行に数分かかります。

ceph pg deep-scrub <pg-id>

スクラブのステータスを確認します。

ceph -w | grep <pg-id>

PG のスクラブのステータスを確認します。PG のスクラブに成功すると、PG のステータスは active+clean+inconsistent になります。

ceph health detail | grep <pg-id>

PG を修復します。

ceph pg repair <pg-id>

PG の修復ステータスを確認します。PG が正常に修復された場合、その PG の ID は active+clean+inconsistent リストから削除されます。

ceph health detail | grep <pg-id>

残りの不整合な PG で手順 3 から 8 を繰り返します。

証明書の更新後のエラー

説明

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

Error

解決策

任意のサーバーノードから、以下のコマンドを実行します。

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

kubectl -n uipath rollout restart deployments

上記のコマンドが成功するまで待機してから、以下のコマンドを実行して前のコマンドのステータスを確認します。

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

回復の手順

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

次のコマンドを実行して、システムに SSH 接続します。

ssh <user>@<node-ip>

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

イベントに示されている PVC ボリュームを確認し、fsck コマンドを実行します。

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

失敗した MongoDB ポッドを削除して、PVC に適切にマウントします。

kubectl delete pod <pod-name> -n mongodb

Mongo pods in CrashLoopBackOff or pending PVC provisioning after deletion

The Mongo pods might get stuck in a cashback loop due to a corrupt PVC. The most probable cause of this issue is an unclean shutdown.
When experiencing this issue, the logs show the following:

Common point must be at least stable timestamp
{"t":{"$date":"2022-05-18T09:37:55.053+00:00"},"s":"W",  "c":"STORAGE",  "id":22271,   "ctx":"initandlisten","msg":"Detected unclean shutdown - Lock file is not empty","attr":{"lockFile":"/data/mongod.lock"}}
    ['currentState.Running' = false]
    ['currentState.IsVCRedistCorrect' = true]
    ['desiredState.ProcessType' != mongos ('desiredState.ProcessType' = mongod)]

回復の手順

Delete the failing pod. If this solution does not work, continue to the next steps.

kubectl delete pod <pod-name> -n mongodb

Get the name of the corrupt PVC for the failing pods.

kubectl -n mongodb get pvc

Delete the PVC.

kubectl -n mongodb delete pvc <pvc-name>

At this point, the PVC should be auto-synced, and the pod should experience no issues anymore. If auto-provisioning does not happen, you need to perform the operation manually by taking the following steps.
Get the PVC YAML for a healthy node.

kubectl -n mongodb get pvc <pvc-name> -o yaml > pvc.yaml

Edit the name and remove uuids/pvc-ids from the YAML.
Remove the volume name and UID, and rename the PVC to the deleted PVC name.

Apply the PVC.

kubectl -n mongodb apply pvc.yaml

The PVC should be provisioned and attached to the PVC for the pod, and the pod should no longer experience any issues. If the pod does not resync, then delete it.

MongoDB pod fails to upgrade from 4.4.4-ent to 5.0.7-ent

説明

When upgrading from Automation Suite 2021.10 to 2022.10, the MongoDB pod is stuck is rolling update and cannot move from version 4.4.4-ent to 5.0.7-ent. Only one pod is available, and it is failing the readiness check.

解決策

To check the MongoDB Agent logs, run the following command:

kubectl get pods -n mongodb
Use the pod name and get log for that pod
kubectl logs <pod-name> -n mongodb -c mongodb-agent
In the Agent logs if we are seeing below line then the upgrade hasn't been successful
  ['currentState.Version = 4.4.4-ent is equal to desiredState.Version = 5.0.7-ent' = false]

To fix the issue, take the following steps:

Disable auto-sync in ArgoCD. Go to Applications > MongoDB > AppDetails > Summary, and click Disable Auto-Sync.
The MongoDB sts definition is still using the old MongoDB localhost:30071/mongodb/mongodb-enterprise-appdb-database:4.4.4-ent image. Edit the definition to use version 5.0.7-ent. Save it and sync it.
Delete the old MongoDB pod.
The pods should come up with MongoDB version 5.0.7-ent.

Upgrade fails due to unhealthy Ceph

説明

When trying to upgrade to a new Automation Suite version, you might see the following error message: Ceph objectstore is not completely healthy at the moment. Inner exception - Timeout waiting for all PGs to become active+clean.

解決策

To fix this upgrade issue, verify if the OSD pods are running and healthy by running the following command:

kubectl -n rook-ceph get pod -l app=rook-ceph-osd  --no-headers | grep -P '([0-9])/\1'  -v

If the command does not output any pods, verify if Ceph placement groups (PGs) are recovering or not by running the following command:

function is_ceph_pg_active_clean() {
  local return_code=1
  if kubectl -n rook-ceph exec  deploy/rook-ceph-tools -- ceph status --format json | jq '. as $root | ($root | .pgmap.num_pgs) as $total_pgs | try ( ($root | .pgmap.pgs_by_state[] | select(.state_name == "active+clean").count)  // 0) as $active_pgs | if $total_pgs == $active_pgs then true else false end' | grep -q 'true';then
    return_code=0
  fi
  [[ $return_code -eq 0 ]] && echo "All Ceph Placement groups(PG) are active+clean"
  if [[ $return_code -ne 0 ]]; then
    echo "All Ceph Placement groups(PG) are not active+clean. Please wait for PGs to become active+clean"
    kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph pg dump --format json | jq -r '.pg_map.pg_stats[] | select(.state!="active+clean") | [.pgid, .state] | @tsv'
  fi
  return "${return_code}"
}
# Execute the function multiple times to get updated ceph PG status
is_ceph_pg_active_clean

📘
If none of the affected Ceph PG recovers even after waiting for more than 30 minutes, raise a ticket with UiPath Support.

If the command outputs pod(s), you must first fix the issue affecting them:
- If a pod is stuck in Init:0/4, then it could be a PV provider (Longhorn) issue. To debut this issue, raise a ticket with UiPath Support.
- If a pod is in CrashLoopBackOff, fix the issue by running the following command:

function cleanup_crashing_osd() {
    local restart_operator="false"
    local min_required_healthy_osd=1
    local in_osd
    local up_osd
    local healthy_osd_pod_count
    local crashed_osd_deploy
    local crashed_pvc_name

    if ! kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph osd pool ls detail  | grep 'rook-ceph.rgw.buckets.data' | grep -q 'replicated'; then
        min_required_healthy_osd=2
    fi
    in_osd=$(kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph status   -f json  | jq -r '.osdmap.num_in_osds')
    up_osd=$(kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph status   -f json  | jq -r '.osdmap.num_up_osds')
    healthy_osd_pod_count=$(kubectl -n rook-ceph get pod -l app=rook-ceph-osd | grep 'Running' | grep -c -P '([0-9])/\1')
    if ! [[ $in_osd -ge $min_required_healthy_osd && $up_osd -ge $min_required_healthy_osd && $healthy_osd_pod_count -ge $min_required_healthy_osd ]]; then
        return
    fi
    for crashed_osd_deploy in $(kubectl -n rook-ceph get pod -l app=rook-ceph-osd  | grep 'CrashLoopBackOff' | cut -d'-' -f'1-4') ; do
        if kubectl -n rook-ceph logs "deployment/${crashed_osd_deploy}" | grep -q '/crash/'; then
            echo "Found crashing OSD deployment: '${crashed_osd_deploy}'"
            crashed_pvc_name=$(kubectl -n rook-ceph get deployment "${crashed_osd_deploy}" -o json | jq -r '.metadata.labels["ceph.rook.io/pvc"]')
            info "Removing crashing OSD deployment: '${crashed_osd_deploy}' and PVC: '${crashed_pvc_name}'"
            timeout 60  kubectl -n rook-ceph delete deployment "${crashed_osd_deploy}" || kubectl -n rook-ceph delete deployment "${crashed_osd_deploy}" --force --grace-period=0
            timeout 100 kubectl -n rook-ceph delete pvc "${crashed_pvc_name}" || kubectl -n rook-ceph delete pvc "${crashed_pvc_name}" --force --grace-period=0
            restart_operator="true"
        fi
    done
    if [[ $restart_operator == "true" ]]; then
        kubectl -n rook-ceph rollout restart deployment/rook-ceph-operator
    fi
    return 0
}
# Execute the cleanup function
cleanup_crashing_osd

After fixing the crashing OSD, verify if PGs are recovering or not by running the following command:

is_ceph_pg_active_clean

2021.10 からの自動アップグレード後にクラスターが異常になる

Automation Suite 2021.10 からの自動アップグレード中に、CNI プロバイダーが Canal から Cilium に移行されます。この操作では、すべてのノードを再起動する必要があります。まれに、1 つ以上のノードが正常に再起動されないことがあります。この場合、それらのノードで実行されているポッドが異常なままになります。

回復の手順

失敗した再起動を特定します。
Ansible の実行中に、次のスニペットのような出力が表示される場合があります。

TASK [Reboot the servers] ***************************************************************************************************************************

fatal: [10.0.1.6]: FAILED! =>

  msg: 'Failed to connect to the host via ssh: ssh: connect to host 10.0.1.6 port 22: Connection timed out'

または、Ansible ホストマシンのログを参照します。このログは、/var/tmp/uipathctl_<version>/_install-uipath.log にあります。失敗した再起動を特定したら、すべてのノードで手順 2 から 4 を実行します。

各ノードで、再起動が必要であるかを確認します。
各ノードに接続し、次のコマンドを実行します。

ssh <username>@<ip-address>
iptables-save 2>/dev/null | grep -i cali -c

結果が 0 でない場合は、再起動が必要です。

ノードを再起動します。

sudo reboot

ノードが応答可能になるまで待ち (ノードに SSH で接続できる必要があります)、他のすべてのノードで手順 2 から 4 を繰り返します。

Longhorn のセットアップ中に最初のインストールが失敗する

まれに、Longhorn の最初のインストール試行に失敗した場合、後続のリトライで Helm 固有のエラー「Error: UPGRADE FAILED: longhorn has no deployed releases」がスローされることがあります。

回復の手順

インストールをリトライする前に、次のコマンドを実行して Longhorn Helm のリリースを削除します。

/opt/UiPathAutomationSuite/<version>/bin/helm uninstall longhorn --namespace longhorn-system

OS のアップグレード後に Automation Suite が動作しない

説明

OS のアップグレード後に、Ceph OSD ポッドが CrashLoopBackOff ステートでスタックすることがあります。この問題が発生すると、Automation Suite にアクセスできなくなります。

解決策

次のコマンドを実行して、ポッドのステートを確認します。

kubectl - n rook-ceph get pods

前の出力のポッドのいずれかが CrashLoopBackOff である場合は、次のコマンドを実行してそのポッドを回復します。

$OSD_PODS=$(kubectl -n rook-ceph get deployment -l app=rook-ceph-rgw --no-headers | awk '{print $1}')
kubectl -n rook-ceph rollout restart deploy $OSD_PODS

ポッドが再び「実行中」ステートになるまで約 5 分待ってから、次のコマンドを実行してそのステータスを確認します。

kubectl - n rook-ceph get pods

Azure disk not marked as SSD

説明

An Azure known issue incorrectly shows the rotational flag enabled for the Azure SSD disk. As a result, the Azure disk is not marked as SSD, and the following error occurs when trying to configure the Objectstore disk:

ERROR][2022-08-18T05:26:35+0000]: Rotational device: '/dev/sdf' is not recommended for ceph OSD

解決策

To fix this issue and mark the Azure SSD disk as non-rotational, run the following commands:

echo "0" > "/sys/block/{raw_device_name}/queue/rotational"
echo "KERNEL==\"${raw_device_name}\", ATTR{queue/rotational}=\"0\"" >> "/etc/udev/rules.d/99-ceph-raw-osd-mark-ssd.rules"
udevadm control --reload
udevadm trigger

Click for an example

echo "0" > "/sys/block/sdf/queue/rotational"
echo "KERNEL==\"sdf\", ATTR{queue/rotational}=\"0\"" >> "/etc/udev/rules.d/99-ceph-raw-osd-mark-ssd.rules"
udevadm control --reload
udevadm trigger

Antivirus causing installation issues

説明

Using an antivirus results in an Automation Suite installation issue.

解決策

To fix this issue, add the following folders to the antivirus allowlist:

/var/lib/rancher
/var/lib/kubelet
/opt/UiPathAutomationSuite
/datadisk
/var/lib/rancher/rke2/server/db
/var/lib/longhorn

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:

[root@server0 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:

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.

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>

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('rabbit@rabbitmq-server-0.rabbitmq-nodes.rabbitmq'): ** ERROR ** (could not write core file: eacces)
 ** FATAL ** Failed to merge schema: Bad cookie in table definition rabbit_user_permission: 'rabbit@rabbitmq-server-0.rabbitmq-nodes.rabbitmq' = {cstruct,rabbit_user_permission,set,[],['rabbit@rabbitmq-server-2.rabbitmq-nodes.rabbitmq','rabbit@rabbitmq-server-0.rabbitmq-nodes.rabbitmq','rabbit@rabbitmq-server-1.rabbitmq-nodes.rabbitmq'],[],[],0,read_write,false,[],[],false,user_permission,[user_vhost,permission],[],[],[],{{1667351034020261908,-576460752303416575,1},'rabbit@rabbitmq-server-1.rabbitmq-nodes.rabbitmq'},{{4,0},{'rabbit@rabbitmq-server-2.rabbitmq-nodes.rabbitmq',{1667,351040,418694}}}}, 'rabbit@rabbitmq-server-1.rabbitmq-nodes.rabbitmq' = {cstruct,rabbit_user_permission,set,[],['rabbit@rabbitmq-server-1.rabbitmq-nodes.rabbitmq'],[],[],0,read_write,false,[],[],false,user_permission,[user_vhost,permission],[],[],[],{{1667372429216834387,-576460752303417087,1},'rabbit@rabbitmq-server-1.rabbitmq-nodes.rabbitmq'},{{2,0},[]}}

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

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 {}

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 {}

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 {}

Sync sfcore application via ArgoCD and wait for the sync to complete:

Perform a rollout restart on all applications in the UiPath namespace:

kubectl -n uipath rollout restart deploy

rke2 not getting started due to space issue

説明

When upgrading to Automation Suite 2022.10 and migrating your data to Azure external storage, rke2 might experience some issues. Specifically, rke2 might not get started and might fail with the following error message: Failed to reconcile with temporary etcd: write /var/lib/rancher/rke2/server/db/etcd-tmp/member/snap/db: no space left on device.

解決策

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

Stop the SSSD service:

systemctl stop sssd

Remove the SSSD logs:

rm /var/log/sssd/*

Start the SSSD service:

systemctl start sssd

We recommend changing the log rotate policy for the SSSD service from weekly to daily.
If the error message persists, try rebooting the host.

Cleaning up old logs stored in the `sf-logs` bundle

A bug might cause log accumulation in the sf-logs object store bucket. To clean up old logs in the sf-logs bucket, follow the instructions on running the dedicated script. Make sure to follow the steps relevant to your environment type.

To clean up old logs stored in the sf-logs bundle, take the following steps:

Get the version of the sf-k8-utils-rhel image available in your environment:
- in an offline environment, run the following command: podman search localhost:30071/uipath/sf-k8-utils-rhel --tls-verify=false --list-tags
- in an online environment, run the following command: podman search registry.uipath.com/uipath/sf-k8-utils-rhel --list-tags
Update line 121 in the following yaml definition accordingly to include the proper image tag:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cleanup-script
  namespace: uipath-infra
data:
  cleanup_old_logs.sh:  |
    #!/bin/bash

    function parse_args() {
      CUTOFFDAY=7
      SKIPDRYRUN=0
      while getopts 'c:sh' flag "$@"; do
        case "${flag}" in
        c)
          CUTOFFDAY=${OPTARG}
          ;;
        s)
          SKIPDRYRUN=1
          ;;
        h)
          display_usage
          exit 0
          ;;
        *)
          echo "Unexpected option ${flag}"
          display_usage
          exit 1
          ;;
        esac
      done

      shift $((OPTIND - 1))
    }

    function display_usage() {
      echo "usage: $(basename "$0") -c <number> [-s]"
      echo "  -s                                                         skip dry run, Really deletes the log dirs"
      echo "  -c                                                         logs older than how many days to be deleted. Default is 7 days"
      echo "  -h                                                         help"
      echo "NOTE: Default is dry run, to really delete logs set -s"
    }

    function setS3CMDContext() {
        OBJECT_GATEWAY_INTERNAL_HOST=$(kubectl -n rook-ceph get services/rook-ceph-rgw-rook-ceph -o jsonpath="{.spec.clusterIP}")
        OBJECT_GATEWAY_INTERNAL_PORT=$(kubectl -n rook-ceph get services/rook-ceph-rgw-rook-ceph -o jsonpath="{.spec.ports[0].port}")
        AWS_ACCESS_KEY=$1
        AWS_SECRET_KEY=$2

        # Reference https://rook.io/docs/rook/v1.5/ceph-object.html#consume-the-object-storage
        export AWS_HOST=$OBJECT_GATEWAY_INTERNAL_HOST
        export AWS_ENDPOINT=$OBJECT_GATEWAY_INTERNAL_HOST:$OBJECT_GATEWAY_INTERNAL_PORT
        export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY
        export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_KEY
    }

    # Set s3cmd context by passing correct AccessKey and SecretKey
    function setS3CMDContextForLogs() {
        BUCKET_NAME='sf-logs'
        AWS_ACCESS_KEY=$(kubectl -n cattle-logging-system get secret s3-store-secret -o json | jq '.data.OBJECT_STORAGE_ACCESSKEY' | sed -e 's/^"//' -e 's/"$//' | base64 -d)
        AWS_SECRET_KEY=$(kubectl -n cattle-logging-system get secret s3-store-secret -o json | jq '.data.OBJECT_STORAGE_SECRETKEY' | sed -e 's/^"//' -e 's/"$//' | base64 -d)

        setS3CMDContext "$AWS_ACCESS_KEY" "$AWS_SECRET_KEY"
    }

    function delete_old_logs() {
        local cutoffdate=$1
        days=$(s3cmd ls  s3://sf-logs/ --host="${AWS_HOST}" --host-bucket= s3://sf-logs --no-check-certificate --no-ssl)
        days=${days//DIR}
        if [[ $SKIPDRYRUN -eq 0 ]];
        then
            echo "DRY RUN. Following log dirs are selected for deletion"
        fi
        for day in $days
        do
            day=${day#*sf-logs/}
            day=${day::-1}
            if [[ ${day} < ${cutoffdate} ]];
            then
                if [[ $SKIPDRYRUN -eq 0 ]];
                then
                    echo "s3://$BUCKET_NAME/$day"
                else
                    echo "###############################################################"
                    echo "Deleting Logs for day: {$day}"
                    echo "###############################################################"
                    s3cmd del "s3://$BUCKET_NAME/$day/" --host="${AWS_HOST}" --host-bucket= --no-ssl --recursive || true
                fi
            fi
        done
    }

    function main() {
        # Set S3 context by setting correct env variables
        setS3CMDContextForLogs
        echo "Bucket name is $BUCKET_NAME"

        CUTOFFDATE=$(date --date="${CUTOFFDAY} day ago" +%Y_%m_%d)
        echo "logs older than ${CUTOFFDATE} will be deleted"

        delete_old_logs "${CUTOFFDATE}"
        if [[ $SKIPDRYRUN -eq 0 ]];
        then
            echo "NOTE: For really deleting the old log directories run with -s option"
        fi
    }

    parse_args "$@"
    main
    exit 0
---
apiVersion: v1
kind: Pod
metadata:
  name: cleanup-old-logs
  namespace: uipath-infra
spec:
   serviceAccountName: fluentd-logs-cleanup-sa
   containers:
   - name: cleanup
     image: localhost:30071/uipath/sf-k8-utils-rhel:0.8
     command: ["/bin/bash"]
     args: ["/scripts-dir/cleanup_old_logs.sh", "-s"]
     volumeMounts:
     - name: scripts-vol
       mountPath: /scripts-dir
     securityContext:
       privileged: false
       allowPrivilegeEscalation: false
       readOnlyRootFilesystem: true
       runAsUser: 9999
       runAsGroup: 9999
       runAsNonRoot: true
       capabilities:
         drop: ["NET_RAW"]
   volumes:
   - name: scripts-vol
     configMap:
       name: cleanup-script

Copy the content of the aforementioned yaml definition to a file called cleanup.yaml. Trigger a pod to clean up the old logs:

kubectl apply -f cleanup.yaml

Get details on the progress:

kubectl -n uipath-infra logs cleanup-old-logs -f

Delete the job:

kubectl delete -f cleanup.yaml

Identity Server の問題

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

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

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

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

Update the underlying directory connections

Disabling or changing the AD integration settings does not update the underlying directory connections properly.

Run the following command to update the SQL DirectoryConnections table entries, then restart the Identity pods:

UPDATE [identity].[DirectoryConnections] SET IsDeleted = 1, DeletionTime=GETUTCDATE() WHERE (Type='ad' OR Type='ldapad') AND IsDeleted=0

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-job、kerberos-jobs-trigger、kerberos-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-job、kerberos-jobs-trigger、kerberos-tgt-update のいずれかに表示される可能性があります。

解決策

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

Alarm received for failed kerberos-tgt-update job

説明

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

解決策

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

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.

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.

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-job と credential-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 を開いた際にライセンスの割り当てが検出されないことがあります。

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

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

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」になるはずです。

Disabling streaming logs

To disable log streaming on existing skills, edit the skill deployment and change the LOGS_STREAMING_ENABLED environment variable to false.
You can also add a logsStreamingEnabled global variable with the value set as false using ArgoCD under the aicenter app details. Make sure to sync ArgoCD after the change is done.

Unknown error when accessing AI Center

説明

The following error can occur when accessing AI Center:
An unknown error has occurred. (#200)

解決策

To recover from this error, run the final step for installing AI Center. For more information, check the page applicable to your case:

Online single-node, Completing AI Center installation section
Offline single-node, Completing AI Center installation section
Online multi-node, Completing AI Center installation section
Offline multi-node, Completing AI Center installation section in Step 4.3: Finishing installing the suite

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 を無効化するか、新しいテナントを作成する必要があります。

解決策 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] をクリックする必要が生じることがあります。

Looker が初期化に失敗する

During Looker initialization, you might encounter and error stating RuntimeError: Error starting Looker. A Looker pod failure produced this error due to a possible system failure or loss of power. The issue is persistent even if you reinitialize Looker.

この問題を解決するには、永続ボリューム要求 (PVC) を削除してから再起動します。

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

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

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

🚧重要

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

一般的な問題

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

説明

潜在的な問題

潜在的な問題

解決策

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

説明

解決策

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

説明

解決策

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

説明

解決策

📘注:

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

説明

解決策

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

説明

解決策

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

説明

解決策

Longhorn エラー

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

説明

解決策

StatefulSet ボリューム アタッチ エラー

説明

解決策

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

説明

解決策

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

説明

解決策

Redis プローブの障害

説明

解決策

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

説明

解決策

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

説明

Istio ログを有効化する

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

説明

解決策

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

説明

解決策

ArgoCD へのログインに失敗した

説明

解決策

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

説明

解決策

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

説明

解決策

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

説明

解決策

PVC resize does not heal Ceph

説明

解決策

object-store (rook-ceph) にデータをアップロード/ダウンロードできない

説明

解決策

証明書の更新後のエラー

説明

Error

解決策

🚧
重要

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

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

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

📘
注:

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

StatefulSet ボリュームアタッチエラー

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

Cleaning up old logs stored in the `sf-logs` bundle