Como migrar para o Kubernetes Engine Monitoring

Há duas opções para o suporte de monitoramento e geração de registro no Google Kubernetes Engine (GKE). Elas são fornecidas por todas as versões do GKE disponíveis para novos clusters e para atualizações de clusters atuais:

Esta página explica as diferenças entre essas duas opções e o que você deve alterar para migrar do Logging e Monitoring legados para o Kubernetes Engine Monitoring.

Quando preciso migrar?

É possível migrar suas configurações existentes do Cloud Monitoring e do Cloud Logging do Logging e Monitoring legados para o Kubernetes Engine Monitoring a qualquer momento. No entanto, lembre-se de que uma versão futura do GKE pode retirar o suporte para Logging e Monitoring legados. Se o suporte ao Logging e Monitoring legados for removido, será necessário migrar para o Kubernetes Engine Monitoring antes se você quiser continuar a usar o suporte do Cloud Monitoring e do Cloud Logging.

A tabela a seguir resume as próximas versões esperadas do GKE com as respectivas opções de suporte:

Versão GKE Logging e Monitoring legados Kubernetes Engine Monitoring
1.10 – 1.12.5 Padrão opcional (Beta)
1.12.7 Padrão Opcional
1.13 Padrão Opcional
1.14 Opcional Padrão
1.15 Não disponível Padrão

O que vai mudar?

O Kubernetes Engine Monitoring usa um modelo de dados diferente para organizar suas métricas, registros e metadados. Veja algumas alterações específicas para seus clusters usando o Kubernetes Engine Monitoring:

  • Alteração da navegação: os painéis do Cloud Monitoring são nomeados como Kubernetes Engine New. Este painel não aparecerá se você não tiver clusters usando o Kubernetes Engine Monitoring.

  • Mudanças nos nomes dos tipos de recursos monitorados: por exemplo, seus nós do Kubernetes estão listados no tipo de recurso monitorado k8s_node , que é um nó do Kubernetes, em vez de gce_instance (instância de VM do Compute Engine).

  • Mudanças nos nomes de métricas do Kubernetes: no Kubernetes Engine Monitoring, nomes de tipos de métricas agora começam com o prefixo kubernetes.io/  em vez do container.googleapis.com/.

A seguinte tabela resume as mudanças anteriores:

Change (Antigo) Logging e Monitoring legados (Novo) Kubernetes Engine Monitoring
Menus do painel Painéis > Kubernetes Engine Painéis > Kubernetes Engine New
Prefixos métricos container.googleapis.com kubernetes.io
Tipos de recursos gke_container (métricas)
container (registros)
gce_instance
(nenhum)
gke_cluster
k8s_container
k8s_container
k8s_node
k8s_pod
k8s_cluster

O que preciso fazer?

Esta seção contém informações mais específicas sobre as alterações do modelo de dados no Kubernetes Engine Monitoring e seu impacto nas configurações existentes de monitoramento e geração de registros.

Como usar o painel de status da migração

Para identificar as configurações do Cloud Monitoring e do Cloud Logging que você deve atualizar como parte da migração para o Kubernetes Engine Monitoring, faça o seguinte:

  1. No Console do Cloud, acesse Monitoring:

    Acessar Monitoring

  2. Para acessar o status de migração, no painel de navegação do Monitoring, clique em Configurações e selecione a guia Kubernetes Migration Status.

Não há ações pendentes no painel de amostra a seguir:

Exibição do painel de migração.

Mudanças de tipo de recurso

O Kubernetes Engine Monitoring tem novos nomes de tipo de recurso, novos nomes de exibição de tipo de recurso e novos nomes para os rótulos que identificam recursos específicos. Essas mudanças estão listadas na tabela a seguir.

Mudanças de tipo de recurso
(Antigo) Tipo de recurso do Logging e Monitoring legados (Novo) Tipo de recurso do Kubernetes Engine Monitoring
Notas de rodapé da tabela:
1 No novo tipo de recurso usado (apenas) para monitoramento, instance_id torna-se node_name em metadata.system_labels.
2 zone refere-se ao local desse contêiner ou instância. location refere-se ao local do nó do mestre do cluster.
3 metadata.system_labels.node_name não está disponível em tipos de recurso k8s_container usados para geração de registros. Não é possível pesquisar registros por nome de nó.
4 O tipo de recurso gce_instance pode representar nós do Kubernetes, bem como instâncias de VM que não são do Kubernetes. Ao fazer upgrade para o Kubernetes Engine Monitoring, os usos relacionados a nó são alterados para usar o novo tipo de recurso, k8s_node, incluindo registros no nível do nó com os seguintes nomes: kubelet, docker, kube-proxy, startupscript e node-problem-detector.
5 Os nós k8s_pod e k8s_cluster podem incluir registros que não estão presentes no suporte ao Logging e Monitoring legados.
Somente Monitoring:
gke_container (Contêiner do GKE)

Rótulos:
  cluster_name
  container_name
  instance_id1
  namespace_id
  pod_id
  project_id
  zone2

Somente Logging:
container (Contêiner do GKE)

Rótulos:
  cluster_name
  container_name
  instance_id1
  namespace_id
  pod_id
  project_id
  zone2

Monitoring e Logging:
k8s_container (Contêiner do Kubernetes)

Rótulos:
  cluster_name
  container_name
  metadata.system_labels.node_name3
  namespace_name
  pod_name
  project_id
  location2

Somente Logging::
gce_instance (Instância de VM do Compute Engine)4

Rótulos:
  cluster_name
  instance_id
  project_id
  zone2
Monitoring e Logging
k8s_node4 (Nó do Kubernetes)

Rótulos:
  cluster_name
  node_name
  project_id
  location2
 
(nenhuma)
Monitoring e Logging:
k8s_pod5 (Pod do Kubernetes)

Rótulos:
  cluster_name
  namespace_name
  pod_name
  project_id
  location2

Somente Logging
gke_cluster (GKE_cluster)

Rótulos:
  cluster_name
  project_id
  location

Monitoring e Logging:
k8s_cluster5 (Cluster do Kubernetes)

Rótulos:
  cluster_name
  project_id
  location

Mudanças nos nomes de métricas

A tabela a seguir mostra algumas amostras dos diferentes nomes de métricas. Mude cada uso de uma métrica com nome iniciado por container.googleapis.com/ para uma nova métrica com nome iniciado por kubernetes.io/.

Os novos nomes de métricas podem ser diferentes de outras maneiras, além do novo prefixo. Procure as novas métricas em kubernetes.io .

Mudanças nos nomes de métricas
(Antigo) Métricas de Logging e Monitoring legados (Novo) Métricas do Kubernetes Engine Monitoring
Métricas legadas do GKE
container.googleapis.com/

Exemplos:
  .../container/cpu/utilization
  .../container/uptime
  .../container/memory/bytes_total
Métricas do Kubernetes Engine Monitoring
kubernetes.io/

Exemplos:
  .../container/cpu/request_utilization
  .../container/uptime
  .../node/memory/total_bytes
  .../node/cpu/total_cores

Mudanças de grupo de recursos

Se você definir seus próprios grupos de recursos e usar qualquer um dos tipos de recursos de Logging e Monitoring legados mostrados na tabela Alterações no tipo de recurso ou qualquer métrica de Logging e Monitoring legados mostrada na tabela anterior Alterações no nome da métrica, altere esses tipos e métricas para serem os tipos de recursos e métricas correspondentes do Kubernetes Engine Monitoring. Se o grupo de recursos incluir gráficos personalizados, talvez seja necessário mudá-los.

Mudanças em gráficos e painéis personalizados

Se você definir seus próprios painéis e gráficos personalizados e usar qualquer um dos tipos de recursos de Logging e Monitoring legados mostrados na tabela anterior Alterações no tipo de recurso ou qualquer métrica de Logging e Monitoring legados mostrado na tabela anterior Alterações de nome da métrica, altere esses tipos e métricas para os tipos e métricas correspondentes do Kubernetes Engine Monitoring.

Para seus gráficos e painéis personalizados, consiga ajuda visualizando o painel de status da migração do GKE:

  1. No Console do Cloud, selecione o projeto do Google Cloud que contém um cluster do GKE para atualizar para o Kubernetes Engine Monitoring:

    Acessar o Console do Cloud

  2. Selecione Monitoring.

  3. Para acessar o status de migração, no painel de navegação do Monitoring, clique em Configurações e selecione a guia Kubernetes Migration Status.

Mudanças na política de alertas e tempo de atividade

Se você definir políticas de alerta ou verificações de tempo de atividade e usar qualquer um dos tipos de recursos de Logging e Monitoring legados mostrados na tabela anterior Alterações de tipo de recurso ou qualquer métrica de Logging e Monitoring legados mostrada na tabela anterior Alterações de nome da métrica, altere esses tipos e métricas para os tipos e métricas correspondentes do Kubernetes Engine Monitoring.

O upgrade das políticas de alertas e das verificações de tempo de atividade podem ser as mudanças mais difíceis de serem realizadas e verificadas. Uma pergunta a ser considerada é: quando fazer essas mudanças? Você muda a configuração da política antes ou depois de fazer upgrade do cluster? As políticas antigas falham depois que você atualiza o cluster e as novas falham antes de você atualizá-lo.

Em vez de mudar políticas, considere deixar as políticas atuais inalteradas e criar novas políticas com as mudanças atualizadas. Isso pode facilitar o acompanhamento das políticas que você espera que falhem e das que você não espera em momentos diferentes durante a atualização.

Aqui estão algumas outras dicas:

  • Examine suas políticas e estime por quanto tempo seu cluster atualizado precisará ser executado antes de acumular dados suficientes para funcionar no estado estável.

  • Tenha uma ideia do desempenho das políticas ou métricas individuais antes de atualizar. Dessa maneira, é possível comparar esse comportamento com o comportamento pós-atualização.

Como gerar registros de consultas

Se você usar consultas para localizar e filtrar seus registros no Cloud Logging e usar qualquer um dos tipos de recursos de Logging e Monitoring legados mostrados na tabela anterior Alterações no tipo de recurso, altere esses tipos para os tipos de Kubernetes Engine Monitoring correspondentes.

Métricas com base em registros

Se você definir suas próprias métricas com base em registros e usar tipos de recursos ou métricas do Logging e Monitoring legados mostrados nas tabelas Alterações de nome da métrica ou Alterações no tipo de recurso, altere esses tipos para os tipos de Kubernetes Engine Monitoring correspondentes.

Exportações e exclusões de registros

Se você exportar ou excluir algum dos registros e os filtros de exportação ou exclusão usarem os tipos de recursos de Logging e Monitoring legados mostrados na tabela Alterações no tipo de recurso, altere esses filtros para usar os tipos de recursos correspondentes do Kubernetes Engine Monitoring.

Mudanças no conteúdo de entradas de registro

Quando você atualiza para o Kubernetes Engine Monitoring, talvez descubra que determinadas informações nas entradas de registro foram movidas para campos com nomes diferentes. Essas informações podem ser exibidas em consultas de registros usadas em métricas baseadas em registros, coletores de registros e exclusões de registros.

A tabela a seguir, Alterações na entrada de registro, lista os novos campos e rótulos. Aqui está um breve resumo:

  • O campo logName pode ser mudado. As entradas de registro do Kubernetes Engine Monitoring usam stdout ou stderr nos nomes de registro, enquanto o Logging and Monitoring legados usaram uma variedade maior de nomes, incluindo o nome do contêiner. O nome de contêiner ainda está disponível como um rótulo de recurso.
  • Verifique o campo labels nas entradas de registro. Esse campo pode conter informações que anteriormente estavam nos campos metadata de entrada de registro.
  • Verifique o campo resource.labels nas entradas de registro. Os novos tipos de recursos têm valores de rótulo a mais.
Mudanças nas entradas de registro
(Antigo) Entradas de registro de Logging e Monitoring legados (Novo) Entradas de registro do Kubernetes Engine Monitoring
Notas de rodapé da tabela:
1 Os rótulos de recurso identificam recursos específicos que geram métricas, como clusters e nós específicos.
2 O campo labels é exibido em novas entradas de registro que fazem parte do Kubernetes Engine Monitoring e, ocasionalmente, em algumas entradas de registro de Logging e Monitoring legados. No Kubernetes Engine Monitoring, ele é usado para reter algumas informações anteriormente nos campos de entrada de registro metadata.
Recursos de entrada de registro
resource.labels (Rótulos de recurso1)
Recursos de entrada de registro
resource.labels (Rótulos de recurso1)
Metadados de entrada de registro
labels (Rótulos de entrada de registro2)

Rótulos (Exemplos)
  compute.googleapis.com/resource_name:
    "fluentd-gcp-v3.2.0-d4d9p"

  container.googleapis.com/namespace_name:
    "kube-system"

  container.googleapis.com/pod_name:
    "fluentd-gcp-scaler-8b674f786-d4pq2"

  container.googleapis.com/stream:
    "stdout"
Metadados de entrada de registro
labels

Mudanças em locais de registro

No Cloud Logging, os registros são armazenados com o tipo de recurso que os gerou. Como esses tipos foram alterados no Kubernetes Engine Monitoring, procure seus registros nos novos tipos de recursos, como Kubernetes Container, não nos tipos de Logging e Monitoring legados, como GKE Container.

A seguir