Monitoramento de componentes do plano de controle, incluindo APIServer, Controller-manager (referido como CM), Scheduler, etc.
1、APIServidor
A função principal do APIServer é a entrada geral da API do cluster Kubernetes. Kube-Proxy, Kubelet, Controller-Manager, Scheduler, etc., todos precisam chamar o APIServer, para que o monitoramento do APIServer possa ser resolvido completamente de acordo com a metodologia RED O núcleo é o rendimento e o atraso da solicitação.
- apiserver_request_total: O indicador do volume de solicitações, que pode contar o número de solicitações por segundo e a taxa de sucesso.
- apiserver_request_duration_seconds: o indicador demorado da solicitação.
- apiserver_current_inflight_requests: O número de solicitações atualmente processadas pelo APIServer, divididas em mutação (solicitações sem obtenção, lista e observação) e somente leitura (solicitações de obtenção, lista e observação). Solicitações excessivas limitarão o fluxo, portanto, este indicador é muito importante para nós É útil observar o nível do volume.
2、Controlador-gerente
O gerenciador-controlador é responsável por monitorar o estado do objeto e compará-lo com o estado esperado. Se o status for inconsistente, ajuste-o, concentrando-se no número de tarefas, na profundidade da fila, etc.
- workqueue_adds_total: O número total de tarefas recebidas por cada controlador.
- workqueue_profundidade: A profundidade da fila de cada controlador, indicando o número de tarefas em cada controlador, quanto maior o número, mais ocupado ele está.
- workqueue_queue_duration_seconds: O tempo de espera da tarefa na fila é contado separadamente pelo controlador.
- workqueue_work_duration_seconds: O tempo desde o momento em que uma tarefa é retirada da fila até o momento em que é processada é contado separadamente pelo controlador.
- workqueue_retries_total: o número de novas tentativas para tarefas que entram na fila.
3、Agendador
O Agendador é responsável por escalonar objetos para Nós apropriados na arquitetura Kubernetes.Durante esse processo, haverá uma série de cálculos e triagens de regras, com foco nos indicadores relevantes de escalonamento desta ação.
- leader_election_master_status: O status de eleição mestre do agendador, 1 significa mestre, 0 significa backup.
- agendador_queue_incoming_pods_total: o número de pods que entram na fila de agendamento.
- agendador_pending_pods: o número de pods pendentes.
- agendador_pod_scheduling_attempts: distribuição do número de novas tentativas de agendamento antes que o agendamento do pod seja bem-sucedido.
- agendador_framework_extension_point_duration_seconds: A distribuição do atraso do ponto de extensão da estrutura de agendamento, contada por extension_point.
- agendador_schedule_attempts_total: O número de tentativas contadas de acordo com os resultados do agendamento, "não programável" significa que o agendamento não pode ser executado e "erro" significa um erro interno no agendador.
4、etcd
O etcd desempenha um papel importante na arquitetura Kubernetes e é relativamente estável. No entanto, o etcd tem altos requisitos para E/S de disco rígido, então você precisa se concentrar nos indicadores relacionados a E/S. Recomenda-se usar pelo menos discos SSD para armazenamento na produção ambiente.
- etcd_server_has_leader: Se o etcd tem um líder.
- etcd_server_leader_changes_seen_total: Cortar ocasionalmente o líder não é um grande problema, mas deve-se prestar atenção às mudanças frequentes de líder.
- etcd_server_proposals_failed_total: O número de propostas com falha.
- etcd_disk_backend_commit_duration_seconds: O tempo gasto na confirmação.
- etcd_disk_wal_fsync_duration_seconds: A sincronização do log Wal consome muito tempo.
5.KSM
Componente Kube-state-metrics, muitos indicadores coletados são usados apenas como meta-informação, pode não ser tão útil retirá-lo sozinho, mas pode ser útil quando conectado com outros indicadores como group_left e group_right.
- kube_node_status_condition: status do nó, status anormal, pressão do disco, etc. podem ser encontrados por meio deste indicador.
- kube_pod_container_status_last_terminated_reason: o motivo pelo qual o contêiner parou.
- kube_pod_container_status_waiting_reason: o motivo pelo qual o contêiner está em estado de espera.
- kube_pod_container_status_restarts_total: o número de reinicializações do contêiner.
- kube_deployment_spec_replicas: o número de réplicas esperadas pela configuração de implantação.
- kube_deployment_status_replicas_available: o número real de réplicas disponíveis para a implantação.
Este artigo é uma nota de estudo para o dia 11 de agosto. O conteúdo vem do Geek Time "Notas Práticas do Sistema de Monitoramento de Operação e Manutenção". Este curso é recomendado.