Migra a las operaciones en la nube para GKE

Hay dos opciones de asistencia de Monitoring y Logging en Google Kubernetes Engine (GKE):

En esta página, se explican las diferencias entre estas dos opciones y lo que debes cambiar con el fin de migrar de Logging y Monitoring heredados a operaciones en la nube para GKE.

¿Cuándo debo migrar?

Puedes migrar la configuración existente de Cloud Monitoring y Cloud Logging desde Logging y Monitoring heredados hasta las operaciones en la nube para GKE en cualquier momento. Sin embargo, ten en cuenta que Logging y Monitoring heredados no son compatibles con la versión 1.20 de GKE.

En la siguiente tabla, se resumen las opciones de supervisión y registro disponibles en cada versión de actualización de GKE:

Versión de GKE Logging y Monitoring heredados Cloud Operations para GKE
1.14 Disponible Valor predeterminado
1.15 Disponible Valor predeterminado
1.16 Disponible Predeterminada
1.17 Disponible Predeterminada
1.18 Disponible Predeterminada
1.19 Disponible Predeterminada
1.20 No disponible Predeterminado

Si deseas obtener información sobre la baja de Logging y Monitoring heredados, consulta la guía Asistencia heredada para la baja de GKE.

¿Cuáles son los beneficios de usar las operaciones en la nube para GKE?

Las operaciones en la nube para GKE te brindan beneficios importantes, como los siguientes:

¿Qué aspectos cambiarán?

En las operaciones en la nube para GKE, se usa un modelo de recursos distinto que Logging y Monitoring heredados a fin de organizar las métricas, los registros y los metadatos. Estos son algunos de los cambios específicos de los clústeres que usan operaciones en la nube para GKE:

  • Cambios en la navegación: El panel de Cloud Monitoring se llama GKE. Este panel no aparecerá si no tienes clústeres que usen las operaciones en la nube para GKE.

  • 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 las métricas de Kubernetes: En las operaciones en la nube para GKE, los nombres de tipos de métricas ahora comienzan con el prefijo kubernetes.io/ en lugar de container.googleapis.com/.

  • Cambios en los metadatos de logEntry: Las entradas de registro de las operaciones en la nube para GKE cambiaron los nombres de algunos campos resource.label y labels. Por ejemplo, el campo resource.labels.namespace_id cambió a resource.labels.namespace_name, pero el valor no cambió.

  • Cambios en logName: Las entradas de registros de las operaciones en la nube para GKE usan stdout o stderr en sus nombres de registro, mientras que Logging y Monitoring heredados usan una variedad más amplia de nombres, incluido el nombre del contenedor. El nombre del contenedor aún está disponible en las operaciones en la nube para GKE como una etiqueta de recurso en resource.labels.container_name.

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

Cambio Logging y Monitoring heredados (antiguo) Operaciones en la nube para GKE (nuevo)
Menús del panel Paneles > Clústeres de GKE Paneles > GKE
Prefijos de métricas container.googleapis.com kubernetes.io
Tipos de recursos de métricas gke_container
gce_instance
(ninguno)		 k8s_container
k8s_node
k8s_pod
Tipos de recursos de registros container
gke_cluster
gce_instance
gke_nodepool
k8s_container
k8s_cluster
gke_cluster (solo registros de auditoría)
k8s_node
k8s_pod

Cambios en los tipos de recursos

Las operaciones en la nube para GKE tienen nuevos nombres de tipos de recursos, nuevos nombres visibles de tipos de recursos y nombres nuevos para las etiquetas que identifican recursos específicos. Estos cambios se enumeran en la siguiente tabla.

Cambios en los tipos de recursos
Tipo de recurso de Logging y Monitoring heredados (antiguo) Tipos de recursos de las operaciones en la nube para GKE (nuevo)
Notas al pie de la tabla:
1 En el tipo de recurso nuevo usado (solo) en la supervisión, 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 se actualiza a las operaciones en la nube para GKE, los usos relacionados con nodos se cambian a fin de usar el tipo de recurso nuevo, 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_id1
  namespace_id
  pod_id
  project_id
  zone2

Solo Logging:
container (contenedor de GKE)

Etiquetas:
  cluster_name
  container_name
  instance_id1
  namespace_id
  pod_id
  project_id
  zone2

 Monitoring y Logging:
k8s_container (contenedor de Kubernetes)

Etiquetas:
  cluster_name
  container_name
  metadata.system_labels.node_name3
  namespace_name
  pod_name
  project_id
  location2

Solo Logging::
gce_instance (instancia de VM de Compute Engine) 4

Etiquetas:
  cluster_name
  instance_id
  project_id
  zone2		 Monitoring y Logging:
k8s_node4 (nodo de Kubernetes)

Etiquetas:
  cluster_name
  node_name
  project_id
  location2
 
(ninguno)
 Monitoring y Logging:
k8s_pod5 (pod de Kubernetes)

Etiquetas:
  cluster_name
  namespace_name
  pod_name
  project_id
  location2
Solo Logging
gke_cluster (GKE_cluster)

Etiquetas:
  cluster_name
  project_id
  location

 Monitoring y Logging:
k8s_cluster5 (clúster de Kubernetes)

Etiquetas:
  cluster_name
  project_id
  location

¿Qué debo hacer?

En esta sección, se incluye información más específica sobre los cambios del modelo de recursos en las operaciones en la nube para GKE y su impacto en la configuración existente de Monitoring y Logging.

Debes realizar los siguientes pasos con el fin de migrar tu clúster a las operaciones en la nube para GKE:

  1. Identifica tus opciones de configuración de Logging y Monitoring: Identifica las opciones de configuración de Logging y Monitoring que podrían estar usando valores que cambiaron entre las funciones de Logging y Monitoring heredados y las operaciones en la nube para GKE.

  2. Actualiza tu configuración de Logging y Monitoring: Actualiza cualquier opción de configuración de Logging y Monitoring con el fin de que se reflejen los cambios presentes en las operaciones en la nube para GKE.

  3. Actualiza la configuración de tu clúster de GKE: Actualiza tu clúster de GKE con el fin de que use la configuración de las operaciones en la nube para GKE.

Debido a que los modelos de recursos y los logNames cambiaron entre las versiones heredadas de Logging y Monitoring y las operaciones en la nube para GKE, también deben actualizarse los parámetros de configuración de Logging o Monitoring que hagan referencia a los cambios en los modelos de recursos. La migración puede requerir que actualices los parámetros de configuración de Logging y Monitoring, incluidos, entre otros, los siguientes:

  • Paneles personalizados
  • Gráficos
  • Filtros de grupo
  • Políticas de alertas
  • Receptores de registros
  • Exclusiones de registros
  • Métricas basadas en registros en Cloud Logging y Cloud Monitoring

Identifica clústeres con Logging y Monitoring heredados

Existen 2 maneras de identificar qué clústeres de un proyecto usan Logging y Monitoring heredados.

  1. Usa la herramienta de línea de comandos de gcloud por proyecto

    Puedes usar el siguiente comando de gcloud para enumerar los valores de loggingService y monitoringService de cada clúster en el proyecto actual.

    gcloud container clusters list | tail +2 | while read name loc rest ; do echo $name ; gcloud container clusters describe $name --zone $loc | egrep 'loggingService|monitoringService' ; echo ; done

    Deberías ver un resultado del comando similar al siguiente texto.

      cluster-1
  loggingService: logging.googleapis.com
  monitoringService: monitoring.googleapis.com

  cluster-2
  loggingService: logging.googleapis.com/kubernetes
  monitoringService: monitoring.googleapis.com/kubernetes

  cluster-3
  loggingService: logging.googleapis.com/kubernetes
  monitoringService: none

    Si el resultado de un clúster contiene loggingService: logging.googleapis.com o monitoringService: monitoring.googleapis.com, entonces el clúster usa Logging y Monitoring heredados.

    Si el resultado de un clúster contiene loggingService: logging.googleapis.com/kubernetes o monitoringService:monitoring.googleapis.com/kubernetes, entonces el clúster usa Cloud Operations para GKE.

  2. Usa el panel de clústeres de GKE de Cloud Monitoring

    1. Haz clic en el panel de clústeres de GKE de Cloud Monitoring.
    2. Selecciona el “Workspace”, que incluye el proyecto de Google Cloud que deseas revisar para los clústeres que ejecutan Logging y Monitoring heredados.

    3. Visualiza la lista de clústeres en el panel. Solo los clústeres que usan Logging y Monitoring heredados aparecen en el panel.

      Por ejemplo, en la siguiente captura de pantalla, hay 4 clústeres que usan Logging y Monitoring heredados.

      Imagen de los clústeres con las soluciones heredadas.

Migra tus recursos de supervisión

Si usas Logging y Monitoring heredados con un clúster de GKE cuya versión del plano de control es 1.15 o posterior, las métricas de tu clúster están disponibles en los modelos de recursos de Monitoring y Cloud Operations para GKE. Esto significa que, incluso antes de migrar tus clústeres a las operaciones de Cloud para GKE, tus clústeres comenzarán a generar métricas con el modelo de datos nuevo sin costo adicional.

A partir de enero de 2021, tus paneles y alertas personalizados se actualizarán de forma automática para hacer referencia a las métricas nuevas del modelo de recursos. Si deseas migrar tus propias configuraciones de Cloud Monitoring (gráficos en paneles personalizados, alertas y grupos), debes actualizar cada configuración para reflejar el modelo de recursos nuevo.

También deberás migrar tus configuraciones si mantienes tu configuración en Terraform o algún otro administrador de implementaciones y sincronizas automáticamente los cambios.

Identifica las configuraciones para el modelo de datos anterior

Para identificar la configuración de Cloud Monitoring que debes actualizar como parte de la migración a las operaciones de Cloud para GKE, consulta el panel Estado de migración de Kubernetes:

  1. En Cloud Console, ve a Monitoring:

    Ir a Monitoring

  2. En el panel de navegación de Monitoring, haz clic en Configuración (Settings) y, luego, selecciona la pestaña Kubernetes Migration Status.

En el siguiente panel de ejemplo, se muestra que debe actualizarse 1 política de alertas:

Se muestra el panel de migración.

Actualiza la configuración de Cloud Monitoring

Si tu clúster usa la versión 1.15 de GKE o una posterior y usa Monitoring heredado, se publica en ambos modelos de datos. En este caso, tienes dos opciones para migrar tus configuraciones.

  • Clona las configuraciones y actualiza los clones. Con esta opción, se crea una copia de los paneles, políticas de alertas y grupos existentes, y migras las copias al nuevo modelo de recursos. De esa manera, puedes seguir usando Monitoring para tu clúster con el modelo de datos anterior y el nuevo de manera simultánea. Por ejemplo, con esta opción, tendrías 2 paneles: el original que continúa usando el modelo de recursos original y una clonación del panel original que usa el nuevo modelo de recursos.

  • Actualiza las configuraciones afectadas. En esta opción, se cambia al modelo de datos nuevo de Cloud Monitoring de inmediato.

En las siguientes secciones, se proporcionan instrucciones para migrar tus configuraciones de paneles, políticas de alertas y grupos.

Un aspecto para decidir qué opción elegir es qué historial de supervisión deseas tener disponible. Actualmente, Cloud Monitoring ofrece 6 semanas de datos históricos de tus clústeres. Después de la actualización del clúster de GKE que comienza a escribir dos veces en los modelos de datos, el modelo de datos anterior aún tiene las métricas históricas para el clúster, mientras que el modelo de datos nuevo solo tiene métricas que comienzan en el momento de la actualización.

Si no necesitas los datos históricos, puedes actualizar las configuraciones al nuevo modelo de datos nuevo en cualquier momento. Si los datos históricos son importantes, puedes clonar las configuraciones y actualizar las clonaciones para usar los nuevos tipos de modelos de recursos.

También puedes esperar 6 semanas después de que tu clúster comience a escribir dos veces en ambos modelos de datos. Después de seis semanas, ambos modelos de datos tienen los mismos datos históricos, por lo que puedes actualizar las configuraciones implementadas y cambiar al modelo de datos nuevo.

Actualiza paneles

Para ver tus paneles, completa los siguientes pasos:

  1. Desde Cloud Console, ve a Monitoring:

    Ir a Monitoring

  2. Selecciona Paneles.

Para clonar un panel y actualizar la clonación, completa los siguientes pasos:

  1. Busca el panel que deseas clonar.

  2. Haz clic en Copiar panel () y, luego, ingresa un nombre para el panel clonado.

  3. Actualiza las configuraciones del panel nuevo según sea necesario.

Para actualizar las definiciones de gráfico en el panel, completa los siguientes pasos:

  1. Haga clic en Más opciones de gráficos (⋮) del gráfico que deseas editar.

  2. Selecciona Editar para abrir el panel Editar gráfico.

  3. Cambia el tipo de recurso y el nombre de la métrica para traducir al nuevo modelo de datos. También puedes actualizar los campos Filtrar y Agrupar por según sea necesario.

Actualiza las políticas de alertas

Para ver tus políticas de alertas, completa los siguientes pasos:

  1. Desde Cloud Console, ve a Monitoring:

    Ir a Monitoring

  2. Selecciona Alertas.

Para clonar y actualizar una política de alertas, completa los siguientes pasos:

  1. Selecciona la política que deseas clonar desde la tabla Políticas.

  2. Haz clic en Copiar para comenzar el flujo de creación de la copia de la política de alertas.

  3. Edita las condiciones que hacen referencia al modelo de datos anterior para actualizar el tipo de recurso y el nombre de la métrica.

    El último paso del flujo te permite ingresar un nombre para la política clonada.

Para editar una política de alertas en su lugar, completa los siguientes pasos:

  1. Selecciona la política que deseas editar en la tabla Políticas.

  2. Haz clic en Editar para actualizar la política.

  3. Actualiza las condiciones que hacen referencia al modelo de datos anterior.

Actualiza grupos

No puedes clonar un grupo a través de Google Cloud Console, por lo que si deseas duplicar un grupo, debes crear un grupo nuevo con el mismo filtro.

Un filtro de grupo puede hacer referencia al modelo de datos anterior de varias maneras.

  • Tipo de recurso: un grupo puede definir un filtro resource.type="gke_container". Porque el gke_container se puede usar para hacer referencia a varios tipos diferentes de entidades de GKE, debes actualizar el filtro al tipo de recurso que en realidad quieres hacer coincidir: k8s_container ,k8s_pod ok8s_node. Si deseas hacer coincidir varios tipos, define un filtro con varias cláusulas combinadas con el operador OR.

  • Etiqueta cloud_account: un grupo puede definir un filtro resource.metadata.cloud_account="<var>CLOUD_ACCOUNT_ID</<var>". Como parte de una baja independiente, el campo de metadatos cloud_account ya no está disponible. Considera usar la etiqueta resource.labels.project_id.

  • Etiqueta region: un grupo puede definir un filtro resource.metadata.region="<var>REGION_NAME</<var>". El campo de metadatos region ya no está disponible en el modelo de datos nuevo. Si deseas hacer coincidir las entidades de GKE según la ubicación geográfica, considera usar la etiqueta resource.labels.location.

Asigna métricas entre modelos de datos

En esta sección, se describe cómo asignar métricas del modelo de datos anterior a las métricas en el nuevo modelo de datos. En el modelo de datos anterior, se publicaron 17 métricas diferentes, que se enumeran en las tablas a continuación. Algunas de estas métricas se publicaron en varios tipos de entidades de GKE, lo que da como resultado más de 17 asignaciones para traducir todas las métricas.

Cuando asignes métricas, recuerda lo siguiente:

  • El prefijo para las métricas anteriores es container.googleapis.com/. El prefijo para las métricas nuevas es kubernetes.io/.

  • En el modelo de datos anterior, el único tipo de recurso es gke_container. Según cómo hayas definido las etiquetas de recursos, este tipo de recurso puede referirse a contenedores de GKE, pods, daemons del sistema y máquinas, que corresponden a nodos de GKE.

  • Puedes consultar la API de Monitoring con combinaciones de pod_id y container_name que no coincidan con las enumeradas en la siguiente tabla. Los datos que muestran esas consultas no están definidos y no se proporcionan asignaciones de estos estados indefinidos.

    Tipo de entidad de GKE Filtro
    Contenedor pod_id != '' y container_name != ''
    (pod_id no es la string vacía y container_name no es la string vacía)
    Pod pod_id != '' y container_name == ''
    (pod_id no es la string vacía y container_name es la string vacía)
    Daemon del sistema pod_id == '' and container_name != 'machine'
    (pod_id es la string vacía y container_name es uno de docker-daemon, kubelets o pods)
    Machine pod_id == '' and container_name == 'machine'
    (pod_id es la string vacía y container_name es la string machine)

Las tablas enumeran tres tipos de asignaciones:

  • Asignación directa entre los modelos de datos antiguos y nuevos.

  • Asignaciones que requieren configuración.

  • Asignaciones de métricas antiguas que no tienen un equivalente directo en el modelo nuevo.

Asignación directa

Las siguientes métricas se traducen directamente entre los modelos de datos antiguos y los nuevos.

Nombre de la métrica anterior Tipo de entidad de GKE anterior Nombre de la métrica nueva Nuevo tipo de recurso de GKE Notas
container/accelerator/
duty_cycle		 Contenedor container/accelerator/
duty_cycle		 k8s_container
container/accelerator/
memory_total		 Contenedor container/accelerator/
memory_total		 k8s_container
container/accelerator/
memory_used		 Contenedor container/accelerator/
memory_used		 k8s_container
container/accelerator/
request		 Contenedor container/accelerator/
request		 k8s_container
container/cpu/
reserved_cores		 Contenedor container/cpu/
limit_cores		 k8s_container Consulta Asignaciones que requieren configuración para asignar cuando el recurso es pod
container/cpu/
usage_time		 Contenedor container/cpu/
core_usage_time		 k8s_container Consulta Asignaciones que requieren configuración para asignar cuando el recurso es pod
container/cpu/
usage_time		 Daemon del sistema node_daemon/cpu/
core_usage_time		 k8s_node En el modelo de datos anterior,
gke_container.container_name es uno de docker-daemon, kubelets o pods. Estos valores de filtro coinciden con los valores del nuevo campo de modelo de datos metric.component.
container/cpu/
utilization		 Contenedor container/cpu/
limit_utilization		 k8s_container
container/disk/
bytes_total		 Pod pod/volume/
total_bytes		 k8s_pod gke_container.device_name (Volume:config-volume) se traduce a k8s_pod.volume_name (config-volume) quitando el Volume: que se antepone.
container/disk/bytes_used Pod pod/volume/
used_bytes		 k8s_pod gke_container.device_name (Volume:config-volume) se traduce a k8s_pod.volume_name (config-volume) quitando el Volume: que se antepone.
container/memory/
bytes_total		 Contenedor container/memory/
limit_bytes		 k8s_container
container/memory/
bytes_used		 Contenedor container/memory/
used_bytes		 k8s_container
container/memory/
bytes_used		 Daemon del sistema node_daemon/memory/
used_bytes		 k8s_node En el modelo de datos anterior,
gke_container.container_name es uno de docker-daemon, kubelets o pods. Estos valores de filtro coinciden con los valores del nuevo campo de modelo de datos metric.component.
container/disk/
inodes_free		 Machine node/ephemeral_storage/
inodes_free		 k8s_node El modelo de datos anterior tiene el campo instance_id, un ID de número al azar. El nuevo modelo de datos tiene node_name, un nombre legible.
container/disk/
inodes_total		 Machine node/ephemeral_storage/
inodes_total		 k8s_node El modelo de datos anterior tiene el campo instance_id, un ID de número al azar. El nuevo modelo de datos tiene node_name, un nombre legible.
container/pid_limit Machine node/pid_limit k8s_node El modelo de datos anterior tiene el campo instance_id, un ID de número al azar. El nuevo modelo de datos tiene node_name, un nombre legible.
container/pid_used Machine node/pid_used k8s_node El modelo de datos anterior tiene el campo instance_id, un ID de número al azar. El nuevo modelo de datos tiene node_name, un nombre legible.
Asignaciones que requieren configuración

Las siguientes métricas traducen desde el modelo de datos anterior al nuevo modelo de datos con cierta manipulación básica.

Nombre de la métrica anterior Tipo de entidad de GKE anterior Nombre de la métrica nueva Nuevo tipo de recurso de GKE Notas
container/cpu/
reserved_cores		 Pod SUM container/cpu/limit_cores
GROUP BY pod_name		 k8s_container El modelo de datos anterior tiene un campo pod_id, un UUID. El nuevo modelo de datos tiene pod_name, un nombre legible.
container/cpu/
usage_time		 Pod SUM container/cpu/core_usage_time
GROUP BY pod_name		 k8s_container El modelo de datos anterior tiene un campo pod_id, un UUID. El nuevo modelo de datos tiene un pod_name, un nombre legible.
container/disk/
bytes_total		 Contenedor node/ephemeral_storage/
total_bytes		 k8s_container gke_container.device_name es uno de / o logs. Cada uno de estos valores es igual al nuevo.
container/disk/
bytes_used		 Contenedor container/ephemeral_storage/
used_bytes		 k8s_container gke_container.device_name es uno de / o logs. Se deben agregar estos 2 valores para obtener el valor nuevo. En el nuevo modelo de datos, no puedes obtener el valor de / y logs por separado.
container/memory/
bytes_total		 Pod SUM container/memory/limit_bytes
GROUP BY pod_name		 k8s_container El modelo de datos anterior tiene un campo pod_id, un UUID. El nuevo modelo de datos tiene pod_name, un nombre legible.
container/memory/
bytes_used		 Pod SUM container/memory/used_bytes
GROUP BY pod_name		 k8s_container El modelo de datos anterior tiene un campo pod_id, un UUID. El nuevo modelo de datos tiene pod_name, un nombre legible.
Asignaciones que no tienen un equivalente directo en el modelo nuevo

Las siguientes métricas no tienen un equivalente en el nuevo modelo de datos.

Uso de CPU para el pod
En el modelo de datos anterior, esta métrica, según el límite de CPU para cada contenedor, es un promedio ponderado del uso de CPU en todos los contenedores de un pod.
En el nuevo modelo de datos, este valor no existe y debe calcularse del lado del cliente según el límite y el uso de cada contenedor.
Tiempo de actividad
En el modelo de datos anterior, esta métrica es una métrica acumulativa que representa la fracción de tiempo que un contenedor está disponible en unidades ms/s. Para un contenedor que siempre está disponible, el valor es de alrededor de 1000 ms/s.
En el nuevo modelo de datos, esta métrica es una métrica de indicador en horas que informa cuánto tiempo se ha ejecutado cada parte del sistema sin interrupciones.

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 aparecen en la tabla Cambios en los tipos de recursos anterior, cambia esos tipos a los correspondientes a las operaciones en la nube para GKE. Si tu grupo de recursos incluye gráficos personalizados, es posible que debas cambiarlos.

Migra tus recursos de registro

Para migrar tus recursos de registro, completa los pasos en las siguientes secciones.

Cambios en el contenido de la entrada de registro

Cuando actualizas a las operaciones en la nube para GKE, es posible que descubras que cierta información de las entradas de registro se trasladó a campos con nombres diferentes. Esta información puede aparecer en las consultas de registros que se usan en las métricas basadas en registros, los receptores de registros y las exclusiones de registros.

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

  • Verifica el campo logName en los filtros. Las entradas de registro de las operaciones en la nube para GKE usan stdout o stderr en sus nombres de registro, mientras que Logging y Monitoring heredados usan una variedad más amplia de nombres, incluido el nombre del contenedor. El nombre del contenedor aún está disponible como etiqueta de recurso.
  • Verifica 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 las entradas de registro
Entradas de registro de Logging y Monitoring heredados (antiguo) Entradas de registro de las operaciones en la nube para GKE (nuevo)
Notas al 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 operaciones en la nube para GKE y, en ocasiones, en algunas entradas de registro de Logging y Monitoring heredados. En las operaciones en la nube para GKE, se usa a fin de almacenar información que antes se encontraba 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 entradas de registro
labels

etiquetas (ejemplos)
  k8s-pod/app:
    "currencyservice"
  k8s-pod/pod-template-hash:
    "5a67f17c"

Registros de ejemplo:

Cambios en los tipos de recursos de contenedor:

El texto rojo y en negrita destaca las diferencias entre los modelos de recursos de Logging y Monitoring heredados y los de las operaciones en la nube para GKE.

Modelo de recursos Registros de ejemplo
Logging y Monitoring heredados 

{
  "insertId": "fji4tsf1a8o5h",
  "jsonPayload": {
    "pid": 1,
    "name": "currencyservice-server",
    "v": 1,
    "message": "conversion request successful",
    "hostname": "currencyservice-6995d74b95-zjkmj"
  },
  "resource": {
    "type": "container",
    "labels": {
      "project_id": "my-test-project",
      "cluster_name": "my-test-cluster",
      "pod_id": "currencyservice-6995d74b95-zjkmj",
      "zone": "us-central1-c",
      "container_name": "server",
      "namespace_id": "default",
      "instance_id": "1234567890"
    }
  },
  "timestamp": "2020-10-02T19:02:47.575434759Z",
  "severity": "INFO",
  "labels": {
    "container.googleapis.com/pod_name": "currencyservice-6995d74b95-zjkmj",
    "compute.googleapis.com/resource_name": "gke-legacy-cluster-default-pool-c534acb8-hvxk",
    "container.googleapis.com/stream": "stdout",
    "container.googleapis.com/namespace_name": "default"
  },
  "logName": "projects/my-test-project/logs/server",
  "receiveTimestamp": "2020-10-02T19:02:50.972304596Z"
}
Operaciones en la nube para GKE 

{
  "insertId": "mye361s5zfcl55amj",
  "jsonPayload": {
    "v": 1,
    "name": "currencyservice-server",
    "pid": 1,
    "hostname": "currencyservice-5b69f47d-wg4zl",
    "message": "conversion request successful"
  },
  "resource": {
    "type": "k8s_container",
    "labels": {
      "container_name": "server",
      "project_id": "my-test-project",
      "pod_name": "currencyservice-5b69f47d-wg4zl",
      "namespace_name": "onlineboutique",
      "location": "us-central1-c",
      "cluster_name": "my-prod-cluster"

    }
  },
  "timestamp": "2020-10-02T18:41:55.359669767Z",
  "severity": "INFO",
  "labels": {
    "k8s-pod/app": "currencyservice",
    "k8s-pod/pod-template-hash": "5b69f47d",
    "compute.googleapis.com/resource_name": "gke-legacy-cluster-default-pool-c534acb8-hvxk"
  },
  "logName": "projects/my-test-project/logs/stdout",
  "receiveTimestamp": "2020-10-02T18:41:57.930654427Z"
}

Cambios en los tipos de recursos del clúster:

El texto rojo y en negrita destaca las diferencias entre los modelos de recursos de Logging y Monitoring heredados y los de las operaciones en la nube para GKE.

Modelo de recursos Registros de ejemplo
Logging y Monitoring heredados 

{
  "insertId": "962szqg9uiyalt",
  "jsonPayload": {
    "type": "Normal",
    "involvedObject": {
      "apiVersion": "policy/v1beta1",
      "uid": "a1bc2345-12ab-12ab-1234-123456a123456",
      "resourceVersion": "50968",
      "kind": "PodDisruptionBudget",
      "namespace": "knative-serving",
      "name": "activator-pdb"
    },
    "apiVersion": "v1",
    "reason": "NoPods",
    "source": {
      "component": "controllermanager"
    },
    "message": "No matching pods found",
    "kind": "Event",
    "metadata": {
      "selfLink": "/api/v1/namespaces/knative-serving/events/activator-pdb.163a42fcb707c1fe",
      "namespace": "knative-serving",
      "name": "activator-pdb.163a42fcb707c1fe",
      "uid": "a1bc2345-12ab-12ab-1234-123456a123456",
      "creationTimestamp": "2020-10-02T19:17:50Z",
      "resourceVersion": "1917"
    }
  },
  "resource": {
    "type": "gke_cluster",
    "labels": {
      "project_id": "my-test-project",
      "location": "us-central1-c",
      "cluster_name": "my-prod-cluster"
    }
  },
  "timestamp": "2020-10-02T21:33:20Z",
  "severity": "INFO",
  "logName": "projects/my-test-project/logs/events",
  "receiveTimestamp": "2020-10-02T21:33:25.510671123Z"
}
Operaciones en la nube para GKE 

{
  "insertId": "1qzipokg6ydoesp",
  "jsonPayload": {
    "involvedObject": {
      "uid": "a1bc2345-12ab-12ab-1234-123456a123456",
      "name": "istio-telemetry",
      "apiVersion": "autoscaling/v2beta2",
      "resourceVersion": "90505937",
      "kind": "HorizontalPodAutoscaler",
      "namespace": "istio-system"
    },
    "source": {
      "component": "horizontal-pod-autoscaler"
    },
    "kind": "Event",
    "type": "Warning",
    "message": "missing request for cpu",
    "metadata": {
      "resourceVersion": "3071416",
      "creationTimestamp": "2020-08-22T14:18:59Z",
      "name": "istio-telemetry.162d9ce2894d6642",
      "selfLink": "/api/v1/namespaces/istio-system/events/istio-telemetry.162d9ce2894d6642",
      "namespace": "istio-system",
      "uid": "a1bc2345-12ab-12ab-1234-123456a123456"
    },
    "apiVersion": "v1",
    "reason": "FailedGetResourceMetric"
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "project_id": "my-test-project"
      "location": "us-central1-a",
      "cluster_name": "my-prod-cluster1",
    }
  },
  "timestamp": "2020-10-02T21:39:07Z",
  "severity": "WARNING",
  "logName": "projects/my-test-project/logs/events",
  "receiveTimestamp": "2020-10-02T21:39:12.182820672Z"
}

Cambios en los tipos de recursos de nodo:

El texto rojo y en negrita destaca las diferencias entre los modelos de recursos de Logging y Monitoring heredados y los de las operaciones en la nube para GKE.

Modelo de recursos Registros de ejemplo
Logging y Monitoring heredados 

{
  "insertId": "16qdegyg9t3n2u5",
  "jsonPayload": {
    "SYSLOG_IDENTIFIER": "kubelet",
    [...]
    "PRIORITY": "6",
    "_COMM": "kubelet",
    "_GID": "0",
    "_MACHINE_ID": "9565f7c82afd94ca22612c765ceb1042",
    "_SYSTEMD_UNIT": "kubelet.service",
    "_EXE": "/home/kubernetes/bin/kubelet"
  },
  "resource": {
    "type": "gce_instance",
    "labels": {
      "instance_id": "1234567890",
      "zone": "us-central1-a",
      "project_id": "my-test-project"
    }
  },
  "timestamp": "2020-10-02T21:43:14.390150Z",
  "labels": {
    "compute.googleapis.com/resource_name": "gke-legacy-monitoring-default-pool-b58ff790-29rr"
  },
  "logName": "projects/my-test-project/logs/kubelet",
  "receiveTimestamp": "2020-10-02T21:43:20.433270911Z"
}
Operaciones en la nube para GKE 

{
  "insertId": "kkbgd6e5tmkpmvjji",
  "jsonPayload": {
    "SYSLOG_IDENTIFIER": "kubelet",
   [...]
    "_CAP_EFFECTIVE": "3fffffffff",
    "_HOSTNAME": "gke-standard-cluster-1-default-pool-f3929440-f4dy",
    "PRIORITY": "6",
    "_COMM": "kubelet",
    "_TRANSPORT": "stdout",
    "_GID": "0",
    "MESSAGE": "E1002 21:43:14.870346    1294 pod_workers.go:190] Error syncing pod 99ba1919-d633-11ea-a5ea-42010a800113 (\"stackdriver-metadata-agent-cluster-level-65655bdbbf-v5vjv_kube-system(99ba1919-d633-11ea-a5ea-42010a800113)\"), skipping: failed to \"StartContainer\" for \"metadata-agent\" with CrashLoopBackOff: \"Back-off 5m0s restarting failed container=metadata-agent pod=stackdriver-metadata-agent-cluster-level-65655bdbbf-v5vjv_kube-system(99ba1919-d633-11ea-a5ea-42010a800113)\""
  },
  "resource": {
    "type": "k8s_node",
    "labels": {
      "cluster_name": "my-prod-cluster-1",
      "location": "us-central1-a",
      "node_name": "gke-standard-cluster-1-default-pool-f3929440-f4dy"
       "project_id": "my-test-project",
    }
  },
  "timestamp": "2020-10-02T21:43:14.870426Z",
  "logName": "projects/my-test-project/logs/kubelet",
  "receiveTimestamp": "2020-10-02T21:43:20.788933199Z"
}

Actualizaciones de la configuración de Logging

En esta sección, se describen los cambios que debes realizar en la configuración de Cloud Logging como parte de una migración a las operaciones en la nube para GKE. También deberás migrar tus configuraciones si mantienes tu configuración en Terraform o algún otro administrador de implementaciones y sincronizas automáticamente los cambios.

Consultas de Logging

Si usas consultas para buscar 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 en los tipos de recursos anterior, cambia esos tipos por los tipos correspondientes de las operaciones en la nube para GKE.

Por ejemplo, en Logging y Monitoring heredados, consultas los registros de contenedores con el tipo de recurso container, mientras que en las operaciones en la nube para GKE usas el tipo de recurso k8s_container para consultar los registros de contenedores.

  resource.type="k8s_container"

Como otro ejemplo, en Logging y Monitoring heredados, consultas nombres de registro específicos para contenedores mediante el nombre del contenedor, mientras que en las operaciones en la nube para GKE usas los nombres de registro stdout y stderr para consultar los registros de contenedores.

  resource.type="k8s_container"
  log_name="projects/YOUR_PROJECT_NAME/logs/stdout"
  resource.labels.container_name="CONTAINER_NAME"

Métricas basadas en registros

Si defines tus propias métricas basadas en registros y usas las métricas o los tipos de recursos de Logging y Monitoring heredados que se muestran en las tablas anteriores Cambios en los nombres de las métricas o Cambios en los tipos de recursos, cambia las métricas y los tipos de recursos a los correspondientes de las operaciones en la nube para GKE.

Puedes usar el siguiente comando de la herramienta de gcloud para encontrar tus métricas basadas en registros:

  gcloud logging metrics list --filter='filter~resource.type=\"container\" OR filter~resource.type=container'

  gcloud logging metrics list --filter='filter~resource.labels.namespace_id'

  gcloud logging metrics list --filter='filter~resource.labels.pod_id'

  gcloud logging metrics list --filter='filter~resource.labels.zone'

Puedes usar el siguiente comando de la herramienta de gcloud para actualizar tus métricas basadas en registros.

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.type=\"container\" OR resource.type=\"k8s_container\"'

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.labels.namespace_id=\"YOUR_NAMESPACE\" OR resource.labels.namespace_name=\"YOUR_NAMESPACE\"'

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.labels.pod_id=\"YOUR_POD_NAME\" OR resource.labels.pod_name=\"YOUR_NAME\"'

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.labels.zone=\"YOUR_ZONE\" OR resource.labels.location=\"YOUR_ZONE\"'

Como alternativa, puedes actualizar las métricas basadas en registros en Cloud Console.

Exportaciones de registros

Si exportas algún registro, y si la exportación usa los tipos de recursos de Logging y Monitoring heredados que aparecen en la tabla Cambios en los tipos de recursos anterior, haz cambios en la exportación a fin de que use los tipos de recursos correspondientes de las operaciones en la nube para GKE. Las entradas de registro de las operaciones en la nube para GKE usan stdout o stderr en sus nombres de registro, mientras que Logging y Monitoring heredados utilizan el nombre del contenedor.

Existen 2 consideraciones importantes para el cambio de nombres de registro:

  1. Cambios en las ubicaciones y tablas del archivo de destino: Los valores de los nombres de registro en las operaciones en la nube para GKE incluyen stdout o stderr en lugar del nombre del contenedor. El nombre del contenedor aún está disponible como etiqueta de recurso. El procesamiento del nombre de registro en las exportaciones o consultas de Cloud Storage en las tablas de BigQuery debe modificarse para usar los nombres de registro stdout y stderr.
  2. Valores de logName: Los valores del nombre de registro se usan para determinar la estructura del archivo exportado en Cloud Storage y la estructura de la tabla de BigQuery. El uso de los archivos de Cloud Storage y las tablas de BigQuery debe ajustarse para la estructura de carpetas en Cloud Storage y las estructuras de tablas en BigQuery.

Puedes usar los siguientes comandos de la herramienta de línea de comandos de gcloud para encontrar tus receptores de Logging afectados:

  gcloud logging sinks list --filter='filter~resource.type=\"container\" OR filter~resource.type=container'

  gcloud logging sinks list --filter='filter~resource.labels.namespace_id'

  gcloud logging sinks list --filter='filter~resource.labels.pod_id'

  gcloud logging sinks list --filter='filter~resource.labels.zone'

Puedes usar el siguiente comando de la herramienta de gcloud para actualizar tus receptores de Logging.

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.type=\"container\" OR resource.type=\"k8s_container\"'

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.labels.namespace_id=\"YOUR_NAMESPACE\" OR resource.labels.namespace_name=\"YOUR_NAMESPACE\"'

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.labels.pod_id=\"YOUR_POD_NAME\" OR resource.labels.pod_name=\"YOUR_NAME\"'

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.labels.zone=\"YOUR_ZONE\" OR resource.labels.location=\"YOUR_ZONE\"'

Como alternativa, puedes actualizar las métricas basadas en registros en Cloud Console.

Exclusiones de registros

Si excluyes algún registro, y si los filtros de exclusión usan los tipos de recursos de Logging y Monitoring heredados que aparecen en la tabla Cambios en los tipos de recursos anterior, haz cambios en los filtros de exclusión a fin de que usen los tipos de recursos correspondientes de las operaciones en la nube para GKE.

Si deseas obtener información para ver las exclusiones de registros, consulta la guía Visualiza filtros de exclusión.

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 cambiaron en las operaciones en la nube para GKE, asegúrate de buscar los registros en los tipos de recursos nuevos, como Kubernetes Container, en lugar de hacerlo en los tipos de Logging y Monitoring heredados, como GKE Container.

Actualiza la configuración de tu clúster

Después de migrar recursos de registro y de supervisión para que usen el formato de datos de operaciones en la nube para GKE, el último paso es actualizar tu clúster de GKE a fin de usar las operaciones en la nube para GKE.

Para actualizar la configuración de registro y supervisión de tu clúster de GKE, sigue estos pasos:

CONSOLE

  1. Ve a la página de Clústeres de GKE para tu proyecto. El siguiente botón te lleva allí:

    Ir a Clústeres de Kubernetes

  2. Haz clic en el clúster que deseas actualizar a fin de usar las operaciones en la nube para GKE.

  3. En la fila etiquetada Operaciones en la nube para GKE, haz clic en el ícono Editar.

  4. En el cuadro de diálogo que aparece, confirma que la opción Habilitar operaciones en la nube para GKE esté seleccionada.

  5. En el menú desplegable del cuadro de diálogo, selecciona qué registros y métricas deseas recopilar. La configuración predeterminada (recomendada) para las operaciones en la nube para GKE es Registros y supervisión del sistema y la carga de trabajo. Si seleccionas cualquier valor de este menú desplegable que no sea “Logging y Monitoring heredados”, se actualizará el clúster a fin de comenzar a usar las operaciones en la nube para GKE en lugar de Logging y Monitoring heredados.

  6. Haz clic en Guardar cambios.

GCLOUD

  1. Ejecuta este comando:

    gcloud container clusters update [CLUSTER_NAME] \
  --zone=[ZONE] \
  --project=[PROJECT_ID] \
  --enable-stackdriver-kubernetes

¿Qué sigue?