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 :
- Requêtes Kubernetes natives pour les pods
- Cloud Logging
- Mesure de l'utilisation de GKE
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 :
Dans le fichier de configuration de Config Management Operator, dans l'objet
spec.hierarchyController
, définissez la valeur deenablePodTreeLabels
surtrue
:# 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...
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 :
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
Inspectez le pod et vérifiez qu'il contient le libellé
default.tree.hnc.x-k8s.io/depth
:kubectl describe pod --namespace default websvr
Sortie :
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...
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 Google Cloud Console 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 la CLI Google Cloud :
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 :
Activez la mesure de l'utilisation standard de GKE sur votre cluster.
Vérifiez que les données sont ingérées dans BigQuery. Dans la console Google Cloud, accédez à BigQuery.
Recherchez
gke_cluster_resource_consumption
.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.
Ouvrez Looker Studio, cliquez sur Rapport vide, puis sélectionnez BigQuery comme source de données.
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
Pour en savoir plus sur les tâches courantes que vous pouvez effectuer en utilisant HNC, consultez le Guide pratique de l'utilisateur HNC.