kubectl doesn't patch removing serviceAccountName from deployment

[mkrutik]

What happened?

kubectl apply -f doesn't patch removed serviceAccountName from the Deployment manifest.

What did you expect to happen?

Removed serviceAccountName from Deployment must be applied using kubectl apply -f deployment.yaml command. (or at least show some warning that it's not applied due to some reasons)

How can we reproduce it (as minimally and precisely as possible)?

1. Create Deployment manifest with any serviceAccountName within and apply it.
2. Remove serviceAccountName field from Deployment and apply it via kubectl apply -f command (use -v=9 to see req/resp logs).
3. Use describe or get command to get that Deployment and you should find that serviceAccountName still exists.

Anything else we need to know?

No response

Kubernetes version

Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.4", GitCommit:"e6c093d87ea4cbb530a7b2ae91e54c0842d8308a", GitTreeState:"clean", BuildDate:"2022-02-16T12:30:48Z", GoVersion:"go1.17.6", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.3", GitCommit:"c92036820499fedefec0f847e2054d824aea6cd1", GitTreeState:"clean", BuildDate:"2021-10-27T18:35:25Z", GoVersion:"go1.16.9", Compiler:"gc", Platform:"linux/amd64"}

Cloud provider

-

OS version

Darwin macbook-pro.home 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:54 PST 2021; root:xnu-8019.61.5~1/RELEASE_X86_64 x86_64

Install tools

`kubectl` installed via `brew`

Container runtime (CRI) and and version (if applicable)

-

Related plugins (CNI, CSI, ...) and versions (if applicable)

-

[mkrutik]

/sig cli

[ardaguclu]

/triage accepted
/sig api-machinery

[knight42]

@mkrutik kubectl apply did remove the serviceAccountName field, but it didn't touch another similar but already deprecated field serviceAccount, so the serviceAccountName field seems to be unchanged.(You could verify this by running kubectl edit, only by removing the serviceAccountName and serviceAccount field at the same time could you unset the service account).

As a workaround, I think you could try kubectl replace which updates instead of patching the deployment.

[ardaguclu]

@knight42 is right, this issue is due to the deprecated field is overriding it. I think, best thing is to use replace in that case.

/remove-triage accepted

[fedebongio]

/assign @apelisse @jpbetz
could either of you take a look / reassign please?
/triage accepted

[apelisse]

/wg api-expression

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[zswanson]

For anyone stumbling into this issue, its effectively a dupe of #72519 which was closed with a comment indicating this is somewhat intentional.

serviceAccountName is defaulted from serviceAccount for backwards compatibility. If you want to remove the fields you must set both to empty explicitly. It is not possible to leave one field unset.