Tag: Known Problem

The underlying Erlang process, Mnesia, is overloaded (` WARNING Mnesia is overloaded`).

A RabbitMQ node has entered the “memory alarm” state because the total memory used by the Erlang VM (plus allocated binaries, ETS tables,and processes) has exceeded the configured `vm_memory_high_watermark`. While the alarm is active the brokerapplies flow-control, blocking publishers and pausing most ingress activity to protect itself from running out of RAM.

The Erlang VM has reported a `busy_dist_port` condition, meaning the send buffer of a distribution port (used for inter-node traffic inside aRabbitMQ cluster) is full. When this happens the scheduler suspends the process owning the port, stalling inter-node replication, managementcalls, and any RabbitMQ process that must use that port. Throughput drops and latency rises until the buffer drains or the node is restarted.

The Google Kubernetes Engine metrics agent is failing to export metrics.

OVN daemons (e.g., ovn-controller) are stuck in a tight poll loop, driving CPU to 100 %. Logs show “Dropped … due to excessive rate” or“Unreasonably long … poll interval,” slowing port-binding and network traffic.

KEDA allows for fine-grained autoscaling (including to/from zero) for event driven Kubernetes workloads. KEDA serves as a Kubernetes Metrics Server and allows users to define autoscaling rules using a dedicated Kubernetes custom resource definition.

When a NGINX upstream becomes unreachable or its DNS entry disappears, NGINX requests begin to fail.

When the configured replication factor for a Kafka topic is greater than the actual number of brokers in the cluster, Kafka repeatedly fails to assign partitions and logs replication-related errors. This results in persistent warnings or an `InvalidReplicationFactorException` when the broker tries to create internal or user-defined topics.

Critical AWS VPC CNI node IP pool depletion detected causing cascading pod scheduling failures.This pattern indicates severe subnet IP address exhaustion combined with ENI allocation failures,leading to complete cluster networking breakdown. The failure sequence shows ipamd errors,kubelet scheduling failures, and controller-level pod creation blocks that render clustersunable to deploy new workloads, scale existing services, or recover from node failures.This represents one of the most severe Kubernetes infrastructure failures, often requiringimmediate manual intervention including subnet expansion, secondary CIDR provisioning,or emergency workload termination to restore cluster functionality.

During rolling updates, when a deployment's maxUnavailable setting conflicts with a Pod Disruption Budget's minAvailable requirement, it can cause service outages by terminating too many pods simultaneously, violating the availability guarantees.This can also occur during node drains, cluster autoscaling, or maintenance operations.