Osserva carichi di lavoro gerarchici

Beta

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Il controller della gerarchia ti offre una migliore osservabilità dei carichi di lavoro utilizzando gli spazi dei nomi gerarchico e astratti nel tuo cluster. Per farlo, propaga le etichette ad albero del cluster ai pod, rendendole disponibili a qualsiasi sistema in grado di importare etichette Kubernetes, tra cui:

• Query Kubernetes native per i pod
• Cloud Logging
• Misurazione dell'utilizzo di GKE

Considera ad esempio un carico di lavoro in esecuzione in uno spazio dei nomi del repository di esempio 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 misurazione 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 posizionati nel repository Git, ad esempio gamestore, ma anche qualsiasi spazio dei nomi figlio di Hierarchy Controller che potresti creare come discendente di questi spazi dei nomi.

Abilita osservabilità gerarchica

Nota: al momento l'osservabilità gerarchica non è supportata sui cluster Autopilot.

L'osservabilità gerarchica è fornita da Hierarchy Controller. Per abilitare l'osservabilità gerarchica:

1. Installa Hierarchy Controller.

2. Nel file di configurazione per l'operatore ConfigManagement, nell'oggetto spec.hierarchyController, imposta il valore di enablePodTreeLabels su 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. Applica la configurazione:

   kubectl apply -f config-management.yaml
   

   Dopo circa un minuto, il controller della gerarchia e l'osservabilità gerarchica diventano utilizzabili nel cluster.

Quando l'osservabilità gerarchica è abilitata, Hierarchy Controller installa un webhook di ammissione mutante per aggiungere le etichette ad albero ai pod. Per verificare che questo webhook funzioni correttamente:

1. Avvia un carico di lavoro in qualsiasi spazio dei nomi, ad esempio:

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

2. Esamina 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...
   

3. Esegui la pulizia del carico di lavoro:

   kubectl delete pod --namespace default websvr
   

I pod esistenti non ricevono le etichette della struttura ad albero dei pod, ma vengono aggiunte solo ai nuovi pod. Per ulteriori informazioni, consulta la sezione Limitazioni più avanti nel documento.

Utilizza l'osservabilità gerarchica dei carichi di lavoro

Una volta abilitate, le etichette ad albero dei pod possono essere utilizzate per migliorare l'osservabilità gerarchica dei carichi di lavoro sia all'interno dei cluster sia in altri prodotti Google Cloud.

Query sui pod in base alla gerarchia

Qualsiasi operazione Kubernetes che includa un selettore di etichette può essere utilizzata per eseguire query sulle etichette dell'albero del 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 seguente query:

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

Output basato sul carico di lavoro di esempio creato per verificare l'installazione:

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

Query su Cloud Logging in base alla 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 ad albero dei pod per attribuire richieste e utilizzi della misurazione dell'utilizzo di GKE alle strutture degli spazi dei nomi. Per abilitare la misurazione dell'utilizzo gerarchico:

1. Abilita la misurazione regolare dell'utilizzo di GKE sul cluster.

2. Verifica che i dati vengano importati in BigQuery. Nella console Google Cloud, vai a BigQuery.

   Vai a BigQuery

3. Cerca gke_cluster_resource_consumption.

   

   Esempio di importazione di dati riuscita in BigQuery

4. Segui la sezione relativa ai prerequisiti per abilitare la misurazione dell'utilizzo dei cluster GKE per abilitare la visualizzazione per la misurazione dell'utilizzo di GKE.

5. Apri Looker Studio, fai clic su Report vuoto, quindi seleziona BigQuery come origine dati.

6. Seleziona Query personalizzata e cerca il tuo ID progetto. Inserisci la query personalizzata nella casella di testo a destra. Per esempi di query personalizzate, vedi 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 di esempio parziale:

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 degli spazi dei nomi discendenti a1 e a2, che vengono mostrati anche in questo caso.

Esempio: utilizzo di un singolo sottoalbero

Questa query mostra la quantità totale di utilizzo nello spazio dei nomi a e tutti gli 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 visualizza 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 viene elencato nei risultati di questa query.

Limitazioni del monitoraggio gerarchico

Di seguito sono riportati i limiti del monitoraggio gerarchico.

Le modifiche apportate alla gerarchia vengono ignorate

Le etichette ad albero dei pod vengono aggiunte ai pod al momento della creazione e non vengono modificate dopo l'avvio del pod. Ciò significa che i pod avviati prima dell'abilitazione del monitoraggio gerarchico non ricevono le etichette della struttura dei pod.

Inoltre, per tutti i pod la cui gerarchia cambia dopo l'avvio del pod, ad esempio usando Hierarchy Controller per cambiare il padre di uno spazio dei nomi, non vengono aggiornate le etichette. 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 le 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 del webhook in sé non ha modo di escludere questi spazi dei nomi. Pertanto, se il controller gerarchia riscontra un problema, la creazione dei pod in tutti gli spazi dei nomi potrebbe risentirne.

Di conseguenza, anziché rischiare un'interruzione a livello di cluster, se Hierarchy Controller non è in grado di elaborare un pod entro due secondi, il webhook non riesce e consente di creare il pod senza le etichette. Questi errori del webhook possono essere monitorati tramite il server API Kubernetes cercando gli errori del webhook di ammissione mutante podlabel.hierarchycontroller.configmanagement.gke.io.

Passaggi successivi

• Utilizza le quote delle risorse gerarchiche.

• Scopri di più sulle attività comuni che potresti utilizzare HNC nella Guida dell'utente di HNC: istruzioni.