Usando Cloud Native Operations (CNO) para Visibilidade

  • Versão de lançamento: Washingtondc
  • Atualizado 1 de fev. de 2024
  • 2 min. de leitura

    • Cloud Native Operations (CNO) para Visibilidade detecta mudanças nos recursos em um cluster Kubernetes. Ele executa a descoberta contínua, relata todas as mudanças para sua instância e atualiza o Configuration Management Database (CMDB) com os dados mais recentes.

    CNO para Visibilidade permite que você obtenha visibilidade dos clusters Kubernetes locais, bem como das seguintes implantações de nuvem: Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), Azure Kubernetes Engine (AKS), Red Hat OpenShifte Fazendeiro.

    Como ele funciona

    Quando você implanta CNO para Visibilidade, Kubernetes cria um recurso de implantação no cluster. Este recurso usa um segredo armazenado em Kubernetes para se conectar à sua instância ServiceNow.

    O recurso de implantação CNO contém um pod chamado Informer, que se conecta ao servidor de API Kubernetes e recebe dele eventos nos recursos no cluster. O Informer envia os dados coletados para a instância por meio da tabela Fila do canal de comunicação externo (ECC), usando a API da tabela ServiceNow para ler e gravar na fila. O Informer atualiza as tabelas apropriadas no CMDB.

    Nota:
    Se o Informer não puder relatar as mudanças, por exemplo, devido a um problema de rede, os recursos que foram adicionados ao cluster durante o evento serão adicionados ao CMDB após o próximo ciclo de descoberta completo. Os recursos que foram removidos do cluster durante o evento são marcados como ausentes e excluídos após dois ciclos de descoberta completos.

    Para obter mais informações sobre os recursos Kubernetes nos quais o Informer coleta dados e as tabelas CMDB que ele preenche, consulte Dados coletados por CNO para Visibilidade.

    Descoberta inicial e periódica

    Em sua descoberta inicial, o Informer encontra todos os recursos no cluster Kubernetes e os relata para sua instância. A cada 30 segundos, o Informer envia até 1 MB de dados para a instância. Normalmente, leva até dois minutos para relatar dados em um cluster que contém 1.000 pods e outro minuto para cada 1.000 pods adicionais. Um único pod do Informer pode lidar com um cluster com dezenas de milhares de pods. Se o Informer sair por qualquer motivo, Kubernetes o reiniciará automaticamente.

    Após a descoberta inicial, o Informer monitora continuamente a adição, a atualização e a exclusão de recursos no cluster. Os recursos que foram excluídos do cluster são marcados com install_status=Absent e excluídos do CMDB em horas em uma limpeza regular.

    Impacto do Informer no servidor de API Kubernetes

    O Informer tem impacto mínimo no servidor de API Kubernetes. Ele busca a lista completa de recursos relevantes apenas uma vez e a salva na memória. A partir de então, ele sincroniza com o servidor de API Kubernetes e nunca mais extrai a lista completa. Durante os ciclos de descoberta completos periódicos e sob demanda, o Informer reenvia a lista salva de recursos para a instância.

    CNO para parâmetro de comparação de desempenho e escalabilidade de visibilidade

    Para CNO para Benchmarks de visibilidade, consulte o artigo Resultados de desempenho do CNO para Visibilidade [KB1555851] na Base de conhecimento Now Support.