Skip to content

OVN-Kubernetes internals

Fonte: ovn-kubernetes.io/observability/metrics e github.com/openshift/ovn-kubernetes (metriche ufficiali del progetto, esposte anche su OCP).

Chi è il leader ovnkube-controller / cluster-manager (deve essere sempre 1)

Section titled “Chi è il leader ovnkube-controller / cluster-manager (deve essere sempre 1)”
ovnkube_controller_leader
ovnkube_clustermanager_leader

Nessun leader eletto (situazione anomala — HA compromessa)

Section titled “Nessun leader eletto (situazione anomala — HA compromessa)”
sum(ovnkube_controller_leader) == 0

Tempo di avvio fino a ready (spike dopo restart/upgrade)

Section titled “Tempo di avvio fino a ready (spike dopo restart/upgrade)”
ovnkube_controller_ready_duration_seconds
ovnkube_node_ready_duration_seconds

Retry falliti sulla riconciliazione delle risorse (drift di configurazione)

Section titled “Retry falliti sulla riconciliazione delle risorse (drift di configurazione)”
rate(ovnkube_resource_retry_failures_total[5m])

Alla base dell’alert ufficiale OVNKubernetesResourceRetryFailure: valori >0 sostenuti indicano che ovnkube-controller non riesce a convergere lo stato desiderato (spesso per conflitti di configurazione o problemi verso apiserver).

Durata di sync/setup per tipo di risorsa (capire cosa rallenta la riconciliazione)

Section titled “Durata di sync/setup per tipo di risorsa (capire cosa rallenta la riconciliazione)”
ovnkube_controller_sync_duration_seconds

CNI request duration (tempo di attach rete per un pod in creazione — impatta lo startup)

Section titled “CNI request duration (tempo di attach rete per un pod in creazione — impatta lo startup)”
histogram_quantile(0.99, sum by (le) (rate(ovnkube_node_cni_request_duration_seconds_bucket[5m])))

Se questo valore cresce, i pod impiegano più tempo a passare da ContainerCreating a Running: sintomo tipico di un nodo con troppi pod/secondi o problemi su OVS.

rate(ovnkube_master_libovsdb_disconnects_total[5m])
ovnkube_master_libovsdb_monitors

Disconnessioni frequenti = instabilità di rete tra ovnkube-controller e i database OVN, spesso correlata a CPU/rete satura sui control-plane node.

Numero di flussi OVS installati per nodo (già in questo sito, vedi Network)

Section titled “Numero di flussi OVS installati per nodo (già in questo sito, vedi Network)”
ovs_vswitchd_dp_flows_total
Section titled “Interfacce OVS in stato reset (link flapping)”
rate(ovs_vswitchd_interface_resets_total[5m])

Pacchetti droppati a livello OVS interface (RX/TX)

Section titled “Pacchetti droppati a livello OVS interface (RX/TX)”
rate(ovs_vswitchd_interface_rx_dropped_total[5m])
rate(ovs_vswitchd_interface_tx_dropped_total[5m])
rate(ovs_vswitchd_interface_rx_errors_total[5m])
rate(ovs_vswitchd_interface_tx_errors_total[5m])

Collisioni (raro su reti moderne full-duplex, ma da tenere d’occhio su bond/VLAN)

Section titled “Collisioni (raro su reti moderne full-duplex, ma da tenere d’occhio su bond/VLAN)”
rate(ovs_vswitchd_interface_collisions_total[5m])

Questi contatori vivono a un livello sotto Multus/pod-network: se container_network_* (vedi pagina Network) mostra drop ma queste metriche OVS sono pulite, il problema è più in alto nello stack (es. NetworkPolicy che droppa, non un problema fisico/OVS).

AdminNetworkPolicy / BaselineAdminNetworkPolicy (se in uso)

Section titled “AdminNetworkPolicy / BaselineAdminNetworkPolicy (se in uso)”
ovnkube_controller_admin_network_policies
ovnkube_controller_baseline_admin_network_policies

Numero di oggetti ANP/BANP effettivamente programmati nel database OVN — utile per verificare che una policy applicata via oc apply sia arrivata fino al dataplane.