KB4929 release notes and known issues

Summary

Kanister Pods Fail Image Pulls on Kubernetes 1.35 KB ID: 4929 Product: Veeam Kasten for Kubernetes Published: 2026-09-15 Last Modified: 2026-09-15 Challenge On Kubernetes 1.35 or later, Veeam Kasten for Kubernetes worker pods fail with ImagePullBackOff errors when the cluster uses a private container registry. These pods run in the application namespace and have no image pull credentials. The following operations are affected: Backup and restore of applications protected by a Kanister blueprint Backup of volumes not attached to a running workload Execution hooks whose blueprint creates a pod Generic Storage Backup operations Kanister times out after approximately 15 minutes per attempt. Cause This issue occurs because Kubernetes 1.35 enables the KubeletEnsureSecretPulledImages feature gate by default. Every pod must now present valid registry credentials to pull an image, and cached images no longer bypass authentication. Veeam Kasten for Kubernetes runs certain worker pods in the application namespace. The image pull secret (by default, k10-ecr ) exists only in the kasten-io namespace. Those worker pods have no imagePullSecrets and reference no service account credentials, so they cannot authenticate against a private registry. On Kubernetes 1.34 and earlier, cached images did not require re-authentication. This masked the missing credentials. Solution Copy the image pull secret into each protected namespace, then attach it to the default service account of that namespace. Both steps are required. A secret that exists in the namespace but is not referenced by the service account has no effect. Prerequisites kubectl access to the cluster Permission to create secrets and patch service accounts in the target namespace The name of the image pull secret used during Veeam Kasten for Kubernetes installation (default: k10-ecr ) Procedure 1. Set variables for the target namespace and secret name. If a name other than k10-ecr was provided to global.imagePullSecret during installation, replace the value accordingly: export APP_NAMESPACE = < application-namespace > export SECRET_NAME = k10-ecr Copy 2. Copy the image pull secret from the kasten-io namespace into the application namespace: kubectl get secret ${SECRET_NAME} --namespace = kasten-io --output = json \ | jq '{apiVersion, kind, metadata: {name: .metadata.name}, type, data}' \ | kubectl apply --namespace = ${APP_NAMESPACE} --filename = - Copy 3. Patch the default service account to reference the secret: kubectl patch serviceaccount default \ --namespace = ${APP_NAMESPACE} \ --patch = "{ \" imagePullSecrets \" :[{ \" name \" : \" ${SECRET_NAME} \" }]}" Copy 4. Repeat steps 1–3 for each protected application namespace. 5. Delete any Kanister pods stuck in ImagePullBackOff . Veeam Kasten for Kubernetes recreates them with the updated credentials. Important The kubectl patch command replaces the imagePullSecrets field rather than merging into it. If the default service account already lists other image pull secrets, include them in the patch value. To restore an application into a namespace that does not yet exist, create and configure that namespace before you run the restore. More Information This is a documented workaround. A product-side fix is tracked internally. Clusters that use a public registry are not affected. For more information on private registry configuration, see the Air-Gapped Installation section of the Veeam Kasten documentation. For details on the upstream Kubernetes change, see KEP-2535 ( KubeletEnsureSecretPulledImages ). If this KB article did not resolve your issue or you need further assistance with Veeam software, please create a Veeam Support Case. To submit feedback regarding this article, please click this link: Send Article Feedback To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.

Improvements and security content

• Kanister Pods Fail Image Pulls on Kubernetes 1.35 KB ID: 4929 Product: Veeam Kasten for Kubernetes Published: 2026-09-15 Last Modified: 2026-09-15 Challenge On Kubernetes 1.35 or later, Veeam Kasten for Kubernetes worker pods fail with ImagePullBackOff errors when the cluster uses a private container registry. These pods run in the application namespace and have no image pull credentials. The following operations are affected: Backup and restore of applications protected by a Kanister blueprint Backup of volumes not attached to a running workload Execution hooks whose blueprint creates a pod Generic Storage Backup operations Kanister times out after approximately 15 minutes per attempt. Cause This issue occurs because Kubernetes 1.35 enables the KubeletEnsureSecretPulledImages feature gate by default. Every pod must now present valid registry credentials to pull an image, and cached images no longer bypass authentication. Veeam Kasten for Kubernetes runs certain worker pods in the application namespace. The image pull secret (by default, k10-ecr ) exists only in the kasten-io namespace. Those worker pods have no imagePullSecrets and reference no service account credentials, so they cannot authenticate against a private registry. On Kubernetes 1.34 and earlier, cached images did not require re-authentication. This masked the missing credentials. Solution Copy the image pull secret into each protected namespace, then attach it to the default service account of that namespace. Both steps are required. A secret that exists in the namespace but is not referenced by the service account has no effect. Prerequisites kubectl access to the cluster Permission to create secrets and patch service accounts in the target namespace The name of the image pull secret used during Veeam Kasten for Kubernetes installation (default: k10-ecr ) Procedure 1. Set variables for the target namespace and secret name. If a name other than k10-ecr was provided to global.imagePullSecret during installation, replace the value accordingly: export APP_NAMESPACE = < application-namespace > export SECRET_NAME = k10-ecr Copy 2. Copy the image pull secret from the kasten-io namespace into the application namespace: kubectl get secret ${SECRET_NAME} --namespace = kasten-io --output = json \ | jq '{apiVersion, kind, metadata: {name: .metadata.name}, type, data}' \ | kubectl apply --namespace = ${APP_NAMESPACE} --filename = - Copy 3. Patch the default service account to reference the secret: kubectl patch serviceaccount default \ --namespace = ${APP_NAMESPACE} \ --patch = "{ \" imagePullSecrets \" :[{ \" name \" : \" ${SECRET_NAME} \" }]}" Copy 4. Repeat steps 1–3 for each protected application namespace. 5. Delete any Kanister pods stuck in ImagePullBackOff . Veeam Kasten for Kubernetes recreates them with the updated credentials. Important The kubectl patch command replaces the imagePullSecrets field rather than merging into it. If the default service account already lists other image pull secrets, include them in the patch value. To restore an application into a namespace that does not yet exist, create and configure that namespace before you run the restore. More Information This is a documented workaround. A product-side fix is tracked internally. Clusters that use a public registry are not affected. For more information on private registry configuration, see the Air-Gapped Installation section of the Veeam Kasten documentation. For details on the upstream Kubernetes change, see KEP-2535 ( KubeletEnsureSecretPulledImages ). If this KB article did not resolve your issue or you need further assistance with Veeam software, please create a Veeam Support Case. To submit feedback regarding this article, please click this link: Send Article Feedback To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.

Affected products and versions

Recommended action

Review the official publisher document before deployment.

Official publisher evidence