Osserva carichi di lavoro gerarchici

Controller gerarchia consente una migliore osservabilità dei carichi di lavoro utilizzando sia gerarchico e astratti nel tuo in un cluster Kubernetes. Per farlo, propaga i dati del cluster etichette ad albero ai tuoi pod, rendendoli disponibili a qualsiasi sistema in grado di importare Kubernetes etichette, tra cui:

Ad esempio, considera un carico di lavoro in esecuzione in uno spazio dei nomi Repository di esempio sull'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 monitoraggio dell'utilizzo generato da qualsiasi carico di lavoro che è un discendente di eng, rnd o qualsiasi in un altro spazio dei nomi astratto. Ciò include non solo i carichi di lavoro negli spazi dei nomi che si trovano nel repository Git, ad esempio gamestore, ma anche Spazio dei nomi figlio di Hierarchy Controller che potresti creare come discendente a ciascuno di questi spazi dei nomi.

Abilita osservabilità gerarchica

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

  1. Installa Hierarchy Controller.

  2. Nel file di configurazione per l'operatore ConfigManagement, nella sezione 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, Hierarchy Controller e osservabilità gerarchica diventano utilizzabili sul cluster.

Quando l'osservabilità gerarchica è abilitata, Hierarchy Controller installa un'istanza 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 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. queste etichette sono aggiunti solo ai nuovi pod. Per ulteriori informazioni, vedi Limitazioni, più avanti in questo documento.

Utilizza l'osservabilità gerarchica dei carichi di lavoro

Dopo aver abilitato le etichette ad albero dei pod, puoi utilizzarle per migliorare la gerarchia l'osservabilità dei carichi di lavoro sia all'interno dei cluster Google Cloud.

Query sui pod in base alla gerarchia

Qualsiasi operazione Kubernetes che includa un selettore di etichette può essere utilizzata per eseguire query sul pod etichette ad albero. Ad esempio, per visualizzare tutti i pod in tutti gli spazi dei nomi in esecuzione un discendente dello spazio dei nomi default, usa 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 in Kubernetes. Ad esempio, per cercare qualsiasi carico di lavoro in esecuzione in un discendente di lo spazio dei nomi default, anziché cercare l'etichetta Kubernetes default.tree.hnc.x-k8s.io/depth, Cloud Logging prevede query simile al seguente in la 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 da Misurazione dell'utilizzo di GKE nelle strutture degli spazi dei nomi. Per abilitare la gerarchia misurazione dell'utilizzo:

  1. Abilita l'utilizzo regolare di GKE misurazione sul tuo cluster.

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

    Vai a BigQuery

  3. Cerca gke_cluster_resource_consumption.

  4. Segui i prerequisiti per abilitare l'utilizzo dei cluster GKE misurazione per abilitare la visualizzazione per la misurazione dell'utilizzo di GKE.

  5. Aperto Looker Studio fai clic su Report vuoto e seleziona BigQuery come dati sorgente.

  6. Seleziona Query personalizzata e cerca il tuo ID progetto. Nella casella di testo su a destra, inserisci la tua query personalizzata. Per esempi di query personalizzate, consulta le sezioni seguenti.

Esempio: utilizzo totale di ogni sottoalbero

Questa query restituisce l'utilizzo per ogni regolare, astratto e gerarchico nello spazio dei nomi 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 dello sono visualizzati anche gli spazi dei nomi discendenti a1 e a2.

Esempio: utilizzo di un singolo sottoalbero

Questa query visualizza 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 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 tipo di utilizzo, perciò 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 dell'avvio dell'esecuzione del pod. Ciò significa che i pod avviati in precedenza il monitoraggio gerarchico non riceve le etichette della struttura di pod.

Inoltre, qualsiasi pod la cui gerarchia cambia dopo il pod ad esempio, utilizzando Hierarchy Controller per modificare principale di uno spazio dei nomi, non ha le etichette aggiornate. Mentre la gerarchia le modifiche sono in genere piuttosto rare se si verifica questa situazione e causa assicurati di riavviare tutti i pod interessati dopo aver modificato nella gerarchia.

I pod vengono comunque creati anche se non è possibile applicare le etichette

Il monitoraggio gerarchico non si applica ai pod in esecuzione negli spazi dei nomi di sistema chiave come kube-system o hnc-system. Tuttavia, la configurazione del webhook non ha modo di escludere questi spazi dei nomi. Pertanto, se il controller della gerarchia riscontri un problema, la creazione dei pod in tutti gli spazi dei nomi potrebbe risentirne.

Di conseguenza, se Hierarchy Controller comporta il rischio di un'interruzione a livello di cluster non è in grado di elaborare un pod entro due secondi, il webhook non riesce e consente al pod di possono essere create senza le etichette. Questi errori del webhook possono essere monitorati tramite Server API Kubernetes cercando gli errori del Ammissione mutante per podlabel.hierarchycontroller.configmanagement.gke.io tramite webhook.

Passaggi successivi