Investigation of the Kubernetes Watch Event ResourceVersion Bug and Its Fix in Versions 1.6–1.7

Recently a Zhihu post titled “Kubernetes 惊天地泣鬼神之大Bug” sparked discussion; the author attempted to reproduce the issue in their own clusters but could not trigger the described behavior.

The reported bug concerns a specific Kubernetes resource where, after creating an early object a , performing other creations, and finally deleting a , the watch Delete event reports the old resourceVersion from the original creation instead of the latest one, causing controller‑manager replay problems and service instability.

In the author’s environment (Kubernetes 1.6) extensive testing showed that all events’ object.resourceVersion values increased monotonically, contradicting the bug description.

Source‑code inspection revealed that in version 1.6 the watch event’s resourceVersion is taken from the current object, guaranteeing monotonic growth. Starting with version 1.7 the code was changed to use the PreObject ’s resourceVersion , which can be lower than the current one, thus introducing non‑monotonic values for delete events.

The community addressed the issue in PR #58547 , restoring the event’s resourceVersion to the object’s version and re‑establishing monotonicity.

Analysis of GitHub commit history shows that the bug was introduced by PR #46223 , merged after the 1.7.0 release, so versions between these two PRs are affected.

The article also provides a step‑by‑step method for reproducing the issue, encouraging readers to verify whether their clusters need the fix.

Finally, the author notes that Kubernetes evolves continuously, with old bugs being fixed and new ones emerging, and mentions upcoming articles and tools from the JDOS team to help operate large‑scale clusters reliably.