Observer les charges de travail hiérarchiques

Hierarchy Controller vous offre une meilleure visibilité sur vos charges de travail grâce aux espaces de noms hiérarchiques et abstraits dans votre cluster. Pour ce faire, les libellés d'arbre de votre cluster sont propagés à vos pods, et sont ainsi mis à la disposition de tous les systèmes pouvant ingérer des libellés Kubernetes, y compris :

Prenons l'exemple d'une charge de travail exécutée dans un espace de noms à partir de l'exemple de dépôt pour l'héritage des espaces de noms. L'architecture de cet exemple de dépôt pour l'héritage des espaces de noms est la suivante :

├── 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

Hierarchy Controller vous permet de sélectionner des pods, des journaux ou une mesure de l'utilisation générés par toute charge de travail correspondant à un descendant de eng, rnd ou de tout autre espace de noms abstrait. Cela inclut non seulement les charges de travail des espaces de noms situés dans le dépôt Git, tels que gamestore, mais également tout espace de noms enfant Hierarchy Controller que vous créez en tant que descendant de ces espaces de noms.

Activer l'observabilité hiérarchique

L'observabilité hiérarchique est fournie par Hierarchy Controller. Pour activer l'observabilité hiérarchique, procédez comme suit :

  1. Installez Hierarchy Controller.

  2. Dans le fichier de configuration de Config Management Operator, dans l'objet spec.hierarchyController, définissez la valeur de enablePodTreeLabels sur 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. Appliquez la configuration :

    kubectl apply -f config-management.yaml

    Après environ une minute, Hierarchy Controller et l'observabilité hiérarchique deviennent utilisables sur votre cluster.

Lorsque l'observabilité hiérarchique est activée, Hierarchy Controller installe un webhook d'admission en mutation pour ajouter les libellés d'arborescence aux pods. Pour vérifier que ce webhook fonctionne correctement, procédez comme suit :

  1. Démarrez une charge de travail dans n'importe quel espace de noms, comme dans l'exemple suivant :

    kubectl run websvr --image=nginx --namespace default --generator=run-pod/v1

  2. Inspectez le pod et vérifiez qu'il contient le libellé default.tree.hnc.x-k8s.io/depth :

    kubectl describe pod --namespace default websvr

    Résultat :

    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. Nettoyez la charge de travail :

    kubectl delete pod --namespace default websvr

Les pods existants ne reçoivent pas les libellés de l'arborescence des pods. Ces libellés ne sont ajoutés qu'aux nouveaux pods. Pour en savoir plus, consultez la section Limites, plus loin dans ce document.

Utiliser l'observabilité hiérarchique de la charge de travail

Une fois les libellés d'arborescence de pods activés, ils peuvent être utilisés pour améliorer l'observabilité hiérarchique des charges de travail à la fois dans les clusters et dans d'autres produits Google Cloud.

Interroger les pods par hiérarchie

N'importe quelle opération Kubernetes incluant un sélecteur de libellés peut être utilisée pour interroger des libellés d'arborescence de pods. Par exemple, pour afficher tous les pods de tous les espaces de noms exécutés dans un descendant de l'espace de noms default, utilisez la requête suivante :

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

Résultat basé sur l'exemple de charge de travail que nous avons créé pour vérifier l'installation :

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

Interroger Cloud Logging par hiérarchie

Le format de libellés accepté par Cloud Logging diffère légèrement du format compatible avec Kubernetes. Par exemple, pour une recherche de charge de travail exécutée dans un descendant de l'espace de noms default, Cloud Logging ne s'attend pas à une recherche du libellé Kubernetes default.tree.hnc.x-k8s.io/depth, mais plutôt à une requête envoyée dans la console Google Cloud comme dans l'exemple suivant :

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

Vous pouvez également utiliser un filtre similaire dans Google Cloud CLI :

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

Interroger la mesure de l'utilisation de GKE par hiérarchie

Vous pouvez utiliser des libellés d'arborescence de pods pour attribuer les requêtes et les utilisations issues de la mesure de l'utilisation de GKE aux arborescences d'espaces de noms. Pour activer la mesure de l'utilisation hiérarchique, procédez comme suit :

  1. Activez la mesure de l'utilisation standard de GKE sur votre cluster.

  2. Vérifiez que les données sont ingérées dans BigQuery. Dans la console Google Cloud, accédez à BigQuery.

    Accéder à BigQuery

  3. Recherchez gke_cluster_resource_consumption.

  4. Suivez la section Prérequis pour activer la mesure de l'utilisation du cluster GKE pour activer la visualisation de la mesure de l'utilisation de GKE.

  5. Ouvrez Looker Studio, cliquez sur Rapport vide, puis sélectionnez BigQuery comme source de données.

  6. Sélectionnez Requête personnalisée, puis recherchez votre ID de projet. Dans la zone de texte à droite, saisissez votre requête personnalisée. Pour obtenir des exemples de requêtes personnalisées, consultez les sections suivantes.

Exemple : Utilisation totale de chaque sous-arborescence

Cette requête renvoie l'utilisation de chaque espace de noms standard, abstrait et hiérarchique du cluster, y compris tous ses descendants :

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

Exemple de résultat partiel :

subtree resource_name unité usage_amount
a processeur secondes 0.09
a1 processeur secondes 0.09
a2 processeur secondes 0
a mémoire byte-seconds 6,315,303,690,240
a1 mémoire byte-seconds 1,355,268,587,520
a2 mémoire byte-seconds 4,960,035,102,720

Dans cet exemple, l'utilisation attribuée à l'espace de noms a inclut l'utilisation de ses espaces de noms descendants a1 et a2, qui sont également affichés.

Exemple : Utilisation d'une seule sous-arborescence

Cette requête affiche la quantité totale d'utilisation sous l'espace de noms a et tous ses espaces de noms descendants :

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

Exemple de résultat pour l'espace de noms a :

resource_name unité usage_amount
processeur secondes 0.09
mémoire byte-seconds 6,315,303,690,240

Exemple : Utilisation de tous les espaces de noms dans une sous-arborescence

Cette requête affiche l'utilisation individuelle de chaque espace de noms dans une sous-arborescence donnée :

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

Exemple de résultat pour l'espace de noms a :

espace de noms resource_name usage_amount
a2 mémoire 4,960,035,102,720
a1 mémoire 1,355,268,587,520
a2 processeur 0
a1 processeur 0.09

L'espace de noms a lui-même ne contient aucune utilisation. Par conséquent, il n'est pas répertorié dans les résultats de cette requête.

Limites de la surveillance hiérarchique

Les limites suivantes s'appliquent à la surveillance hiérarchique.

Les modifications apportées à la hiérarchie sont ignorées

Les libellés de l'arborescence des pods sont ajoutés aux pods lors de leur création et ne sont pas modifiés après le démarrage du pod. Cela signifie que les pods démarrés avant l'activation de la surveillance hiérarchique ne reçoivent pas de libellés d'arborescence de pods.

Par ailleurs, les libellés des pods dont la hiérarchie est modifiée après le démarrage du pod (par exemple, en utilisant Hierarchy Controller pour changer le parent d'un espace de noms) ne sont pas mis à jour. Bien que les modifications de hiérarchie soient généralement assez rares, elles peuvent se produire et occasionner des problèmes. Dans ce cas, redémarrez tous les pods concernés après avoir modifié la hiérarchie.

Les pods sont toujours créés même si les libellés ne peuvent pas être appliqués

La surveillance hiérarchique ne s'applique pas aux pods qui s'exécutent dans des espaces de noms du système de clés, tels que kube-system ou hnc-system. Cependant, la configuration du webhook lui-même ne permet pas d'exclure ces espaces de noms. Par conséquent, si Hierarchy Controller rencontre un problème, la création de pod dans tous les espaces de noms peut être affectée.

Par conséquent, au lieu de risquer une panne à l'échelle du cluster, si Hierarchy Controller ne peut pas traiter un pod dans les deux secondes, le webhook échoue et autorise la création du pod sans libellé. Ces échecs de webhook peuvent être surveillés via le serveur d'API Kubernetes en recherchant les échecs du webhook d'admission en mutation podlabel.hierarchycontroller.configmanagement.gke.io.

Étapes suivantes