fix sidecarset hash without image is calculated differently when changing image tag to latest

[chengjoey]

Ⅰ. Describe what this PR does

kruise/apis/apps/defaults/v1alpha1.go

Lines 105 to 108 in 5a862a3

	func setDefaultContainer(sidecarContainer *v1alpha1.SidecarContainer) {
	container := &sidecarContainer.Container
	v1.SetDefaults_Container(container)
	for i := range container.Ports {

https://github.com/kubernetes/kubernetes/blob/60c4c2b2521fb454ce69dee737e3eb91a25e0535/pkg/apis/core/v1/defaults.go#L73-L78

when change image tag to latest, the sidecarset without image hash will be changed
I think ImagePullPolicy should not be involved in the hash, because it will cause the hash to change, causing the pod not to to be upgraded

Ⅱ. Does this pull request fix one issue?

Ⅲ. Describe how to verify it

apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
  name: sidecarset
spec:
  selector:
    matchLabels:
      app: sample
  containers:
  - name: nginx
    image: nginx:1.19.6
  updateStrategy:
    type: RollingUpdate

change 1.19.6 to latest
This is the change I printed that participates in the hash calculation
IfNotPresent -> Always

{
    "containers": [
        {
            "name": "nginx",
            "resources": {},
            "terminationMessagePath": "/dev/termination-log",
            "terminationMessagePolicy": "File",
            "imagePullPolicy": "IfNotPresent",
            "podInjectPolicy": "BeforeAppContainer",
            "upgradeStrategy": {
                "upgradeType": "ColdUpgrade"
            },
            "shareVolumePolicy": {
                "type": "disabled"
            }
        }
    ]
}

{
    "containers": [
        {
            "name": "nginx",
            "resources": {},
            "terminationMessagePath": "/dev/termination-log",
            "terminationMessagePolicy": "File",
            "imagePullPolicy": "Always",
            "podInjectPolicy": "BeforeAppContainer",
            "upgradeStrategy": {
                "upgradeType": "ColdUpgrade"
            },
            "shareVolumePolicy": {
                "type": "disabled"
            }
        }
    ]
}

Ⅳ. Special notes for reviews

[kruise-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign fei-guo for approval by writing /assign @fei-guo in a comment. For more information see:The Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 48.86%. Comparing base (0d0031a) to head (98d0f9d).
Report is 64 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1697      +/-   ##
==========================================
+ Coverage   47.91%   48.86%   +0.95%     
==========================================
  Files         162      188      +26     
  Lines       23491    19291    -4200     
==========================================
- Hits        11256     9427    -1829     
+ Misses      11014     8633    -2381     
- Partials     1221     1231      +10     

Flag	Coverage Δ
unittests	48.86% <100.00%> (+0.95%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[chengjoey]

@zmberg @furykerry , could you please take a look, because changing the image tag to latest will cause the pod to fail to update, I think imagePolicy should not be included in the calculation, and imagePolicy is easily affected by the mutation controller

[ABNER-1]

Hi, @chengjoey.
I believe Kruise computes the hash with the imagePullPolicy in SidecarSet because we cannot modify the imagePullPolicy within a pod.

[chengjoey]

Hi, @chengjoey. I believe Kruise computes the hash with the imagePullPolicy in SidecarSet because we cannot modify the imagePullPolicy within a pod.

Hi @ABNER-1 , Sorry I may not have expressed myself clearly, here are the problems I'm facing:

step1: create a sidecarset, siidecarset.yaml:

apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
  name: test-sidecarset
spec:
  selector:
    matchLabels:
      app: nginx
  updateStrategy:
    type: HotUpgrade
  containers:
  - name: sidecar1
    image: busybox:1.36.1
    command: ["sleep", "999d"]

step2: create a deploy that match sidecarset selector, nginx-deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: app
          image: nginx:1.15.1

At this time, nginx pod will be injected as expected, busybox:1.36.1 sidecar container

step3, change sidecarset.Spec.Containers[0].image to busybox:1.37

spec:
  containers:
  - name: sidecar1
    # change tag
    image: busybox:1.37

After a while, the sidecar container of the nginx pod became busybox:1.37 as expected.

step4, change sidecarset.Spec.Containers[0].image to busybox:latest

spec:
  containers:
  - name: sidecar1
    # use latest
    image: busybox:latest

After this change, the sidecar container of nginx-pod did not change the image to busybox:latest as expected.

I think the sidecarset in step 4 should still work for nginx-pod, what do you think?

[ABNER-1]

I understand your scenario, and I roughly comprehend that the actual changes taking effect in step 3 are:

1. image: busybox:1.37 -> busybox:latest
2. "imagePullPolicy": "IfNotPresent" -> "Always"

Then, because there are modifications that cannot be upgraded in place, the changes to the SidecarSet cannot take immediate effect on the pod.

I tried to reproduce with the example you provided, but I couldn't reproduce it in my environment:

• k8s 1.28
• kruise 1.6.4
• kruise feature gate: ImagePullJobGate=true

In my experiment, when I apply the SidecarSet YAML, Kruise will supplement imagePullPolicy: IfNotPresent.

apiVersion: v1
items:
- apiVersion: apps.kruise.io/v1alpha1
  kind: SidecarSet
  metadata:
    annotations:
      kruise.io/sidecarset-hash: 5d8b6x9dw69z965249484c7x924x699xd2764w4zc89z25b89xwd489c4vz4f6x9
      kruise.io/sidecarset-hash-without-image: 4zv6464d6c4bb89d2298d2w2cww65d2d5f89bd72zcxw4dbcf85f44774f6c4794
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"apps.kruise.io/v1alpha1","kind":"SidecarSet","metadata":{"annotations":{},"name":"test-sidecarset2"},"spec":{"containers":[{"command":["sleep","999d"],"image":"busybox:1.36.1","name":"sidecar1"}],"selector":{"matchLabels":{"app":"nginx"}},"updateStrategy":{"type":"HotUpgrade"}}}
    creationTimestamp: "2024-10-12T02:28:34Z"
    generation: 1
    name: test-sidecarset2
    resourceVersion: "470842"
    uid: b978f698-3484-419a-963a-85396999164f
  spec:
    containers:
    - command:
      - sleep
      - 999d
      image: busybox:1.36.1
      imagePullPolicy: IfNotPresent
      name: sidecar1
      podInjectPolicy: BeforeAppContainer
      resources: {}
      shareVolumePolicy:
        type: disabled
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      upgradeStrategy:
        upgradeType: ColdUpgrade
    injectionStrategy: {}
    revisionHistoryLimit: 10
    selector:
      matchLabels:
        app: nginx
    updateStrategy:
      maxUnavailable: 1
      partition: 0
      type: HotUpgrade
  status:
    collisionCount: 0
    latestRevision: test-sidecarset2-67d46f799d
    matchedPods: 0
    observedGeneration: 1
    readyPods: 0
    updatedPods: 0
kind: List
metadata:
  resourceVersion: ""

If this is the operation I understand, then this part of the code should not be modified; instead, imagePullPolicy should be explicitly supplemented to make users understand the specific changes they are making.

@chengjoey You can add specific version details, and I will try to reproduce it again.