Acerca dos registos do GKE

Esta página apresenta uma vista geral das opções de registo disponíveis no Google Kubernetes Engine (GKE).

Vista geral

Os registos do GKE enviados para o Cloud Logging são armazenados num repositório de dados dedicado e persistente. Embora o GKE armazene registos, estes não são armazenados permanentemente. Por exemplo, os registos de contentores do GKE são removidos quando o respetivo pod anfitrião é removido, quando o disco no qual estão armazenados fica sem espaço ou quando são substituídos por registos mais recentes. Os registos do sistema são removidos periodicamente para libertar espaço para novos registos. Os eventos de cluster são removidos após uma hora.

Agente de registos do GKE

Para os registos de contentores e do sistema, o GKE implementa, por predefinição, um agente de registo por nó que lê os registos de contentores, adiciona metadados úteis e, em seguida, armazena-os no Cloud Logging. O agente de registo do GKE verifica os registos de contentores nas seguintes origens:

• Registos de saída padrão e de erro padrão de processos em contentores

• Registos do kubelet e do tempo de execução do contentor

• Registos de componentes do sistema, como scripts de arranque de VMs

Para eventos, o GKE usa uma implementação no espaço de nomes kube-system que recolhe automaticamente eventos e envia-os para o Logging.

Que registos são recolhidos

Por predefinição, o GKE recolhe vários tipos de registos do seu cluster e armazena-os no Cloud Logging:

• Os registos de auditoria incluem o registo de atividade do administrador, o registo de acesso aos dados e o registo de eventos. Para obter informações detalhadas sobre os registos de auditoria do GKE, consulte a documentação Registos de auditoria do GKE. Não é possível desativar os registos de auditoria do GKE.

• Registos do sistema, incluindo os registos indicados nos registos disponíveis.

• Os registos de aplicações incluem todos os registos gerados por contentores não pertencentes ao sistema executados em nós do utilizador.

  As seguintes limitações podem fazer com que não seja possível enviar os registos da aplicação para o Cloud Logging:

  • Para registos JSON, as chaves JSON duplicadas não são suportadas.
  • stream é uma chave reservada no pipeline de registo do GKE. Uma chave stream no registo JSON da aplicação pode causar um comportamento inesperado e a eliminação de registos.
  • O Cloud Logging tem um limite de tamanho por LogEntry. Qualquer LogEntry que exceda o limite de tamanho é ignorado para registos jsonPayload e truncado para registos textPayload.

Opcionalmente, o GKE pode recolher tipos adicionais de registos de determinados componentes do plano de controlo do Kubernetes e armazená-los no Cloud Logging:

• Os registos do servidor da API incluem todos os registos gerados pelo servidor da API Kubernetes (kube-apiserver).

• Os registos do programador incluem todos os registos gerados pelo programador do Kubernetes (kube-scheduler).

• Os registos do gestor do controlador incluem todos os registos gerados pelo gestor do controlador do Kubernetes (kube-controller-manager).

Para saber mais acerca de cada um destes componentes do plano de controlo, consulte o artigo Arquitetura do cluster do GKE.

A recolher os seus registos

Quando cria um novo cluster do GKE, a integração com o Cloud Logging é ativada por predefinição.

Os registos de sistema e de aplicações são enviados para o encaminhamento de registos no Cloud Logging.

A partir daí, os registos podem ser carregados no Cloud Logging, excluídos ou exportados para o BigQuery, Pub/Sub ou Cloud Storage.

Também pode configurar um cluster padrão para capturar apenas registos do sistema e não recolher registos de aplicações. Para clusters do Autopilot e Standard, os filtros de exclusão permitem-lhe reduzir o volume de registos enviados para o Cloud Logging.

Débito de registo

Quando o registo do sistema está ativado, um agente do Cloud Logging dedicado é implementado e gerido automaticamente. É executado em todos os nós do GKE num cluster para recolher registos, adiciona metadados úteis sobre o contentor, o pod e o cluster e, em seguida, envia os registos para o Cloud Logging através de um agente baseado no fluentbit.

Se algum nó do GKE exigir mais do que o débito de registo predefinido e o cluster padrão do GKE estiver a usar a versão 1.23.13-gke.1000 ou posterior do plano de controlo, pode configurar o GKE para implementar uma configuração alternativa do agente de registo concebida para maximizar o débito de registo.

Para mais informações, consulte o artigo Ajuste o débito de registos.

Recolha de registos com fluentd ou fluentbit personalizado

O agente de registo predefinido do GKE oferece uma solução gerida para implementar e gerir os agentes que enviam os registos dos seus clusters para o Cloud Logging. Os registos são recolhidos através de um agente baseado no fluentbit.

Recolher registos auditd do Linux para nós do GKE

Pode ativar os registos de auditoria do sistema operativo detalhados em nós do GKE que executam o SO otimizado para contentores. Os registos do sistema operativo nos seus nós fornecem informações valiosas sobre o estado do cluster e das cargas de trabalho, como mensagens de erro, tentativas de início de sessão e execuções binárias. Pode usar estas informações para depurar problemas ou investigar incidentes de segurança.

Para saber mais, consulte o artigo Ativar registos auditd do Linux em nós do GKE.

Registos de auditoria do GKE

Para ver informações detalhadas sobre as entradas de registo que se aplicam aos tipos de recursos do cluster do Kubernetes e das operações do cluster do GKE, aceda a Registo de auditoria.

Controlo de acesso ao registo

Existem dois aspetos do registo do controlo de acesso: acesso à aplicação e acesso do utilizador. O Cloud Logging fornece funções da gestão de identidade e de acesso (IAM) que pode usar para conceder o acesso adequado.

Acesso à aplicação

As aplicações precisam de autorizações para escrever registos no Cloud Logging, que são concedidas através da atribuição da função de IAM roles/logging.logWriter à conta de serviço associada ao conjunto de nós subjacente.

Acesso à vista do utilizador

Tem de ter a função de roles/logging.viewer para ver os registos no seu projeto. Se precisar de ter acesso aos registos de acesso aos dados, tem de ter a autorização de IAM logging.privateLogViewer.

Para mais informações sobre autorizações e funções, aceda ao guia de Controlo de acesso. Também pode rever as práticas recomendadas para os registos de auditoria do Cloud, que também se aplicam ao Cloud Logging em geral.

Acesso de administrador de utilizadores

As funções IAM roles/logging.configWriter e roles/logging.admin oferecem as capacidades administrativas. A função roles/logging.configWriter é necessária para criar um destino de registo, que é usado frequentemente para direcionar os seus registos para um projeto específico ou centralizado. Por exemplo, pode querer usar um sink de registo juntamente com um filtro de registo para direcionar todos os registos de um espaço de nomes para um contentor de registo centralizado.

Para saber mais, aceda ao guia Controlo de acesso do Cloud Logging.

Práticas recomendadas

• Registo estruturado: o agente de registo integrado com o GKE lê documentos JSON serializados em strings de linha única e escritos no resultado padrão ou no erro padrão, e envia-os para o Google Cloud Observability como entradas de registo estruturadas.
  • Consulte a secção Registo estruturado para ver mais detalhes sobre como trabalhar com um agente de registo integrado.
  • Pode usar filtros de registos avançados para filtrar registos com base nos campos do documento JSON.
  • Os registos gerados com glog vão ter os campos comuns analisados, por exemplo, severity, pid, source_file, source_line. No entanto, a carga útil da mensagem em si não é analisada e é apresentada literalmente na mensagem de registo resultante no Google Cloud Observability.
• Gravidades: por predefinição, os registos escritos na saída padrão estão no nível INFO e os registos escritos no erro padrão estão no nível ERROR. Os registos estruturados podem incluir um campo severity, que define a gravidade do registo.
• Exportar para o BigQuery: para uma análise adicional, pode exportar registos para serviços externos, como o BigQuery ou o Pub/Sub. Os registos exportados para o BigQuery mantêm o respetivo formato e estrutura. Consulte a vista geral do encaminhamento e armazenamento para mais informações.

• Alertas: quando o registo regista um comportamento inesperado, pode usar métricas baseadas em registos para configurar políticas de alertas. Para ver um exemplo, consulte o artigo Crie uma política de alerta numa métrica de contador. Para obter informações detalhadas sobre métricas baseadas em registos, consulte o artigo Vista geral das métricas baseadas em registos.

• Relatório de erros: para recolher erros de aplicações em execução nos seus clusters, pode usar o relatório de erros.

Registos disponíveis

Se optar por enviar registos para o Cloud Logging, tem de enviar registos do sistema e, opcionalmente, pode enviar registos de origens adicionais.

A tabela seguinte indica os valores suportados para a flag --logging para os comandos create e update.

Origem do registo	Valor: --logging	Registos recolhidos
Nenhum	NONE	Não foram enviados registos para o Cloud Logging; não foi instalado nenhum agente de recolha de registos no cluster. Este valor não é suportado para clusters do Autopilot.
Sistema	SYSTEM	Recolhe registos do seguinte: Todos os pods em execução nos espaços de nomes kube-system, istio-system, knative-serving, gke-system e config-management-system. Serviços que não estão contentorizados, incluindo: Tempo de execução do docker/containerd, kubelet, kubelet-monitor, node-problem-detector e kube-container-runtime-monitor. A saída das portas série do nó, se os metadados da instância de VM serial-port-logging-enable estiverem definidos como true. Também recolhe eventos do Kubernetes. Este valor é obrigatório para todos os tipos de clusters.
Cargas de trabalho	WORKLOAD	Todos os registos gerados por contentores não pertencentes ao sistema em execução em nós de utilizador. Este valor está ativado por predefinição, mas é opcional para todos os tipos de clusters.
Servidor de API	API_SERVER	Todos os registos gerados por kube-apiserver. Este valor é opcional para todos os tipos de clusters.
Programador	SCHEDULER	Todos os registos gerados por kube-scheduler. Este valor é opcional para todos os tipos de clusters.
Gestor de comandos	CONTROLLER_MANAGER	Todos os registos gerados por kube-controller-manager. Este valor é opcional para todos os tipos de clusters.
Redimensionador automático horizontal de pods	KCP_HPA	Exporta os registos de decisões de recomendações atómicas e finais para cada objeto HPA no seu cluster do GKE. Para mais detalhes, consulte Ver eventos do redimensionador automático horizontal de pods.
Ligações de rede do plano de controlo	KCP_CONNECTION	Apenas disponível com a autoridade do plano de controlo do GKE Registos de ligações de rede de entrada para instâncias do plano de controlo do GKE. Para obter detalhes, consulte o artigo Valide as ligações da Google ao plano de controlo do cluster.
Eventos SSH do plano de controlo	KCP_SSHD	Apenas disponível com a autoridade do plano de controlo do GKE Gera registos para todos os eventos SSH, como a aceitação de chaves públicas e o encerramento da sessão, que ocorrem quando o pessoal da Google se liga às instâncias do plano de controlo do cluster durante os pedidos de apoio técnico ou para outro acesso administrativo. Para obter detalhes, consulte o artigo Valide as ligações da Google ao plano de controlo do cluster.

Quota

Os registos do plano de controlo consomem a quota de "Pedidos de escrita por minuto" da API Cloud Logging. Antes de ativar os registos do plano de controlo, verifique a sua utilização máxima recente dessa quota. Se tiver muitos clusters no mesmo projeto ou já estiver a aproximar-se do limite da quota, pode pedir um aumento do limite da quota antes de ativar os registos do plano de controlo.

Controlos de acesso

Se quiser limitar o acesso na sua organização aos registos do plano de controlo do Kubernetes, pode criar um contentor de registos separado com controlos de acesso mais limitados.

Ao armazená-los num contentor de registo separado com acesso limitado, os registos do plano de controlo no contentor de registo não ficam automaticamente acessíveis a ninguém com acesso ao projeto.roles/logging.viewer Além disso, se decidir eliminar determinados registos do plano de controlo devido a preocupações com a privacidade ou a segurança, o armazenamento dos mesmos num contentor de registos separado com acesso limitado permite eliminar os registos sem afetar os registos de outros componentes ou serviços.