Supervisa clústeres de GKE para optimizar costos mediante Cloud Monitoring

En este instructivo, se explica cómo supervisar tus clústeres de Google Kubernetes Engine (GKE) para optimizar el uso de recursos. Este tipo de optimización suele ser una tarea compleja porque se quiere reducir los costos mediante la reducción del consumo de recursos sin comprometer la estabilidad y el rendimiento de las apps. En este instructivo, se explica un proceso para configurar paneles y políticas de alertas para las causas más comunes del aprovisionamiento en exceso. En el instructivo también se proporcionan recomendaciones de recursos a fin de que puedas mantener las apps ejecutándose de manera confiable y optimizadas para el costo.

Este instructivo es para desarrolladores y operadores que desean optimizar sus apps y clústeres de GKE a fin de lograr bajo costo, alto rendimiento y alta estabilidad de la app. En el instructivo, se supone que estás familiarizado con Docker, Kubernetes, CronJobs de Kubernetes, GKE, Cloud Monitoring. y Linux.

Descripción general

La optimización de costos suele interpretarse de forma errónea como un único proceso que se enfoca en reducir costos. Sin embargo, como la define Gartner, la optimización de costos es una disciplina continua que también debe maximizar el valor comercial. Cuando creas una instancia de esta disciplina para el mundo de Kubernetes, también son importantes otras perspectivas.

Equilibrar 4 objetivos diferentes: reducir costos, lograr objetivos de rendimiento, lograr estabilidad y maximizar resultados comerciales.

Como se muestra en este diagrama, la optimización de costos en Kubernetes requiere que equilibres 4 objetivos diferentes: reducir los costos, lograr los objetivos de rendimiento, lograr la estabilidad y maximizar los resultados comerciales. En otras palabras, la reducción de costos no debe generarse a expensas de la experiencia del usuario o del rendimiento de la empresa, a menos que ese impacto se comprenda bien y sea deliberado.

Google Cloud proporciona las herramientas necesarias para equilibrar estos objetivos. Sin embargo, no todos los equipos que adoptan soluciones basadas en la nube, como Kubernetes, para sus cargas de trabajo tienen la experiencia necesaria a fin de lograr sus objetivos de rendimiento y estabilidad. Por lo general, su solución es aprovisionar en exceso los entornos para mitigar el impacto en el negocio.

El aprovisionamiento excesivo puede proporcionar una ayuda a corto plazo, pero a un costo mayor. Úsalo con cuidado y solo como parte de un proceso continuo de optimización de costos. En la siguiente imagen, se muestran los 4 problemas principales entre los equipos que inician el recorrido de optimización de costos.

Los 4 problemas principales que se encuentran en los equipos: cultural, compresión, redimensionamiento de aplicaciones y no reducir la escala verticalmente durante las horas de menor demanda.

  • El primer problema es cultural. Muchos equipos que adoptan la nube pública no están acostumbrados al estilo de facturación prepago y con frecuencia no comprenden por completo el entorno en el que se ejecutan las apps, en este caso, Kubernetes. El movimiento FinOps, que recibe mucha atención recientemente, consiste en desarrollar esa cultura. Una práctica recomendada de FinOps es proporcionar a los equipos información en tiempo real sobre sus gastos y su impacto en el negocio. Aspectos pequeños como estos tienen un impacto considerable en la cultura de las empresas, lo que da como resultado una ecuación de optimización de costos más equilibrada.

  • El segundo problema es la compresión. La compresión es la capacidad de empaquetar apps en nodos de GKE. Cuanto más eficientemente empaquetes las apps en nodos, más ahorrarás.

  • El tercer problema es el redimensionamiento de las apps. El redimensionamiento es la capacidad de configurar la solicitud de recursos adecuada y el objetivo de ajuste de escala automático de cargas de trabajo para los objetos que se implementan en el clúster. Cuanto más preciso seas para configurar los recursos exactos en los pods, mayor será la confiabilidad con la que se ejecutará tu app y, en la mayoría de los casos, más espacio abrirás en el clúster.

  • El último problema es no reducir verticalmente la escala de tu clúster durante las horas de menor demanda. Lo ideal es que, para ahorrar dinero durante los períodos de baja demanda (por ejemplo, por la noche), el clúster debe poder reducir la escala verticalmente según la demanda real. Sin embargo, en algunos casos, la reducción vertical de la escala no se produce como se espera debido a cargas de trabajo o configuraciones de clústeres que bloquean el escalador automático del clúster (CA).

Para optimizar los costos de tu entorno de forma efectiva, debes trabajar de forma continua en estos problemas. Para enfocarse en los elementos prácticos, en el resto de este instructivo se omite el problema cultural y se explica cómo usar Cloud Monitoring para supervisar la compresión y el redimensionamiento de la app en un clúster de GKE. Para obtener más información sobre la optimización de costos de tu clúster durante los períodos de baja demanda, consulta Reduce los costos mediante la reducción vertical de la escala de los clústeres de GKE durante las horas de menor demanda.

Objetivos

  • Crear un clúster de GKE.
  • Implementar una app de ejemplo
  • Configurar los componentes para exportar las métricas necesarias a Cloud Monitoring
  • Generar paneles de forma dinámica para supervisar el uso y las recomendaciones de recursos.
  • Generar de forma dinámica políticas de alertas de aprovisionamiento insuficiente y excesivo

Costos

En este instructivo, se usan los siguientes componentes facturables de Google Cloud:

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Antes de comenzar

  1. En Google Cloud Console, ve a la página del selector de proyectos.

    Ir al selector de proyectos

  2. Selecciona o crea un proyecto de Google Cloud.

  3. Comprueba que la facturación esté habilitada en tu proyecto.

    Descubre cómo puedes habilitar la facturación

Cuando finalices este instructivo, podrás borrar los recursos creados para evitar que se te siga facturando. Para obtener más información, consulta Cómo realizar una limpieza.

Prepara tu entorno

  1. En la consola, abre Cloud Shell. A lo largo de este instructivo, ejecutarás comandos en Cloud Shell.

    En la parte inferior de la consola, se abre una sesión de Cloud Shell que muestra una ventana emergente con una línea de comandos. Cloud Shell es un entorno de shell con Google Cloud CLI ya instalada, que incluye Google Cloud CLI, y con valores ya establecidos para el proyecto actual. La sesión puede tardar unos segundos en inicializarse.

  2. En Cloud Shell, configura el ID del proyecto de Cloud y la dirección de correo electrónico, y habilita las API de Compute Engine, GKE y Cloud Monitoring:

    PROJECT_ID=YOUR_PROJECT_ID
    ALERT_EMAIL=YOUR_EMAIL_ADDRESS
    CLUSTER=gke-cost-optimization-monitoring
    gcloud config set project $PROJECT_ID
    
    gcloud services enable \
        compute.googleapis.com \
        container.googleapis.com \
        monitoring.googleapis.com
    
    gcloud config set compute/region us-central1
    gcloud config set compute/zone us-central1-f
    

    Reemplaza lo siguiente:

    • YOUR_PROJECT_ID: El ID del proyecto de Cloud para el proyecto que usas en este instructivo.
    • YOUR_EMAIL_ADDRESS: Una dirección de correo electrónico para recibir notificaciones cuando se encuentran oportunidades de aprovisionamiento excesivo e insuficiente en tu clúster

    Puedes elegir una región y una zona diferentes.

  3. Clona el repositorio de GitHub gke-cost-optimization-monitoring:

    git clone https://github.com/GoogleCloudPlatform/gke-cost-optimization-monitoring
    cd gke-cost-optimization-monitoring
    

    El código de este repositorio se organiza en las siguientes carpetas:

    • Raíz: contiene los archivos main.go y Dockerfile que el CronJob usa para exportar métricas personalizadas a Cloud Monitoring.
    • api/: Contiene la API de golang para manipular objetos de Kubernetes y Monitoring.
    • k8s/templates/: Contiene la plantilla que se usa para crear los objetos de CronJob, VPA y escalador automático horizontal de Pods (HPA) en el clúster.
    • monitoring/dashboards/templates/: Contiene las plantillas que se usan para crear de forma dinámica los paneles de compresión y redimensionamiento la app.
    • monitoring/policies/templates/: Contiene las plantillas usadas para crear de manera dinámica políticas de alertas de compresión y redimensionamiento de la app.

Crea el clúster de GKE

  1. En Cloud Shell, crea un clúster de GKE:

    gcloud container clusters create $CLUSTER \
        --enable-ip-alias \
        --release-channel=stable \
        --machine-type=e2-standard-2 \
        --enable-autoscaling --min-nodes=1 --max-nodes=5 \
        --enable-vertical-pod-autoscaling
    

    Esta configuración no es de producción, pero es adecuada para este instructivo. En esta configuración, habilitas VPA a fin de extraer la base para el redimensionamiento de las apps.

Implementa la app de ejemplo

  1. Implementa la app Online Boutique:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/main/release/kubernetes-manifests.yaml
    

    La app Online Boutique es una tienda web de venta minorista de demostración compuesta por muchos microservicios escritos en diferentes lenguajes de computación.

  2. Si deseas simular un entorno más realista, crea un HPA para implementaciones de Online Boutique:

    kubectl get deployments --field-selector='metadata.name!=adservice,metadata.name!=cartservice' -o go-template-file=k8s/templates/cpu-hpa.gtpl | kubectl apply -f -
    
    kubectl get deployments --field-selector='metadata.name==cartservice' -o go-template-file=k8s/templates/memory-hpa.gtpl | kubectl apply -f -
    

    Ten en cuenta que creas objetos HPA de objetivo de CPU para la mayoría de las implementaciones de Online Boutique, HPA de objetivo de memoria para la implementación de cartservice y sin configuración de HPA para adservice. Esta configuración ayuda a demostrar diferentes visualizaciones del panel, como se muestra en las siguientes secciones.

Configura los componentes para exportar métricas a Cloud Monitoring

  1. Compila y envía el código del exportador de métricas personalizadas:

    docker build . -t gcr.io/$PROJECT_ID/metrics-exporter
    docker push gcr.io/$PROJECT_ID/metrics-exporter
    

    Este código es responsable de consultar los objetos VPA y HPA en el clúster y enviar métricas personalizadas basadas en esos datos a Cloud Monitoring. Esta implementación exporta recomendaciones de objetivo de VPA y uso objetivo de recursos de HPA: CPU y memoria definidas en formato de porcentaje.

  2. Implementa el CronJob para enviar métricas del escalador automático de carga de trabajo a Cloud Monitoring cada minuto:

    sed "s/PROJECT_ID/$PROJECT_ID/g" k8s/templates/metrics-exporter.yaml > k8s/metrics-exporter.yaml
    kubectl create ns custom-metrics
    kubectl apply -f k8s/metrics-exporter.yaml
    

    Si ejecutas este instructivo en tu propio clúster (en lugar del que creaste antes) y tiene habilitado Workload Identity, asegúrate de seguir los pasos que se indican enUsa Workload Identity para permitir que las métricas se exporten a Cloud Monitoring.

  3. Crea un VPA para todos los objetos Deployments, StatefulSets y DaemonSets del clúster:

    rm k8s/vpas.yaml 2> /dev/null
    ALL_NAMESPACES=$(kubectl get namespaces -o jsonpath={.items[*].metadata.name})
    for NAMESPACE in $ALL_NAMESPACES
    do
        kubectl get deployments,statefulset,daemonset -n $NAMESPACE -o go-template-file=k8s/templates/vpa.gtpl >> k8s/vpas.yaml
    done
    kubectl apply -f k8s/vpas.yaml
    

    El fragmento anterior crea un VPA en modo Off para todos los objetos de todos los espacios de nombres, incluidos los del sistema. Este enfoque ofrece una vista más precisa de las recomendaciones a nivel de clúster y de grupo de nodos. Sin embargo, para evitar sobrecargar el servicio del servidor de métricas , no recomendamos que ejecutes la secuencia de comandos anterior tal como está en clústeres grandes, con unos cientos de aplicaciones implementadas. , Para una situación de clúster grande, te recomendamos que ejecutes la secuencia de comandos anterior solo en los espacios de nombres en los que te interese optimizar costos. En este caso, las recomendaciones a nivel de clúster y de grupo de nodos no son precisas, así que ignóralas o quítalas.

Configura paneles para supervisar el uso de recursos y las recomendaciones

  1. En la consola, ve a la página Recomendaciones.

    Ir a Monitoring

  2. Crear un proyecto

    1. En la página Agrega tu proyecto a un lugar de trabajo, selecciona tu proyecto de Cloud.
    2. Haga clic en Add.

    El lugar de trabajo puede tardar varios minutos en crearse.

  3. En Cloud Shell, genera de forma dinámica tus paneles para la optimización de costos:

    YOUR_NAMESPACES=$( echo $ALL_NAMESPACES| sed 's/[a-zA-Z0-9_.-]*-system//g; s/gke-[a-zA-Z0-9_.-]*//g; s/kube-public//g; s/kube-node-lease//g; s/custom-metrics//g')
    for NAMESPACE in $YOUR_NAMESPACES
    do
        GTPL_FILE='./monitoring/dashboards/templates/app-rightsizing.gtpl'
        OUTPUT_FILE="./monitoring/dashboards/app-rightsizing-$CLUSTER-$NAMESPACE.yaml"
    
        kubectl get deployments,statefulset,daemonset -n $NAMESPACE -o go-template-file=$GTPL_FILE > $OUTPUT_FILE
    
        sed -i.bkp "s/CLUSTER_TO_REPLACE/$CLUSTER/g" $OUTPUT_FILE
        sed -i.bkp "s/NAMESPACE_TO_REPLACE/$NAMESPACE/g" $OUTPUT_FILE
    
        replace=""
        i=0
        while : ; do
            if grep -q "Y_POS_TO_REPLACE_$i" $OUTPUT_FILE
            then
                ((yPos=12 + (4 * $i)))
                replace="s/Y_POS_TO_REPLACE_$i/$yPos/g; ${replace}"
                ((i=i+1))
            else
                break
            fi
        done
        eval "sed -i.bkp '$replace' $OUTPUT_FILE"
        rm "$OUTPUT_FILE.bkp"
    done
    
    sed "s/CLUSTER_TO_REPLACE/$CLUSTER/g" ./monitoring/dashboards/templates/binpacking.yaml > ./monitoring/dashboards/binpacking.yaml
    

    Además de crear un panel de compresión, esta secuencia de comandos también genera un panel de redimensionamiento de la app para cada espacio de nombres en tu clúster, excepto los espacios de nombres del sistema. En este instructivo, la secuencia de comandos genera solo un panel para el espacio de nombres default, ya que Online Boutique se implementa por completo en ese espacio de nombres. Sin embargo, si ejecutas la misma secuencia de comandos en tu clúster de GKE, se genera un panel para cada uno de los espacios de nombres.

  4. Importa los paneles generados a Cloud Monitoring:

    for filename in monitoring/dashboards/*.yaml; do
        echo "Creating dashboard policy based on file: $filename"
        gcloud monitoring dashboards create \
            --config-from-file=$filename
    done
    

    El resultado es similar al siguiente:

    Creating dashboard policy based on file: monitoring/dashboards/app-rightsizing-gke-cost-optimization-monitoring-default.yaml
    Created [9c1a6cb6-3424-44a8-b824-f2ec959f6588].
    Creating dashboard policy based on file: monitoring/dashboards/binpacking.yaml
    Created [97f6349d-4880-478d-9da8-ca3c8a433093].
    

Visualiza el panel de redimensionamiento de la app

  1. Ve a la página Paneles de Monitoring.

    Ir a la página Paneles

  2. Haz clic en el panel GKE: Redimensionamiento de la app (gke-cost-optimization-monitoring:default).

En el resto de esta sección, se explica cómo ver e interpretar los gráficos que se muestran en el panel.

El entorno de demostración instalado tiene una carga simulada constante. En otras palabras, no verás cambios grandes en los gráficos a lo largo del tiempo. Sin embargo, si ejecutas el mismo instructivo en tus propios clústeres, debes esperar algunas horas (idealmente, 24 horas o más) para ver la dinámica de los escalamientos verticales y las reducciones verticales de la escala, y cómo ocurren diferentes distribuciones de carga durante el día y la semana.

La primera fila del gráfico muestra el aprovisionamiento en exceso de espacio de nombres. la segunda fila muestra las 5 apps con mayor aprovisionamiento en exceso y la tercera fila muestra las 5 apps con aprovisionamiento insuficiente.

Como se muestra en el gráfico anterior, en las tres primeras filas del panel, se resume la siguiente información de espacio de nombres agregada:

  • Primera fila: CPU y memoria. Aprovisionamiento en exceso de espacio de nombres Proporciona una descripción general breve de qué tanto se optimizaron los costos de tus apps en este espacio de nombres determinado.
  • Segunda fila: CPU y memoria. Las 5 apps con mayor aprovisionamiento en exceso. Te muestra dónde encontrar las apps en las que debes trabajar primero cuando buscas maneras de mejorar el espacio de nombres.
  • Tercera fila: CPU y memoria. Las 5 apps on aprovisionamiento insuficiente. De manera similar a la segunda fila, esta fila muestra las apps que requieren atención especial. Sin embargo, en este caso, no quieres enfocarte en ahorrar dinero, sino en hacer que las apps se ejecuten sin problemas en tu clúster. Si ve el mensaje “No hay datos disponibles”, significa que no se encontraron oportunidades.

En el siguiente gráfico, se muestran los detalles que presenta el panel por app con respecto a la CPU, la memoria y las réplicas. Cada fila representa una app en el espacio de nombres determinado. Esta información es útil para redimensionar tus apps, ya que compara lo que los desarrolladores indican que las apps necesitan (líneas requested_<cores|memory>) en comparación con lo que realmente usan (líneas used_<cores|memory>).

El panel de redimensionamiento de la app muestra detalles de CPU, memoria y réplicas.

En las siguientes secciones, se analizan las tres filas de los gráficos anteriores.

Primera fila: CPU (p/Pod)

En función de cómo se configure la carga de trabajo, estos gráficos muestran diferentes sugerencias que te ayudan a determinar el tamaño adecuado para la app:

  • Recomendación de CPU del VPA (vpa_recommended_cores): Esta sugerencia se muestra cuando tu app no tiene un HPA configurado (gráfico CPU: adservice (p/Pod) en el panel) o si el HPA está configurado con cualquier métrica, excepto CPU (gráfico CPU: cartservice (p/Pod) en el panel). Cuando veas estas sugerencias, te recomendamos que las apliques de manera estática o, si te sientes cómodo consultando el historial del gráfico, habilites el VPA con el modo Initial o Auto.

  • Uso objetivo de CPU de HPA (hpa_target_utilization): Esta sugerencia se muestra cuando tu app está configurada con HPA según el uso de CPU (todos los demás gráficos de CPU). En este caso, te recomendamos que hagas lo siguiente:

    • Casos de aprovisionamiento excesivo: Si el uso real (used_cores) se encuentra constantemente muy por debajo del objetivo de HPA (hpa_target_utilization), significa que la implementación se ejecuta con el valor especificado en minReplicas de HPA. La acción sugerida en esta situación es disminuir el valor minReplicas.
    • Casos de aprovisionamiento insuficiente: Si el uso real (used_cores) se encuentra constantemente por encima del objetivo de HPA (hpa_target_utilization), la implementación se ejecuta con el valor especificado en maxReplicas de HPA. La acción sugerida es aumentar el valor maxReplicas o los recursos solicitados para aumentar el tamaño de los Pods.
    • Comprende los escalamientos verticales y las reducciones verticales de la escala: Mira los gráficos CPU y Replicas para comprender cuándo el HPA en la CPU activa los escalamientos verticales y las reducciones verticales de la escala de Pods.
    • Ajuste de uso objetivo de HPA: revisa nuestras prácticas recomendadas antes de aplicar algo al entorno.
    • También es importante que evites combinar VPA y HPA con CPU o memoria en la misma carga de trabajo. Para eso, usa MPA.

Segunda fila: Memoria (p/Pod)

Al igual que la fila de CPU, estos gráficos muestran diferentes sugerencias a fin de ayudarte a determinar el tamaño adecuado para tu app, en función de cómo se configure la carga de trabajo:

  • Recomendación de memoria del VPA (vpa_recommended_bytes): Esta sugerencia se muestra cuando tu aplicación no tiene un HPA configurado (gráfico Mem: adservice (p/Pod) en el panel) o si el HPA está configurado con cualquier métrica, excepto la memoria (Men: emailservice (p/Pod), por ejemplo) Considera aplicar esas recomendaciones para evitar el desperdicio de recursos y los eventos “Out Of Memory Kill” (OOMKill) o, si te sientes cómodo consultando el historial de gráficos. habilita el VPA con el modo Initial o Auto.

  • Uso objetivo de memoria de HPA (hpa_target_utilization): Esta sugerencia se muestra cuando tu app se configura con HPA según el uso de memoria (gráfico Mem: cartservice (p/Pod) en el panel). En este caso, te recomendamos que hagas lo siguiente:

    • Casos de aprovisionamiento excesivo: Si el uso real (used_bytes) se encuentra constantemente muy por debajo del objetivo de HPA (hpa_target_utilization), la implementación se ejecuta con el valor especificado en minReplicas de HPA. La acción sugerida en esta situación es disminuir el valor minReplicas.
    • Casos de aprovisionamiento insuficiente: Si el uso real (used_bytes) se encuentra constantemente por encima del objetivo de HPA (hpa_target_utilization), la implementación se ejecuta con el valor especificado en maxReplicas de HPA. La acción sugerida es aumentar el valor maxReplicas o los recursos solicitados para aumentar el tamaño de los Pods.
    • Comprende los escalamientos verticales y las reducciones verticales de la escala: Mira los gráficos Mem y Replicas para comprender cuándo el HPA en la memoria activa los escalamientos verticales y las reducciones verticales de la escala de Pods.
    • Ajuste de uso objetivo de HPA: revisa nuestras prácticas recomendadas antes de aplicar algo al entorno.
    • También es importante que evites combinar VPA y HPA con CPU o memoria en la misma carga de trabajo. Para eso, usa MPA.

Tercera fila: Réplicas

En los gráficos de esta fila, se muestra la cantidad de Pods que tiene una aplicación determinada. Esta información es útil a fin de comprender la volatilidad de los recursos usados en comparación con los recursos recomendados para cargas de trabajo implementadas junto con HPA.

Visualiza el panel de compresión

  1. Vuelve a la página Paneles de control de Cloud Monitoring.

    Ir a Paneles

  2. Haz clic en el panel GKE: Compresión del clúster (gke-cost-optimization-monitoring).

Como se muestra en los siguientes gráficos, el panel de compresión presenta información agregada por clúster (primera fila) y grupos de nodos (segunda fila). Esta información es útil para comprimir tu clúster, ya que compara la capacidad asignable en el clúster y los grupos de nodos (líneas allocable_<cores|memory>) con lo que tus desarrolladores dicen que sus apps necesitan (líneas requested_<cores|memory>).

El panel de compresión presenta información agregada por clúster (primera fila) y grupos de nodos (segunda fila).

Un análisis útil que puedes ejecutar sobre estos gráficos es verificar si te estás quedando sin un tipo de recurso (por ejemplo, memoria), y desperdiciando otro tipo de recurso (por ejemplo, CPU). En esta situación, el escalador automático del clúster activa escalamientos verticales porque no hay memoria disponible en el clúster para los Pods programados. Otro caso común se relaciona con la densidad del Pod o la cantidad de Pods por nodo. En el gráfico Grupo de nodos: cantidad de Pods, puedes ver la densidad del Pod en cada grupo de nodos y compararla con la información configurada (no proporcionada en el gráfico). Si alcanzaste la densidad configurada de tu grupo de nodos, la CA iniciará nodos nuevos para ajustarse a tus Pods programados, incluso si tienes mucha CPU y memoria disponible.

Otro análisis importante, que no está disponible en los paneles anteriores, se relaciona con la configuración mínima y máxima del escalador automático. Por ejemplo, es posible que el clúster no reduzca la escala verticalmente por la noche porque tus HPA o tu CA necesitan más que el mínimo. Además, es posible que tu CA no inicie Pods en el grupo de nodos esperado porque puede haber alcanzado la cantidad máxima de nodos configurados para ese grupo.

Limitaciones del panel

  • Aunque el panel de redimensionamiento de la app presenta información agregada para todas las apps de un espacio de nombres determinado, solo muestra la CPU, la memoria y las réplicas de las primeras 8 apps, ordenadas por nombre, debido a una limitación de la cantidad de widgets permitidos en un panel único. Si descubres que las apps que se muestran no son las más importantes, edita el panel para que se adapte a tus necesidades.
  • El panel de compresión proporciona datos agregados para clústeres y grupos de nodos. Cuando se trata de muchos clústeres o grupos de nodos, la visualización está limitada porque no se pueden ejecutar filtros en el lenguaje de consulta de Monitoring (MQL) que se usa para compilar los gráficos.
  • El panel de compresión puede tardar mucho tiempo en cargarse cuando se supervisan clústeres grandes con cientos de apps. En este caso, para reducir la cantidad de datos cargados, recomendamos que evites filtrar el panel por un período extenso.

Configura políticas de alertas de aprovisionamiento insuficiente y excesivo

Cuando el equipo de finanzas de tu empresa te pregunte por qué tu factura de nube se duplicó recientemente, es probable que no quieras decirles que tienes un problema de aprovisionamiento excesivo. Para evitar esta situación, te recomendamos que crees políticas de alertas que se activen cuando el entorno comience a divergir de lo que planeaste.

  1. En Cloud Shell, crea un canal de notificaciones:

    gcloud beta monitoring channels create \
        --display-name="Cost Optimization team (Primary)" \
        --description="Primary contact method for the Cost Optimization effort"  \
        --type=email \
        --channel-labels=email_address=${ALERT_EMAIL}
    

    El resultado es similar al siguiente:

    Created notification channel [projects/your_project/notificationChannels/13166436832066782447].
    

    El comando anterior crea un canal de notificaciones de tipo email para simplificar los pasos del instructivo. Para entornos de producción, te recomendamos que uses una estrategia menos asíncrona. Para ello, establece el canal de notificaciones en sms o pagerduty.

  2. Configura una variable que tenga el valor que se mostró en el marcador de posición NOTIFICATION_CHANNEL_ID:

    NOTIFICATION_CHANNEL_ID=$(gcloud beta monitoring channels list --filter='displayName="Cost Optimization team (Primary)"' | grep 'name:' | sed 's/name: //g')
    
  3. Crea e implementa las políticas de alertas de forma dinámica:

    for NAMESPACE in $YOUR_NAMESPACES
    do
        for templatefile in monitoring/policies/templates/rightsizing/*.yaml; do
            outputfile=monitoring/policies/$(basename $templatefile)
            sed "s/CLUSTER_TO_REPLACE/$CLUSTER/g;s/NAMESPACE_TO_REPLACE/$NAMESPACE/g" $templatefile > $outputfile
            echo "Creating alert policy based on file: $outputfile"
            gcloud alpha monitoring policies create \
                --policy-from-file=$outputfile \
                --notification-channels=$NOTIFICATION_CHANNEL_ID
        done
    done
    
    for templatefile in monitoring/policies/templates/binpacking/*.yaml; do
        outputfile=monitoring/policies/$(basename $templatefile)
        sed "s/CLUSTER_TO_REPLACE/$CLUSTER/g;s/NAMESPACE_TO_REPLACE/$NAMESPACE/g" $templatefile > $outputfile
        echo "Creating alert policy based on file: $outputfile"
        gcloud alpha monitoring policies create \
            --policy-from-file=$outputfile \
            --notification-channels=$NOTIFICATION_CHANNEL_ID
    done
    

    El resultado es similar al siguiente:

    Creating alert policy based on file: monitoring/policies/app-rightsizing-cpu-overprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/18091138402474167583].
    Creating alert policy based on file: monitoring/policies/app-rightsizing-cpu-underprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/8586234469403227589].
    Creating alert policy based on file: monitoring/policies/app-rightsizing-memory-overprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/9685822323903723723].
    Creating alert policy based on file: monitoring/policies/app-rightsizing-memory-underprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/15705075159352926212].
    Creating alert policy based on file: monitoring/policies/nodepools-binpacking-cpu-overprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/14555072091442814207].
    Creating alert policy based on file: monitoring/policies/nodepools-binpacking-memory-overprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/1442392910032052087].
    

    De forma predeterminada, las políticas de alertas creadas contienen la especificación para activar alertas si las apps están sobreaprovisionadas en más de un 80% y los grupos de nodos en más de un 40%, durante un período mayor que un día. Asegúrate de ajustar estas políticas para cumplir con los requisitos de uso de recursos.

  4. Ve a la página Alertas de Monitoring para ver la política de alertas.

    Ir a la página de alertas

  5. Haz clic en cualquiera de las políticas creadas y verifica o edita los detalles de la configuración de alertas.

Limpia

Para evitar que se generen costos en tu cuenta de Google Cloud por los recursos que se usaron en este instructivo, sigue estos pasos:

Borra el proyecto

La manera más fácil de eliminar la facturación es borrar el proyecto que creaste para el instructivo.

  1. En la consola, ve a la página Administrar recursos.

    Ir a Administrar recursos

  2. En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
  3. En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

¿Qué sigue?