Process changes to docs from: repo: EnterpriseDB/cloud-native-postgres ref: refs/tags/v1.22.10

product_docs/docs/postgres_for_kubernetes/1/applications.mdx

@@ -3,6 +3,8 @@ title: 'Connecting from an application'
 originalFilePath: 'src/applications.md'
 ---
 
+
+
 Applications are supposed to work with the services created by EDB Postgres for Kubernetes
 in the same Kubernetes cluster.
 

product_docs/docs/postgres_for_kubernetes/1/architecture.mdx

@@ -3,11 +3,10 @@ title: 'Architecture'
 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
-    considerations for PostgreSQL deployments in Kubernetes.
+
+
+This section covers the main architectural aspects you need to consider
+when deploying PostgreSQL in Kubernetes.
 
 This documentation page provides an overview of the key architectural
 considerations for implementing a robust business continuity strategy when
@@ -138,7 +137,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
+    If you are at an 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
     from a traditional bare-metal or VM based infrastructure, and the benefits

product_docs/docs/postgres_for_kubernetes/1/backup.mdx

@@ -3,6 +3,16 @@ title: 'Backup'
 originalFilePath: 'src/backup.md'
 ---
 
+
+
+!!! Important
+    With version 1.21, backup and recovery capabilities in EDB Postgres for Kubernetes
+    have sensibly changed due to the introduction of native support for
+    [Kubernetes Volume Snapshots](backup_volumesnapshot.md).
+    Up to that point, backup and recovery were available only for object
+    stores. Please carefully read this section and the [recovery](recovery.md)
+    one if you have been a user of EDB Postgres for Kubernetes 1.15 through 1.20.
+
 PostgreSQL natively provides first class backup and recovery capabilities based
 on file system level (physical) copy. These have been successfully used for
 more than 15 years in mission critical production databases, helping

product_docs/docs/postgres_for_kubernetes/1/backup_barmanobjectstore.mdx

@@ -3,6 +3,8 @@ title: 'Backup on object stores'
 originalFilePath: 'src/backup_barmanobjectstore.md'
 ---
 
+
+
 EDB Postgres for Kubernetes natively supports **online/hot backup** of PostgreSQL
 clusters through continuous physical backup and WAL archiving on an object
 store. This means that the database is always up (no downtime required)
@@ -96,7 +98,10 @@ algorithms via `barman-cloud-backup` (for backups) and
 
 -   bzip2
 -   gzip
+-   lz4
 -   snappy
+-   xz
+-   zstd
 
 The compression settings for backups and WALs are independent. See the
 [DataBackupConfiguration](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#DataBackupConfiguration) and

product_docs/docs/postgres_for_kubernetes/1/backup_recovery.mdx

@@ -3,4 +3,14 @@ title: 'Backup and Recovery'
 originalFilePath: 'src/backup_recovery.md'
 ---
 
-[Backup](backup.md) and [recovery](recovery.md) are in two separate sections.
+
+
+Until EDB Postgres for Kubernetes 1.20, this page used to contain both the backup and
+recovery phases of a PostgreSQL cluster. The reason was that EDB Postgres for Kubernetes
+supported only backup and recovery object stores.
+
+Version 1.21 introduces support for the Kubernetes `VolumeSnapshot` API,
+providing more possibilities for the end user.
+
+As a result, [backup](backup.md) and [recovery](recovery.md) are now in two
+separate sections.

product_docs/docs/postgres_for_kubernetes/1/backup_volumesnapshot.mdx

@@ -3,6 +3,8 @@ title: 'Backup on volume snapshots'
 originalFilePath: 'src/backup_volumesnapshot.md'
 ---
 
+
+
 !!! Warning
     As noted in the [backup document](backup.md), a cold snapshot explicitly
     set to target the primary will result in the primary being fenced for

product_docs/docs/postgres_for_kubernetes/1/before_you_start.mdx

@@ -3,6 +3,8 @@ title: 'Before You Start'
 originalFilePath: 'src/before_you_start.md'
 ---
 
+
+
 Before we get started, it is essential to go over some terminology that is
 specific to Kubernetes and PostgreSQL.
 

product_docs/docs/postgres_for_kubernetes/1/benchmarking.mdx

@@ -3,6 +3,8 @@ title: 'Benchmarking'
 originalFilePath: 'src/benchmarking.md'
 ---
 
+
+
 The CNP kubectl plugin provides an easy way for benchmarking a PostgreSQL deployment in Kubernetes using EDB Postgres for Kubernetes.
 
 Benchmarking is focused on two aspects:
@@ -177,7 +179,7 @@ It will:
 3.  Create a fio deployment composed by a single Pod, which will run fio on
     the PVC, create graphs after completing the benchmark and start serving the
     generated files with a webserver. We use the
-    [`fio-tools`](https://github.com/wallnerryan/fio-tools`) image for that.
+    [`fio-tools`](https://github.com/wallnerryan/fio-tools) image for that.
 
 The Pod created by the deployment will be ready when it starts serving the
 results. You can forward the port of the pod created by the deployment

product_docs/docs/postgres_for_kubernetes/1/bootstrap.mdx

@@ -3,6 +3,8 @@ title: 'Bootstrap'
 originalFilePath: 'src/bootstrap.md'
 ---
 
+
+
 !!! Note
     When referring to "PostgreSQL cluster" in this section, the same
     concepts apply to both PostgreSQL and EDB Postgres Advanced Server, unless
@@ -33,7 +35,7 @@ For more detailed information about this feature, please refer to the
     EDB Postgres for Kubernetes requires both the `postgres` user and database to
     always exist. Using the local Unix Domain Socket, it needs to connect
     as the `postgres` user to the `postgres` database via `peer` authentication in
-    order to perform administrative tasks on the cluster.
+    order to perform administrative tasks on the cluster.  
     **DO NOT DELETE** the `postgres` user or the `postgres` database!!!
 
 !!! Info
@@ -498,7 +500,23 @@ or a standby PostgreSQL server. It’s crucial to thoroughly review the
 requirements section below, as the pros and cons of PostgreSQL physical
 replication fully apply.
 
-The primary use cases for this method include:
+-   Reporting and business intelligence clusters that need to be regenerated
+    periodically (daily, weekly)
+-   Test databases containing live data that require periodic regeneration
+    (daily, weekly, monthly) and anonymization
+-   Rapid spin-up of a standalone replica cluster
+-   Physical migrations of EDB Postgres for Kubernetes clusters to different namespaces or
+    Kubernetes clusters
+
+!!! Important
+    Avoid using this method, based on physical replication, to migrate an
+    existing PostgreSQL cluster outside of Kubernetes into EDB Postgres for Kubernetes, unless you
+    are completely certain that all [requirements](#requirements) are met and
+    the operation has been
+    thoroughly tested. The EDB Postgres for Kubernetes community does not endorse this approach
+    for such use cases, and recommends using logical import instead. It is
+    exceedingly rare that all requirements for physical replication are met in a
+    way that seamlessly works with EDB Postgres for Kubernetes.
 
 -   Reporting and business intelligence clusters that need to be regenerated
     periodically (daily, weekly)
@@ -621,7 +639,7 @@ file on the source PostgreSQL instance:
 host replication streaming_replica all md5
 ```
 
-The following manifest creates a new PostgreSQL 17.4 cluster,
+The following manifest creates a new PostgreSQL 17.5 cluster,
 called `target-db`, using the `pg_basebackup` bootstrap method
 to clone an external PostgreSQL cluster defined as `source-db`
 (in the `externalClusters` array). As you can see, the `source-db`
@@ -636,7 +654,7 @@ metadata:
   name: target-db
 spec:
   instances: 3
-  imageName: quay.io/enterprisedb/postgresql:17.4
+  imageName: quay.io/enterprisedb/postgresql:17.5
 
   bootstrap:
     pg_basebackup:
@@ -656,7 +674,7 @@ spec:
 ```
 
 All the requirements must be met for the clone operation to work, including
-the same PostgreSQL version (in our case 17.4).
+the same PostgreSQL version (in our case 17.5).
 
 #### TLS certificate authentication
 
@@ -671,7 +689,7 @@ in the same Kubernetes cluster.
     This example can be easily adapted to cover an instance that resides
     outside the Kubernetes cluster.
 
-The manifest defines a new PostgreSQL 17.4 cluster called `cluster-clone-tls`,
+The manifest defines a new PostgreSQL 17.5 cluster called `cluster-clone-tls`,
 which is bootstrapped using the `pg_basebackup` method from the `cluster-example`
 external cluster. The host is identified by the read/write service
 in the same cluster, while the `streaming_replica` user is authenticated
@@ -686,7 +704,7 @@ metadata:
   name: cluster-clone-tls
 spec:
   instances: 3
-  imageName: quay.io/enterprisedb/postgresql:17.4
+  imageName: quay.io/enterprisedb/postgresql:17.5
 
   bootstrap:
     pg_basebackup:

product_docs/docs/postgres_for_kubernetes/1/certificates.mdx

@@ -3,6 +3,8 @@ title: 'Certificates'
 originalFilePath: 'src/certificates.md'
 ---
 
+
+
 EDB Postgres for Kubernetes was designed to natively support TLS certificates.
 To set up a cluster, the operator requires:
 

product_docs/docs/postgres_for_kubernetes/1/cluster_conf.mdx

@@ -3,6 +3,8 @@ title: 'Instance pod configuration'
 originalFilePath: 'src/cluster_conf.md'
 ---
 
+
+
 ## Projected volumes
 
 EDB Postgres for Kubernetes supports mounting custom files inside the Postgres pods through