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:

• Logging e Monitoring legados: para ver a documentação, consulte as páginas Monitoring legado e Logging legado.

• Operações do Kubernetes Engine: para documentação, consulte Operações do Kubernetes Engine.

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.

Cuidado: o suporte ao Logging e Monitoring legados e o suporte a operações do Kubernetes Engine são incompatíveis. Para atualizar para as operações do Kubernetes Engine, você precisa alterar manualmente as configurações do Monitoring e do Logging, incluindo, sem limitação, políticas de alerta, gráficos, filtros de grupo e consultas de registro.

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.

Observação: a alteração da versão do GKE do seu cluster não altera o monitoramento configurado e o suporte à geração de registro. Consulte Qual suporte a monitoramento e a geração de registro meu cluster usa? para determinar o suporte atual para seu cluster.

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.

Observação: depois de fazer upgrade de um cluster, não se esqueça de encontrar os dados de monitoramento usando apenas os novos nomes de tipo de recurso. Talvez você ainda veja os tipos de recursos legados, mas eles mantêm apenas dados de monitoramento anteriores à atualização dos clusters.

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:

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_id^1   namespace_id   pod_id   project_id   zone^2 Somente Logging: container (Contêiner do GKE) Rótulos:   cluster_name   container_name   instance_id^1   namespace_id   pod_id   project_id   zone^2	Monitoring e Logging: k8s_container (Contêiner do Kubernetes) Rótulos:   cluster_name   container_name   metadata.system_labels.node_name^3   namespace_name   pod_name   project_id   location^2
Somente Logging:: gce_instance (Instância de VM do Compute Engine)^4 Rótulos:   cluster_name   instance_id   project_id   zone^2	Monitoring e Logging k8s_node^4 (Nó do Kubernetes) Rótulos:   cluster_name   node_name   project_id   location^2
(nenhum)	Monitoring e Logging: k8s_pod^5 (Pod do Kubernetes) Rótulos:   cluster_name   namespace_name   pod_name   project_id   location^2
Somente Logging gke_cluster (GKE_cluster) Rótulos:   cluster_name   project_id   location	Monitoring e Logging: k8s_cluster^5 (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.

Observação: verifique se os grupos atualizados contêm o mesmo número de recursos que tinham antes do upgrade. É provável que poucos recursos indiquem que você perdeu algumas alterações.

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.

Observação: verifique se os gráficos atualizados estão recebendo dados com carimbo de data e hora após a atualização. Dados não encontrados podem indicar que você não mudou algumas métricas corretamente.

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.

Observação: se você não vir amostras de suas métricas com base em registros após a atualização para as operações do Kubernetes Engine, talvez ainda esteja usando as métricas ou tipos de recursos do Logging e Monitoring legados.

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.

Observação: antes de atualizar para as operações do Kubernetes Engine, anote o número aproximado de entradas de registro que você está exportando ou excluindo do projeto do GCP para verificar se você está ainda recebendo um número apropriado.

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 recurso^1)	Recursos de entrada de registro resource.labels (Rótulos de recurso^1)
Metadados de entrada de registro labels (Rótulos de entrada de registro^2) 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

• Para saber mais sobre o novo painel de operações do Kubernetes Engine, consulte Como observar o sistema.