- Visão geral
- Requisitos
- Modelos de implantação
- Manual: preparando a instalação
- Manual: preparando a instalação
- Etapa 2: configuração do registro compatível com OCI para instalações offline
- Etapa 3: configuração do objectstore externo
- Etapa 4: configuração do High Availability Add-on
- Etapa 5: configuração de bancos de dados SQL
- Etapa 7: configuração do DNS
- Etapa 8: configuração dos discos
- Etapa 9: configuração dos ajustes do nível do kernel e do sistema operacional
- Etapa 10: configuração das portas do nó
- Etapa 11: aplicação de configurações diversas
- Etapa 12: validação e instalação dos pacotes RPM necessários
- Etapa 13: geração de cluster_config.json
- Amostra Cluster_config.json
- Configuração geral
- Configuração do perfil
- Configuração de Certificados
- Configuração do Banco de Dados
- Configuração externa do Objectstore
- Configuração de URL pré-assinada
- Configuração do ArgoCD
- Configuração da autenticação do Kerberos
- Configuração de registro externo compatível com OCI
- Disaster Recovery: configurações Ativo/Passivo e Ativo/Ativo
- Configuração do High Availability Add-on
- Configuração específica do Orchestrator
- Configuração específica do Insights
- Process Mining-specific configuration
- Configuração específica do Document Understanding
- Automation Suite Robots-specific configuration
- Configuração do monitoramento
- Opcional: configuração do servidor proxy
- Opcional: habilitação da resiliência a falhas zonais em um cluster de produção pronto para alta disponibilidade de vários nós
- Opcional: transmitindo resolv.conf personalizado
- Optional: Increasing fault tolerance
- Adicionando um nó de agente dedicado com suporte a GPU
- Adicionando um nó de agente dedicado para robôs do Automation Suite
- Etapa 15: configuração do registro temporário do Docker para instalações offline
- Etapa 16: validação dos pré-requisitos para a instalação
- Executando o uipathctl
- Manual: realizando a instalação
- Pós-instalação
- Administração de cluster
- Gerenciando produtos
- Introdução ao portal de administração do cluster
- Migração do Redis do High Availability Add-on no cluster para externo
- Migrating data between objectstores
- Migrating in-cluster objectstore to external objectstore
- Migração de um registro no cluster para um registro externo compatível com OCI
- Mudança para o cluster secundário manualmente em uma configuração Ativo/Passivo
- Disaster Recovery: executando operações pós-instalação
- Convertendo uma instalação existente para configuração multi-local
- Diretrizes sobre atualização de uma implantação Ativo/Passivo ou Ativo/Ativo
- Diretrizes sobre backup e restauração de uma implantação Ativo/Passivo ou Ativo/Ativo
- Escalando uma implantação de nó único (avaliação) para uma implantação de vários nós (HA)
- Monitoramento e alertas
- Migração e atualização
- Migração entre clusters do Automation Suite
- Atualizando o Automação Suite
- Download dos pacotes de instalação e obtenção de todos os arquivos no primeiro nó do servidor
- Recuperação da mais recente configuração aplicada do cluster
- Atualização da configuração de cluster
- Configuração do registro compatível com OCI para instalações offline
- Execução da atualização
- Realização de operações pós-atualização
- Configuração específica do produto
- Configuração avançada do Orchestrator
- Configuração de parâmetros do Orchestrator
- Configuração do AppSettings
- Configuração do tamanho máximo da solicitação
- Substituição da configuração de armazenamento no nível do cluster
- Configuração do NLog
- Salvando logs do robô no Elasticsearch
- Configuração dos repositórios de credenciais
- Configuração da chave de criptografia por tenant
- Limpeza do banco de dados do Orchestrator
- Ignorar a instalação da biblioteca do host
- Melhores práticas e manutenção
- Solução de problemas
- Como solucionar problemas dos serviços durante a instalação
- Como reduzir as permissões para um diretório de backup NFS
- Como desinstalar o cluster
- Como limpar os artefatos offline para melhorar o espaço em disco
- Como limpar os dados do Redis
- Como habilitar o registro em log do Istio
- Como limpar logs manualmente
- Alterando o modo somente leitura do Ceph
- Como limpar logs antigos armazenados no bucket do sf-logs
- Como desabilitar os logs de streaming para o AI Center
- Como depurar instalações do Automation Suite com falha
- Como excluir imagens do instalador antigo após a atualização
- Como desabilitar o descarregamento de soma de verificação do TX
- Como definir manualmente o nível de log do ArgoCD como Info
- Como expandir o armazenamento do AI Center
- Como gerar o pull_secret_value codificado para registros externos
- Como lidar com cifras fracas no TLS 1.2
- Como verificar a versão do TLS
- Como trabalhar com certificados
- Como agendar o backup e restaurar dados do Ceph
- Como coletar dados de uso de DU com objectstore (Ceph) no cluster
- Como instalar o RKE2 SELinux em ambientes air-gapped
- Como limpar backups diferenciados antigos em um servidor NFS
- Como implantar o Insights em um cluster habilitado para FIPS
- Como migrar para o Cgroup v2
- Como recuperar a autenticação do Kerberos após uma reinicialização da VM
- Como enviar uma imagem do Docker local para o registro no cluster
- Como excluir buckets do backup
- Erro ao baixar o pacote
- A instalação offline falha devido a um binário ausente
- Azure disk not marked as SSD
- Falha após a atualização do certificado
- Erros de validação de certificado TLS
- Antivírus causa problemas de instalação
- Automation Suite not working after OS upgrade
- O Automation Suite requer que backlog_wait_time seja definido como 0
- A instalação do registro temporário falha no RHEL 8.9
- Problema de reinício frequente em implantações de namespace uipath durante instalações offline
- Configurações de DNS não honradas pelo CoreDNS
- A geração de registros no cluster falha devido a memória insuficiente
- As verificações de pré-requisitos falham quando os projetos modernos do Document Understanding estão habilitados e o AI Center está desabilitado
- Upgrade fails due to unhealthy Ceph
- A atualização falha devido a objetos clássicos no banco de dados do Orchestrator
- Um cluster do Ceph foi encontrado em um estado degradado após atualização lado a lado
- A atualização do serviço falha para o Apps
- Tempos limite de atualização no local
- Falha de atualização em ambientes offline
- pod snapshot-controller-crds no estado CrashLoopBackOff após a atualização
- Falha de atualização devido aos tamanhos de PVC do Insights substituídos
- Falha de atualização devido ao nome de host em letra maiúscula
- Configurando um intervalo de tempo limite para os portais de gerenciamento
- Autenticação não funciona após migração
- kinit: não é possível encontrar o KDC para o realm <AD Domain> ao obter credenciais iniciais
- kinit: o Keytab não contém chaves adequadas para *** ao obter credenciais iniciais
- Falha na operação GSSAPI devido a código de status inválido
- Alarme recebido para trabalho com falha do Kerberos-tgt-update
- Provedor de SSPI: servidor não encontrado no banco de dados Kerberos
- Falha de login para usuário do AD devido a conta desabilitada
- ArgoCD login failed
- Falha ao obter a imagem do sandbox
- Os pods não são exibidos na UI do ArgoCD
- Falha de teste do Redis
- O servidor RKE2 falha ao iniciar
- O ArgoCD entra em estado Em andamento após a primeira instalação
- Pod de repositório do ArgoCD em CrashLoopBackOff
- Migreção manual do ArgoCD NetworkPolicy (GHSA-47m3-95c7-g2g8)
- Métricas Ceph-rook ausentes nos painéis de monitoramento
- Incompatibilidade em erros relatados durante as verificações de integridade do diagnóstico
- Configuração de solicitações e limites de recursos para cargas de trabalho criadas pelo uipathctl
- Nenhum problema upstream íntegro
- Inicialização do Redis bloqueada por antivírus
- Os pods do AI Center e do Document Understanding falham ao iniciar com a verificação do certificado TLS habilitada
- O Fluentd não exporta logs em ambientes IPv6
- O Studio Desktop não pode carregar conectores e atividades do Integration Service
- O Document Understanding não está no menu de navegação esquerdo do Automation Suite
- Status de Falha ao criar uma sessão de rotulagem de dados
- Status de Falha ao tentar implantar uma habilidade de ML
- Trabalho de migração falha no ArgoCD
- Reconhecimento de escrita com o Extrator de formulários inteligente não está funcionando
- Execução de alta disponibilidade com o Process Mining
- Falha na ingestão do Process Mining ao fazer logon usando o Kerberos
- Não é possível conectar-se ao banco de dados AutomationSuite_ProcessMining_Warehouse usando uma string de conexão em formato pyodbc.
- A instalação do Airflow falha com sqlalchemy.exc.ArgumentError: não foi possível analisar o URL rfc1738 da string ''
- Como adicionar uma regra de tabela de IP para usar a porta 1433 do SQL Server
- O certificado do Automation Suite não é confiável para o servidor em que o CData Sync está sendo executado
- Process Mining fails to load after disabling and re-enabling it
- Execução da ferramenta de diagnóstico
- Usando o pacote de suporte do Automation Suite
- Exploração de logs
Responda a alertas de alto uso do disco e identifique os pods que consomem armazenamento excessivo em nós do Kubernetes no Automation Suite.
kubernetes-system
KubernetesDiskPressure
Esse alerta indica que o uso do disco é muito alto no nó Kubernetes.
Ao surgir esse alerta, tente ver qual pod está consumindo mais disco:
-
Confirme se o nó está sob
DiskPressureusando o seguinte comando:kubectl describe node <node-name>kubectl describe node <node-name>
Identifique a condição DiskPressure na saída.
-
Verifique o uso do espaço em disco no nó afetado:
df -hdf -h
Isso mostra o uso do disco em todos os sistemas de arquivos montados. Identificar onde está o alto uso.
- Se o disco estiver cheio e a limpeza for insuficiente, considere redimensionar o disco para o nó (principalmente em ambientes de nuvem, como AWS ou GCP). Esse processo pode envolver a expansão de volumes, dependendo de sua infraestrutura.
KubernetesMemoryPressure
Esse alerta indica que o uso de memória está muito alto no nó do Kubernetes.
Os nós do Kubernetes com tipo de incidente MemoryPressure ocorrem quando um nó do cluster do Kubernetes está com pouca memória, o que pode ser causado por um vazamento de memória em um aplicativo. Esse tipo de incidente requer atenção imediata para evitar tempo de inatividade e garantir o funcionamento adequado do cluster do Kubernetes.
Se esse alerta for disparado, tente identificar o pod no nó que está consumindo mais memória, seguindo estas etapas:
-
Recupere as estatísticas de CPU e memória dos nós:
kubectl top nodekubectl top node -
Recupere os pods em execução no nó:
kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=${NODE_NAME}kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=${NODE_NAME} -
Verifique o uso de memória para pods em um namespace usando:
kubectl top pod --namespace <namespace> kubectl logs -f <pod-name> -n <ns>kubectl top pod --namespace <namespace> kubectl logs -f <pod-name> -n <ns>
Se você conseguir identificar qualquer pod com alto uso de memória, verifique os logs do pod e procure erros de vazamento de memória.
Para resolver o problema, aumente a especificação de memória para os nós, se possível.
Se o problema persistir, gere o pacote de suporte e entre em contato com o Suporte da UiPath®.
KubePersistentVolumeFillingUp
When Warning: The available space is less than 30% and is likely to fill up within four days.
When Critical: The available space is less than 10%.
Para qualquer serviço que fique sem espaço, pode ser difícil recuperar os dados, portanto, os volumes devem ser redimensionados antes de atingir 0% de espaço disponível.
Para obter instruções, consulte Configuração do cluster.
Para alertas específicos do Prometheus, consulte PrometheusStorageUsage para obter detalhes.
KubePersistentVolumeErrors
O PersistentVolume não pode ser provisionado. Isso significa que qualquer serviço que exija o volume não será iniciado. Verifique se há outros erros com armazenamento Longhorn e/ou Ceph e entre em contato com o Suporte da UiPath®.
node-exporter
NodeFilesystemSpaceFillingUp
O sistema de arquivos em um nó específico está sendo preenchido completamente.
Ao surgir esse alerta, considere as etapas a seguir:
-
Confirme se o nó está sob
DiskPressureusando o seguinte comando:kubectl describe node <node-name>kubectl describe node <node-name>Identifique a condição
DiskPressurena saída. -
Limpe os logs e arquivos temporários. Verifique se há arquivos de log grandes em
/var/log/e limpe-os, se possível. -
Verifique o uso do espaço em disco no nó afetado:
df -hdf -h
Isso mostra o uso do disco em todos os sistemas de arquivos montados. Identificar onde está o alto uso.
- Se o disco estiver cheio e a limpeza for insuficiente, considere redimensionar o disco para o nó (principalmente em ambientes de nuvem, como AWS ou GCP). Esse processo pode envolver a expansão de volumes, dependendo de sua infraestrutura.
NodeFilesystemAlmostOutOfSpace
O sistema de arquivos em um nó específico está sendo preenchido completamente. Provisione mais espaço adicionando um disco ou montando discos não utilizados.
NodeFilesystemFilesFillingUp
O sistema de arquivos em um nó específico está sendo preenchido completamente. Provisione mais espaço adicionando um disco ou montando discos não utilizados.
NodeFilesystemAlmostOutOfFiles
O sistema de arquivos em um nó específico está sendo preenchido completamente. Provisione mais espaço adicionando um disco ou montando discos não utilizados.
NodeNetworkReceiveErrs
Esses erros indicam que o driver de rede está relatando um número alto de falhas. Isso pode ser causado por falhas de hardware físico ou configuração incorreta na rede física. Esse problema pertence ao sistema operacional e não é controlado pelo aplicativo UiPath®.
O alerta é acionado monitorando o contador/proc/net/dev que o kernel do Linux fornece.
Entre em contato com seu administrador de rede e a equipe que gerencia a infraestrutura física.
NodeNetworkTransmitErrs
Esses erros indicam que o driver de rede está relatando um número alto de falhas. Isso pode ser causado por falhas de hardware físico ou configuração incorreta na rede física. Esse problema pertence ao sistema operacional e não é controlado pelo aplicativo UiPath®.
O alerta é acionado monitorando o contador/proc/net/dev que o kernel do Linux fornece.
Entre em contato com seu administrador de rede e a equipe que gerencia a infraestrutura física.
ceph.rule, cluster-state-alert.rule
CephClusterErrorState
Este alerta indica que o cluster de armazenamento Ceph está em estado de erro por mais de 10m.
Este alerta reflete que a tarefa rook-ceph-mgr esteve em estado de erro por um período de tempo inaceitável. Verifique se há outros alertas que possam ter sido acionados antes deste e solucione-os primeiro.
kubectl describe cephcluster -n rook-ceph
kubectl describe cephcluster -n rook-ceph
CephMonQuorumAtRisk
Esse alerta indica que o quorum do cluster de armazenamento está baixo.
Múltiplos mons trabalham juntos para fornecer redundância; isso é possível porque cada um mantém uma cópia dos metadados. O cluster é implantado com 3 mons e requer 2 ou mais mons para estar em funcionamento para quorum e para que as operações de armazenamento sejam executadas. Se o quorum for perdido, o acesso aos dados estará em risco.
Se esse alerta for disparado, verifique se algum OSD está no estado de término, se houver algum, force a exclusão desses pods e aguarde algum tempo até que o operador se reconcilie. Se o problema persistir, entre em contato com o Suporte da UiPath®.
CephMgrIsAbsent
Esse alerta indica que o Ceph Manager desapareceu da descoberta de destino do Prometheus.
Se esse alerta for disparado, verifique e se o pod do Ceph Manager está funcionando e íntegro. Se o pod estiver íntegro, verifique os logs e verifique se o pod está habilitado para emitir métricas do Prometheus.
Nó Ceph Abaixo
Esse alerta indica que um nó que executa pods do Ceph está inativo. Embora as operações de armazenamento continuem a funcionar, pois o Ceph foi projetado para lidar com uma falha de nó, é recomendável resolver o problema para minimizar o risco de outro nó ficar inativo e afetar as funções de armazenamento.
Se esse alerta for disparado, no caso de um cluster de vários nós, o pod deverá ser agendado em outro nó. Certifique-se de que os novos pods osd no namespace rook-ceph estejam em execução e em estado íntegro no novo nó.
Você pode verificar a falha do nó descrevendo o nó usando o seguinte comando:
kubectl get nodes
kubectl get nodes
Verifique o nó para identificar a causa raiz do problema e entre em contato com o Suporte da UiPath®.
cluster-utilization-alert.rules
CephClusterNearFull
Esse alerta indica que a utilização do cluster de armazenamento Ceph ultrapassou 75% e se tornará somente leitura em 85%.
Se esse alerta for disparado, libere algum espaço no Ceph excluindo alguns conjuntos de dados não utilizados no AI Center ou expanda o armazenamento disponível para o Ceph PVC.
Antes de redimensionar o PVC, certifique-se de atender aos requisitos de armazenamento. Para obter detalhes, consulte Avaliando suas necessidades de armazenamento.
CephClusterCriticallyFull
Esse alerta indica que a utilização do cluster de armazenamento Ceph superou 80% e se tornará somente leitura aos 85%.
Se esse alerta for disparado, libere algum espaço no Ceph excluindo alguns conjuntos de dados não utilizados no AI Center ou expanda o armazenamento disponível para o Ceph PVC.
Antes de redimensionar o PVC, certifique-se de atender aos requisitos de armazenamento. Para obter detalhes, consulte Avaliando suas necessidades de armazenamento.
CephClusterReadOnly
Esse alerta indica que a utilização do cluster de armazenamento do Ceph ultrapassou 85% e se tornará somente leitura agora. Libere algum espaço ou expanda o cluster de armazenamento imediatamente.
Se esse alerta for disparado, libere algum espaço no Ceph excluindo alguns conjuntos de dados não utilizados no AI Center ou expanda o armazenamento disponível para o Ceph PVC.
Antes de redimensionar o PVC, certifique-se de atender aos requisitos de armazenamento. Para obter detalhes, consulte Avaliando suas necessidades de armazenamento.
osd-alert.rules
CephOSDCriticallyFull
Quando a gravidade do alerta é Critical, o espaço disponível é inferior a 20%.
Para qualquer serviço que fique sem espaço, pode ser difícil recuperar os dados, portanto, você deve redimensionar os volumes antes de atingir 10% de espaço disponível. Consulte as seguintes instruções: Configuração do cluster.
CephOSDNearFull
Esse alerta indica que a utilização do cluster de armazenamento Ceph ultrapassou 75% e se tornará somente leitura em 85%.
Se esse alerta for disparado, libere algum espaço no Ceph excluindo alguns conjuntos de dados não utilizados no AI Center ou expanda o armazenamento disponível para o Ceph PVC.
Antes de redimensionar o PVC, certifique-se de atender aos requisitos de armazenamento. Para obter detalhes, consulte Avaliando suas necessidades de armazenamento.
PersistentVolumeUsageNearFull
Esse alerta indica que a utilização do cluster de armazenamento Ceph ultrapassou 75% e se tornará somente leitura em 85%.
Se esse alerta for disparado, libere algum espaço no Ceph excluindo alguns conjuntos de dados não utilizados no AI Center ou expanda o armazenamento disponível para o Ceph PVC.
Antes de redimensionar o PVC, certifique-se de atender aos requisitos de armazenamento. Para obter detalhes, consulte Avaliando suas necessidades de armazenamento.
CephOSFlaping
Esse alerta indica que o daemon de armazenamento foi reiniciado mais de 5 vezes nos últimos 5 minutos.
Se esse alerta disparar, siga os seguintes passos:
-
Verifique a integridade do cluster do Ceph. O YO deve executar
ceph statusna caixa de ferramentas do Ceph para identificar os OSDs flutuantes:kubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph statuskubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph statusVocê pode identificar o pod de ferramentas do Ceph listando os pods no namespace:
kubectl -n rook-ceph get pod | grep toolskubectl -n rook-ceph get pod | grep tools -
Verifique os logs do OSD para o pod do OSD para identificar problemas:
kubectl -n rook-ceph logs <osd-pod>kubectl -n rook-ceph logs <osd-pod> -
Identificar problemas no nível do nó:
-
Verifique o uso do recurso:
kubectl top node <node-name>kubectl top node <node-name> -
Verifique a integridade do disco. Você precisa fazer o SSH no nó e executar
df -hedmesgpara verificar os erros do disco.
-
-
Reinicie o pod do OSD. Se o problema for transitório, será necessário reiniciar o pod do OSD:
kubectl -n rook-ceph delete pod <osd-pod>kubectl -n rook-ceph delete pod <osd-pod> -
Certifique-se de que não haja problemas de conectividade de rede entre os OSDs e os monitores Ceph.
-
Se necessário, marque temporariamente o OSD abaulado como
out:ceph osd out <osd-id>ceph osd out <osd-id> -
Continue a monitorar o cluster para garantir que o problema não se repita.
CephOSDDiskNotResponding
Esse alerta indica que o dispositivo de disco do host não está respondendo.
Se esse alerta disparar, siga os seguintes passos:
-
Verifique o status do cluster do Ceph. Você precisa confirmar a integridade geral do cluster do Ceph e obter mais detalhes sobre o status do OSD:
-
Execute o seguinte comando dentro do pod da caixa de ferramentas do Ceph:
kubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph statuskubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph status -
Identifique o pod de ferramentas do Ceph listando os pods no namespace:
kubectl -n rook-ceph get pod | grep toolskubectl -n rook-ceph get pod | grep tools
-
-
Verifique o status do pod do OSD. Você precisa verificar se os pods OSD estão em execução. Execute o seguinte comando para verificar todos os status do pod OSD:
kubectl -n rook-ceph get pods | grep osdkubectl -n rook-ceph get pods | grep osdSe algum pod do OSD estiver em um estado
CrashLoopBackOffouPending, isso pode indicar um problema com o disco OSD ou o nó subjacente. -
Reinicie o pod do OSD afetado. Se um pod do OSD estiver em um estado defeituoso (
CrashLoopBackOff,Erroretc.), você deve reiniciar o pod para ver se o problema se resolve sozinho. O Kubernetes tenta reagendar o pod automaticamente.kubectl -n rook-ceph delete pod <osd-pod>kubectl -n rook-ceph delete pod <osd-pod>O pod OSD será reiniciado e, se for um problema transitório, isso pode resolvê-lo.
-
Verifique os logs do OSD. Se a reinicialização não resolver o problema, verifique os logs do pod OSD para obter mais detalhes sobre o motivo pelo qual o disco não está respondendo:
kubectl -n rook-ceph logs <osd-pod>kubectl -n rook-ceph logs <osd-pod>Procure por erros relacionados ao disco ou outros problemas (por exemplo, erros de E/S, falhas de montagem).
-
Identificar problemas no nível do nó. Se o disco OSD não estiver montado corretamente ou tiver sido desconectado, faça login no nó afetado e verifique o status de montagem do disco:
ssh <node> df -hssh <node> df -hProcure por discos ausentes ou não montados que o Ceph está esperando. Se necessário, remonte o disco ou substitua-o se ele tiver falhado.
CephOSDDiskIndisponível
Esse alerta indica que o disco OSD do Ceph não está acessível no host.
Se esse alerta disparar, siga os seguintes passos:
-
Verifique o status do cluster do Ceph. Você precisa confirmar a integridade geral do cluster do Ceph e obter mais detalhes sobre o status do OSD:
-
Execute o seguinte comando dentro do pod da caixa de ferramentas do Ceph:
kubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph statuskubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph status -
Identifique o pod de ferramentas do Ceph listando os pods no namespace:
kubectl -n rook-ceph get pod | grep toolskubectl -n rook-ceph get pod | grep tools
-
-
Verifique o status do pod do OSD. Você precisa verificar se os pods OSD estão em execução. Execute o seguinte comando para verificar todos os status do pod OSD:
kubectl -n rook-ceph get pods | grep osdkubectl -n rook-ceph get pods | grep osdSe algum pod do OSD estiver em um estado
CrashLoopBackOffouPending, isso pode indicar um problema com o disco OSD ou o nó subjacente. -
Reinicie o pod do OSD afetado. Se um pod do OSD estiver em um estado defeituoso (
CrashLoopBackOff,Erroretc.), você deve reiniciar o pod para ver se o problema se resolve sozinho. O Kubernetes tenta reagendar o pod automaticamente.kubectl -n rook-ceph delete pod <osd-pod>kubectl -n rook-ceph delete pod <osd-pod>O pod OSD será reiniciado e, se for um problema transitório, isso pode resolvê-lo.
-
Verifique os logs do OSD. Se a reinicialização não resolver o problema, verifique os logs do pod OSD para obter mais detalhes sobre o motivo pelo qual o disco não está respondendo:
kubectl -n rook-ceph logs <osd-pod>kubectl -n rook-ceph logs <osd-pod>Procure por erros relacionados ao disco ou outros problemas (por exemplo, erros de E/S, falhas de montagem).
persistent-volume-alert.rules
PersistentVolumeUsageCritical
Se esse alerta for disparado, libere algum espaço no Ceph excluindo alguns conjuntos de dados não utilizados no AI Center ou expanda o armazenamento disponível para o Ceph PVC.
Antes de redimensionar o PVC, certifique-se de atender aos requisitos de armazenamento. Para obter detalhes, consulte Avaliando suas necessidades de armazenamento.
pool-quota.rules
CephPoolQuotaBytesCriticallyExhausted
Esse alerta indica que o uso do pool de armazenamento do Ceph ultrapassou 90%.
Se esse alerta disparar, libere algum espaço no CEPH excluindo alguns conjuntos de dados não utilizados no AI Center ou expanda o armazenamento disponível para o Ceph PVC.
Antes de redimensionar o PVC, certifique-se de atender aos requisitos de armazenamento. Para obter detalhes, consulte Avaliando suas necessidades de armazenamento.
host-disk
LowDiskForRancherPartition
Este alerta indica que o espaço livre para a partição /var/lib/rancher é menor que:
- 25% - a gravidade do alerta é crítica
Você deve fazer logon no servidor host e verificar o uso do disco. Você pode usar comandos como df -h /var/lib/rancher para verificar o espaço em disco disponível. Se você estiver com pouco espaço, considere as seguintes opções:
-
Limpe os arquivos desnecessários. Ao longo do tempo, arquivos de log, arquivos temporários, dados órfãos e backups podem consumir uma quantidade significativa de espaço. A limpeza regular desses arquivos pode ajudar a manter o espaço em disco.
-
Redimensionar a partição. Se seu sistema de arquivos o suportar, e se houver espaço disponível não utilizado em seu disco, você pode redimensionar a partição para fornecer mais espaço em disco.
-
Adicione mais espaço em disco. Se as opções anteriores não forem suficientes e se sua infraestrutura permitir, aumente o tamanho do disco para o funcionamento adequado do Rancher.
-
Verifique o uso de armazenamento para arquivos anormalmente grandes:
find /var/lib/rancher -type f -exec du -h {} + | sort -rh | head -n 10find /var/lib/rancher -type f -exec du -h {} + | sort -rh | head -n 10 -
Verifique se há contêineres que estejam gravando arquivos grandes no disco.
LowDiskForKubeletPartition
Este alerta indica que o espaço livre para a partição /var/lib/kubelet é menor que:
- 25% - a gravidade do alerta é crítica
Se esse alerta disparar, aumente o tamanho do disco.
LowDiskForVarPartition
Este alerta indica que o espaço livre para a partição /var é menor que:
- 25% - a gravidade do alerta é crítica
Isso pode acontecer devido ao depósito de logs do sistema de contêineres.
Se esse alerta disparar, siga os seguintes passos:
-
Verifique o uso do armazenamento:
find /var/ -type f -exec du -h {} + | sort -rh | head -n 10find /var/ -type f -exec du -h {} + | sort -rh | head -n 10 -
Aumente o tamanho do disco.
PoucoDiscoParaPartiçãoDeVarLog
Este alerta indica que o espaço livre para a partição /var/lib/var é menor que:
- 25% - a gravidade do alerta é crítica
Se esse alerta disparar, aumente o tamanho do disco.
- kubernetes-system
- KubernetesDiskPressure
- KubernetesMemoryPressure
- KubePersistentVolumeFillingUp
- KubePersistentVolumeErrors
- node-exporter
- NodeFilesystemSpaceFillingUp
- NodeFilesystemAlmostOutOfSpace
- NodeFilesystemFilesFillingUp
- NodeFilesystemAlmostOutOfFiles
- NodeNetworkReceiveErrs
- NodeNetworkTransmitErrs
- ceph.rule, cluster-state-alert.rule
- CephClusterErrorState
- CephMonQuorumAtRisk
- CephMgrIsAbsent
- Nó Ceph Abaixo
- cluster-utilization-alert.rules
- CephClusterNearFull
- CephClusterCriticallyFull
- CephClusterReadOnly
- osd-alert.rules
- CephOSDCriticallyFull
- CephOSDNearFull
- PersistentVolumeUsageNearFull
- CephOSFlaping
- CephOSDDiskNotResponding
- CephOSDDiskIndisponível
- persistent-volume-alert.rules
- PersistentVolumeUsageCritical
- pool-quota.rules
- CephPoolQuotaBytesCriticallyExhausted
- host-disk
- LowDiskForRancherPartition
- LowDiskForKubeletPartition
- LowDiskForVarPartition
- PoucoDiscoParaPartiçãoDeVarLog