Osserva carichi di lavoro gerarchici
Il controller della gerarchia ti offre una migliore osservabilità nei carichi di lavoro utilizzando sia gli spazi dei nomi gerarchici che astratti nel tuo cluster. A questo scopo, propaga le etichette ad albero del cluster ai pod, rendendole disponibili per qualsiasi sistema in grado di importare etichette Kubernetes, tra cui:
- Query Kubernetes native per i pod
- Cloud Logging
- Misurazione dell'utilizzo di GKE
Ad esempio, considera un carico di lavoro in esecuzione in uno spazio dei nomi dal repository di esempi di ereditarietà dello spazio dei nomi. Il repository di esempio di ereditarietà dello spazio dei nomi ha la seguente architettura:
├── 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 consente di selezionare pod, log o misurazioni dell'utilizzo generati da qualsiasi carico di lavoro discendente di eng
, rnd
o qualsiasi altro spazio dei nomi astratto. Ciò include non solo i carichi di lavoro negli spazi dei nomi
che si trovano nel repository Git come gamestore
, ma anche qualsiasi
spazio dei nomi figlio del Controller gerarchia che potresti creare come discendente
di questi spazi dei nomi.
Abilita l'osservabilità gerarchica
L'osservabilità gerarchica è fornita da Hierarchy Controller. Per abilitare l'osservabilità gerarchica:
Nel file di configurazione per l'operatore ConfigManagement, nell'oggetto
spec.hierarchyController
imposta il valore dienablePodTreeLabels
sutrue
:# 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...
Applica la configurazione:
kubectl apply -f config-management.yaml
Dopo circa un minuto, Hierarchy Controller e l'osservabilità gerarchica diventano utilizzabili sul cluster.
Se l'osservabilità gerarchica è abilitata, Hierarchy Controller installa un hook di ammissione mutante per aggiungere le etichette della struttura ad albero ai pod. Per verificare che questo webhook funzioni correttamente:
Avvia un carico di lavoro in qualsiasi spazio dei nomi, ad esempio:
kubectl run websvr --image=nginx --namespace default --generator=run-pod/v1
Ispeziona il pod e verifica che contenga l'etichetta
default.tree.hnc.x-k8s.io/depth
:kubectl describe pod --namespace default websvr
Output:
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...
Esegui la pulizia del carico di lavoro:
kubectl delete pod --namespace default websvr
I pod esistenti non ricevono le etichette dell'albero dei pod; queste etichette vengono aggiunte solo ai pod nuovi. Per ulteriori informazioni, consulta la sezione Limitazioni più avanti nel documento.
Utilizza l'osservabilità gerarchica del carico di lavoro
Una volta abilitate, le etichette della struttura ad albero dei pod possono essere utilizzate per migliorare l'osservabilità gerarchica del carico di lavoro sia all'interno dei cluster che in altri prodotti Google Cloud.
Eseguire query sui pod in base alla gerarchia
Puoi utilizzare qualsiasi operazione Kubernetes che include un selettore di etichette per
eseguire query sulle etichette della struttura ad albero dei pod. Ad esempio, per visualizzare tutti i pod in tutti gli spazi dei nomi in esecuzione in un discendente dello spazio dei nomi default
, utilizza la query seguente:
kubectl get pods --all-namespaces -l default.tree.hnc.x-k8s.io/depth
Output basato sul carico di lavoro di esempio che abbiamo creato per verificare l'installazione:
NAMESPACE NAME READY STATUS RESTARTS AGE
default websvr 1/1 Running 0 70s
Esegui query su Cloud Logging per gerarchia
Cloud Logging supporta un formato leggermente diverso per le etichette rispetto a Kubernetes. Ad esempio, per cercare qualsiasi carico di lavoro in esecuzione in un discendente dello spazio dei nomi default
, anziché cercare l'etichetta Kubernetes default.tree.hnc.x-k8s.io/depth
, Cloud Logging prevede una query simile alla seguente nella console Google Cloud:
resource.type="k8s_container" labels.k8s-pod/default_tree_hnc_x-k8s_io/depth!=""
In alternativa, puoi utilizzare un filtro simile in Google Cloud CLI:
gcloud logging read "resource.type=k8s_container AND labels.k8s-pod/default_tree_hnc_x-k8s_io/depth!=''"
Esegui query sulla misurazione dell'utilizzo di GKE per gerarchia
Puoi utilizzare le etichette della struttura ad albero dei pod per attribuire richieste e utilizzi dalla misurazione dell'utilizzo di GKE alle strutture degli spazi dei nomi. Per abilitare la misurazione dell'utilizzo gerarchico:
Abilita il monitoraggio dell'utilizzo standard di GKE sul cluster.
Conferma che i dati vengano importati in BigQuery. Nella console Google Cloud, vai a BigQuery.
Cerca
gke_cluster_resource_consumption
.Segui la sezione dei prerequisiti per l'abilitazione della misurazione dell'utilizzo dei cluster GKE per abilitare la visualizzazione per la misurazione dell'utilizzo di GKE.
Apri Looker Studio, fai clic su Report vuoto, poi seleziona BigQuery come origine dati.
Seleziona Query personalizzata e cerca l'ID progetto. Inserisci la query personalizzata nella casella di testo a destra. Per esempi di query personalizzate, consulta le sezioni seguenti.
Esempio: utilizzo totale di ogni sottoalbero
Questa query restituisce l'utilizzo per ogni spazio dei nomi regolare, astratto e gerarchico nel cluster, inclusi tutti i relativi discendenti:
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
Output parziale di esempio:
sottoalbero | resource_name | unità | usage_amount |
---|---|---|---|
a | cpu | secondi | 0,09 |
a1 | cpu | secondi | 0,09 |
a2 | cpu | secondi | 0 |
a | memoria | byte-secondi | 6.315.303.690.240 |
a1 | memoria | byte-secondi | 1.355.268.587.520 |
a2 | memoria | byte-secondi | 4.960.035.102.720 |
In questo esempio, l'utilizzo attribuito allo spazio dei nomi a
include l'utilizzo
dei suoi spazi dei nomi discendenti a1
e a2
, che sono anch'essi mostrati.
Esempio: utilizzo di un singolo sottoalbero
Questa query mostra la quantità totale di utilizzo nello spazio dei nomi a
e tutti i relativi spazi dei nomi discendenti:
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
Output di esempio per lo spazio dei nomi a
:
resource_name | unità | usage_amount |
---|---|---|
cpu | secondi | 0,09 |
memoria | byte-secondi | 6.315.303.690.240 |
Esempio: utilizzo di tutti gli spazi dei nomi in un sottoalbero
Questa query mostra l'utilizzo singolo di ogni spazio dei nomi in un determinato sottoalbero:
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
Output di esempio per lo spazio dei nomi a
:
spazio dei nomi | resource_name | usage_amount |
---|---|---|
a2 | memoria | 4.960.035.102.720 |
a1 | memoria | 1.355.268.587.520 |
a2 | cpu | 0 |
a1 | cpu | 0,09 |
Lo spazio dei nomi a
non contiene alcun utilizzo, quindi non è elencato nei risultati di questa query.
Limitazioni del monitoraggio gerarchico
Di seguito sono riportate le limitazioni del monitoraggio gerarchico.
Le modifiche alla gerarchia vengono ignorate
Le etichette dell'albero dei pod vengono aggiunte ai pod quando vengono creati e non vengono modificate dopo l'avvio del pod. Ciò significa che i pod avviati prima dell'abilitazione del monitoraggio gerarchico non ricevono etichette ad albero dei pod.
Inoltre, le etichette non vengono aggiornate per tutti i pod la cui gerarchia cambia dopo l'avvio del pod, ad esempio utilizzando Hierarchy Controller per modificare il padre di uno spazio dei nomi. Sebbene le modifiche alla gerarchia siano in genere piuttosto rare, se questa situazione si verifica e causa un problema, assicurati di riavviare tutti i pod interessati dopo aver modificato la gerarchia.
I pod vengono comunque creati anche se non è possibile applicare etichette
Il monitoraggio gerarchico non si applica ai pod in esecuzione in spazi dei nomi di sistema chiave, come kube-system
o hnc-system
. Tuttavia, la configurazione webhook
non ha modo di escludere questi spazi dei nomi. Pertanto, se Hierarchy Controller riscontra un problema, la creazione dei pod in tutti gli spazi dei nomi potrebbe risentirne.
Di conseguenza, se Hierarchy Controller non è in grado di elaborare un pod entro due secondi, il webhook ha esito negativo e consente la creazione del pod senza le etichette. Questi errori webhook possono essere monitorati tramite il server API Kubernetes cercando gli errori del webhook di ammissione mutante podlabel.hierarchycontroller.configmanagement.gke.io
.
Passaggi successivi
Scopri di più sulle attività comuni che potresti voler svolgere con HNC nella Guida dell'utente di HNC: How-to.