Nesta página, você encontra uma visão geral das opções de registro disponíveis no Google Kubernetes Engine (GKE).
Visão geral
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.
Registros do sistema, incluindo os listados nos registros disponíveis.
Registros do aplicativo, que 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.
Também é possível configurar um cluster Standard para capturar apenas registros do sistema e não 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. Os registros são coletados usando um agente baseado em fluentbit.
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ívelERROR. Os registros estruturados podem incluir um camposeverity, 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 disponíveis
Se você optar por enviar registros ao Cloud Logging, será necessário enviar registros do sistema e, opcionalmente, registros de outras fontes.
A tabela a seguir indica os valores compatíveis com a flag --logging para os comandos
create e
update.
| Origem do registro | valor --logging |
Registros coletados |
|---|---|---|
| Nenhum | NONE |
Nenhum registro enviado ao Cloud Logging, nenhum agente de coleta de registros instalado no cluster. Esse valor não é compatível com clusters do Autopilot. |
| Sistema | SYSTEM |
Coleta registros dos seguintes itens:
Também coleta eventos do Kubernetes. Esse valor é obrigatório para todos os tipos de cluster. |
| Cargas de trabalho | WORKLOAD |
Todos os registros gerados por contêineres que não são do sistema em execução nos nós do usuário. Esse valor é ativado por padrão, mas opcional para todos os tipos de cluster. |
| Servidor de API | API_SERVER |
Todos os registros gerados por kube-apiserver. Esse valor é
opcional para todos os tipos de cluster.
|
| Programador | SCHEDULER |
Todos os registros gerados por kube-scheduler. Esse valor é
opcional para todos os tipos de cluster.
|
| Controller Manager | CONTROLLER_MANAGER |
Todos os registros gerados por kube-controller-manager. Esse valor
é opcional para todos os tipos de cluster.
|
Registros ativados por padrão no GKE Enterprise
Quando você cria um cluster do GKE no Google Cloud, os registros de carga de trabalho são ativados por padrão em todos os clusters do Autopilot, podem ser desativadas.
Para projetos da edição GKE Enterprise, outros registros e métricas úteis serão ativados por padrão se você se registrar em uma frota durante a criação do cluster.
) indica quais registros são ativados por padrão quando você cria e registra um novo cluster em um projeto com o GKE Enterprise ativado:
| Nome do registro | Piloto automático | Padrão |
|---|---|---|
| Sistema | ||
| Cargas de trabalho | - | |
| Servidor de API | ||
| Programador | ||
| Controller Manager |
Os registros do plano de controle (servidor de API, programador e gerenciador do controlador) geram cobranças do Cloud Logging.
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.
Há cobrança pelos custos de armazenamento acumulados ao exportar registros para outro serviço do Google Cloud, como o BigQuery. Para os custos associados ao Cloud Logging, consulte Preços.
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.