ExtremelyHighIndividualControlPlaneCPU

[goern]

Alertmanager URL: https://console-openshift-console.apps.nostromo.erdgeschoss.b4mad.emea.operate-first.cloud/monitoring

• firing https://console-openshift-console.apps.nostromo.erdgeschoss.b4mad.emea.operate-first.cloud/monitoring/graph?g0.expr=100+-+%28avg+by+%28instance%29+%28rate%28node_cpu_seconds_total%7Bmode%3D%22idle%22%7D%5B1m%5D%29%29+%2A+100%29+%3E+90+and+on+%28instance%29+label_replace%28kube_node_role%7Brole%3D%22master%22%7D%2C+%22instance%22%2C+%22%241%22%2C+%22node%22%2C+%22%28.%2B%29%22%29&g0.tab=1

  Labels:

  • alertname = ExtremelyHighIndividualControlPlaneCPU
  • environment = nostromo
  • instance = bridge
  • namespace = openshift-kube-apiserver
  • openshift_io_alert_source = platform
  • org = b4mad
  • prometheus = openshift-monitoring/k8s
  • region = emea
  • severity = warning

  Annotations:

  • description = Extreme CPU pressure can cause slow serialization and poor performance from the kube-apiserver and etcd. When this happens, there is a risk of clients seeing non-responsive API requests which are issued again causing even more CPU pressure. It can also cause failing liveness probes due to slow etcd responsiveness on the backend. If one kube-apiserver fails under this condition, chances are you will experience a cascade as the remaining kube-apiservers are also under-provisioned. To fix this, increase the CPU and memory on your control plane nodes.
  • runbook_url = https://github.com/openshift/runbooks/blob/master/alerts/cluster-kube-apiserver-operator/ExtremelyHighIndividualControlPlaneCPU.md
  • summary = CPU utilization on a single control plane node is very high, more CPU pressure is likely to cause a failover; increase available CPU.

TODO: add graph url from annotations.