PG4K import for v1.24.2

product_docs/docs/postgres_for_kubernetes/1/addons.mdx

@@ -11,6 +11,7 @@ per-cluster basis. These add-ons are:
 3.  [Velero](#velero)
 
 !!! Info
+
     If you are planning to use Velero in OpenShift, please refer to the
     [OADP section](openshift.md#oadp-for-velero) in the Openshift documentation.
 
@@ -51,6 +52,7 @@ Recovery simply relies on the operator to reconcile the cluster from an
 existing PVC group.
 
 !!! Important
+
     The External Backup Adapter is not a tool to perform backups. It simply
     provides a generic interface that any third-party backup tool in the Kubernetes
     space can use. Such tools are responsible for safely storing the PVC
@@ -327,6 +329,7 @@ Here is a full example of YAML content to be placed in either:
     for the `external-backup-adapter-cluster` add-on
 
 !!! Hint
+
     Copy the content below and paste it inside the `ConfigMap` or `Secret` that
     you use to configure the operator or the annotation in the `Cluster`, making
     sure you use the `|` character that [YAML reserves for literals](https://yaml.org/spec/1.2.2/#812-literal-style),
@@ -446,6 +449,7 @@ ahead replica instance to be the designated backup and will add Kasten-specific
 backup hooks through annotations and labels to that instance.
 
 !!! Important
+
     The operator will refuse to shut down a primary instance to take a cold
     backup unless the Cluster is annotated with
     `k8s.enterprisedb.io/snapshotAllowColdBackupOnPrimary: enabled`
@@ -510,6 +514,7 @@ These [annotations](https://velero.io/docs/latest/backup-hooks/) are used by
 Velero to run the commands to prepare the Postgres instance to be backed up.
 
 !!! Important
+
     The operator will refuse to shut down a primary instance to take a cold
     backup unless the Cluster is annotated with
     `k8s.enterprisedb.io/snapshotAllowColdBackupOnPrimary: enabled`
@@ -556,6 +561,7 @@ This command will create a standard Velero backup using the configured object
 storage and the configured Snapshot API.
 
 !!! Important
+
     By default, the Velero add-on exclude only a few resources from the backup
     operation, namely pods and PVCs of the instances that have not been selected
     (as you recall, the operator tries to backup the PVCs of the first replica).

product_docs/docs/postgres_for_kubernetes/1/applications.mdx

@@ -10,6 +10,7 @@ For more information on services and how to manage them, please refer to the
 ["Service management"](service_management.md) section.
 
 !!! Hint
+
     It is highly recommended using those services in your applications,
     and avoiding connecting directly to a specific PostgreSQL instance, as the latter
     can change during the cluster lifetime.
@@ -23,6 +24,7 @@ For the credentials to connect to PostgreSQL, you can
 use the secrets generated by the operator.
 
 !!! Seealso "Connection Pooling"
+
     Please refer to the ["Connection Pooling" section](connection_pooling.md) for
     information about how to take advantage of PgBouncer as a connection pooler,
     and create an access layer between your applications and the PostgreSQL clusters.
@@ -83,4 +85,5 @@ The `-superuser` ones are supposed to be used only for administrative purposes,
 and correspond to the `postgres` user.
 
 !!! Important
+
     Superuser access over the network is disabled by default.

product_docs/docs/postgres_for_kubernetes/1/architecture.mdx

@@ -4,6 +4,7 @@ originalFilePath: 'src/architecture.md'
 ---
 
 !!! Hint
+
     For a deeper understanding, we recommend reading our article on the CNCF
     blog post titled ["Recommended Architectures for PostgreSQL in Kubernetes"](https://www.cncf.io/blog/2023/09/29/recommended-architectures-for-postgresql-in-kubernetes/),
     which provides valuable insights into best practices and design
@@ -53,6 +54,7 @@ Replicas are usually called *standby servers* and can also be used for
 read-only workloads, thanks to the *Hot Standby* feature.
 
 !!! Important
+
     **We recommend against storage-level replication with PostgreSQL**, although
     EDB Postgres for Kubernetes allows you to adopt that strategy. For more information, please refer
     to the talk given by Chris Milsted and Gabriele Bartolini at KubeCon NA 2022 entitled
@@ -75,6 +77,7 @@ This means that **each data center is active at any time** and can run workloads
 simultaneously.
 
 !!! Note
+
     Most of the public Cloud Providers' managed Kubernetes services already
     provide 3 or more availability zones in each region.
 
@@ -107,6 +110,7 @@ managing them via declarative configuration. This setup is ideal for disaster
 recovery (DR), read-only operations, or cross-region availability.
 
 !!! Important
+
     Each operator deployment can only manage operations within its local
     Kubernetes cluster. For operations across Kubernetes clusters, such as
     controlled switchover or unexpected failover, coordination must be handled
@@ -138,6 +142,7 @@ the [replica cluster feature](replica_cluster.md)).
 ![Example of a Kubernetes architecture with only 2 data centers](./images/k8s-architecture-2-az.png)
 
 !!! Hint
+
     If you are at en early stage of your Kubernetes journey, please share this
     document with your infrastructure team. The two data centers setup might
     be simply the result of a "lift-and-shift" transition to Kubernetes
@@ -171,6 +176,7 @@ within EDB Postgres for Kubernetes' scope, as the operator can only function wit
 Kubernetes cluster.
 
 !!! Important
+
     EDB Postgres for Kubernetes provides all the necessary primitives and probes to
     coordinate PostgreSQL active/passive topologies across different Kubernetes
     clusters through a higher-level operator or management tool.
@@ -186,6 +192,7 @@ This approach ensures optimal performance and resource allocation for your
 database operations.
 
 !!! Hint
+
     As a general rule of thumb, deploy Postgres nodes in multiples of
     three—ideally with one node per availability zone. Three nodes is
     an optimal number because it ensures that a PostgreSQL cluster with three
@@ -199,6 +206,7 @@ taints help prevent any non-`postgres` workloads from being scheduled on that
 node.
 
 !!! Important
+
     This methodology is the most straightforward way to ensure that PostgreSQL
     workloads are isolated from other workloads in terms of both computing
     resources and, when using locally attached disks, storage. While different
@@ -279,6 +287,7 @@ Kubernetes cluster, with the following specifications:
         within the same Kubernetes cluster / region
 
 !!! Important
+
     You can configure the above services through the `managed.services` section
     in the `Cluster` configuration. This can be done by reducing the number of
     services and selecting the type (default is `ClusterIP`). For more details,
@@ -298,16 +307,19 @@ automatically updates the `-rw` service to point to the promoted primary,
 making sure that traffic from the applications is seamlessly redirected.
 
 !!! Seealso "Replication"
+
     Please refer to the ["Replication" section](replication.md) for more
     information about how EDB Postgres for Kubernetes relies on PostgreSQL replication,
     including synchronous settings.
 
 !!! Seealso "Connecting from an application"
+
     Please refer to the ["Connecting from an application" section](applications.md) for
     information about how to connect to EDB Postgres for Kubernetes from a stateless
     application within the same Kubernetes cluster.
 
 !!! Seealso "Connection Pooling"
+
     Please refer to the ["Connection Pooling" section](connection_pooling.md) for
     information about how to take advantage of PgBouncer as a connection pooler,
     and create an access layer between your applications and the PostgreSQL clusters.
@@ -329,6 +341,7 @@ service to another instance of the cluster.
 ### Read-only workloads
 
 !!! Important
+
     Applications must be aware of the limitations that
     [Hot Standby](https://www.postgresql.org/docs/current/hot-standby.html)
     presents and familiar with the way PostgreSQL operates when dealing with
@@ -348,6 +361,7 @@ Applications can also access any PostgreSQL instance through the
 ## Deployments across Kubernetes clusters
 
 !!! Info
+
     EDB Postgres for Kubernetes supports deploying PostgreSQL across multiple Kubernetes
     clusters through a feature that allows you to define a distributed PostgreSQL
     topology using replica clusters, as described in this section.
@@ -403,12 +417,14 @@ This is typically triggered by:
     cluster by promoting the PostgreSQL replica cluster.
 
 !!! Warning
+
     EDB Postgres for Kubernetes cannot perform any cross-cluster automated failover, as it
     does not have authority beyond a single Kubernetes cluster. Such operations
     must be performed manually or delegated to a multi-cluster/federated
     cluster-aware authority.
 
 !!! Important
+
     EDB Postgres for Kubernetes allows you to control the distributed topology via
     declarative configuration, enabling you to automate these procedures as part of
     your Infrastructure as Code (IaC) process, including GitOps.
@@ -422,6 +438,7 @@ You can also define replica clusters with a lower number of replicas, and then
 increase this number when the cluster is promoted to primary.
 
 !!! Seealso "Replica clusters"
+
     Please refer to the ["Replica Clusters" section](replica_cluster.md) for
     more detailed information on how physical replica clusters operate and how to
     define a distributed topology with read-only clusters across different

product_docs/docs/postgres_for_kubernetes/1/backup.mdx

@@ -10,6 +10,7 @@ organizations all over the world achieve their disaster recovery goals with
 Postgres.
 
 !!! Note
+
     There's another way to backup databases in PostgreSQL, through the
     `pg_dump` utility - which relies on logical backups instead of physical ones.
     However, logical backups are not suitable for business continuity use cases
@@ -35,11 +36,13 @@ On the other hand, EDB Postgres for Kubernetes supports two ways to store physic
     the underlying storage class
 
 !!! Important
+
     Before choosing your backup strategy with EDB Postgres for Kubernetes, it is important that
     you take some time to familiarize with some basic concepts, like WAL archive,
     hot and cold backups.
 
 !!! Important
+
     Please refer to the official Kubernetes documentation for a list of all
     the supported [Container Storage Interface (CSI) drivers](https://kubernetes-csi.github.io/docs/drivers.html)
     that provide snapshotting capabilities.
@@ -56,6 +59,7 @@ is fundamental for the following reasons:
     time from the first available base backup in your system
 
 !!! Warning
+
     WAL archive alone is useless. Without a physical base backup, you cannot
     restore a PostgreSQL cluster.
 
@@ -72,6 +76,7 @@ When you [configure a WAL archive](wal_archiving.md), EDB Postgres for Kubernete
 out-of-the-box an RPO <= 5 minutes for disaster recovery, even across regions.
 
 !!! Important
+
     Our recommendation is to always setup the WAL archive in production.
     There are known use cases - normally involving staging and development
     environments - where none of the above benefits are needed and the WAL
@@ -157,6 +162,7 @@ Scheduled backups are the recommended way to configure your backup strategy in
 EDB Postgres for Kubernetes. They are managed by the `ScheduledBackup` resource.
 
 !!! Info
+
     Please refer to [`ScheduledBackupSpec`](pg4k.v1.md#postgresql-k8s-enterprisedb-io-v1-ScheduledBackupSpec)
     in the API reference for a full list of options.
 
@@ -165,6 +171,7 @@ which includes seconds, as expressed in
 the [Go `cron` package format](https://pkg.go.dev/github.com/robfig/cron#hdr-CRON_Expression_Format).
 
 !!! Warning
+
     Beware that this format accepts also the `seconds` field, and it is
     different from the `crontab` format in Unix/Linux systems.
 
@@ -190,6 +197,7 @@ In Kubernetes CronJobs, the equivalent expression is `0 0 * * *` because seconds
 are not included.
 
 !!! Hint
+
     Backup frequency might impact your recovery time object (RTO) after a
     disaster which requires a full or Point-In-Time recovery operation. Our
     advice is that you regularly test your backups by recovering them, and then
@@ -217,6 +225,7 @@ In case you want to issue a backup as soon as the ScheduledBackup resource is cr
 you can set `.spec.immediate: true`.
 
 !!! Note
+
     `.spec.backupOwnerReference` indicates which ownerReference should be put inside
     the created backup resources.
 
@@ -227,6 +236,7 @@ you can set `.spec.immediate: true`.
 ## On-demand backups
 
 !!! Info
+
     Please refer to [`BackupSpec`](pg4k.v1.md#postgresql-k8s-enterprisedb-io-v1-BackupSpec)
     in the API reference for a full list of options.
 
@@ -302,6 +312,7 @@ Events:         <none>
 ```
 
 !!!Important
+
     This feature will not backup the secrets for the superuser and the
     application user. The secrets are supposed to be backed up as part of
     the standard backup procedures for the Kubernetes cluster.
@@ -321,6 +332,7 @@ By default, backups will run on the most aligned replica of a `Cluster`. If
 no replicas are available, backups will run on the primary instance.
 
 !!! Info
+
     Although the standby might not always be up to date with the primary,
     in the time continuum from the first available backup to the last
     archived WAL this is normally irrelevant. The base backup indeed
@@ -345,6 +357,7 @@ spec:
 ```
 
 !!! Warning
+
     Beware of setting the target to primary when performing a cold backup
     with volume snapshots, as this will shut down the primary for
     the time needed to take the snapshot, impacting write operations.

product_docs/docs/postgres_for_kubernetes/1/backup_barmanobjectstore.mdx

@@ -24,6 +24,7 @@ as it is composed of a community PostgreSQL image and the latest
 `barman-cli-cloud` package.
 
 !!! Important
+
     Always ensure that you are running the latest version of the operands
     in your system to take advantage of the improvements introduced in
     Barman cloud (as well as improve the security aspects of your cluster).
@@ -46,6 +47,7 @@ provider, please refer to [Appendix A - Common object stores](object_stores.md).
 ## Retention policies
 
 !!! Important
+
     Retention policies are not currently available on volume snapshots.
 
 EDB Postgres for Kubernetes can manage the automated deletion of backup files from
@@ -77,6 +79,7 @@ spec:
 ```
 
 !!! Note "There's more ..."
+
     The **recovery window retention policy** is focused on the concept of
     *Point of Recoverability* (`PoR`), a moving point in time determined by
     `current time - recovery window`. The *first valid backup* is the first
@@ -99,9 +102,9 @@ algorithms via `barman-cloud-backup` (for backups) and
 -   snappy
 
 The compression settings for backups and WALs are independent. See the
-[DataBackupConfiguration](pg4k.v1.md#postgresql-k8s-enterprisedb-io-v1-DataBackupConfiguration) and
-[WALBackupConfiguration](pg4k.v1.md#postgresql-k8s-enterprisedb-io-v1-WalBackupConfiguration) sections in
-the API reference.
+[DataBackupConfiguration](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#DataBackupConfiguration) and
+[WALBackupConfiguration](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#WalBackupConfiguration) sections in
+the barman-cloud API reference.
 
 It is important to note that archival time, restore time, and size change
 between the algorithms, so the compression algorithm should be chosen according