Observar cargas de trabajo jerárquicas

Beta

Este producto está sujeto a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones específicas del Servicio. Los productos de la fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

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:

• Consultas nativas de Kubernetes para Pods
• Cloud Logging
• Medición de uso de GKE

Por ejemplo, considera una carga de trabajo que se ejecuta en un espacio de nombres del repositorio de ejemplo de herencia de espacios de nombres. El repositorio de ejemplo de herencia de espacios de nombres tiene la siguiente arquitectura:

├── namespaces # Namespace directory
│   ├── eng # Namespace directory
│   │   ├── analytics # Abstract namespace directory
│   │   └── gamestore # Abstract namespace directory
│   ├── rnd # Namespace directory
│   │   ├── incubator-1 # Abstract namespace directory
│   │   └── incubator-2 # Abstract namespace directory
|   |── network-policy-default-deny-all.yaml
|   |── viewers-rolebinding.yaml

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

Nota: En este momento, la observabilidad jerárquica no es compatible con los clústeres de piloto automático.

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 ConfigManagement, 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 las cargas 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 los 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 la consola de Google Cloud:

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

Como alternativa, puedes usar un filtro similar en la CLI de Google Cloud:

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 la consola de Google Cloud, ve a BigQuery.

   Ir a BigQuery

3. Busca gke_cluster_resource_consumption.

   

   Ejemplo de importación de datos exitosa a BigQuery

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 Looker Studio, haz clic en Informe vacío 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?

• Usa cuotas de recursos jerárquicos.

• Si deseas obtener más información sobre las tareas comunes que puedes completar con HNC, consulta HNC User Guide: How-to (Guía del usuario de HNC: Instructivo).