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

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.
 !!!
@@ -52,6 +53,7 @@ Recovery simply relies on the operator to reconcile the cluster from an
 existing PVC group.
 
 !!!info 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
@@ -329,6 +331,7 @@ Here is a full example of YAML content to be placed in either:
     for the `external-backup-adapter-cluster` add-on
 
 !!!tip 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),
@@ -449,6 +452,7 @@ ahead replica instance to be the designated backup and will add Kasten-specific
 backup hooks through annotations and labels to that instance.
 
 !!!info 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`
@@ -514,6 +518,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.
 
 !!!info 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`
@@ -561,6 +566,7 @@ This command will create a standard Velero backup using the configured object
 storage and the configured Snapshot API.
 
 !!!info 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/appendixes/_category_.json

@@ -0,0 +1,7 @@
+{
+  "label": "Appendixes",
+  "position": 600,
+  "link": {
+    "type": "generated-index"
+  }
+}

product_docs/docs/postgres_for_kubernetes/1/applications.mdx

@@ -12,6 +12,7 @@ For more information on services and how to manage them, please refer to the
 ["Service management"](service_management.md) section.
 
 !!!tip 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.
@@ -26,6 +27,7 @@ For the credentials to connect to PostgreSQL, you can
 use the secrets generated by the operator.
 
 !!!note 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.
@@ -94,5 +96,6 @@ The `-superuser` ones are supposed to be used only for administrative purposes,
 and correspond to the `postgres` user.
 
 !!!info Important
+
 Superuser access over the network is disabled by default.
 !!!

product_docs/docs/postgres_for_kubernetes/1/architecture.mdx

@@ -6,6 +6,7 @@ originalFilePath: 'src/architecture.md'
 
 
 !!!tip 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
@@ -56,6 +57,7 @@ Replicas are usually called *standby servers* and can also be used for
 read-only workloads, thanks to the *Hot Standby* feature.
 
 !!!info Important
+
 **We recommend against storage-level replication with PostgreSQL**, although
 {{name.ln}} 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
@@ -79,6 +81,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.
 !!!
@@ -112,6 +115,7 @@ managing them via declarative configuration. This setup is ideal for disaster
 recovery (DR), read-only operations, or cross-region availability.
 
 !!!info 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
@@ -144,6 +148,7 @@ the [replica cluster feature](replica_cluster.md)).
 ![Example of a Kubernetes architecture with only 2 data centers](./images/k8s-architecture-2-az.png)
 
 !!!tip Hint
+
 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
@@ -178,6 +183,7 @@ within {{name.ln}}' scope, as the operator can only function within a single
 Kubernetes cluster.
 
 !!!info Important
+
 {{name.ln}} 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.
@@ -194,6 +200,7 @@ This approach ensures optimal performance and resource allocation for your
 database operations.
 
 !!!tip 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
@@ -208,6 +215,7 @@ taints help prevent any non-`postgres` workloads from being scheduled on that
 node.
 
 !!!info 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
@@ -289,6 +297,7 @@ Kubernetes cluster, with the following specifications:
         within the same Kubernetes cluster / region
 
 !!!info 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,
@@ -309,18 +318,21 @@ automatically updates the `-rw` service to point to the promoted primary,
 making sure that traffic from the applications is seamlessly redirected.
 
 !!!note Replication
+
 Please refer to the ["Replication" section](replication.md) for more
 information about how {{name.ln}} relies on PostgreSQL replication,
 including synchronous settings.
 !!!
 
 !!!note Connecting from an application
+
 Please refer to the ["Connecting from an application" section](applications.md) for
 information about how to connect to {{name.ln}} from a stateless
 application within the same Kubernetes cluster.
 !!!
 
 !!!note 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.
@@ -343,6 +355,7 @@ service to another instance of the cluster.
 ### Read-only workloads
 
 !!!info 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
@@ -363,6 +376,7 @@ Applications can also access any PostgreSQL instance through the
 ## Deployments across Kubernetes clusters
 
 !!!info
+
 {{name.ln}} 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.
@@ -420,13 +434,15 @@ This is typically triggered by:
     cluster by promoting the PostgreSQL replica cluster.
 
 !!!warning
+
 {{name.ln}} 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.
 !!!
 
 !!!info Important
+
 {{name.ln}} 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.
@@ -442,6 +458,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.
 
 !!!note 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