Sobre os registros do GKE

Nesta página, você encontra uma visão geral das opções de registro disponíveis no Google Kubernetes Engine (GKE).

Informações gerais

Os registros do GKE enviados ao Cloud Logging são armazenados em um repositório de dados dedicado e permanente. O próprio GKE armazena os registros, mas eles não são mantidos permanentemente. Por exemplo, os registros de contêiner do GKE são removidos quando o pod de host é removido, quando o disco no qual eles são armazenados fica sem espaço ou quando eles são substituídos por registros mais recentes. Os registros do sistema são periodicamente removidos para liberar espaço para novos. Os eventos de cluster são removidos após uma hora.

Agente do Logging do GKE

Para registros de contêiner e sistema, o GKE implanta por padrão um agente do Logging por nó, que lê registros de contêiner, adiciona metadados úteis e os armazena no Cloud Logging. O agente do Logging do GKE verifica se há registros de contêiner nas fontes abaixo:

Saídas e registros de erros padrão de processos em contêiner
kubelet e registros de ambiente de execução em contêiner
Registros de componentes do sistema, como scripts de inicialização de VM

Para eventos, o GKE usa uma implementação no namespace do kube-system que coleta eventos automaticamente e os envia para o Logging.

Quais registros são coletados

Por padrão, o GKE coleta vários tipos de registros do cluster e os armazena no Cloud Logging:

Os registros de auditoria incluem os registros de atividades do administrador, os registros de acesso aos dados e o log de eventos. Para informações detalhadas sobre os registros de auditoria do GKE, consulte a documentação Registros de auditoria do GKE. Os registros de auditoria do GKE não podem ser desativados.
Os registros do sistema incluem os registros das seguintes origens:
- Todos os pods em execução nos namespaces kube-system, istio-system, knative-serving, gke-system e config-management-system.
- Os principais serviços não conteinerizados, incluindo ambiente de execução docker/containerd, kubelet, kubelet-monitor, node-problem-detector e kube-container-runtime-monitor.
- A saída das portas seriais do nó, se os metadados da instância de VM serial-port-logging-enable estiverem definidos como true. A partir do GKE 1.16-13-gke.400, a saída de porta serial para nós é coletada pelo agente do Logging. Para desativar a geração de registros de saída da porta serial, defina --metadata serial-port-logging-enable=false durante a criação do cluster. A saída da porta serial é útil para solucionar falhas, inicializações com falha, problemas de inicialização ou problemas de desligamento com nós do GKE. Desativar esses registros pode dificultar a solução de problemas.
Registros do aplicativo: incluem todos os registros gerados por contêineres que não são do sistema em execução em nós do usuário.

Opcionalmente, o GKE pode coletar outros tipos de registros de determinados componentes do plano de controle do Kubernetes e armazená-los no Cloud Logging:

Os registros do servidor da API incluem todos os registros gerados pelo servidor da API do Kubernetes (kube-apiserver).
Os registros do programador incluem todos os registros gerados pelo programador do Kubernetes (kube-scheduler).
Os registros do gerenciador de controladores incluem todos os registros gerados pelo gerenciador de controladores do Kubernetes (kube-controller-manager).

Para saber mais sobre cada um desses componentes do plano de controle, consulte Arquitetura de clusters do GKE.

Como coletar seus registros

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

Os registros do sistema e do aplicativo são entregues no Roteador de registros no Cloud Logging.

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

A partir da versão 1.15.7 do GKE, é possível configurar um cluster Standard para capturar apenas registros do sistema, e não para coletar registros de aplicativos. Para clusters Autopilot e Standard, os filtros de exclusão permitem reduzir o volume de registros enviados ao Cloud Logging.

Capacidade de geração de registros

Quando a geração de registros do sistema é ativada, um agente do Cloud Logging dedicado é implantado e gerenciado automaticamente. Ele é executado em todos os nós do GKE em um cluster para coletar registros, adiciona metadados úteis sobre o contêiner, pod e cluster e depois envia os registros para o Cloud Logging usando um agente baseado em fluentbit.

Se algum nó do GKE exigir mais do que a capacidade de registro padrão e seu cluster do GKE Standard estiver usando a versão 1.23.13-gke.1000 ou mais recente do plano de controle, configure o GKE para implantar uma configuração alternativa do agente do Logging projetado para maximizar a capacidade de geração de registros.

Para mais informações, consulte Ajustar a capacidade de processamento do registro.

Coleta de registros com fluentd personalizado ou fluentbit

O agente de geração de registros padrão do GKE fornece uma solução gerenciada para implantar e gerenciar os agentes que enviam os registros dos clusters para o Cloud Logging. Dependendo da versão do plano de controle do GKE, o fluentd ou o fluentbit são usados para coletar registros. A partir do GKE 1.17, os registros são coletados usando um agente baseado em fluidos. Os clusters do GKE que usam versões anteriores ao GKE 1.17 usam um agente baseado em fluentd. Se você quiser alterar o comportamento padrão dos agentes fluentd, execute um agente fluentd personalizado ou um agente personalizado fluentbit.

Os casos de uso comuns incluem:

remover dados confidenciais dos registros
coletar outros registros não gravados em STDOUT ou STDERR
Usar configurações específicas relacionadas ao desempenho
Formatação de registro personalizada

Como coletar registros `auditd` do Linux para nós do GKE

É possível ativar registros de auditoria do sistema operacional detalhados nos nós do GKE que executam o Container-Optimized OS. Os registros do sistema operacional nos nós fornecem informações valiosas sobre o estado do cluster e das cargas de trabalho, como mensagens de erro, tentativas de login e execuções binárias. Use essas informações para depurar problemas ou investigar incidentes de segurança.

Para saber mais, consulte Como ativar registros auditd do Linux nos nós do GKE.

Registros de auditoria do GKE

Para informações detalhadas sobre entradas de registro que se aplicam aos tipos de recursos do cluster do Kubernetes e do GKE, acesse Geração de registros de auditoria.

Controle de acesso do Logging

Há dois aspectos de controle de acesso de registro: acesso a aplicativos e acesso de usuário. O Cloud Logging fornece papéis do Identity and Access Management (IAM) que podem ser usados para conceder o acesso apropriado.

Acesso ao aplicativo

Os aplicativos precisam de permissões para gravar registros no Cloud Logging. Para concedê-las, atribua o papel do IAM roles/logging.logWriter à conta de serviço anexada ao pool de nós subjacente.

Acesso de visualização de usuário

Você precisa ter o papel roles/logging.viewer para ver os registros no projeto. Se você precisa ter acesso aos registros de acesso a dados, precisa ter a permissão do IAM logging.privateLogViewer.

Para mais informações sobre permissões e papéis, acesse o guia Controle de acesso. É possível revisar as Práticas recomendadas para os Registros de auditoria do Cloud, que também se aplicam ao Cloud Logging em geral.

Acesso de administrador de usuário

Os papéis do IAM roles/logging.configWriter e roles/logging.admin fornecem os recursos administrativos. O papel do IAM roles/logging.configWriter é necessário a fim de criar um coletor de geração de registros comumente usado para direcionar os registros a um projeto específico ou centralizado. Por exemplo, talvez você queira usar um coletor de registro com um filtro de geração de registros para direcionar todos os seus registros de um namespace para um intervalo de registro centralizado.

Para saber mais, acesse o Controle de acesso do Cloud Logging.

Práticas recomendadas

Geração de registros estruturada: o agente de geração de registros integrado ao GKE lerá documentos JSON serializados para strings de linha única e gravados na saída padrão ou erro padrão e enviará ao Google Cloud Observability como entradas de registro estruturadas.
- Consulte Geração de registros estruturada para mais detalhes sobre como trabalhar com um agente do Logging integrado.
- É possível usar filtros de registros avançados para filtrar registros com base nos campos do documento JSON.
- Os registros gerados com glog terão os campos comuns analisados, por exemplo, severity, pid, source_file, source_line. No entanto, o payload da mensagem não é analisado e aparece literalmente na mensagem de registro resultante na observabilidade do Google Cloud.
Gravidades: por padrão, os registros gravados na saída padrão estão no nível INFO, e os registros gravados no erro padrão estão no nível ERROR. Os registros estruturados podem incluir um campo severity, que define a gravidade do registro.
Exportação para BigQuery: para realizar análises adicionais, exporte registros para serviços externos, como o BigQuery ou o Pub/Sub. Os registros exportados para o BigQuery mantêm o formato e a estrutura. Consulte Visão geral de roteamento e armazenamento para mais informações.
Alerta: ao registrar um comportamento inesperado, é possível usar métricas com base em registros para configurar políticas de alertas. Por exemplo, consulte Criar uma política de alertas em uma métrica de contador. Consulte Visão geral de métricas com base em registros para informações mais detalhadas.

Error Reporting: para coletar erros de aplicativos em execução nos clusters, use o Error Reporting.

Registros do plano de controle

É possível configurar um cluster do GKE para enviar registros emitidos pelo servidor da API do Kubernetes, pelo programador e pelo gerenciador de controladores ao Cloud Logging.

Requisitos

O envio de registros emitidos por componentes do plano de controle do Kubernetes para o Cloud Logging requer a versão 1.22.0 ou posterior do plano de controle do GKE e exige que a coleta de registros do sistema esteja ativada.

Como configurar a coleta de registros do plano de controle

Consulte as instruções para configurar o suporte à geração de registros para um novo cluster ou para um cluster atual.

Preços

Os registros do plano de controle do GKE são exportados para o Cloud Logging. Os preços do Cloud Logging são aplicáveis.

Cota

Os registros do plano de controle consomem a cota de "Solicitações de gravação por minuto" da API Cloud Logging. Antes de ativar os registros do plano de controle, verifique o pico de uso recente dessa cota. Se você tiver muitos clusters no mesmo projeto ou já estiver se aproximando do limite da cota, solicite um aumento no limite de cota antes de ativar os registros do plano de controle.

Controles de acesso

Para limitar o acesso na sua organização aos registros do plano de controle do Kubernetes, crie um bucket de registros separado com controles de acesso mais limitados.

Ao armazenar os registros do plano de controle em um bucket de registros separado com acesso limitado, eles não ficam automaticamente acessíveis para ninguém com acesso roles/logging.viewer ao projeto. Além disso, se você decidir excluir determinados registros do plano de controle por questões de privacidade ou segurança, armazene-os em um bucket de registros separado com acesso limitado a fim de excluí-los sem afetar os registros de outros componentes ou serviços.