Skip to content

Kyverno Metrics: KCA practice questions

Kyverno exposes Prometheus metrics that describe what its policies do and how long that takes. With the Helm chart, each controller gets a metrics Service in the kyverno namespace serving on port 8000, kyverno-svc-metrics among them, created when metricsService.create is true for that controller.

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What Kyverno Metrics covers in KCA

Kyverno exposes Prometheus metrics that describe what its policies do and how long that takes. With the Helm chart, each controller gets a metrics Service in the kyverno namespace serving on port 8000, kyverno-svc-metrics among them, created when metricsService.create is true for that controller. The default Service type is ClusterIP, so only a Prometheus inside the cluster can scrape it; NodePort or LoadBalancer make it reachable from outside. The monitoring guide shows a ServiceMonitor scraping port 8000 at /metrics, the chart can create a PrometheusRule for alerts, and a Grafana dashboard is available through the chart or as JSON to import.

What gets measured is controlled by the kyverno-metrics ConfigMap. It can include or exclude namespaces, with exclusion winning when a namespace appears in both lists, change histogram bucket boundaries, disable individual metrics and drop label dimensions to reduce cardinality. Excluding a namespace there only changes what is measured; it does not stop policies from applying to it. Metrics and traces can also be sent to an OpenTelemetry collector over gRPC by setting otelConfig to grpc, with transportCreds naming the Secret that holds the CA certificate for TLS.

The reference groups the series by purpose. kyverno_policy_results is the main counter for rule outcomes. Its labels include rule_result, such as PASS or FAIL, rule_execution_cause, which separates admission_request from background_scan, policy_validation_mode, and resource_request_operation for create, update or delete, so the same counter answers both how many requests were rejected and how many existing resources fail a rule. kyverno_policy_execution_duration_seconds is a histogram with the same labels, exposed as _bucket, _sum and _count series. kyverno_policy_rule_info_total is a gauge, despite its suffix, with the value 1 for each rule currently present, labelled by policy type, rule type, validation mode and readiness. kyverno_policy_changes_total counts policy creations, updates and deletions.

Admission traffic has its own series: kyverno_admission_requests_total, labelled by whether the request was allowed, the webhook and the operation, and kyverno_admission_review_duration_seconds for latency. Further series cover HTTP requests, client queries to the API server by client type, controller reconciles, requeues and drops, and requests for deprecated APIs. The CEL-based policy types report through their own counters and histograms, for example kyverno_validating_policy_results_total, whose labels are result, execution_cause and a validation mode of Audit or Deny.

Two naming details trip people up. Most counters carry a _total suffix but the reference lists kyverno_policy_results without one, and histograms never use _total. Queries should be written against the names the reference documents for the installed version.

Key points

  • Helm metrics Services listen on port 8000 and default to type ClusterIP.
  • In the kyverno-metrics ConfigMap, namespace exclusion takes precedence over inclusion.
  • rule_execution_cause separates admission requests from background scans.
  • kyverno_policy_rule_info_total is a gauge even though its name ends in _total.

Three sample questions

10 KCA questions on Kyverno Metrics, 10 with explanations. How practice works

Question 1

You want to scrape Kyverno's admission controller metrics from inside the cluster. Which Service and port?
  1. A.kyverno-svc on port 443.
  2. B.kyverno-admission-controller-metrics on port 9090.
  3. C.kyverno-svc-metrics on port 8000, path /metrics.
  4. D.kyverno-reports-controller-metrics on port 8000.

Correct answer: C

Every Kyverno controller serves Prometheus metrics on port 8000 at /metrics, and the admission controller's metrics Service is named kyverno-svc-metrics — matching its main Service kyverno-svc rather than its Deployment name.

Question 2

The Kyverno docs refer to kyverno_policy_results. Your /metrics endpoint shows kyverno_policy_results_total. What is going on?
  1. A.Two different metrics with overlapping purposes.
  2. B.The _total version is deprecated.
  3. C._total only appears once the counter exceeds zero.
  4. D.Kyverno instruments with OpenTelemetry; its Prometheus exporter appends the conventional _total suffix to counters at export time. Query the name the endpoint shows.

Correct answer: D

The instrument name in code and documentation has no suffix; the Prometheus exporter adds _total because that is the Prometheus convention for counters. PromQL must use the exported name. Grepping the prefix (^kyverno_policy_results) matches either form.

Question 3

Which label on kyverno_policy_results_total separates live admission traffic from background-scan re-evaluation?
  1. A.policy_background_mode
  2. B.resource_request_operation
  3. C.rule_execution_cause, with values admission_request and background_scan
  4. D.policy_validation_mode

Correct answer: C

rule_execution_cause records what triggered the evaluation. Without filtering on it, a spike caused by hourly background scans looks identical to a spike caused by real deploy traffic being rejected — two very different incidents.

Practice this topic

Focus mode keeps every question on Kyverno Metrics until you leave it. 10 free guest answers, then a free account; no credit card.

Or open KCA practice across all topics.

Sources

The explanation above was checked against these official documents.