Your policy warns on a deprecated Kubernetes API version the server already warns about - what should your text say?
answer
- the server already warns about this
- add only what the platform cannot know
- source, owner, and what changes next
- one line, to stderr, easily lost
- measure server-side, not by delivery
basics
~20 sCarry only what the API server cannot know. Its built-in deprecation warning already names the version and its replacement, so your text must add local detail: which template produced the object, which rule fired and who owns it.
solid answer
~50 sKubernetes already returns a deprecation warning on requests to a deprecated group/version, and that warning names the replacement. If your policy emits a second warning saying the same thing, you have doubled the noise on the one channel you rely on and taught the team that warnings are wallpaper. Your text earns its place only by carrying what the API server cannot know: which internal chart, base template or generator produced the object; which rule fired and which team owns it, so the developer knows who to ask; and what will change next. Keep it to one line - a message containing a line break is discarded in favour of the fallback. And remember it goes to stderr, a channel non-interactive applies quietly drop, so measure adoption from the server side rather than assuming anyone read it.
go deeper
Recall that Kubernetes itself warns you when you use a deprecated API version and that its warning already names the replacement version to use.
Explain the difference between the API server's built-in deprecation warning and one your own policy emits, and where each appears in a client's output.
Show that you would not duplicate a warning the server already sends. Your text has to carry local knowledge - which template produced the object, who owns the rule, what changes next - in one actionable line.
Own the noise budget. Every advisory line you add spends credibility from a channel shared by the platform and every other team, so decide deliberately how many warnings an estate can carry before all of them are ignored.
## The API server got there first When a client submits an object under a deprecated API group/version, the Kubernetes API server itself returns a warning: it says the version is deprecated, indicates when it stops being served, and names the replacement. No policy is involved. That is the baseline your rule is competing with, and it is the fact most people writing a deprecated-API policy forget. So the interview question underneath the scenario is not 'can you write a warning' but **'what does your warning add?'** ### What the platform cannot know The API server sees one request for one group/version. It knows nothing about your organisation. Everything below is yours to supply: - **The source of the object.** Developers rarely hand-write the manifest that tripped the rule. It came out of a chart, a base overlay, a generator, a copied example. 'This came from the shared service base template; the fix is in that repo' converts a confusing warning into a routed task. - **Who owns the rule.** A developer who cannot tell whether the message came from the platform, from a security policy, or from Kubernetes itself has nobody to ask. Naming the rule identifier makes it searchable; naming the owning team makes it answerable. - **What changes next, and roughly when.** A warning with no future is decoration. 'This will start being refused' - with a date or a release - is the sentence that gets a ticket created. - **Scope the server does not cover.** Your policy may also flag things Kubernetes considers perfectly current but your organisation has decided to retire. There the built-in warning does not exist at all, and yours is the only signal. ### What to leave out Do not restate the deprecation. Do not paste the CEL expression. Do not write a paragraph. Each warning line spends a little of the credibility of the warning channel, and that channel is shared: your policy, other teams' policies and the API server all write to it. An estate where every apply prints four advisory lines is an estate where nobody reads the fifth. ### Mechanics that shape the text - The text must be **one line**. A validation message containing a line break is discarded and the fallback text is used instead, so formatting a bulleted list into the string produces a worse message than the plain sentence you started from. - Keep it short and specific, addressed to the human running the command; Kubernetes guidance for warning text is a brief phrase without trailing punctuation, not prose. - Warnings are printed to **stderr**. A CI step capturing stdout, an apply run by automation, or output consumed as JSON will not show it to anyone. - The text can be computed from the object, so name the actual object rather than the class of object: the specific name is what turns a search into a fix. ### Did anyone read it? This is the part seniors are expected to raise unprompted. The warning channel is fire-and-forget: nothing tells you it was seen. If you need to know whether usage is actually falling, look at the server side instead - the API server records requests in the audit log and publishes a metric for requests against deprecated APIs, both of which give you a count over time that a warning header never will. Measure the behaviour, not the delivery. ### Putting it together A weak warning: 'batch/v1beta1 is deprecated, use batch/v1.' It is true, it is already being said by the server, and it changes nothing. A warning that earns its place names the object, points at where the object actually came from, identifies the rule and its owner, and states what happens next - all in one line the developer can act on without opening a policy repository or asking in a channel. If you cannot write a line that meets that bar, the honest conclusion is that your policy has nothing to add here and should not be emitting a warning at all.
- A team insists they never saw the warning. What are the likely explanations?Warnings are printed to stderr, so a CI step capturing only stdout drops them; output rendered as JSON or YAML does not carry them; and an apply performed non-interactively has no human watching the stream. None of these are policy bugs - they are properties of the channel, and they are why a warning alone is not a delivery mechanism you can rely on.
- How do you tell whether the warning actually reduced use of the deprecated version?From the server, not the client. The audit log records the requests, and the API server publishes a metric counting requests made against deprecated APIs, so you can watch the count fall week over week. The warning channel gives you no delivery or read receipt of any kind.
- Is it ever right to emit no warning at all here?Yes. If your line only restates what the API server already says, it adds noise to a shared channel and nothing else. Either write text carrying local remediation detail the platform cannot know, or leave the built-in warning to do its job and put your effort into finding the templates that generate the object.
Putting a second sticker next to the manufacturer's warning label does not make anyone read either one; it only makes the label area easier to ignore.
saying these in an interview costs you the question
- Restates the built-in deprecation warning and calls it a policy
- Writes a multi-line message with a formatted list
- Assumes a warning was read because it was emitted
- Names the resource class but never the specific object
- Treats the warning channel as unlimited and free