Como migrar para as operações do Kubernetes Engine

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:

Nesta página, você aprenderá as diferenças entre essas duas opções e o que alterar para migrar do Logging e do Monitoring legados para as operações do Kubernetes Engine.

Quando preciso migrar?

É possível migrar as configurações atuais do Cloud Monitoring e do Cloud Logging do Logging e do Monitoring legados para o Kubernetes Engine Operations 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 para geração de registros e monitoramento legado for removido, você precisará migrar para as operações do Kubernetes Engine antes disso se quiser continuar usando 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 Operações do Kubernetes Engine
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?

As operações do Kubernetes Engine usam um modelo de dados diferente para organizar as métricas, os registros e os metadados. Veja algumas alterações específicas para os clusters usando as operações do Kubernetes Engine:

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

  • 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 em gce_instance (instância de VM do Compute Engine).

  • Mudanças nos nomes das métricas do Kubernetes: nas operações do Kubernetes Engine, os nomes dos tipos de métrica agora começam com o prefixo kubernetes.io/  em vez de. container.googleapis.com/ (em inglês).

A seguinte tabela resume as mudanças anteriores:

Change (Antigo) Logging e Monitoring legados Operações do Kubernetes Engine (novo)
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?

Nesta seção, você encontrará informações mais específicas sobre as mudanças do modelo de dados nas operações do Kubernetes Engine e o impacto delas nas configurações de monitoramento e de geração de registro atuais.

Como usar o painel de status da migração

Para identificar as configurações do Cloud Monitoring e do Cloud Logging que você precisa atualizar como parte da migração para as operações do Kubernetes Engine, 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 Operations tem novos nomes de tipo de recurso, novos nomes de exibição de tipo de recurso e novos nomes dos 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 Tipo de recurso de operações do Kubernetes Engine (novo)
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 as operações do Kubernetes Engine, 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

(nenhum)
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 Métricas de operações do Kubernetes Engine (novo)
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 do Logging e do Monitoring legados mostrados na tabela Alterações de tipo de recurso anteriores ou qualquer métrica do Logging ou do Monitoring legados mostrada na anterior à tabela Alterações de nome de métrica e, em seguida, altere esses tipos e métricas para que sejam os tipos de recursos e métricas correspondentes das operações do Kubernetes Engine. 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 do Logging e Monitoring legados mostrados na tabela Alterações no tipo de recurso acima ou qualquer métrica de Logging e Monitoring legados mostrado na tabela Alterações de nome da métrica acima, altere esses tipos e métricas para os tipos e métricas correspondentes das operações do Kubernetes Engine.

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 a ser atualizado para as operações do Kubernetes Engine:

    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 do Logging e Monitoring legados mostrados na tabela anterior Alterações de tipo de recurso ou qualquer métrica do 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 das operações do Kubernetes Engine.

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 de fazer upgrade do cluster ou depois? 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 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 registros no Cloud Logging e usar qualquer um dos tipos de recursos do Logging e Monitoring legados mostrados na tabela anterior Alterações no tipo de recurso, altere esses tipos para os tipos correspondentes das operações do Kubernetes Engine.

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 acima, altere esses tipos para tipos correspondentes das operações do Kubernetes Engine.

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 do Logging e Monitoring legados mostrados na tabela Alterações no tipo de recurso acima, altere esses filtros para usar os tipos de recursos correspondentes das operações do Kubernetes Engine.

Mudanças no conteúdo de entradas de registro

Quando você atualiza para as operações do Kubernetes Engine, pode descobrir 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 das operações do Kubernetes Engine usam stdout ou stderr nos nomes de registro, enquanto o Logging e o Monitoring legados usavam uma variedade maior de nomes, inclusive 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 Entradas de registro de operações do Kubernetes Engine (novo)
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 das operações do Kubernetes Engine e, ocasionalmente, em algumas entradas de registro do Logging e Monitoring legados. Nas operações do Kubernetes Engine, ele é usado para armazenar 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 nas operações do Kubernetes Engine, verifique os registros nos novos tipos de recursos, como Kubernetes Container, não nos tipos do Logging e Monitoring legados, como GKE Container.

A seguir