Kube-Zustandsmetriken
v2.14.0
kube-state-metrics (KSM) ist ein einfacher Dienst, der auf den Kubernetes-API-Server lauscht und Metriken über den Zustand der Objekte generiert. (Siehe Beispiele im Abschnitt „Metriken“ weiter unten.) Der Schwerpunkt liegt nicht auf dem Zustand der einzelnen Kubernetes-Komponenten, sondern vielmehr auf dem Zustand der verschiedenen darin enthaltenen Objekte, wie Bereitstellungen, Knoten und Pods.
Bei kube-state-metrics geht es darum, Metriken aus Kubernetes-API-Objekten ohne Änderungen zu generieren. Dadurch wird sichergestellt, dass die von kube-state-metrics bereitgestellten Funktionen den gleichen Stabilitätsgrad aufweisen wie die Kubernetes-API-Objekte selbst. Dies bedeutet wiederum, dass kube-state-metrics in bestimmten Situationen möglicherweise nicht genau die gleichen Werte wie kubectl anzeigt, da kubectl bestimmte Heuristiken anwendet, um verständliche Nachrichten anzuzeigen. kube-state-metrics stellt Rohdaten unverändert von der Kubernetes-API zur Verfügung, sodass Benutzer über alle Daten verfügen, die sie benötigen, und Heuristiken nach eigenem Ermessen durchführen können.
Die Metriken werden auf dem HTTP-Endpunkt /metrics auf dem Überwachungsport exportiert (Standard 8080). Sie werden als Klartext bereitgestellt. Sie sind so konzipiert, dass sie entweder von Prometheus selbst oder von einem Scraper genutzt werden können, der mit dem Scraping eines Prometheus-Client-Endpunkts kompatibel ist. Sie können /metrics auch in einem Browser öffnen, um die Rohmetriken anzuzeigen. Beachten Sie, dass die auf dem /metrics Endpunkt bereitgestellten Metriken den aktuellen Status des Kubernetes-Clusters widerspiegeln. Wenn Kubernetes-Objekte gelöscht werden, sind sie auf dem /metrics Endpunkt nicht mehr sichtbar.
Notiz
Diese README-Datei wird aus einer Vorlage generiert. Bitte nehmen Sie dort Ihre Änderungen vor und führen Sie make generate-template aus.
Versionierung
Kubernetes-Version
Kompatibilitätsmatrix
Kompatibilität der Ressourcengruppenversion
Containerbild
Metrikdokumentation
Konfliktlösung in Labelnamen
Kube-State-Metrics-Selbstmetriken
Ressourcenempfehlung
Latenz
Ein Hinweis zur Kostenkalkulation
kube-state-metrics vs. metrics-server
Kube-State-Metriken skalieren
Automatisiertes Sharding
Ressourcenempfehlung
Horizontales Sharding
Daemonset-Sharding für Pod-Metriken
Aufstellen
Aufbau des Docker-Containers
Verwendung
Kubernetes-Bereitstellung
Umgebung mit eingeschränkten Berechtigungen
Helmkarte
Entwicklung
Entwicklerbeiträge
Gemeinschaft
kube-state-metrics verwendet client-go um mit Kubernetes-Clustern zu kommunizieren. Die unterstützte Kubernetes-Clusterversion wird durch client-go bestimmt. Die Kompatibilitätsmatrix für Client-Go und Kubernetes-Cluster finden Sie hier. Jegliche zusätzliche Kompatibilität erfolgt nur nach bestem Wissen oder wird zufällig noch/bereits unterstützt.
Im Folgenden werden höchstens 5 Kube-State-Metriken und 5 Kubernetes-Releases erfasst. Im Allgemeinen wird empfohlen, die neueste Version von kube-state-metrics zu verwenden. Wenn Sie eine sehr aktuelle Version von Kubernetes ausführen, möchten Sie möglicherweise eine unveröffentlichte Version verwenden, um über den gesamten Umfang der unterstützten Ressourcen zu verfügen. Wenn Sie eine ältere Version von Kubernetes ausführen, müssen Sie möglicherweise eine ältere Version ausführen, um vollständige Unterstützung für alle Ressourcen zu erhalten. Beachten Sie, dass die Betreuer nur die neueste Version unterstützen. Ältere Versionen werden möglicherweise von interessierten Benutzern der Community unterstützt.
| Kube-State-Metriken | Kubernetes Client-Go-Version |
|---|---|
| v2.10.1 | v1.27 |
| v2.11.0 | v1.28 |
| v2.12.0 | v1.29 |
| v2.13.0 | v1.30 |
| v2.14.0 | v1.31 |
| hauptsächlich | v1.31 |
Ressourcen in Kubernetes können sich weiterentwickeln, d. h. die Gruppenversion einer Ressource kann sich in verschiedenen Kubernetes-Versionen von Alpha zu Beta und schließlich GA ändern. Derzeit verwendet kube-state-metrics nur die älteste in der neuesten Version verfügbare API.
Das neueste Containerbild finden Sie unter:
registry.k8s.io/kube-state-metrics/kube-state-metrics:v2.14.0 (arch: amd64 , arm , arm64 , ppc64le und s390x )
Sehen Sie sich hier alle Multi-Architektur-Bilder an
Alle Ressourcen und Metriken, die auf Alpha-Kubernetes-APIs basieren, sind von der Stabilitätsgarantie ausgenommen und können bei jedem Release geändert werden.
Weitere Informationen zu den bereitgestellten Metriken finden Sie im Verzeichnis docs .
Die Metrikfamilie *_labels macht Kubernetes-Labels als Prometheus-Labels verfügbar. Da Kubernetes hinsichtlich der zulässigen Zeichen in Labelnamen liberaler ist als Prometheus, konvertieren wir nicht unterstützte Zeichen automatisch in Unterstriche. Beispielsweise wird app.kubernetes.io/name zu label_app_kubernetes_io_name .
Diese Konvertierung kann zu Konflikten führen, wenn mehrere Kubernetes-Labels wie foo-bar und foo_bar in dasselbe Prometheus-Label label_foo_bar konvertiert würden.
Kube-state-metrics fügt automatisch das Suffix _conflictN hinzu, um diesen Konflikt zu lösen, und konvertiert daher die oben genannten Bezeichnungen in label_foo_bar_conflict1 und label_foo_bar_conflict2 .
Wenn Sie mehr Kontrolle darüber haben möchten, wie dieser Konflikt gelöst wird, sollten Sie erwägen, dieses Problem auf einer anderen Ebene des Stapels anzugehen, z. B. durch die Standardisierung von Kubernetes-Labels mithilfe eines Admission Webhooks, der sicherstellt, dass es keine möglichen Konflikte gibt.
kube-state-metrics stellt seine eigenen allgemeinen Prozessmetriken unter --telemetry-host und --telemetry-port bereit (Standard 8081).
kube-state-metrics stellt auch Erfolgs- und Fehlermetriken für Listen und Überwachungen bereit. Diese können zur Berechnung der Fehlerrate von Listen- oder Überwachungsressourcen verwendet werden. Wenn Sie auf diese Fehler in den Metriken stoßen, handelt es sich höchstwahrscheinlich um ein Konfigurations- oder Berechtigungsproblem. Als Nächstes sollten Sie sich die Protokolle von kube-state-metrics ansehen.
Beispiel für die oben genannten Metriken:
kube_state_metrics_list_total{resource="*v1.Node",result="success"} 1
kube_state_metrics_list_total{resource="*v1.Node",result="error"} 52
kube_state_metrics_watch_total{resource="*v1beta1.Ingress",result="success"} 1kube-state-metrics stellt auch einige HTTP-Anforderungsmetriken bereit. Beispiele hierfür sind:
http_request_duration_seconds_bucket{handler="metrics",method="get",le="2.5"} 30
http_request_duration_seconds_bucket{handler="metrics",method="get",le="5"} 30
http_request_duration_seconds_bucket{handler="metrics",method="get",le="10"} 30
http_request_duration_seconds_bucket{handler="metrics",method="get",le="+Inf"} 30
http_request_duration_seconds_sum{handler="metrics",method="get"} 0.021113919999999998
http_request_duration_seconds_count{handler="metrics",method="get"} 30kube-state-metrics macht auch Build- und Konfigurationsmetriken verfügbar:
kube_state_metrics_build_info{branch="main",goversion="go1.15.3",revision="6c9d775d",version="v2.0.0-beta"} 1
kube_state_metrics_shard_ordinal{shard_ordinal="0"} 0
kube_state_metrics_total_shards 1 kube_state_metrics_build_info wird verwendet, um Versions- und andere Build-Informationen offenzulegen. Weitere Informationen zur Verwendung des Infomusters finden Sie im Blogbeitrag hier. Sharding-Metriken legen die Flags --shard und --total-shards offen und können zur Validierung der Laufzeitkonfiguration verwendet werden, siehe /examples/prometheus-alerting-rules .
kube-state-metrics stellt auch Metriken zur Konfigurationsdatei und zur Konfigurationsdatei für den benutzerdefinierten Ressourcenstatus bereit:
kube_state_metrics_config_hash{filename="crs.yml",type="customresourceconfig"} 2.38272279311849e+14
kube_state_metrics_config_hash{filename="config.yml",type="config"} 2.65285922340846e+14
kube_state_metrics_last_config_reload_success_timestamp_seconds{filename="crs.yml",type="customresourceconfig"} 1.6704882592037103e+09
kube_state_metrics_last_config_reload_success_timestamp_seconds{filename="config.yml",type="config"} 1.6704882592035313e+09
kube_state_metrics_last_config_reload_successful{filename="crs.yml",type="customresourceconfig"} 1
kube_state_metrics_last_config_reload_successful{filename="config.yml",type="config"} 1Die Ressourcennutzung für Kube-State-Metriken ändert sich mit der Größe der Kubernetes-Objekte (Pods/Knoten/Bereitstellungen/Geheimnisse usw.) des Clusters. Bis zu einem gewissen Grad stehen die Kubernetes-Objekte in einem Cluster in direktem Verhältnis zur Knotennummer des Clusters.
Als allgemeine Regel sollten Sie Folgendes zuweisen:
250 MB Speicher
0,1 Kerne
Beachten Sie, dass bei zu niedrigen CPU-Grenzwerten die internen Warteschlangen von kube-state-metrics nicht schnell genug abgearbeitet werden können, was zu einem erhöhten Speicherverbrauch führt, wenn die Warteschlangenlänge zunimmt. Wenn Probleme aufgrund einer hohen Speicherzuweisung oder CPU-Drosselung auftreten, versuchen Sie, die CPU-Grenzwerte zu erhöhen.
In einem 100-Knoten-Cluster-Skalierungstest waren die Latenzzahlen wie folgt:
"Perc50": 259615384 ns, "Perc90": 475000000 ns, "Perc99": 906666666 ns.
Standardmäßig stellt kube-state-metrics mehrere Metriken für Ereignisse in Ihrem Cluster bereit. Wenn Ihr Cluster über eine große Anzahl häufig aktualisierter Ressourcen verfügt, werden möglicherweise viele Daten in diese Metriken aufgenommen. Dies kann bei einigen Cloud-Anbietern zu hohen Kosten führen. Bitte nehmen Sie sich einen Moment Zeit, um zu konfigurieren, welche Metriken Sie offenlegen möchten, und konsultieren Sie auch die Dokumentation für Ihre Kubernetes-Umgebung, um unerwartet hohe Kosten zu vermeiden.
Der Metrikserver ist ein von Heapster inspiriertes Projekt, das implementiert wurde, um die Ziele der Kernmetrikpipelines in der Kubernetes-Überwachungsarchitektur zu erfüllen. Dabei handelt es sich um eine Komponente auf Clusterebene, die regelmäßig Metriken von allen Kubernetes-Knoten sammelt, die von Kubelet über die Metrics-API bedient werden. Die Metriken werden aggregiert, im Speicher gespeichert und im Metrics-API-Format bereitgestellt. Der Metrikserver speichert nur die neuesten Werte und ist nicht für die Weiterleitung von Metriken an Drittziele verantwortlich.
kube-state-metrics konzentriert sich auf die Generierung völlig neuer Metriken aus dem Objektstatus von Kubernetes (z. B. Metriken basierend auf Bereitstellungen, Replikatsätzen usw.). Es speichert einen vollständigen Snapshot des Kubernetes-Status im Speicher und generiert darauf basierend kontinuierlich neue Metriken. Und genau wie der Metrikserver ist auch er nicht dafür verantwortlich, seine Metriken irgendwohin zu exportieren.
Kube-State-Metriken als separates Projekt zu haben, ermöglicht auch den Zugriff auf diese Metriken von Überwachungssystemen wie Prometheus.
Um Kube-State-Metriken horizontal zu teilen, wurden einige automatisierte Sharding-Funktionen implementiert. Es ist mit den folgenden Flags konfiguriert:
--shard (null indiziert)
--total-shards
Das Sharding erfolgt, indem eine MD5-Summe der UID des Kubernetes-Objekts genommen und darauf eine Modulo-Operation mit der Gesamtzahl der Shards durchgeführt wird. Jeder Shard entscheidet, ob das Objekt von der jeweiligen Instanz von kube-state-metrics behandelt wird oder nicht. Beachten Sie, dass dies bedeutet, dass alle Instanzen von kube-state-metrics, auch wenn sie fragmentiert sind, den Netzwerkverkehr und den Ressourcenverbrauch für das Unmarshaling von Objekten für alle Objekte haben, nicht nur für diejenigen, für die sie verantwortlich sind. Um dies weiter zu optimieren, müsste die Kubernetes-API Shard-Listen-/Überwachungsfunktionen unterstützen. Im optimalen Fall beträgt der Speicherverbrauch für jeden Shard 1/n im Vergleich zu einem Setup ohne Shard. Normalerweise müssen Kube-State-Metriken speicher- und latenzoptimiert werden, damit sie ihre Metriken relativ schnell an Prometheus zurückgeben können. Eine Möglichkeit, die Latenz zwischen kube-state-metrics und dem kube-apiserver zu reduzieren, besteht darin, KSM mit dem Flag --use-apiserver-cache auszuführen. Neben der Reduzierung der Latenz führt diese Option auch zu einer Reduzierung der Belastung von etcd.
Sharding sollte sorgfältig eingesetzt werden und es sollte eine zusätzliche Überwachung eingerichtet werden, um sicherzustellen, dass Sharding eingerichtet ist und wie erwartet funktioniert (z. B. werden Instanzen für jeden Shard aus der Gesamtzahl der Shards konfiguriert).
Automatisches Sharding ermöglicht es jedem Shard, seine nominelle Position zu ermitteln, wenn er in einem StatefulSet bereitgestellt wird, was für die automatische Sharding-Konfiguration nützlich ist. Dies ist eine experimentelle Funktion und kann ohne Vorankündigung beschädigt oder entfernt werden.
Um automatisiertes Sharding zu ermöglichen, müssen kube-state-metrics von einem StatefulSet ausgeführt werden und der Pod-Name und Namespace muss über die Flags --pod und --pod-namespace an den kube-state-metrics-Prozess übergeben werden. Beispielmanifeste, die die Autosharding-Funktionalität demonstrieren, finden Sie in /examples/autosharding .
Diese Art der Bereitstellung von Shards ist nützlich, wenn Sie KSM-Shards über eine einzelne Kubernetes-Ressource (in diesem Fall ein einzelnes StatefulSet ) verwalten möchten, anstatt eine Deployment pro Shard durchzuführen. Der Vorteil kann besonders bedeutend sein, wenn eine große Anzahl von Shards bereitgestellt wird.
Der Nachteil der Verwendung eines Auto-Sharding-Setups ergibt sich aus der von StatefulSet s unterstützten Rollout-Strategie. Bei der Verwaltung durch ein StatefulSet werden Pods einzeln ersetzt, wobei jeder Pod zuerst beendet und dann neu erstellt wird. Abgesehen davon, dass solche Rollouts langsamer sind, führen sie auch zu kurzen Ausfallzeiten für jeden Shard. Wenn während eines Rollouts ein Prometheus-Scrape auftritt, können einige der von kube-state-metrics exportierten Metriken fehlen.
Für Pod-Metriken können sie mit dem folgenden Flag pro Knoten aufgeteilt werden:
--node=$(NODE_NAME)
Jeder kube-state-metrics-Pod verwendet FieldSelector (spec.nodeName), um Pod-Metriken nur auf demselben Knoten zu überwachen/aufzulisten.
Ein Daemonset-Kube-State-Metrics-Beispiel:
apiVersion: apps/v1 kind: DaemonSet spec: template: spec: containers: - image: registry.k8s.io/kube-state-metrics/kube-state-metrics:IMAGE_TAG name: kube-state-metrics args: - --resource=pods - --node=$(NODE_NAME) env: - name: NODE_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: spec.nodeName
Um Metriken für nicht zugewiesene Pods zu verfolgen, müssen Sie eine zusätzliche Bereitstellung hinzufügen und --track-unscheduled-pods festlegen, wie im folgenden Beispiel gezeigt:
apiVersion: apps/v1 kind: Deployment spec: template: spec: containers: - image: registry.k8s.io/kube-state-metrics/kube-state-metrics:IMAGE_TAG name: kube-state-metrics args: - --resources=pods - --track-unscheduled-pods
Andere Metriken können über horizontales Sharding aufgeteilt werden.
Installieren Sie dieses Projekt mit go get in Ihrem $GOPATH :
go get k8s.io/kube-state-metrics
Führen Sie einfach den folgenden Befehl in diesem Stammordner aus, wodurch eine eigenständige, statisch verknüpfte Binärdatei erstellt und ein Docker-Image erstellt wird:
make container
Erstellen Sie einfach kube-state-metrics und führen Sie es in einem Kubernetes-Pod aus, der über ein Dienstkonto-Token verfügt, das schreibgeschützten Zugriff auf den Kubernetes-Cluster hat.
Der ( kube-prometheus )-Stack installiert kube-state-metrics als eine seiner Komponenten; Sie müssen kube-state-metrics nicht installieren, wenn Sie den kube-prometheus-Stack verwenden.
Wenn Sie die Standardkonfiguration für kube-prometheus überarbeiten möchten, um beispielsweise nicht standardmäßige Metriken zu aktivieren, schauen Sie sich Kube-Prometheus anpassen an.
Um dieses Projekt bereitzustellen, können Sie einfach kubectl apply -f examples/standard ausführen und ein Kubernetes-Dienst und eine Kubernetes-Bereitstellung werden erstellt. (Hinweis: Passen Sie die apiVersion einiger Ressourcen an, wenn die Version Ihres Kubernetes-Clusters nicht 1.8+ ist. Weitere Informationen finden Sie in der Yaml-Datei.)
Damit Prometheus Kube-State-Metrics-Instanzen erkennt, wird empfohlen, eine spezielle Prometheus-Scrape-Konfiguration für Kube-State-Metrics zu erstellen, die beide Metrik-Endpunkte erfasst. Von einer auf Anmerkungen basierenden Erkennung wird abgeraten, da nur einer der Endpunkte ausgewählt werden könnte. Außerdem gelten für kube-state-metrics in den meisten Fällen besondere Authentifizierungs- und Autorisierungsanforderungen, da es im Wesentlichen Lesezugriff über den Metrik-Endpunkt auf die meisten verfügbaren Informationen gewährt.
Hinweis: Benutzer von Google Kubernetes Engine (GKE) – GKE verfügt über strenge Rollenberechtigungen, die verhindern, dass die kube-state-metrics-Rollen und Rollenbindungen erstellt werden. Um dies zu umgehen, können Sie Ihrer GCP-Identität die Cluster-Administratorrolle zuweisen, indem Sie den folgenden Einzeiler ausführen:
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=$(gcloud info --format='value(config.account)')
Beachten Sie, dass bei Ihrer GCP-Identität die Groß-/Kleinschreibung beachtet wird, bei gcloud info ab Google Cloud SDK 221.0.0 jedoch nicht. Das heißt, wenn Ihr IAM-Mitglied Großbuchstaben enthält, funktioniert der obige Einzeiler möglicherweise nicht für Sie. Wenn nach der Ausführung des obigen Befehls und kubectl apply -f examples/standard 403 verbotene Antworten angezeigt werden, überprüfen Sie das mit Ihrem Konto verknüpfte IAM-Mitglied unter https://console.cloud.google.com/iam-admin/iam?project=PROJECT_ID . Wenn es Großbuchstaben enthält, müssen Sie möglicherweise das Flag --user im obigen Befehl auf die unter https://console.cloud.google.com/iam-admin/iam?project=PROJECT_ID aufgeführte Rolle mit Berücksichtigung der Groß-/Kleinschreibung setzen.
Wenn Sie nach der Ausführung des oben genannten Vorgangs sehen, Clusterrolebinding "cluster-admin-binding" created , können Sie mit der Einrichtung dieses Dienstes fortfahren.
Die folgenden Healthcheck-Endpunkte sind verfügbar ( self bezieht sich auf den Telemetrie-Port, während main sich auf den Exposition-Port bezieht):
/healthz (im main verfügbar): Gibt den Statuscode 200 zurück, wenn die Anwendung ausgeführt wird. Wir empfehlen, dies für die Startup-Probe zu verwenden.
/livez (auf main verfügbar gemacht): Gibt den Statuscode 200 zurück, wenn die Anwendung nicht von einem Ausfall des Kubernetes-API-Servers betroffen ist. Wir empfehlen, dies für die Lebendigkeitssonde zu verwenden.
/readyz (auf self verfügbar gemacht): Gibt den Statuscode 200 zurück, wenn die Anwendung bereit ist, Anfragen anzunehmen und Metriken bereitzustellen. Wir empfehlen, dies für die Bereitschaftsprüfung zu verwenden.
Beachten Sie, dass davon abgeraten wird, den Endpunkt für Telemetriemetriken für beliebige Sonden zu verwenden, wenn die Expositionsdaten als Proxy weitergeleitet werden.
Wenn Sie kube-state-metrics in einer Umgebung ausführen möchten, in der Sie keine Cluster-Reader-Rolle haben, können Sie Folgendes tun:
Erstellen Sie ein Servicekonto
apiVersion: v1kind: ServiceAccountmetadata: Name: kube-state-metrics Namespace: Ihr-Namespace-wo-kube-state-metrics-bereitgestellt werden
Geben Sie ihm view für bestimmte Namespaces (mithilfe von RoleBinding) ( Hinweis: Sie können dieses RoleBinding allen NS hinzufügen, auf die Ihr Dienstkonto zugreifen soll .)
apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata: Name: kube-state-metrics Namespace: project1roleRef: apiGroup: rbac.authorization.k8s.io Art: ClusterRole Name: Themen anzeigen: - Art: ServiceAccountname: kube-state-metricsnamespace: Ihr-Namespace-wo-kube-state-metrics-bereitgestellt wird
Geben Sie dann in der kube-state-metrics -Bereitstellungskonfiguration eine Reihe von Namespaces (mit der Option --namespaces ) und eine Reihe von Kubernetes-Objekten (mit der Option --resources ) an, auf die Ihr Serviceaccount Zugriff hat
spec: Vorlage: spec: Container:
- Name: kube-state-metricsargs:
- '--resources=pods' - '--namespaces=project1'Die vollständige Liste der verfügbaren Argumente finden Sie in der Dokumentation unter docs/developer/cli-arguments.md
Ab dem kube-state-metrics-Diagramm v2.13.3 (kube-state-metrics image v1.9.8 ) wird das offizielle Helm-Diagramm in prometheus-community/helm-charts verwaltet. Ab kube-state-metrics chart v3.0.0 werden nur kube-state-metrics-Bilder von v2.0.0 + unterstützt.
Testen Sie beim Entwickeln einen Metrik-Dump für Ihren lokalen Kubernetes-Cluster, indem Sie Folgendes ausführen:
Benutzer können die Apiserver-Adresse in der KUBE-CONFIG-Datei mit der Befehlszeile
--apiserverüberschreiben.
go install kube-state-metrics --port=8080 --telemetry-port=8081 --kubeconfig=--apiserver=
Rollen Sie dann den Metrikendpunkt ein
curl localhost:8080/metrics
Informationen zum lokalen Ausführen der e2e-Tests finden Sie in der Dokumentation in tests/README.md.
Bei der Entwicklung müssen bestimmte Codemuster befolgt werden, um Ihr Beitragserlebnis und die Wahrscheinlichkeit, dass e2e und andere CI-Tests bestehen, zu verbessern. Weitere Informationen hierzu finden Sie in der Dokumentation unter docs/developer/guide.md.
Dieses Projekt wird von SIG Instrumentation gesponsert.
Es gibt auch einen Kanal für #kube-state-metrics auf Kubernetes‘ Slack.
Sie können auch der SIG Instrumentation-Mailingliste beitreten. Dadurch werden in der Regel Einladungen für die folgenden Besprechungen zu Ihrem Kalender hinzugefügt, in denen Themen rund um Kube-State-Metriken besprochen werden können.
Reguläres SIG-Treffen: Donnerstags um 9:30 PT (Pacific Time) (zweiwöchentlich). Konvertieren Sie in Ihre Zeitzone.
Regelmäßige Triage-Sitzung: Donnerstags um 9:30 Uhr PT (Pacific Time) (zweiwöchentlich – abwechselnd mit der regulären Sitzung). Konvertieren Sie in Ihre Zeitzone.
