Hierarchische Arbeitslasten beobachten

Der Hierarchy Controller sorgt für eine bessere Beobachtbarkeit Ihrer Arbeitslasten. Dafür werden die Namespaces hierarchisch und abstrakt in Ihrem Cluster verwendet. Dies erreichen Sie, indem Sie die Strukturlabels des Clusters an Ihre Pods verteilen und für jedes System verfügbar machen, das Kubernetes-Labels aufnehmen kann. Dazu gehören:

Beispiel: Eine Arbeitslast wird in einem Namespace aus dem Beispiel-Repository für die Namespace-Übernahme ausgeführt. Das Beispiel-Repository für die Namespace-Übernahme hat die folgende Architektur:

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

Mit dem Hierarchie-Controller können Sie Pods, Logs oder die Nutzungsmessung auswählen, die von jeder Arbeitslast generiert werden, die ein untergeordnetes Element von eng, rnd oder einem anderen abstrakten Namespace ist. Dies umfasst nicht nur die Arbeitslasten in Namespaces im Git-Repository, z. B. gamestore, sondern auch einen beliebigen untergeordneten Namespace des Hierarchy Controllers, den Sie möglicherweise als untergeordnetes Element dieser Namespaces erstellen.

Hierarchische Beobachtbarkeit aktivieren

Die hierarchische Beobachtbarkeit wird vom Hierarchy Controller bereitgestellt. So aktivieren Sie die hierarchische Beobachtbarkeit:

  1. Hierarchy Controller installieren.

  2. Legen Sie in der Konfigurationsdatei für den ConfigManagement Operator im Objekt spec.hierarchyController den Wert von enablePodTreeLabels auf true fest:

    # 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. Wenden Sie die Konfiguration an:

    kubectl apply -f config-management.yaml

    Nach etwa einer Minute können Sie den Hierarchy Controller und die hierarchische Beobachtbarkeit in Ihrem Cluster verwenden.

Wenn die hierarchische Beobachtbarkeit aktiviert ist, installiert der Hierarchy Controller einen mutierenden Zulassungs-Webhook, um den Pods die Strukturlabels hinzuzufügen. So können Sie prüfen, ob dieser Webhook ordnungsgemäß funktioniert:

  1. Starten Sie eine Arbeitslast in einem beliebigen Namespace. Beispiel:

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

  2. Prüfen Sie den Pod und vergewissern Sie sich, dass er das Label default.tree.hnc.x-k8s.io/depth enthält:

    kubectl describe pod --namespace default websvr

    Ausgabe:

    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. Bereinigen Sie die Arbeitslast:

    kubectl delete pod --namespace default websvr

Vorhandene Pods erhalten die Pod-Strukturlabels nicht. Diese Labels werden nur neuen Pods hinzugefügt. Weitere Informationen finden Sie weiter unten in diesem Dokument unter Einschränkungen.

Hierarchische Beobachtbarkeit der Arbeitslast verwenden

Wenn Pod-Baumlabels aktiviert sind, können diese verwendet werden, um die hierarchische Beobachtbarkeit von Arbeitslasten sowohl in Clustern als auch in anderen Google Cloud-Produkten zu verbessern.

Pods nach Hierarchie abfragen

Jeder Kubernetes-Vorgang, der eine Labelauswahl enthält, kann zum Abfragen von Pod-Strukturlabels verwendet werden. Wenn Sie beispielsweise alle Pods in allen Namespaces anzeigen möchten, die in einem untergeordneten Namespace des Typs default ausgeführt werden, verwenden Sie die folgende Abfrage:

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

Ausgabe basierend auf der Beispielarbeitslast, die wir erstellt haben, um die Installation zu prüfen:

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

Cloud Logging nach Hierarchie abfragen

Cloud Logging unterstützt ein etwas anderes Format für Labels als Kubernetes. Wenn Sie beispielsweise nach einer Arbeitslast suchen möchten, die in einem untergeordneten Element des Namespace default ausgeführt wird, erwartet Cloud Logging anstelle des Kubernetes-Labels default.tree.hnc.x-k8s.io/depth eine Abfrage ähnlich der folgenden in der Google Cloud Console:

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

Alternativ können Sie einen ähnlichen Filter im Google Cloud CLI verwenden:

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

GKE-Nutzungsmessung nach Hierarchie abfragen

Mithilfe von Pod-Strukturlabels können Sie Anfragen und Nutzungen von GKE-Nutzungsmessungen zu Namespace-Strukturen zuordnen. So aktivieren Sie die hierarchische Nutzungsmessung:

  1. Aktivieren Sie die reguläre GKE-Nutzungsmessung für Ihren Cluster.

  2. Prüfen Sie, ob die Daten in BigQuery aufgenommen werden. Wechseln Sie in der Google Cloud Console zu BigQuery.

    BigQuery aufrufen

  3. Suchen Sie nach gke_cluster_resource_consumption.

  4. Folgen Sie den Voraussetzungen zum Aktivieren der GKE-Clusternutzungsmessung, um die Visualisierung für die GKE-Nutzungsmessung zu aktivieren.

  5. Öffnen Sie Looker Studio, klicken Sie auf Leerer Bericht und wählen Sie dann BigQuery als Datenquelle aus.

  6. Wählen Sie Benutzerdefinierte Abfrage aus und suchen Sie nach Ihrer Projekt-ID. Geben Sie in das Textfeld rechts Ihre benutzerdefinierte Abfrage ein. Beispiele für benutzerdefinierte Abfragen finden Sie in den folgenden Abschnitten.

Beispiel: Gesamtnutzung aller Unterstrukturen

Diese Abfrage gibt die Verwendung für jeden regulären, abstrakten und hierarchischen Namespace im Cluster zurück, einschließlich aller Nachfolgerelemente:

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

Teilbeispielausgabe:

Unterstruktur resource_name unit usage_amount
a cpu Sekunden 0,09
a1 cpu Sekunden 0,09
a2 cpu Sekunden 0
a Speicher byte-seconds 6.315.303.690.240
a1 Speicher byte-seconds 1.355.268.587.520
a2 Speicher byte-seconds 4.960.035.102.720

In diesem Beispiel beinhaltet die Nutzung des Namespace a die Verwendung der untergeordneten Namespaces a1 und a2, die ebenfalls zu sehen sind.

Beispiel: Verwendung einer einzelnen Unterstruktur

Diese Abfrage zeigt die Gesamtnutzung unter dem Namespace a und allen untergeordneten Namespaces an:

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

Beispielausgabe für Namespace a:

resource_name unit usage_amount
cpu Sekunden 0,09
Speicher byte-seconds 6.315.303.690.240

Beispiel: Verwendung aller Namespaces in einer Unterstruktur

Diese Abfrage zeigt die Einzelnutzung jedes Namespace in einer bestimmten Unterstruktur an:

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

Beispielausgabe für Namespace a:

Namespace resource_name usage_amount
a2 Speicher 4.960.035.102.720
a1 Speicher 1.355.268.587.520
a2 cpu 0
a1 cpu 0,09

Der Namespace a selbst enthält keine Nutzung, daher wird er nicht in den Ergebnissen dieser Abfrage aufgeführt.

Einschränkungen des hierarchischen Monitorings

Im Folgenden sind die Einschränkungen für das hierarchische Monitoring beschrieben.

Änderungen an der Hierarchie werden ignoriert

Pod-Strukturlabels werden Pods bei ihrer Erstellung hinzugefügt und nicht geändert, nachdem der Pod gestartet wurde. Das bedeutet, dass Pods, die vor der Aktivierung des hierarchischen Monitorings gestartet wurden, keine Pod-Strukturlabels erhalten.

Darüber hinaus werden Pods, deren Hierarchie nach dem Start des Pods geändert wird, z. B. mithilfe des Hierarchiecontrollers, nicht geändert, um das übergeordnete Element eines Namespace zu ändern. Hierarchieänderungen sind in der Regel recht selten. Wenn dies aber der Fall ist und dadurch ein Problem verursacht wird, müssen Sie alle betroffenen Pods neu starten, nachdem Sie die Hierarchie geändert haben.

Pods werden auch dann erstellt, wenn Labels nicht angewendet werden können

Das hierarchische Monitoring gilt nicht für Pods, die in wichtigen System-Namespaces wie kube-system oder hnc-system ausgeführt werden. In der Webhook-Konfiguration selbst können diese Namespaces jedoch nicht ausgeschlossen werden. Wenn der Hierarchy Controller ein Problem ermittelt, könnte sich dies auf die Erstellung von Pods in allen Namespaces auswirken.

Statt einen clusterweiten Ausfall zu riskieren, schlägt der Webhook dann fehl und ermöglicht die Erstellung des Pods ohne Label, wenn der Hierarchy Controller einen Pod nicht innerhalb von zwei Sekunden verarbeiten kann. Solche Webhook-Fehler können über den Kubernetes API-Server überwacht werden. Dazu müssen Sie nach Fehlern des mutierenden Zulassungs-Webhooks podlabel.hierarchycontroller.configmanagement.gke.io suchen.

Nächste Schritte