plugin-barman-cloud fails with Istio sidecar injection enabled

[is-zwozniak]

Description

When using CloudNativePG with the plugin-barman-cloud.cloudnative-pg.io plugin in a namespace where Istio sidecar injection is enabled, the operator fails to create Pods.

Environment

CNPG version: 1.26.1
Kubernetes version: v1.29.14
Istio version: 1.18.2

Steps to reproduce

1. Create a namespace with Istio injection enabled
2. Deploy CNPG Cluster with plugin-barman-cloud enabled
3. Observe the operator logs and Pod creation

Actual result

Pods cannot be created. Operator logs show:

{"level":"info","ts":"2025-09-11T11:10:20.313679675Z","msg":"Creating new Pod to reattach a PVC","controller":"cluster","controllerGroup":"postgresql.cnpg.io","controllerKind":"Cluster","Cluster":{"name":"pg-cluster-test2","namespace":"test2"},"namespace":"test2","name":"pg-cluster-test2","reconcileID":"6bb22819-9916-4040-b8b6-e5e408e0db7a","pod":"pg-cluster-test2-1","pvc":"pg-cluster-test2-1"}                                                                                                                                                                                                                                                                           
{"level":"error","ts":"2025-09-11T11:10:20.381608713Z","msg":"Reconciler error","controller":"cluster","controllerGroup":"postgresql.cnpg.io","controllerKind":"Cluster","Cluster":{"name":"pg-cluster-test2","namespace":"test2"},"namespace":"test2","name":"pg-cluster-test2","reconcileID":"6bb22819-9916-4040-b8b6-e5e408e0db7a","error":"unable to create Pod: Pod \"pg-cluster-test2-1\" is invalid: spec.initContainers[2].startupProbe: Forbidden: may not be set for init containers without restartPolicy=Always","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).reconcileHandler\n\tpkg/mod/sigs.k8s.io/controller-runtime@v0.21.0/pkg/internal/controller/controller.go:353\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).processNextWorkItem\n\tpkg/mod/sigs.k8s.io/controller-runtime@v0.21.0/pkg/internal/controller/controller.go:300\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).Start.func2.1\n\tpkg/mod/sigs.k8s.io/controller-runtime@v0.21.0/pkg/internal/controller/controller.go:202"}

Expected result

Pods should be created successfully,
WAL archiver / backup plugin should work correctly,
Istio injection should either be compatible or possible to disable only for backup/archiver Pods.

[dosubot]

Hi @is-zwozniak! I'm Dosu and I’m helping the plugin-barman-cloud team.

This is a known issue with CloudNativePG 1.26.x and the plugin-barman-cloud: Kubernetes forbids setting a startupProbe on initContainers unless restartPolicy=Always, which is not supported for init containers. The operator sometimes generates pod specs that violate this, and Istio sidecar injection (or any mutating webhook) can make the problem worse by further mutating the pod spec, leading to pod creation failures reference.

There is no built-in support in CloudNativePG or plugin-barman-cloud to automatically disable Istio injection for backup/archiver pods. The only reliable workaround is to manually add the annotation sidecar.istio.io/inject: "false" to the relevant pod specs. You can do this by specifying pod annotations in your cluster or backup configuration, leveraging CloudNativePG's extensible annotation system reference.

Also, make sure the operator, plugin, and cluster are all deployed in the same namespace—namespace mismatches are a common cause of pod creation failures with the plugin reference.

There are no configuration flags or Helm options to disable the startupProbe on initContainers, and no recent releases have addressed this specific compatibility issue with Istio as of September 2025. Keep an eye on the release notes for future fixes reference.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[calizarr]

@dosu
It should not be necessary to have the controller and plugin in the same namespace as the cluster itself. They should be able to be deployed in any of the namespaces across k8s as long as RBAC is configured properly.