Usar el almacenamiento de registros y la monitorización de los componentes del sistema

En este documento se explica cómo configurar el registro y la monitorización de los componentes del sistema en Google Distributed Cloud (solo software) para VMware.

De forma predeterminada, Cloud Logging, Cloud Monitoring y Google Cloud Managed Service para Prometheus están habilitados.

Para obtener más información sobre las opciones, consulta el artículo Información general sobre el registro y la monitorización.

Recursos monitorizados

Los recursos monitorizados son la forma en que Google representa recursos como clústeres, nodos, pods y contenedores. Para obtener más información, consulta la documentación sobre los tipos de recursos monitorizados de Cloud Monitoring.

Para consultar registros y métricas, debes conocer al menos estas etiquetas de recursos:

• project_id: ID de proyecto del proyecto de registro y monitorización del clúster. Ha proporcionado este valor en el campo stackdriver.projectID del archivo de configuración del clúster.

• location: una región en la que quieras enrutar y almacenar tus métricas de Cloud Monitoring. Google Cloud Puedes especificar la región durante la instalación en el campo stackdriver.clusterLocation del archivo de configuración del clúster. Te recomendamos que elijas una región que esté cerca de tu centro de datos local.

  Puede especificar la ubicación de almacenamiento y enrutamiento de los registros de Cloud Logging en la configuración del enrutador de registros. Para obtener más información sobre el enrutamiento de registros, consulta la descripción general del enrutamiento y el almacenamiento.

• cluster_name: nombre del clúster que has elegido al crearlo.

  Para obtener el valor de cluster_name del clúster de administrador o de usuario, inspecciona el recurso personalizado de Stackdriver:

  kubectl get stackdriver stackdriver --namespace kube-system \
  --kubeconfig CLUSTER_KUBECONFIG --output yaml | grep 'clusterName:'
  

  donde

  • CLUSTER_KUBECONFIG es la ruta al archivo kubeconfig del clúster de administrador o del clúster de usuario para el que se requiere el nombre del clúster.

Enrutamiento de registros y métricas

El reenviador de registros de Stackdriver (stackdriver-log-forwarder) envía los registros de cada máquina de nodo a Cloud Logging. Del mismo modo, el agente de métricas de GKE (gke-metrics-agent) envía métricas de cada máquina de nodo a Cloud Monitoring. Antes de que se envíen los registros y las métricas, el operador de Stackdriver (stackdriver-operator) adjunta el valor del campo clusterLocation del recurso personalizado stackdriver a cada entrada de registro y métrica antes de que se enruten a Google Cloud. Además, los registros y las métricas se asocian al Google Cloud proyectostackdriver especificado en la especificación de recursos personalizada spec.projectID. El recurso stackdriver obtiene los valores de los campos clusterLocation y projectID de los campos stackdriver.clusterLocation y stackdriver.projectID de la sección clusterOperations del recurso Cluster en el momento de la creación del clúster.

Todas las métricas y entradas de registro enviadas por los agentes de Stackdriver se dirigen a un endpoint de ingestión global. A partir de ahí, los datos se reenvían al endpoint regional Google Cloud más cercano para asegurar la fiabilidad de la transferencia de datos.

Una vez que el endpoint global recibe la métrica o la entrada de registro, lo que ocurre a continuación depende del servicio:

• Cómo se configura el enrutamiento de registros: cuando el endpoint de registro recibe un mensaje de registro, Cloud Logging lo envía a través del enrutador de registros. Los sumideros y los filtros de la configuración del enrutador de registros determinan cómo se enruta el mensaje. Puedes enrutar entradas de registro a destinos como segmentos de Logging regionales, que almacenan la entrada de registro, o a Pub/Sub. Para obtener más información sobre cómo funciona el enrutamiento de registros y cómo configurarlo, consulta el resumen sobre el enrutamiento y el almacenamiento.

  En este proceso de enrutamiento no se tienen en cuenta ni el campo clusterLocation del recurso personalizado stackdriver ni el campo clusterOperations.location de la especificación de clúster. En el caso de los registros, clusterLocation se usa para etiquetar solo las entradas de registro, lo que puede ser útil para filtrar en Explorador de registros.

• Cómo se configura el enrutamiento de métricas: cuando el endpoint de métricas recibe una entrada de métrica, Cloud Monitoring la enruta automáticamente a la ubicación especificada por la métrica. La ubicación de la métrica procede del campo clusterLocation del recurso personalizado stackdriver.

• Planifica tu configuración: cuando configures Cloud Logging y Cloud Monitoring, configura el enrutador de registros y especifica un clusterLocation adecuado con las ubicaciones que mejor se adapten a tus necesidades. Por ejemplo, si quieres que los registros y las métricas se envíen a la misma ubicación, asigna a clusterLocation la misma región Google Cloud que usa el enrutador de registros para tu proyecto Google Cloud .

• Actualice su configuración cuando sea necesario: puede hacer cambios en cualquier momento en los ajustes de destino de los registros y las métricas debido a requisitos empresariales, como los planes de recuperación ante desastres. Los cambios en la configuración de Log Router en los campos Google Cloud y clusterLocation del recurso personalizado stackdriver se aplican rápidamente.

Usar Cloud Logging

No tienes que hacer nada para habilitar Cloud Logging en un clúster. Sin embargo, debes especificar el Google Cloud proyecto en el que quieres ver los registros. En el archivo de configuración del clúster, especifica el proyecto en la sección Google Cloud stackdriver.

Puedes acceder a los registros mediante el Explorador de registros de la consola de Google Cloud . Por ejemplo, para acceder a los registros de un contenedor, sigue estos pasos:

1. Abre Explorador de registros en la consola de Google Cloud de tu proyecto.
2. Para encontrar los registros de un contenedor, puedes hacer lo siguiente:
   1. Haciendo clic en el cuadro desplegable del catálogo de registros de la parte superior izquierda y seleccionando Contenedor de Kubernetes.
   2. Seleccionando el nombre del clúster, luego el espacio de nombres y, a continuación, un contenedor de la jerarquía.

Ver los registros de los controladores del clúster de arranque

1. En la Google Cloud consola, ve a la página Explorador de registros:

   Ve al Explorador de registros.

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Registro.

2. Para ver todos los registros de los controladores del clúster de arranque, ejecuta la siguiente consulta en el editor de consultas:

   "ADMIN_CLUSTER_NAME"
   resource.type="k8s_container"
   resource.labels.cluster_name="gkectl-bootstrap-cluster"
   

3. Para ver los registros de un pod específico, edita la consulta para incluir el nombre de ese pod:

   resource.type="k8s_container"
   resource.labels.cluster_name="gkectl-bootstrap-cluster"
   resource.labels.pod_name="POD_NAME"
   

Usar Cloud Monitoring

No tienes que hacer nada para habilitar Cloud Monitoring en un clúster. Sin embargo, debe especificar el Google Cloud proyecto en el que quiere ver las métricas. En el archivo de configuración del clúster, especifica el proyecto en la sección Google Cloud stackdriver.

Puede elegir entre más de 1500 métricas con el explorador de métricas. Para acceder al explorador de métricas, haz lo siguiente:

1. En la Google Cloud consola, selecciona Monitoring. También puedes hacer clic en el siguiente botón:

   Ir a Monitoring

2. Seleccione Recursos > Explorador de métricas.

También puede ver las métricas en los paneles de control de la Google Cloud consola. Para obtener información sobre cómo crear paneles de control y ver métricas, consulta Crear paneles de control.

Nota: Los paneles de control de GKE solo muestran información de los clústeres de GKE que se ejecutan en Google Cloud. No muestran información de Google Distributed Cloud.

Ver datos de monitorización a nivel de flota

Para obtener una vista general de la utilización de los recursos de tu flota mediante los datos de Cloud Monitoring, incluidos tus clústeres de Google Distributed Cloud, puedes usar la vista general de Google Kubernetes Engine en la Google Cloud consola. Consulta más información en el artículo sobre cómo gestionar clústeres desde la Google Cloud consola.

Límites de cuota predeterminados de Cloud Monitoring

La monitorización de Google Distributed Cloud tiene un límite predeterminado de 6000 llamadas a la API por minuto en cada proyecto. Si superas este límite, es posible que no se muestren tus métricas. Si necesitas un límite de monitorización superior, solicítalo a través de la Google Cloud consola.

Usar Managed Service para Prometheus

Google Cloud Managed Service para Prometheus forma parte de Cloud Monitoring y está disponible de forma predeterminada. Estas son algunas de las ventajas del servicio gestionado de Prometheus:

• Puedes seguir usando tu monitorización basada en Prometheus sin modificar tus alertas ni tus paneles de control de Grafana.

• Si usas tanto GKE como Google Distributed Cloud, puedes usar el mismo PromQL para las métricas de todos tus clústeres. También puedes usar la pestaña PROMQL del Explorador de métricas de la Google Cloud consola.

Habilitar e inhabilitar Managed Service para Prometheus

A partir de la versión 1.30.0-gke.1930 de Google Distributed Cloud, Managed Service para Prometheus está siempre habilitado. En versiones anteriores, puedes editar el recurso de Stackdriver, stackdriver, para habilitar o inhabilitar Managed Service for Prometheus. Para inhabilitar Managed Service for Prometheus en versiones de clúster anteriores a la 1.30.0-gke.1930, asigna el valor false a spec.featureGates.enableGMPForSystemMetrics en el recurso stackdriver.

Ver datos de métricas

Cuando Managed Service para Prometheus está habilitado, las métricas de los siguientes componentes tienen un formato diferente en cuanto a cómo se almacenan y se consultan en Cloud Monitoring:

• kube-apiserver
• kube-scheduler
• kube-controller-manager
• kubelet y cadvisor
• kube-state-metrics
• node-exporter

Con el nuevo formato, puede consultar las métricas anteriores mediante el lenguaje de consulta de Prometheus (PromQL).

Ejemplo de PromQL:

histogram_quantile(0.95, sum(rate(apiserver_request_duration_seconds_bucket[5m])) by (le))

Configurar paneles de control de Grafana con Managed Service para Prometheus

Para usar Grafana con datos de métricas de Managed Service para Prometheus, sigue los pasos que se indican en Consultar con Grafana para autenticarte y configurar una fuente de datos de Grafana que consulte datos de Managed Service para Prometheus.

En el repositorio anthos-samples de GitHub se proporciona un conjunto de paneles de Grafana de ejemplo. Para instalar los paneles de control de ejemplo, siga estos pasos:

1. Descarga los archivos .json de ejemplo:

   git clone https://github.com/GoogleCloudPlatform/anthos-samples.git
   cd anthos-samples/gmp-grafana-dashboards
   

2. Si ha creado su fuente de datos de Grafana con un nombre diferente a Managed Service for Prometheus, cambie el campo datasource en todos los archivos .json:

   sed -i "s/Managed Service for Prometheus/[DATASOURCE_NAME]/g" ./*.json
   

   Sustituye [DATASOURCE_NAME] por el nombre de la fuente de datos de tu Grafana que apuntaba al servicio frontend de Prometheus.

3. Accede a la interfaz de usuario de Grafana desde tu navegador y selecciona + Import (Importar) en el menú Dashboards (Paneles de control).

   

4. Sube el archivo .json o copia y pega el contenido del archivo y selecciona Cargar. Cuando el contenido del archivo se haya cargado correctamente, selecciona Importar. También puedes cambiar el nombre y el UID del panel de control antes de importarlo.

   

5. El panel de control importado debería cargarse correctamente si Google Distributed Cloud y la fuente de datos están configurados correctamente. Por ejemplo, en la siguiente captura de pantalla se muestra el panel de control configurado por cluster-capacity.json.

   

Recursos adicionales

Para obtener más información sobre Managed Service para Prometheus, consulta los siguientes recursos:

• Google Cloud Managed Service para Prometheus

• Las métricas del plano de control de GKE son compatibles con PromQL

• Usar Managed Service para Prometheus en aplicaciones de usuario en Google Distributed Cloud

Usar Prometheus y Grafana

A partir de la versión 1.16, Prometheus y Grafana no están disponibles en los clústeres recién creados. Te recomendamos que uses Managed Service para Prometheus como sustituto de la monitorización en el clúster.

Si actualizas un clúster 1.15 que tiene habilitados Prometheus y Grafana a la versión 1.16, Prometheus y Grafana seguirán funcionando como hasta ahora, pero no se actualizarán ni recibirán parches de seguridad.

Si quieres eliminar todos los recursos de Prometheus y Grafana después de actualizar a la versión 1.16, ejecuta el siguiente comando:

kubectl --kubeconfig KUBECONFIG delete -n kube-system \
    statefulsets,services,configmaps,secrets,serviceaccounts,clusterroles,clusterrolebindings,certificates,deployments \
    -l addons.gke.io/legacy-pg=true

Como alternativa a los componentes de Prometheus y Grafana incluidos en versiones anteriores de Google Distributed Cloud, puedes cambiar a una versión de la comunidad de código abierto de Prometheus y Grafana.

Problema conocido

En los clústeres de usuario, Prometheus y Grafana se inhabilitan automáticamente durante las actualizaciones. Sin embargo, los datos de configuración y métricas no se pierden.

Para solucionar este problema, después de la actualización, abre monitoring-sample para editarlo y asigna el valor true a enablePrometheus.

Acceder a métricas de monitorización desde paneles de Grafana

Grafana muestra las métricas recogidas de tus clústeres. Para ver estas métricas, debe acceder a los paneles de Grafana:

1. Obtén el nombre del pod de Grafana que se ejecuta en el kube-system espacio de nombres de un clúster de usuarios:

   kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system get pods

   donde [USER_CLUSTER_KUBECONFIG] es el archivo kubeconfig del clúster de usuarios.

2. El pod de Grafana tiene un servidor HTTP que escucha en el puerto 3000 de localhost TCP. Reenvía un puerto local al puerto 3000 del pod para que puedas ver los paneles de control de Grafana desde un navegador web.

   Por ejemplo, supongamos que el nombre del pod es grafana-0. Para reenviar el puerto 50000 al puerto 3000 del pod, introduce este comando:

   kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system port-forward grafana-0 50000:3000

3. En un navegador web, ve a http://localhost:50000.

4. En la página de inicio de sesión, introduce admin como nombre de usuario y contraseña.

5. Si el inicio de sesión se realiza correctamente, se te pedirá que cambies la contraseña. Una vez que hayas cambiado la contraseña predeterminada, se cargará el panel de control principal de Grafana del clúster de usuarios.

6. Para acceder a otros paneles de control, haz clic en el menú desplegable Inicio de la esquina superior izquierda de la página.

Para ver un ejemplo de cómo usar Grafana, consulta Crear un panel de control de Grafana.

Acceder a las alertas

Alertmanager de Prometheus recoge alertas del servidor de Prometheus. Puedes ver estas alertas en un panel de Grafana. Para ver las alertas, debe acceder al panel de control:

1. El contenedor del pod alertmanager-0 escucha en el puerto TCP 9093. Reenvía un puerto local al puerto 9093 del pod:

   kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] port-forward \
      -n kube-system alertmanager-0 50001:9093

2. En un navegador web, ve a http://localhost:50001.

Cambiar la configuración de Alertmanager de Prometheus

Puedes cambiar la configuración predeterminada de Prometheus Alertmanager editando el archivo monitoring.yaml de tu clúster de usuario. Deberías hacerlo si quieres dirigir las alertas a un destino específico en lugar de mantenerlas en el panel de control. Puedes consultar cómo configurar Alertmanager en la documentación de configuración de Prometheus.

Para cambiar la configuración de Alertmanager, sigue estos pasos:

1. Haz una copia del archivo de manifiesto monitoring.yaml del clúster de usuarios:

   kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system \
      get monitoring monitoring-sample -o yaml > monitoring.yaml

2. Para configurar Alertmanager, modifica los campos de spec.alertmanager.yml. Cuando hayas terminado, guarda el manifiesto modificado.

3. Aplica el manifiesto a tu clúster:

   kubectl apply --kubeconfig [USER_CLUSTER_KUBECONIFG] -f monitoring.yaml

Crear un panel de control de Grafana

Has implementado una aplicación que expone una métrica, has verificado que la métrica se expone y has comprobado que Prometheus la obtiene. Ahora puede añadir la métrica a nivel de aplicación a un panel de control de Grafana personalizado.

Para crear un panel de control de Grafana, sigue estos pasos:

1. Si es necesario, obtén acceso a Grafana.
2. En el panel de control de la página principal, haz clic en el menú desplegable Página principal, situado en la esquina superior izquierda de la página.
3. En el menú de la derecha, haz clic en Nuevo panel de control.
4. En la sección Nuevo panel, haga clic en Gráfico. Aparecerá un panel de control con un gráfico vacío.
5. Haz clic en Título del panel y, a continuación, en Editar. Se abre el panel Gráfico de la parte inferior, que muestra la pestaña Métricas.
6. En el menú desplegable Fuente de datos, selecciona usuario. Haz clic en Añadir consulta e introduce foo en el campo búsqueda.
7. Haz clic en el botón Volver al panel de control, situado en la esquina superior derecha de la pantalla. Se muestra tu panel de control.
8. Para guardar el panel de control, haz clic en Guardar panel de control en la esquina superior derecha de la pantalla. Elige un nombre para el panel de control y haz clic en Guardar.

Inhabilitar Prometheus y Grafana

A partir de la versión 1.16, Prometheus y Grafana ya no se controlan mediante el campo enablePrometheus del objeto monitoring-sample. Para obtener más información, consulta el artículo Usar Prometheus y Grafana.

Ejemplo: añadir métricas a nivel de aplicación a un panel de control de Grafana

En las siguientes secciones se explica cómo añadir métricas a una aplicación. En esta sección, debes completar las siguientes tareas:

• Despliega una aplicación de ejemplo que exponga una métrica llamada foo.
• Verifica que Prometheus exponga y obtenga la métrica.
• Crea un panel de Grafana personalizado.

Desplegar la aplicación de ejemplo

La aplicación de ejemplo se ejecuta en un solo pod. El contenedor del pod expone una métrica, foo, con un valor constante de 40.

Crea el siguiente archivo de manifiesto de Pod, pro-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: prometheus-example
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/port: '8080'
    prometheus.io/path: '/metrics'
spec:
  containers:
  - image: registry.k8s.io/prometheus-dummy-exporter:v0.1.0
    name: prometheus-example
    command:
    - /bin/sh
    - -c
    - ./prometheus_dummy_exporter --metric-name=foo --metric-value=40 --port=8080

A continuación, aplica el manifiesto de Pod a tu clúster de usuario:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] apply -f pro-pod.yaml

Verifica que la métrica se exponga y se obtenga

1. El contenedor del pod prometheus-example escucha en el puerto TCP 8080. Reenvía un puerto local al puerto 8080 del pod:

   kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] port-forward prometheus-example 50002:8080

2. Para verificar que la aplicación expone la métrica, ejecuta el siguiente comando:

   curl localhost:50002/metrics | grep foo
   

   El comando devuelve el siguiente resultado:

   # HELP foo Custom metric
   # TYPE foo gauge
   foo 40

3. El contenedor del pod prometheus-0 escucha en el puerto TCP 9090. Redirige un puerto local al puerto 9090 del pod:

   kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] port-forward prometheus-0 50003:9090

4. Para verificar que Prometheus está recogiendo la métrica, ve a http://localhost:50003/targets, que debería llevarte al prometheus-0 pod del grupo de destino prometheus-io-pods.

5. Para ver las métricas en Prometheus, ve a http://localhost:50003/graph. En el campo search (buscar), introduce foo y haz clic en Execute (ejecutar). La página debe mostrar la métrica.

Configurar el recurso personalizado de Stackdriver

Cuando creas un clúster, Google Distributed Cloud crea automáticamente un recurso personalizado de Stackdriver. Puedes editar la especificación del recurso personalizado para anular los valores predeterminados de las solicitudes y los límites de CPU y memoria de un componente de Stackdriver, así como anular por separado el tamaño y la clase de almacenamiento predeterminados.

Anular los valores predeterminados de las solicitudes y los límites de CPU y memoria

Para anular estos valores predeterminados, siga estos pasos:

1. Abre tu recurso personalizado de Stackdriver en un editor de línea de comandos:

   kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver

   donde KUBECONFIG es la ruta al archivo kubeconfig del clúster. Puede ser un clúster de administrador o de usuario.

2. En el recurso personalizado de Stackdriver, añade el campo resourceAttrOverride en la sección spec:

   resourceAttrOverride:
         POD_NAME_WITHOUT_RANDOM_SUFFIX/CONTAINER_NAME:
           LIMITS_OR_REQUESTS:
             RESOURCE: RESOURCE_QUANTITY

   Ten en cuenta que el campo resourceAttrOverride anula todos los límites y solicitudes predeterminados del componente que especifiques. resourceAttrOverride admite los siguientes componentes:

   • gke-metrics-agent/gke-metrics-agent
   • stackdriver-log-forwarder/stackdriver-log-forwarder
   • stackdriver-metadata-agent-cluster-level/metadata-agent
   • node-exporter/node-exporter
   • kube-state-metrics/kube-state-metrics

Un archivo de ejemplo tiene el siguiente aspecto:

apiVersion: addons.gke.io/v1alpha1
    kind: Stackdriver
    metadata:
      name: stackdriver
      namespace: kube-system
    spec:
      projectID: my-project
      clusterName: my-cluster
      clusterLocation: us-west-1a
      resourceAttrOverride:
        gke-metrics-agent/gke-metrics-agent:
          requests:
            cpu: 110m
            memory: 240Mi
          limits:
            cpu: 200m
            memory: 4.5Gi

1. Guarda los cambios y cierra el editor de línea de comandos.

2. Comprueba el estado de tus pods:

   kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep gke-metrics-agent

   Por ejemplo, un pod correcto tiene el siguiente aspecto:

   gke-metrics-agent-4th8r                                1/1     Running   0          5d19h

3. Comprueba la especificación del pod del componente para asegurarte de que los recursos estén configurados correctamente.

   kubectl --kubeconfig=KUBECONFIG -n kube-system describe pod POD_NAME

   donde POD_NAME es el nombre del pod que acabas de cambiar. Por ejemplo, stackdriver-prometheus-k8s-0

   La respuesta tiene este aspecto:

     Name:         gke-metrics-agent-4th8r
     Namespace:    kube-system
     ...
     Containers:
       gke-metrics-agent:
         Limits:
           cpu: 200m
           memory: 4.5Gi
         Requests:
           cpu: 110m
           memory: 240Mi
         ...
         

Anular los valores predeterminados del tamaño de almacenamiento

Para anular estos valores predeterminados, siga estos pasos:

1. Abre tu recurso personalizado de Stackdriver en un editor de línea de comandos:

   kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver

2. Añade el campo storageSizeOverride en la sección spec. Puedes usar el componente stackdriver-prometheus-k8s o stackdriver-prometheus-app. La sección tiene este formato:

   storageSizeOverride:
   STATEFULSET_NAME: SIZE
   

   En este ejemplo se usa el statefulset stackdriver-prometheus-k8s y el tamaño 120Gi.

   apiVersion: addons.gke.io/v1alpha1
   kind: Stackdriver
   metadata:
     name: stackdriver
     namespace: kube-system
   spec:
     projectID: my-project
     clusterName: my-cluster
     clusterLocation: us-west-1a
     storageSizeOverride:
       stackdriver-prometheus-k8s: 120Gi
     

3. Guarda los cambios y cierra el editor de línea de comandos.

4. Comprueba el estado de tus pods:

   kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep stackdriver

   Por ejemplo, un pod correcto tiene el siguiente aspecto:

   stackdriver-prometheus-k8s-0                                2/2     Running   0          5d19h

5. Comprueba la especificación del pod del componente para asegurarte de que el tamaño del almacenamiento se ha sustituido correctamente.

   kubectl --kubeconfig=KUBECONFIG -n kube-system describe statefulset STATEFULSET_NAME

   La respuesta tiene este aspecto:

   Volume Claims:
    Name:          my-statefulset-persistent-volume-claim
    StorageClass:  my-storage-class
    Labels:
    Annotations:
    Capacity:      120Gi
    Access Modes:  [ReadWriteOnce]          

Anular los valores predeterminados de la clase de almacenamiento

Requisito previo

Primero debes crear un StorageClass que quieras usar.

Para anular la clase de almacenamiento predeterminada de los volúmenes persistentes reclamados por los componentes de registro y monitorización, haz lo siguiente:

1. Abre tu recurso personalizado de Stackdriver en un editor de línea de comandos:

   kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver

   donde KUBECONFIG es la ruta al archivo kubeconfig del clúster. Puede ser un clúster de administrador o de usuario.

2. Añade el campo storageClassName en la sección spec:

   storageClassName: STORAGECLASS_NAME

   Ten en cuenta que el campo storageClassName anula la clase de almacenamiento predeterminada y se aplica a todos los componentes de registro y monitorización con volúmenes persistentes reclamados. Un archivo de ejemplo tiene el siguiente aspecto:

   apiVersion: addons.gke.io/v1alpha1
   kind: Stackdriver
   metadata:
     name: stackdriver
     namespace: kube-system
   spec:
     projectID: my-project
     clusterName: my-cluster
     clusterLocation: us-west-1a
     proxyConfigSecretName: my-secret-name
     enableVPC: 
     optimizedMetrics: true
     storageClassName: my-storage-class

3. Guarda los cambios.

4. Comprueba el estado de tus pods:

   kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep stackdriver

   Por ejemplo, un pod correcto tiene el siguiente aspecto:

   stackdriver-prometheus-k8s-0                                1/1     Running   0          5d19h

5. Comprueba la especificación de un componente para asegurarte de que la clase de almacenamiento esté configurada correctamente.

   kubectl --kubeconfig=KUBECONFIG -n kube-system describe statefulset STATEFULSET_NAME

   Por ejemplo, si se usa el conjunto con estado stackdriver-prometheus-k8s, la respuesta tiene el siguiente aspecto:

   Volume Claims:
    Name:          stackdriver-prometheus-data
    StorageClass:  my-storage-class
    Labels:
    Annotations:
    Capacity:      120Gi
    Access Modes:  [ReadWriteOnce]          

Inhabilitar métricas optimizadas

De forma predeterminada, los agentes de métricas que se ejecutan en el clúster recogen y registran un conjunto optimizado de métricas de contenedor, kubelet y kube-state-metrics en Stackdriver. Si necesitas más métricas, te recomendamos que busques una alternativa en la lista de métricas de Google Distributed Cloud.

Estos son algunos ejemplos de sustituciones que puedes usar:

Métrica inhabilitada	Sustituciones
kube_pod_start_time	container/uptime
kube_pod_container_resource_requests	container/cpu/request_cores container/memory/request_bytes
kube_pod_container_resource_limits	container/cpu/limit_cores container/memory/limit_bytes

Para inhabilitar el ajuste predeterminado de las métricas optimizadas de kube-state-metrics (no recomendado), haz lo siguiente:

1. Abre tu recurso personalizado de Stackdriver en un editor de línea de comandos:

   kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver

   donde KUBECONFIG es la ruta al archivo kubeconfig del clúster. Puede ser un clúster de administrador o de usuario.

2. Asigna el valor false al campo optimizedMetrics:

   apiVersion: addons.gke.io/v1alpha1
   kind: Stackdriver
   metadata:
     name: stackdriver
     namespace: kube-system
   spec:
     projectID: my-project
     clusterName: my-cluster
     clusterLocation: us-west-1a
     proxyConfigSecretName: my-secret-name
     enableVPC: 
     optimizedMetrics: false
     storageClassName: my-storage-class

3. Guarda los cambios y cierra el editor de línea de comandos.

Problema conocido: condición de error de Cloud Monitoring

(ID del problema 159761921)

En determinadas condiciones, el pod predeterminado de Cloud Monitoring, que se implementa de forma predeterminada en cada clúster nuevo, puede dejar de responder. Por ejemplo, cuando se actualizan los clústeres, los datos de almacenamiento pueden dañarse si se reinician los pods de statefulset/prometheus-stackdriver-k8s.

En concreto, el pod de monitorización stackdriver-prometheus-k8s-0 puede entrar en un bucle cuando los datos dañados impiden que prometheus-stackdriver-sidecar escriba en el almacenamiento del clúster PersistentVolume.

Para diagnosticar y solucionar el error manualmente, sigue los pasos que se indican a continuación.

Diagnosticar el fallo de Cloud Monitoring

Si el pod de monitorización ha fallado, los registros mostrarán lo siguiente:

{"log":"level=warn ts=2020-04-08T22:15:44.557Z caller=queue_manager.go:534 component=queue_manager msg=\"Unrecoverable error sending samples to remote storage\" err=\"rpc error: code = InvalidArgument desc = One or more TimeSeries could not be written: One or more points were written more frequently than the maximum sampling period configured for the metric.: timeSeries[0-114]; Unknown metric: kubernetes.io/anthos/scheduler_pending_pods: timeSeries[196-198]\"\n","stream":"stderr","time":"2020-04-08T22:15:44.558246866Z"}

{"log":"level=info ts=2020-04-08T22:15:44.656Z caller=queue_manager.go:229 component=queue_manager msg=\"Remote storage stopped.\"\n","stream":"stderr","time":"2020-04-08T22:15:44.656798666Z"}

{"log":"level=error ts=2020-04-08T22:15:44.663Z caller=main.go:603 err=\"corruption after 29032448 bytes: unexpected non-zero byte in padded page\"\n","stream":"stderr","time":"2020-04-08T22:15:44.663707748Z"}

{"log":"level=info ts=2020-04-08T22:15:44.663Z caller=main.go:605 msg=\"See you next time!\"\n","stream":"stderr","time":"2020-04-08T22:15:44.664000941Z"}

Recuperación tras el error de Cloud Monitoring

Para recuperar Cloud Monitoring manualmente, sigue estos pasos:

1. Detener la monitorización del clúster. Reduce la escala del operador stackdriver para evitar la reconciliación de la monitorización:

   kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system scale deployment stackdriver-operator --replicas 0

2. Elimina las cargas de trabajo de la canalización de monitorización:

   kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system delete statefulset stackdriver-prometheus-k8s

3. Elimina los PersistentVolumeClaims (PVCs) de la canalización de monitorización:

   kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system delete pvc -l app=stackdriver-prometheus-k8s

4. Reinicia la monitorización del clúster. Aumenta la escala del operador de Stackdriver para reinstalar una nueva canalización de monitorización y reanudar la conciliación:

   kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system scale deployment stackdriver-operator --replicas=1