Pods restart every time the chart is deployed

[futureviperowner]

What steps did you take and what happened:
As part of integrating this module with our CI/CD pipeline, we're configuring it to do a helm deployment of the CSI driver chart every time the pipeline is run. However, I've noticed that the pods restart every single time this is done even when nothing about the configuration changes.

Is there a good reason for this? At least one of the pods can take several minutes to terminate and restart.

What did you expect to happen:
Pods should only restart if changes are required to the deployment.

Which access mode did you use to access the Azure Key Vault instance:
Service Principal

Environment:

• Secrets Store CSI Driver version: v0.0.11
• Azure Key Vault provider version: 0.0.6
• Kubernetes version: 1.16.6
• Cluster type: AKS

[aramase]

@doug-papenthien-by How are you redeploying every time in the CI? If the chart already exists and is redeployed, then the helm revision # changes every time. Since helm revision # is used as a label in all the daemonsets, k8s detects changes in the daemonset metadata and restarts all the pods.

  labels:
    app: secrets-store-csi-driver
    app.kubernetes.io/managed-by: Helm
    chart: secrets-store-csi-driver
    chartVersion: 0.0.11
    heritage: Helm
    release: csi
    revision: "2"

[futureviperowner]

We're using helm upgrade --install .... Normally, we would only run this if something about the deployment has changed in our repo. In the case of the CSI driver, we just need to make sure it's installed in the target environment before attempting our deployment. We can script something to make sure this is only done if it's not already deployed (or we're upgrading the chart version), but this seems contrary to letting helm manage it for us.

Is there a reason those labels are included in the daemonsets? If I do a helm create with helm 3 to create the skeleton of a new chart, it does not include chartVersion, heritgate, release, or revision labels.

[aramase]

@doug-papenthien-by I went through the helm best practices too and you are right. The revision and heritage are redundant information thats not required and isn't part of recommended labels by helm. We'll remove those from the helm chart as part of next releases.

[aramase]

Tracker issue - kubernetes-sigs/secrets-store-csi-driver#226

[danquah]

Any news on when version 0.0.13 of secrets-store-csi-driver is going to be released, and subsequently, when the secrets-store-csi-driver-provider-azure chart will bump its dependency on it?

[aramase]

@danquah The release was postponed to this week because of test issues. We're planning to release the new driver and helm charts this week.

[danquah]

Sounds great 😃