Migra a las operaciones de Kubernetes Engine

Hay dos opciones para la asistencia de Monitoring y Logging en Google Kubernetes Engine (GKE). Todas las versiones de GKE disponibles para los clústeres nuevos y las actualizaciones de los clústeres existentes ofrecen estas opciones:

• Logging y Monitoring heredados: para ver la documentación, consulta las páginas de Monitoring heredado y Logging heredado.

• Operaciones de Kubernetes Engine: para obtener más información, consulta Operaciones de Kubernetes Engine.

En esta página, se explican las diferencias entre estas dos opciones y lo que debes cambiar para migrar de las operaciones de registro y supervisión heredadas a Kubernetes Engine.

Precaución: La asistencia de Logging y Monitoring heredados y la asistencia de Operaciones de Kubernetes Engine no son compatibles. Para realizar la actualización a operaciones de Kubernetes Engine, debes cambiar manualmente tus configuraciones de Monitoring y Logging, incluidas, entre otras, las políticas de alertas, los gráficos, los filtros de grupo y las consultas de registro.

¿Cuándo debo migrar?

Puedes migrar tus configuraciones existentes de Cloud Monitoring y Cloud Logging de Logging heredado y Monitoring a operaciones de Kubernetes Engine en cualquier momento. Sin embargo, ten en cuenta que una próxima actualización de GKE podría anular la asistencia para Logging y Monitoring heredados. Si se quita la asistencia para el registro y la supervisión heredados, debes migrar a las operaciones de Kubernetes Engine antes de eso si deseas continuar usando la supervisión de Cloud Monitoring y Cloud Logging.

Nota: Si cambias la versión de GKE de tu clúster, no se modificará la asistencia de Monitoring y Logging configurada. Consulta la sección ¿qué asistencia de Monitoring y Logging usa mi clúster? a fin de determinar la asistencia actual de tu clúster.

En la siguiente tabla, se resumen las próximas versiones previstas de GKE con sus opciones de asistencia:

Versión de GKE	Logging y Monitoring heredados	Operaciones de Kubernetes Engine
1.10-1.12.5	Predeterminado	Habilitación opcional (Beta)
1.12.7	Predeterminado	Opcional
1.13	Predeterminado	Opcional
1.14	Opcional	Predeterminado
1.15	No disponible	Predeterminado

¿Qué aspectos cambiarán?

Las operaciones de Kubernetes Engine usan un modelo de datos diferente para organizar sus métricas, registros y metadatos. Estos son algunos cambios específicos para tus clústeres con las operaciones de Kubernetes Engine:

• Cambios en la navegación: los paneles de Cloud Monitoring se llaman Nuevo Kubernetes Engine. Este panel no aparece si no tienes clústeres que usan operaciones de Kubernetes Engine.

• Cambios en los nombres de tipos de recursos supervisados: por ejemplo, tus nodos de Kubernetes se enumeran en el tipo de recurso supervisado k8s_node, que es un nodo de Kubernetes, en lugar de gce_instance (instancia de VM de Compute Engine).

• Cambios en los nombres de métricas de Kubernetes: En las operaciones de Kubernetes Engine, ahora los nombres de tipo de métrica comienzan con el prefijo kubernetes.io/ en lugar de container.googleapis.com/.

En la siguiente tabla, se resumen los cambios mencionadas anteriormente:

Cambio	Logging y Monitoring heredados (antiguo)	(Nuevo) Operaciones de Kubernetes Engine
Menús del panel	Paneles > Kubernetes Engine	Paneles > Nuevo Kubernetes Engine
Prefijos de métricas	container.googleapis.com	kubernetes.io
Tipos de recursos	gke_container (métricas) container (registros) gce_instance (ninguno) gke_cluster	k8s_container k8s_container k8s_node k8s_pod k8s_cluster

¿Qué debo hacer?

Esta sección contiene información más específica sobre los cambios del modelo de datos en las operaciones de Kubernetes Engine y su impacto en tus configuraciones de supervisión y registro existentes.

Nota: Después de actualizar un clúster, asegúrate de buscar los datos de supervisión únicamente a través de los nuevos nombres de tipos de recursos. Es posible que aún veas los tipos de recursos heredados, pero solo almacenarán los datos de supervisión anteriores a la actualización de tus clústeres.

Usa el panel de estado de migración

Para identificar las configuraciones de Cloud Monitoring y Cloud Logging que debes actualizar como parte de la migración a las operaciones de Kubernetes Engine, haz lo siguiente:

1. En Cloud Console, ve a Monitoring:

   Ir a Monitoring

2. Para acceder al estado de la migración, en el panel de navegación de Monitoring, haz clic en Settings (Configuración) y, luego, selecciona la pestaña Kubernetes Migration Status (Estado de la migración de Kubernetes).

En el siguiente panel de ejemplo, no se muestra ninguna tarea pendiente:

Cambios en los tipos de recursos

Las operaciones de Kubernetes Engine tienen nombres nuevos de tipos de recursos, nombres visibles nuevos para los tipos de recursos nuevos y nombres nuevos para las etiquetas que identifican recursos. Estos cambios se enumeran en la siguiente tabla.

Cambios en los tipos de recursos

Tipo de recurso de Logging y Monitoring heredados (antiguo)	(Nuevo) Tipo de recurso de las operaciones de Kubernetes Engine
Notas al pie de la tabla: ^1 En el tipo de recurso nuevo utilizado en la supervisión (solamente), instance_id se convierte en node_name en metadata.system_labels. ^2zone hace referencia a la ubicación de este contenedor o instancia. location hace referencia a la ubicación del nodo de la instancia principal del clúster. ^3metadata.system_labels.node_name no está disponible en los tipos de recursos k8s_container utilizados para los registros. No puedes buscar registros por nombre de nodo. ^4 El tipo de recurso gce_instance puede representar nodos de Kubernetes, así como instancias de VM que no son de Kubernetes. Cuando actualizas a las operaciones de Kubernetes Engine, los usos relacionados con los nodos se cambian para usar el nuevo tipo de recurso, k8s_node, incluidos los registros a nivel de nodo con los siguientes nombres: kubelet, docker, kube-proxy, startupscript y node-problem-detector. ^5 Los nodos k8s_pod y k8s_cluster pueden incluir registros que no están presentes en la asistencia de Logging y Monitoring heredados.
Solo Monitoring: gke_container (contenedor de GKE) Etiquetas:   cluster_name   container_name   instance_id^1   namespace_id   pod_id   project_id   zone^2 Solo Logging: container (contenedor de GKE) Etiquetas:   cluster_name   container_name   instance_id^1   namespace_id   pod_id   project_id   zone^2	Monitoring y Logging: k8s_container (contenedor de Kubernetes) Etiquetas:   cluster_name   container_name   metadata.system_labels.node_name^3   namespace_name   pod_name   project_id   location^2
Solo Logging:: gce_instance (instancia de VM de Compute Engine) ^4 Etiquetas:   cluster_name   instance_id   project_id   zone^2	Monitoring y Logging: k8s_node^4 (nodo de Kubernetes) Etiquetas:   cluster_name   node_name   project_id   location^2
(ninguno)	Monitoring y Logging: k8s_pod^5 (pod de Kubernetes) Etiquetas:   cluster_name   namespace_name   pod_name   project_id   location^2
Solo Logging gke_cluster (GKE_cluster) Etiquetas:   cluster_name   project_id   location	Monitoring y Logging: k8s_cluster^5 (clúster de Kubernetes) Etiquetas:   cluster_name   project_id   location

Cambios en los nombres de las métricas

En la siguiente tabla, se muestran algunos ejemplos de nombres de métricas. Debes cambiar cada uso de una métrica cuyo nombre comience con container.googleapis.com/ por una métrica nueva cuyo nombre comience con kubernetes.io/.

Los nombres nuevos de las métricas pueden variar según otros criterios además del prefijo nuevo. Busca las métricas nuevas en kubernetes.io .

Cambios en los nombres de las métricas

Métricas de Logging y Monitoring heredados (antiguo)	(Nuevo) Métricas de operaciones de Kubernetes Engine
Métricas de GKE heredado container.googleapis.com/ Ejemplos:   .../container/cpu/utilization   .../container/uptime   .../container/memory/bytes_total	Métricas de Kubernetes Engine Monitoring kubernetes.io/ Ejemplos:   .../container/cpu/request_utilization   .../container/uptime   .../node/memory/total_bytes   .../node/cpu/total_cores

Cambios en los grupos de recursos

Si defines tus propios grupos de recursos y usas cualquiera de los tipos de recursos de Logging y Monitoring heredados que se muestran en la tabla anterior Cambios en el tipo de recurso o cualquier métrica de Logging y Monitoring heredados que aparece en la tabla de Cambios en el nombre de la métrica anterior, cambia esos tipos y métricas para que sean los tipos de recursos y las métricas de operaciones de Kubernetes Engine correspondientes. Si tu grupo de recursos incluye gráficos personalizados, es posible que debas cambiarlos.

Nota: Comprueba que los grupos actualizados contengan la misma cantidad de recursos que tenían antes de la actualización. Si usas pocos recursos, es posible que hayas pasado por alto algunos cambios.

Cambios en los paneles y gráficos personalizados

Si defines tus propios gráficos y paneles personalizados y usas cualquiera de los tipos de recursos de Logging y Monitoring heredados que se muestran en la tabla anterior Cambios en el tipo de recurso o cualquier métrica de Logging y Monitoring heredados que se muestra en la tabla anterior Cambios en el nombre de la métrica, cambia esos tipos y métricas a los tipos y métricas de operaciones de Kubernetes Engine correspondientes.

Nota: Comprueba que los gráficos actualizados reciban datos con marcas de tiempo después de la actualización. Si faltan datos, es posible que no hayas cambiado algunas métricas correctamente.

Si deseas obtener ayuda con tus paneles y gráficos personalizados, consulta el panel de estado de migración de GKE:

1. En Cloud Console, selecciona el proyecto de Google Cloud que contenga un clúster de GKE para llevar a cabo las operaciones de Kubernetes Engine:

   Ir a Cloud Console

2. Selecciona Monitoring.

3. Para acceder al estado de la migración, en el panel de navegación de Monitoring, haz clic en Settings (Configuración) y, luego, selecciona la pestaña Kubernetes Migration Status (Estado de la migración de Kubernetes).

Cambios en las políticas de alertas y tiempo de actividad

Si defines políticas de alertas o verificaciones de tiempo de actividad, y usas cualquiera de los tipos de recursos de Logging y Monitoring heredados que se muestran en la tabla anterior Cambios de tipo de recurso o cualquier métrica de registro y supervisión heredada que se muestra en la tabla anterior Cambios en el nombre de la métrica, cambia esos tipos y métricas a los tipos y métricas de operaciones de Kubernetes Engine correspondientes.

La actualización de las políticas de alertas y las verificaciones de tiempo de actividad pueden ser los cambios más difíciles de realizar y verificar. Una pregunta que debes tener en cuenta es cuándo realizar estos cambios. ¿Debes cambiar la configuración de tu política antes o después de actualizar el clúster? Las políticas anteriores fallarán después de actualizar el clúster, y las nuevas lo harán antes de realizar dicha actualización.

En lugar de cambiar las políticas implementadas, puedes dejar las políticas existentes sin modificarlas y crear políticas nuevas con los cambios actualizados. Esto podría facilitar el seguimiento de las políticas que se espera que fallen y las que no en diferentes momentos de la actualización.

A continuación, se brindan las siguientes sugerencias:

• Revisa tus políticas y calcula durante cuánto tiempo tendrá que ejecutarse el clúster actualizado antes de que hayas acumulado suficientes datos para que funcione en el estado estable.

• Se recomienda que conozcas el rendimiento de tus políticas o métricas individuales antes de realizar la actualización, de modo que puedas comparar ese comportamiento con el que surja después a la actualización.

Consultas en Logging

Si usas consultas para encontrar y filtrar tus registros en Cloud Logging, y usas cualquiera de los tipos de recursos de Logging y Monitoring heredados que se muestran en la tabla Cambios de tipo de recurso anterior, cambia esos tipos a los tipos de operaciones de Kubernetes Engine correspondientes.

Métricas según registros

Si defines tus propias métricas basadas en registros y usas métricas o tipos de recursos heredados de Logging y Monitoring que se muestran en los cambios de nombre de la métrica o en Cambia las tablas de los tipos de recursos. cambia esas métricas y tipos de recursos a las de las operaciones de Kubernetes Engine correspondientes.

Nota: Si no ves ejemplos de tus métricas basadas en registros después de realizar la actualización a Kubernetes Engine Monitoring, es posible que continúes usando las métricas o los tipos de recursos de Logging y Monitoring heredados.

Exportaciones y exclusiones de registros

Si exportas o excluyes cualquiera de tus registros, y si los filtros de exportación o exclusión usan los tipos de recursos heredados de Logging y Monitoring que se muestran en la tabla anterior Cambios en los tipos de recursos, cambia los filtros de exportación y exclusión para usar los tipos de recursos de las operaciones de Kubernetes Engine correspondientes.

Nota: Antes de actualizar a Kubernetes Engine Monitoring, anota la cantidad aproximada de entradas de registros que exportas o excluyes de tu proyecto de Google Cloud, de forma que puedas verificar que aún obtienes una cantidad adecuada.

Cambios en el contenido de la entrada de registro

Cuando actualizas a las operaciones de Kubernetes Engine, es posible que encuentres cierta información en las entradas de registro que se movieron a campos con nombres diferentes. Esta información puede aparecer en las consultas de registros usadas en las métricas basadas en registros, los receptores de registros y las exclusiones de registros.

En la siguiente tabla, Cambios en la entrada de registro, se enumeran las etiquetas y los campos nuevos. A continuación, presentamos un breve resumen:

• El campo logName puede cambiar. Las entradas de registro de operaciones de Kubernetes Engine usan stdout o stderr en sus nombres de registro, mientras que Logging y Monitoring heredados usaron una variedad más amplia de nombres, incluido el nombre del contenedor. El nombre del contenedor aún está disponible como etiqueta de recurso.
• Comprueba el campo labels en las entradas de registro. Es posible que este campo contenga información que anteriormente se encontraba en los campos de entrada de registro metadata.
• Comprueba el campo resource.labels en las entradas de registro. Los tipos de recursos nuevos tienen valores de etiqueta adicionales.

Cambios en la entrada de registro

Entradas de registro de Logging y Monitoring heredados (antiguo)	(Nuevo) Entradas de registro de operaciones de Kubernetes Engine
Notas a pie de tabla: ^1 Las etiquetas de recursos identifican recursos específicos que generan métricas, como clústeres y nodos determinados. ^2 El campo labels aparece en entradas de registro nuevas que forman parte de las operaciones de Kubernetes Engine y, a veces, en algunas entradas de registro de Logging y Monitoring heredados. En las operaciones de Kubernetes Engine, se usa para almacenar información que antes estaba en los campos de entrada de registro metadata.
Recursos de entrada de registro resource.labels (etiquetas de recursos ^1)	Recursos de entrada de registro resource.labels (etiquetas de recursos ^1)
Metadatos de entrada de registro labels (etiquetas de entrada de registro ^2) etiquetas (ejemplos)   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"	Metadatos de entrada de registro labels

Cambios en las ubicaciones de los registros

En Cloud Logging, los registros se almacenan con el tipo de recurso que los generó. Debido a que estos tipos de recursos cambiaron en las operaciones de Kubernetes Engine, asegúrate de buscar tus registros en los tipos de recursos nuevos, como Kubernetes Container, en lugar de hacerlo en los tipos de registro heredado y supervisión, como GKE Container.

Qué sigue

• Para obtener más información sobre el nuevo panel de operaciones de Kubernetes Engine, consulta Observa tu sistema.