Kubectl edit is not honoring appArmorProfile update for k8s deployments

[rickypeng99]

What happened:
When updating a k8s deployment that was using the old annotation approach to the new security context approach, the edit will go though, but the deployment remains unchanged

What you expected to happen:
The change should be applied to the deployment

How to reproduce it (as minimally and precisely as possible):

1. Create a dummy k8s deployment with annotation under template:

   annotations:
     container.apparmor.security.beta.kubernetes.io/test-container: localhost/test_container_profile
   

2. Edit the deployment to remove the annotation and edit the securityContext to be

    securityContext:
      appArmorProfile:
          type: "Localhost"
          localhostProfile: "test_container_profile"
   

3. Obeserve that the edit will go though, but if you edit / describe it again, the annotation is gone, but the securityContext update is not there.

Anything else we need to know?:

Environment:

• Kubernetes client and server versions (use kubectl version):
  • Client Version: v1.33.2
  • Kustomize Version: v5.6.0
  • Server Version: v1.32.5-eks-5d4a308
• Cloud provider or hardware configuration: AWS EKS
• OS (e.g: cat /etc/os-release): MacOS

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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-sigs/prow repository.

[itzPranshul]

cc @seans3 @mengqiy I would like to take this

[ardaguclu]

I think, official recommendation is to use apply command (preferably with --server-side flag). I don't think, we want to add resource specific data in kubectl edit.

[Goend]

@rickypeng99 You should check the ReplicaSet configuration corresponding to your Deployment to see whether the container configuration includes the relevant AppArmor securityContext.
If it does not, verify whether your kube-controller-manager version matches that of the API server.
If they are not the same, any resulting differences may be expected, as there are differences in certain functions.
A successful patch operation indicates that the API server has accepted it, but if the corresponding field in the ReplicaSet is missing, it falls under the kube-controller-manager’s responsibility.

tips: I tested it on my own cluster running version v1.32 and did not encounter this issue.