Barman Cloud Integration Plugin Fails

[hroberg]

plugins:

name: barman-cloud.cloudnative-pg.io
isWALArchiver: true
parameters:
barmanObjectName: minio-store

When we apply the Plugin we get the following error:

{"level":"error","ts":"2026-02-10T01:27:20.782025709Z","msg":"Reconciler error","controller":"cluster","controllerGroup":"postgresql.cnpg.io","controllerKind":"Cluster","Cluster":{"name":"licloud-pg-cluster","namespace":"cnpg-system"},"namespace":"cnpg-system","name":"licloud-pg-cluster","reconcileID":"e5fe6d86-f9d8-4e81-870c-b1e36b600fdb","error":"unable to create Pod: Pod "licloud-pg-cluster-3" is invalid: spec.initContainers[1].startupProbe: Forbidden: may not be set for init containers","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).reconcileHandler\n\tpkg/mod/sigs.k8s.io/controller-runtime@v0.22.4/pkg/internal/controller/controller.go:474\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).processNextWorkItem\n\tpkg/mod/sigs.k8s.io/controller-runtime@v0.22.4/pkg/internal/controller/controller.go:421\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).Start.func1.1\n\tpkg/mod/sigs.k8s.io/controller-runtime@v0.22.4/pkg/internal/controller/controller.go:296"}

We are on:

• Kuberenetes Version v1.30.14
• Barman Plugin Version v0.11.0
• Cloud Native PG Version v1.28.1

All Resources (ServiceAccounts, ObjectStore, Cluster, Operator, etc.) are installed in the same namespace.
We are not using Istio.

Ist there any timeline on when this bug will be fixed?

[dosubot]

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

This is a known bug affecting CloudNativePG v1.26+ with the barman-cloud plugin. The operator incorrectly generates pod specs with a startupProbe on init containers, which Kubernetes forbids.

Common causes:

1. Namespace mismatch – The cluster is deployed in a different namespace than the operator/plugin. All resources must be in the same namespace.
2. Third-party webhook interference – AWS pod-identity-webhook or similar webhooks can modify init container specs.

Since you mentioned everything is in the same namespace and you're not using Istio, I'd check whether any admission webhooks in your cluster might be modifying the pod spec.

Workarounds:

• Downgrade to CloudNativePG v1.25.1, which doesn't have this regression
• Check for any mutating webhooks that might be affecting pod specs

Fix timeline: As of the latest information available, no official fix has been released yet. There's an open PR (#511) that makes startup probes configurable, but it hasn't been merged.

To reply, just mention @dosu.

---

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

   

[hroberg]

@dosu

How can we identify if mutatin webhooks cause this issue and if that is the case fix it?

Downgrading to PG v1.25.1 is not an Option since this only supports barman plugin v0.3.0 which is no longer supported.

[dosubot]

Here's how to identify if mutating webhooks are causing this issue:

1. List all mutating webhooks in your cluster:

kubectl get mutatingwebhookconfigurations

2. Inspect each webhook's configuration:

kubectl describe mutatingwebhookconfigurations <webhook-name>

Look at the namespaceSelector and objectSelector to see which namespaces/pods they target.

3. Compare the intended vs actual pod spec:
When the operator tries to create a pod, check the final spec after webhooks have applied:

kubectl get pod -n <NAMESPACE> <CLUSTER>-<N> -o yaml

Look specifically at .spec.initContainers for any startupProbe fields or missing restartPolicy settings.

4. Check operator logs for mutation indicators:
The operator logs signs of webhook mutations like:

• "the instance is using an old bootstrap container image"
• "environment variable configuration changed"

Common culprits:

• AWS pod-identity-webhook: Older versions remove restartPolicy from init containers. Check if you're on an older version and consider upgrading.
• Kyverno/image mutation policies: If you have image rewriting policies, exclude the CNPG namespace.

If you identify a problematic webhook:

• For AWS pod-identity-webhook: Upgrade to the latest version
• For Kyverno: Exclude the CNPG namespace from mutation policies
• For other webhooks: Add namespace or label selectors to exclude CNPG resources

Unfortunately, since downgrading isn't an option for you and this is a bug in the operator itself, identifying and mitigating the webhook interference may be your best path forward until an official fix is released.

To reply, just mention @dosu.

---

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