[QUESTION] How is the plugin expected to work on Kubernetes <1.28?

[belo4ya]

The README currently states that the plugin supports k8s 1.11+. I am trying to understand how this is expected to work on k8s versions older than 1.28.

From the current implementation, the plugin injects the WAL-G instance process as an init container with restartPolicy: Always. This relies on Kubernetes native sidecar containers, which were introduced in k8s 1.28. This means that on k8s <1.28 this field is not supported.

I saw the previous discussion in #34 and the fix in #35, where the following parameter was added:

sidecarRestartPolicy: unset

As I understand it, this allows the plugin to avoid setting restartPolicy: Always, so the Pod can pass k8s API validation on clusters without native sidecar support. However, I do not understand how this is supposed to work at runtime.

If restartPolicy is not set, the plugin-wal-g container still remains in .spec.initContainers, but now behaves as a traditional init container. The WAL-G plugin instance process is a long-running process that provides the CNPG-I Unix socket. This means:

• if the init container keeps running, the main Postgres container will never start
• if the init container exits, the CNPG-I server stops working
• CNPG expects the plugin socket to be available when the instance manager starts and the WAL archiver plugin is enabled

So my question is: how is this expected to be used on k8s <1.28? Is there a working configuration for such clusters, or is the actual requirement k8s 1.28+?

My current assumption is that, with the current architecture, the plugin cannot really work on k8s <1.28.

Possible compatibility work

At first glance, it may seem that support for older k8s versions could be restored by switching from native sidecars to the old sidecar pattern: a regular container in .spec.containers. However, a regular app-container sidecar does not provide the same startup ordering guarantees. It may start in parallel with the Postgres container, so the CNPG instance manager may start before the plugin socket is ready.

Because of that, supporting k8s without native sidecars would likely require larger changes, not just moving the container from initContainers to containers. For example, CNPG and/or the plugin would need an explicit startup/discovery contract: waiting for the plugin socket, retrying plugin discovery, or some other way to coordinate sidecar readiness before treating the WAL archiver plugin as missing. This makes the compatibility work significantly more complex.

Suggested direction

Maybe the project should focus on currently supported Kubernetes/CNPG versions and document a narrower support matrix. For example:

• Kubernetes 1.28+ (1.28 via feature gate, and 1.29+ by default)
• CloudNativePG 1.27+ (where the cnpg-i plugin interface became mature enough for this use case)

If k8s <1.28 is not intended to be supported, it may also make sense to remove or deprecate the sidecarRestartPolicy: unset configuration added in #34/#35, because it appears to avoid the validation error but does not provide a working runtime model for the plugin.