WhatBrokeToday
Today's Trends
mediumInvestigatingKubernetes

Kubernetes Server-Side Apply Status Subresource Incorrectly Acquires Root Field Ownership

  1. Investigating(current)
  2. Trending(upcoming)
  3. Workaround available(upcoming)
  4. Resolved(upcoming)

Executive summary

Server-Side Apply on a CRD's /status subresource can acquire ownership of an unchanged, non-status root field that the status strategy restores from the old object. This causes subsequent changes by the original main-endpoint manager to conflict with the unintended status ownership.

No verified workaround yet

None of the linked reports describe a mitigation. Follow this incident to hear when one appears.

Official fix
Technical root cause

Server-side Apply on the /status subresource acquires ownership of additional root fields that are restored by the CRD status strategy from the old object.

Evidence

1 report · 1 GitHubShow
  1. [1]
    GitHub First report
    SSA /status acquires ownership of additional root fields reset by the CRD status strategy(opens GitHub issue in a new tab)

    What happened? Server-side Apply on a CRD's /status subresource can acquire ownership of an unchanged, non-status root field that the status strategy restores from the old object. The original main-endpoint manager's subsequent change then conflicts with that status ownership. This requires a valid root property outside spec and status, such as settings. It uses one API version, no conversion webhook, no admission webhook, no default, and no force. The same literal manager name is used on both…

    by sttts 0upvotes 1comments

Timeline

  1. First report on GitHub issue

    SSA /status acquires ownership of additional root fields reset by the CRD status strategy

    Source