Incident Library
Applied filters Root causeSoftware defectComponentNode operating system imageOrganisationMicrosoft AzureClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases1 case

1 to 1 of 1

  1. Symptoms

    In newly created AKS clusters using Azure CNI in Central India, kubectl exec and kubectl logs could time out, and pod-to-pod or pod-to-node traffic could time out. The cluster diagnostics page showed tunnel exec issues. Clusters using kubenet were not affected.

    Trigger

    VMs in Central India started being assigned MAC addresses in a much higher range than before (06 prefix rather than the usual 00).

    Root cause
    Component
    Contributing factor
    –
    Remediation
    • told owners of affected scale-set clusters to run a node image upgrade, or any Kubernetes upgrade such as a patch version, to get the Azure CNI that does not use a bridge
    • told owners of availability-set clusters to scale out and delete the VMs with a high-range MAC address in bridge mode
    • advised recreating affected clusters that were brand new
    Action items
    • Roll out a hotfix that makes transparent mode the default in all regions
    Lessons

    A change in how the platform assigns MAC addresses can wake a long-dormant bug in the network plugin. Knowing which CNI mode the nodes run (bridge or transparent) and keeping node images current decides whether such a bug reaches you.

Check your cluster for this

This case involves Azure CNI and Node operating system image. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.

By root cause1