Configuração da geração de registros e o monitoramento

O GKE em Bare Metal inclui várias opções de geração de registros e monitoramento de clusters, incluindo serviços gerenciados baseados em nuvem, ferramentas de código aberto e compatibilidade validada com soluções comerciais de terceiros. Nesta página, explicamos essas opções e fornecemos algumas orientações básicas sobre como selecionar a solução adequada para seu ambiente.

Opções para o GKE em Bare Metal

Há várias opções de geração de registros e monitoramento para o GKE em Bare Metal:

  • Cloud Logging e Cloud Monitoring, ativados por padrão nos componentes do sistema Bare Metal.
  • O Prometheus e o Grafana estão disponíveis no Cloud Marketplace.
  • Configurações validadas com soluções de terceiros

Cloud Logging e Cloud Monitoring

O pacote de operações do Google Cloud é a solução de observabilidade integrada do Google Cloud. Ele oferece uma solução de geração de registros totalmente gerenciada, coleta de métricas, monitoramento, uso de painéis e emissão de alertas. O Cloud Monitoring monitora o Anthos em clusters bare metal de maneira semelhante aos clusters do GKE baseados na nuvem.

É possível configurar os agentes para alterar o escopo de geração de registros e monitoramento, bem como o nível de métricas coletadas:

  • O escopo de geração de registros e monitoramento só pode ser definido como componentes do sistema (padrão) ou para componentes e aplicativos do sistema.
  • O nível das métricas coletadas pode ser configurado para um conjunto otimizado de métricas (padrão) ou para métricas completas.

Confira Como configurar agentes do Stackdriver para GKE em Bare Metal neste documento para mais informações.

O Logging e o Monitoring oferecem uma solução de observabilidade única, fácil de configurar e avançada, baseada na nuvem. Recomendamos o Logging e o Monitoring ao executar cargas de trabalho apenas no GKE em Bare Metal ou nas cargas de trabalho do GKE e do GKE em Bare Metal. Para aplicativos com componentes em execução no GKE em Bare Metal que exigem infraestrutura local e tradicional, considere outras soluções para uma visão completa desses aplicativos.

Prometheus e Grafana

O Prometheus e o Grafana são dois produtos de monitoramento de código aberto conhecidos disponíveis no Cloud Marketplace:

  • O Prometheus coleta métricas de aplicativo e sistema.

  • O Alertmanager gerencia o envio de alertas com vários mecanismos diferentes.

  • Grafana é uma ferramenta de painéis.

É possível ativar o Prometheus e o Grafana em cada cluster de administrador e cluster de usuário. O Prometheus e o Grafana são recomendados para equipes de aplicativos com experiência anterior nesses produtos. Esses produtos também são recomendados para equipes operacionais que preferem manter métricas de aplicativos no cluster e para solucionar problemas quando a conectividade de rede for perdida.

Soluções de terceiros

O Google trabalhou com vários provedores de soluções de monitoramento e geração de registros de terceiros para ajudar seus produtos a funcionarem bem com o GKE em Bare Metal. Entre eles, Datadog, Elastic e Splunk. Outros terceiros validados serão adicionados no futuro.

Os guias de solução a seguir estão disponíveis para usar soluções de terceiros com o GKE em Bare Metal:

Como funciona a geração de registros e o monitoramento do GKE em Bare Metal

O Cloud Logging e o Cloud Monitoring são instalados e ativados em cada cluster quando você cria um novo cluster de administrador ou de usuário.

Os agentes do Stackdriver incluem vários componentes em cada cluster:

  • Operador do Stackdriver (stackdriver-operator-*). Gerencia o ciclo de vida de todos os outros agentes do Stackdriver implantados no cluster.

  • Recurso personalizado do Stackdriver. Um recurso que é criado automaticamente como parte do processo de instalação do GKE em Bare Metal.

  • Agente de métricas do GKE (gke-metrics-agent-*). Um DaemonSet baseado no OpenTelemetry Collector que copia métricas de cada nó para o Cloud Monitoring. Um DaemonSet node-exporter e uma implantação kube-state-metrics também estão incluídos para fornecer mais métricas sobre o cluster.

  • Encaminhamento de registros do Stackdriver (stackdriver-log-forwarder-*). Um DaemonSet do Fluent Bit que encaminha os registros de cada máquina para o Cloud Logging. O encaminhador de registro armazena em buffer as entradas de registro no nó localmente e as envia por até quatro horas. Se o buffer ficar cheio ou se o encaminhador de registro não conseguir acessar a API Cloud Logging por mais de quatro horas, os registros serão descartados.

  • Agente de metadados do Anthos (stackdriver-metadata-agent-). Uma implantação que envia metadados de recursos do Kubernetes, como pods, implantações ou nós para a API Config Monitoring for Ops. Esses dados são usados para enriquecer consultas de métricas, permitindo consultas por nome de implantação, nome de nó ou até mesmo nome de serviço do Kubernetes.

Veja os agentes instalados pelo Stackdriver executando o seguinte comando:

kubectl -n kube-system get pods -l "managed-by=stackdriver"

A saída deste comando é semelhante a:

kube-system   gke-metrics-agent-4th8r                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-8lt4s                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-dhxld                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-lbkl2                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-pblfk                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-qfwft                                     1/1     Running   1 (40h ago)   40h
kube-system   kube-state-metrics-9948b86dd-6chhh                          1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-5s4pg                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-d9gwv                                         1/1     Running   2 (40h ago)   40h
kube-system   node-exporter-fhbql                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-gzf8t                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-tsrpp                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-xzww7                                         1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-8lwxh                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-f7cgf                             1/1     Running   2 (40h ago)   40h
kube-system   stackdriver-log-forwarder-fl5gf                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-q5lq8                             1/1     Running   2 (40h ago)   40h
kube-system   stackdriver-log-forwarder-www4b                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-xqgjc                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-metadata-agent-cluster-level-5bb5b6d6bc-z9rx7   1/1     Running   1 (40h ago)   40h

Métricas do Cloud Monitoring

Para consultar uma lista de métricas coletadas pelo Cloud Monitoring, confira Ver métricas do GKE em Bare Metal.

Como configurar agentes do Stackdriver para GKE em Bare Metal

Os agentes do Stackdriver instalados com GKE em Bare Metal coletam dados sobre componentes do sistema para manter e resolver problemas com os clusters. As seções a seguir descrevem os modos de configuração e operação do Stackdriver.

Somente componentes do sistema (modo padrão)

Após a instalação, os agentes do Stackdriver são configurados, por padrão, para coletar registros e métricas, incluindo detalhes de desempenho (por exemplo, uso de CPU e memória) e metadados semelhantes dos componentes de sistema fornecidos pelo Google. Isso inclui todas as cargas de trabalho no cluster de administrador e, para clusters de usuário, as cargas de trabalho nos namespaces kube-system, gke-system, gke-connect, istio-system e config-management-system.

Componentes do sistema e aplicativos.

Para ativar a geração de registros e o monitoramento de aplicativos no modo padrão, siga as etapas em Ativar a geração de registros e o monitoramento de aplicativos.

Métricas otimizadas (métricas padrão)

Por padrão, as implantações kube-state-metrics em execução no cluster coletam e informam um conjunto otimizado de métricas do kube para o pacote de operações do Google Cloud (antigo Stackdriver).

Menos recursos são necessários para coletar esse conjunto otimizado de métricas, o que melhora o desempenho e a escalonabilidade geral.

Para desativar as métricas otimizadas (não recomendado), modifique a configuração padrão no recurso personalizado do Stackdriver.

Como configurar recursos do componente Stackdriver

Ao criar um cluster, o GKE em Bare Metal cria automaticamente um recurso personalizado do Stackdriver. É possível editar a especificação no recurso personalizado para substituir os valores padrão das solicitações e limites de CPU e memória de um componente do Stackdriver, além de substituir separadamente a configuração padrão de métricas otimizadas.

Como modificar as solicitações e os limites padrão de CPU e memória para um componente do Stackdriver.

Os clusters com alta densidade de pods introduzem sobrecarga de geração de registros e monitoramento. Em casos extremos, os componentes do Stackdriver podem relatar perto do limite de CPU e de utilização de memória ou podem estar sujeitos a reinicializações constantes devido a limites de recursos. Nesse caso, para substituir os valores padrão de solicitações e limites de CPU e memória de um componente do Stackdriver, use as seguintes etapas:

  1. Execute o seguinte comando para abrir o recurso personalizado do Stackdriver em um editor de linha de comando:

    kubectl -n kube-system edit stackdriver stackdriver

  2. No recurso personalizado do Stackdriver, adicione a seção resourceAttrOverride no campo spec:

    resourceAttrOverride:
      DAEMONSET_OR_DEPLOYMENT_NAME/CONTAINER_NAME:
        LIMITS_OR_REQUESTS:
          RESOURCE: RESOURCE_QUANTITY

    Observe que a seção resourceAttrOverride substitui todos os limites e solicitações padrão existentes do componente que você especificar. Os seguintes componentes são compatíveis com resourceAttrOverride:

    • gke-metrics-agent/gke-metrics-agent
    • stackdriver-log-forwarder/stackdriver-log-forwarder
    • stackdriver-metadata-agent-cluster-level/metadata-agent
    • node-exporter/node-exporter
    • kube-state-metrics/kube-state-metrics

    Um arquivo de exemplo será parecido com o seguinte:

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
  name: stackdriver
  namespace: kube-system
spec:
  anthosDistribution: baremetal
  projectID: my-project
  clusterName: my-cluster
  clusterLocation: us-west-1a
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      requests:
        cpu: 110m
        memory: 240Mi
      limits:
        cpu: 200m
        memory: 4.5Gi

  3. Para salvar as alterações no recurso personalizado do Stackdriver, salve e saia do editor de linha de comando.

  4. Para verificar a integridade do pod:

    kubectl -n kube-system get pods -l "managed-by=stackdriver"

    Uma resposta para um pod íntegro é semelhante a esta:

    gke-metrics-agent-4th8r                1/1     Running   1   40h

  5. Para verificar a especificação do pod do componente para garantir que os recursos estão configurados corretamente:

    kubectl -n kube-system describe pod POD_NAME

    Substitua POD_NAME pelo nome do pod que você acabou de alterar. Por exemplo, gke-metrics-agent-4th8r.

    A resposta é semelhante a esta:

      Name:         gke-metrics-agent-4th8r
  Namespace:    kube-system
  ...
  Containers:
    gke-metrics-agent:
      Limits:
        cpu: 200m
        memory: 4.5Gi
      Requests:
        cpu: 110m
        memory: 240Mi
      ...

Desativar métricas otimizadas

Por padrão, as implantações kube-state-metrics em execução no cluster coletam e informam um conjunto otimizado de métricas do kube para o Stackdriver. Se você precisar de métricas adicionais, recomendamos que encontre um substituto na lista de Métricas do GKE em Bare Metal.

Veja alguns exemplos de substituições que podem ser usadas:

Métrica desativada Substituição
kube_pod_start_time container/uptime
kube_pod_container_resource_requests container/cpu/request_cores
container/memory/request_bytes
kube_pod_container_resource_limits container/cpu/limit_cores
container/memory/limit_bytes

Para desativar a configuração padrão de métricas otimizadas (não recomendado), faça o seguinte:

  1. Abra o recurso personalizado do Stackdriver em um editor de linha de comando:

    kubectl -n kube-system edit stackdriver stackdriver

  2. Defina o campo optimizedMetrics como false:

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
name: stackdriver
namespace: kube-system
spec:
anthosDistribution: baremetal
projectID: my-project
clusterName: my-cluster
clusterLocation: us-west-1a
optimizedMetrics: false

  3. Salve as alterações e saia do editor da linha de comando.

Servidor de métricas

O servidor de métricas é a origem das métricas de recursos do contêiner para vários pipelines de escalonamento automático. O Metrics Server recupera métricas de kubelets e as expõe por meio da API Metrics do Kubernetes. O HPA e o VPA usam essas métricas para determinar quando acionar o escalonamento automático. O servidor de métricas é escalonado usando o complemento de redimensionamento.

Em casos extremos em que a alta densidade de pods cria sobrecarga de geração de registros e monitoramento, o servidor de métricas pode ser interrompido e reiniciado devido a limitações de recursos. Nesse caso, é possível alocar mais recursos para o servidor de métricas editando o configmap metrics-server-config no namespace gke-managed-metrics-server e alterando o valor de cpuPerNode e memoryPerNode.

kubectl edit cm metrics-server-config -n gke-managed-metrics-server

O conteúdo de exemplo do ConfigMap é:

apiVersion: v1
data:
  NannyConfiguration: |-
    apiVersion: nannyconfig/v1alpha1
    kind: NannyConfiguration
    cpuPerNode: 3m
    memoryPerNode: 20Mi
kind: ConfigMap

Depois de atualizar o ConfigMap, recrie os pods do metric-server com o seguinte comando:

kubectl delete pod -l k8s-app=metrics-server -n gke-managed-metrics-server

Requisitos de configuração do Logging e do Monitoring

Há vários requisitos de configuração para ativar o Cloud Logging e o Cloud Monitoring com o GKE em Bare Metal. Estas etapas estão incluídas em Como configurar uma conta de serviço para uso com o Logging e o Monitoring na página de ativação dos serviços do Google e na lista a seguir:

  1. É preciso criar um espaço de trabalho do Cloud Monitoring no projeto do Google Cloud. Para isso, clique em Monitoramento no console do Google Cloud e siga o fluxo de trabalho.

  2. Você precisa ativar as seguintes APIs do Stackdriver:

  3. Você precisa atribuir os seguintes papéis de IAM à conta de serviço usada pelos agentes do Stackdriver:

    • logging.logWriter
    • monitoring.metricWriter
    • stackdriver.resourceMetadata.writer
    • monitoring.dashboardEditor
    • opsconfigmonitoring.resourceMetadata.writer

Preços

Os registros e métricas do sistema do GKE Enterprise não são cobrados.

Em um cluster do GKE em Bare Metal, os registros e as métricas do sistema do GKE Enterprise incluem o seguinte:

  • Registros e métricas de todos os componentes em um cluster de administrador
  • Registros e métricas de componentes nesses namespaces em um cluster de usuário: kube-system, gke-system, gke-connect, knative-serving, istio-system, monitoring-system, config-management-system, gatekeeper-system, cnrm-system

Para mais informações, consulte Preços do pacote de operações do Google Cloud.

Para saber mais sobre o crédito para métricas do Cloud Logging, entre em contato com a equipe de vendas e receba mais informações sobre preços.