cluster start failed

[wht1998]

postgres cluster config
plugins:

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

when i apply it,cluster-3 dont' work
{"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"}

[dosubot]

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

This error is a known bug in CloudNativePG 1.26 and 1.27 when using the barman-cloud plugin: the operator generates an invalid pod spec by setting a startupProbe on an init container, which Kubernetes forbids and blocks pod creation—even with official manifests and no custom pod patches. There is currently no official fix as of February 2026, and the issue persists on Kubernetes 1.29+ and 1.32 for some users, though others report it resolved after upgrading Kubernetes. The bug is in the operator logic, not your configuration or manifests [details].

Workarounds that have helped some users: deploy the operator, plugin, and cluster in the same namespace; ensure all referenced ServiceAccounts, secrets, and ObjectStore resources are in the cluster's namespace; and, if using Istio, add the annotation sidecar.istio.io/inject: "false" to your cluster or pod spec to prevent Istio sidecar injection [details].

If you need a working setup immediately, using CloudNativePG 1.25.1 avoids this bug. Otherwise, keep an eye on future releases for a fix [details].

To reply, just mention @dosu.

---

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

   

[wht1998]

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

This error is a known bug in CloudNativePG 1.26 and 1.27 when using the barman-cloud plugin: the operator generates an invalid pod spec by setting a startupProbe on an init container, which Kubernetes forbids and blocks pod creation—even with official manifests and no custom pod patches. There is currently no official fix as of February 2026, and the issue persists on Kubernetes 1.29+ and 1.32 for some users, though others report it resolved after upgrading Kubernetes. The bug is in the operator logic, not your configuration or manifests [details].

Workarounds that have helped some users: deploy the operator, plugin, and cluster in the same namespace; ensure all referenced ServiceAccounts, secrets, and ObjectStore resources are in the cluster's namespace; and, if using Istio, add the annotation sidecar.istio.io/inject: "false" to your cluster or pod spec to prevent Istio sidecar injection [details].

If you need a working setup immediately, using CloudNativePG 1.25.1 avoids this bug. Otherwise, keep an eye on future releases for a fix [details].

To reply, just mention @dosu.

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

   

how resolve

[dosubot]

This is a confirmed bug in CloudNativePG 1.26 and 1.27 with the barman-cloud plugin: the operator sets a startupProbe on an init container, which Kubernetes forbids and blocks pod creation—even with official manifests and no custom pod patches. There is no official fix as of February 2026, and the bug is in the operator logic, not your configuration or manifests (source, source).

Workarounds that have helped some users:

• Deploy the operator, plugin, and cluster in the same namespace (source, source).
• Make sure all referenced ServiceAccounts, secrets, and ObjectStore resources are in the same namespace as the cluster (source).
• If using Istio, add the annotation sidecar.istio.io/inject: "false" to your cluster or pod spec (source).
• Upgrading to Kubernetes 1.29+ resolves the issue for some users, but not all (source, source).
• If you need a working setup immediately, use CloudNativePG 1.25.1 (source).

There are no configuration flags or Helm options to disable the startupProbe on initContainers. If you’re still stuck, check for mixed-version Kubernetes clusters or problematic webhooks (like an old AWS pod-identity-webhook) that might mutate the pod spec (source).

Keep an eye on future CloudNativePG releases for a permanent fix. If you share your Kubernetes version, Istio usage, and namespace layout, I can help troubleshoot further.

To reply, just mention @dosu.

---

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