Observa las cargas de trabajo jerárquicas

El controlador de jerarquía te brinda una mejor observabilidad en tus cargas de trabajo mediante el uso de los espacios de nombres jerárquicos y abstractos en tu clúster. Para ello, propaga las etiquetas de árbol de tu clúster a tus Pods y los pone a disposición de cualquier sistema que pueda transferir etiquetas de Kubernetes, que incluyen los siguientes:

Por ejemplo, considera una carga de trabajo que se ejecuta en un espacio de nombres del repositorio de ejemplo.

El controlador de jerarquía te permite seleccionar registros, Pods o métricas de uso que se hayan generado por cualquier carga de trabajo que sea descendiente de eng, rnd o cualquier otro espacio de nombres abstracto. Esto incluye no solo las cargas de trabajo de los espacios de nombres ubicados en el repositorio de Git, como gamestore, sino también cualquier subespacio de nombres del controlador de jerarquía que puedas crear como descendiente de esos espacios de nombres.

Habilita la observabilidad jerárquica

Hierarchy Controller proporciona observabilidad jerárquica. Para habilitar la observabilidad jerárquica, haz lo siguiente:

  1. Instala el controlador de jerarquías.

  2. En el archivo de configuración para el operador del Administrador de configuración, en el objeto spec.hierarchyController, establece el valor de enablePodTreeLabels en true:

    # config-management.yaml
    
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
      name: config-management
    spec:
      hierarchyController:
        enabled: true
        # Set to true to enable hierarchical observability:
        enablePodTreeLabels: true
      # ...other fields...
    
  3. Aplica la configuración:

    kubectl apply -f config-management.yaml
    

    Después de un minuto, Hierarchy Controller y la observabilidad jerárquica se pueden empezar a usar en tu clúster.

Cuando la observabilidad jerárquica está habilitada, Hierarchy Controller instala un webhook de admisión mutante para agregar las etiquetas de árbol a los pods. Para verificar que este webhook funcione correctamente, haz lo siguiente:

  1. Inicia una carga de trabajo en cualquier espacio de nombres, como el siguiente:

    kubectl run websvr --image=nginx --namespace default --generator=run-pod/v1
    
  2. Inspecciona el pod y verifica que contenga la etiqueta default.tree.hnc.x-k8s.io/depth:

    kubectl describe pod --namespace default websvr
    

    Resultado:

    Name:         websvr
    Namespace:    default
    # ...other fields...
    Labels:       default.tree.hnc.x-k8s.io/depth=0 # This is the Pod tree label
                  # ...other labels...
    # ...other fields...
    
  3. Limpia la carga de trabajo:

    kubectl delete pod --namespace default websvr
    

Los Pods existentes no reciben las etiquetas del árbol de Pods. Estas etiquetas solo se agregan a los Pods nuevos. Para obtener más información, consulta Limitaciones, más adelante en este documento.

Usa la observabilidad jerárquica de la carga de trabajo

Después de que se habilitan las etiquetas de árbol de los Pods, se pueden usar para mejorar la observabilidad de las cargas de trabajo jerárquicas dentro de los clústeres y en otros productos de Google Cloud.

Consulta Pods por jerarquía

Cualquier operación de Kubernetes que incluya un selector de etiquetas se puede usar para consultar las etiquetas de árbol del pod. Por ejemplo, para ver todos los pods en todos los espacios de nombres que se ejecutan en un descendente del espacio de nombres default, usa la siguiente consulta:

kubectl get pods --all-namespaces -l default.tree.hnc.x-k8s.io/depth

Salida según la carga de trabajo de muestra que creamos para verificar la instalación:

NAMESPACE   NAME     READY   STATUS    RESTARTS   AGE
default     websvr   1/1     Running   0          70s

Consulta Cloud Logging por jerarquía

Cloud Logging admite un formato un poco diferente para las etiquetas que Kubernetes. Por ejemplo, para buscar cualquier carga de trabajo que se ejecute en un descendiente del espacio de nombres default, en lugar de buscar la etiqueta de Kubernetes default.tree.hnc.x-k8s.io/depth, Cloud Logging espera una consulta similar a la siguiente en Google Cloud Console:

resource.type="k8s_container" labels.k8s-pod/default_tree_hnc_x-k8s_io/depth!=""

Como alternativa, puedes usar un filtro similar en la herramienta de línea de comandos de gcloud:

gcloud logging read "resource.type=k8s_container AND labels.k8s-pod/default_tree_hnc_x-k8s_io/depth!=''"

Consulta la medición de uso de GKE por jerarquía

Puedes usar las etiquetas de árbol de Pods para atribuir solicitudes y usos de la medición de uso de GKE a los árboles de espacios de nombres. Para habilitar la medición de uso jerárquica, sigue estos pasos:

  1. Habilita la medición de uso regular de GKE en tu clúster.

  2. Confirma que los datos se estén transfiriendo a BigQuery. En Cloud Console, ve a BigQuery.

    Ir a BigQuery

  3. Busca el ícono gke_cluster_resource_consumption.

  4. Sigue la sección de requisitos previos para habilitar la medición de uso del clúster de GKE a fin de habilitar la visualización de medición de uso de GKE.

  5. Abre Google Data Studio, haz clic en Informe en blanco y, luego, selecciona BigQuery como la fuente de datos.

  6. Selecciona Consulta personalizada y busca el ID del proyecto. En el cuadro de texto a la derecha, ingresa tu consulta personalizada. Para ver ejemplos de las consultas personalizadas, revisa las siguientes secciones.

Ejemplo: uso total de cada subárbol

Esta búsqueda muestra el uso de todos los espacios de nombres regulares, abstractos y jerárquicos en el clúster, incluidos todos sus descendientes:

SELECT
  REGEXP_EXTRACT(label.key, r"^[a-zA-Z0-9\-]+") as subtree,
  resource_name,
  usage.unit,
  SUM(usage.amount) AS usage_amount
FROM
  `PROJECT_NAME.DATASET_NAME.TABLE_NAME`,
  UNNEST(labels) AS label
WHERE
  regexp_contains(label.key, "tree.hnc.x-k8s.io/depth")
GROUP BY
  subtree,
  resource_name,
  usage.unit
ORDER BY
  resource_name ASC,
  subtree ASC

Resultado de muestra parcial:

subárbol resource_name unidad usage_amount
a cpu segundos 0.09
a1 cpu segundos 0.09
a2 cpu segundos 0
a memory byte-seconds 6,315,303,690,240
a1 memory byte-seconds 1,355,268,587,520
a2 memory byte-seconds 4,960,035,102,720

En este ejemplo, el uso atribuido al espacio de nombres a incluye el uso de sus espacios de nombres subordinados a1 y a2, que también se muestran.

Ejemplo: uso de un subárbol único

En esta consulta se muestra la cantidad total de uso en el espacio de nombres a y todos sus espacios de nombres subordinados:

SELECT
  resource_name,
  usage.unit,
  SUM(usage.amount) AS usage_amount
FROM
  `PROJECT_NAME.DATASET_NAME.TABLE_NAME`,
  UNNEST(labels) AS label
WHERE
  label.key="SUBTREE_NAME.tree.hnc.x-k8s.io/depth"
GROUP BY
  resource_name,
  usage.unit

Resultado de muestra del espacio de nombres a:

resource_name unidad usage_amount
cpu segundos 0.09
memory byte-seconds 6,315,303,690,240

Ejemplo: uso de todos los espacios de nombres en un subárbol

En esta consulta se muestra el uso individual de cada espacio de nombres en un subárbol determinado:

SELECT
  namespace,
  resource_name,
  SUM(usage.amount) AS usage_amount
FROM
  `PROJECT_NAME.DATASET_NAME.TABLE_NAME`,
  UNNEST(labels) AS label
WHERE
  label.key="SUBTREE_NAME.tree.hnc.x-k8s.io/depth"
GROUP BY
  namespace,
  resource_name

Resultado de muestra del espacio de nombres a:

espacio de nombres resource_name usage_amount
a2 memory 4,960,035,102,720
a1 memory 1,355,268,587,520
a2 cpu 0
a1 cpu 0.09

El espacio de nombres a en sí mismo no contiene uso, por lo que no aparece en los resultados de esta búsqueda.

Limitaciones de la supervisión jerárquica

Las siguientes son limitaciones de la supervisión jerárquica.

Se ignoran los cambios en la jerarquía

Las etiquetas de árbol de los Pods se agregan a los Pods cuando se crean y no se modifican después de que el Pod comienza a ejecutarse. Esto significa que los Pods que se iniciaron antes de que se habilitara la supervisión jerárquica no recibieron etiquetas de árbol de Pod.

Además, no se actualizarán las etiquetas de los Pods cuya jerarquía cambia después de que se inició el Pod (por ejemplo, mediante el uso del controlador de jerarquía para cambiar el superior de un espacio de nombres). Si bien las modificaciones de jerarquía suelen poco frecuentes, si esta situación ocurre y genera un problema, asegúrate de reiniciar todos los Pods afectados después de modificar la jerarquía.

Los Pods se crean incluso si no se pueden aplicar etiquetas

La supervisión jerárquica no se aplica a los pods que se ejecutan en espacios de nombres clave del sistema, como kube-system o hnc-system. Sin embargo, la configuración del webhook por sí sola no tiene forma de excluir estos espacios de nombres. Por lo tanto, si Hierarchy Controller encuentra un problema, podría verse afectada la creación de pods en todos los espacios de nombres.

Como resultado, en lugar de arriesgarse a una interrupción en todo el clúster, si el controlador de jerarquía no puede procesar un Pod en dos segundos, el webhook falla y permite que el Pod se cree sin las etiquetas. Estas fallas de webhook se pueden supervisar a través del servidor de la API de Kubernetes mediante la búsqueda de fallas del webhook de admisión mutante podlabel.hierarchycontroller.configmanagement.gke.io.

¿Qué sigue?