rest of edits to EDB PGD for Kubernetes

product_docs/docs/postgres_distributed_for_kubernetes/1/connectivity.mdx

@@ -140,7 +140,7 @@ using cert-manager (the recommended approach) or pre-provisioned using secrets.
 #### Dynamic provisioning via cert-manager
 
 The client certificates configuration is managed by the `.spec.connectivity.tls.clientCert.certManager`
-section of the PGDGroup custom resource.
+section of the `PGDGroup` custom resource.
 The following assumptions were made for this section to work:
 
 -   An issuer `.spec.connectivity.tls.clientCert.certManager.issuerRef` is available
@@ -171,7 +171,7 @@ service that routes the connection to the write leader of the PGD group.
 
 When connecting from inside the cluster, you can use the proxy service name to connect
 to the PGD group. The proxy service name is composed of the PGD group name and the optional
-host suffix defined in the `.spec.connectivity.dns` section of the PGDGroup custom resource.
+host suffix defined in the `.spec.connectivity.dns` section of the `PGDGroup` custom resource.
 
 For example, if the PGD group name is `my-group`, and the host suffix is `.my-domain.com`,
 the proxy service name is `my-group.my-domain.com`.

product_docs/docs/postgres_distributed_for_kubernetes/1/recovery.mdx

@@ -5,27 +5,27 @@ originalFilePath: 'src/recovery.md'
 
 In EDB Postgres Distributed for Kubernetes, recovery is available as a way
 to bootstrap a new PGD group starting from an available physical backup of a PGD node.
-The recovery can't be performed in-place on an existing PGD group.
-EDB Postgres Distributed for Kubernetes also supports point-in-time recovery, which allows you to restore a PGDGroup up to
+The recovery can't be performed in place on an existing PGD group.
+EDB Postgres Distributed for Kubernetes also supports point-in-time recovery (PITR), which allows you to restore a PGD group up to
 any point in time, from the first available backup in your catalog to the last archived
-WAL. (Having a WAL archive is mandatory in this case.)
+WAL. Having a WAL archive is mandatory in this case.
 
 ## Prerequisite
 
-Before recovering from a backup, take care to apply the following considerations:
+Before recovering from a backup:
 
 -   Make sure that the PostgreSQL configuration (`.spec.cnp.postgresql.parameters`) of the
-    recovered cluster is compatible with the original one from a physical replication standpoint, .
+    recovered cluster is compatible with the original one from a physical replication standpoint.
 
--   When recovering in a newly created namespace, remember to first set up a cert-manager CA issuer before deploying the recovered PGDGroup.
+-   When recovering in a newly created namespace, first set up a cert-manager CA issuer before deploying the recovered PGD group.
 
 For more information, see [EDB Postgres for Kubernetes recovery - Additional considerations](/postgres_for_kubernetes/latest/bootstrap/#additional-considerations) in the EDB Postgres for Kubernetes documentation.
 
 ## Recovery from an object store
 
 You can recover from a PGD node backup created by Barman Cloud and stored on supported object storage.
 
-For example, given a PGDGroup named `pgdgroup-example` with three instances with backups available, your object storage contains a directory for each node:
+For example, given a PGD group` named `pgdgroup-example` with three instances with backups available, your object storage contains a directory for each node:
 
 `pgdgroup-example-1`, `pgdgroup-example-2`, `pgdgroup-example-3`
 
@@ -62,8 +62,8 @@ spec:
 
 !!! Important
     Make sure to correctly configure the WAL section according to the source cluster.
-    In the example, since the `pgdgroup-example` PGDGroup uses `compression`
-    and `encryption`, make sure to set the proper parameters also in the PGDGroup
+    In the example, since the `pgdgroup-example` PGD group uses `compression`
+    and `encryption`, make sure to set the proper parameters also in the PGD group
     that's being created by the `restore`.
 
 !!! Note
@@ -73,12 +73,12 @@ spec:
     for this scenario and tune the value of this parameter for your environment.
     It makes a difference when you need it.
 
-## Point-in-time recovery (PITR) from an object store
+## PITR from an object store
 
 Instead of replaying all the WALs up to the latest one, after extracting a base backup, you can ask PostgreSQL to stop replaying
-WALs at any given point in time.
+WALs at any point in time.
 PostgreSQL uses this technique to achieve PITR.
-The presence of a WAL archive is mandatory.
+(The presence of a WAL archive is mandatory.)
 
 This example defines a time-base target for the recovery:
 
@@ -123,7 +123,7 @@ The `.spec.restore.recoveryTarget.backupID` option allows you to specify a base
 which to start the recovery process. By default, this value is empty.
 If you assign a value to it, the operator uses that backup as the base for the recovery. The value must be in the form of a Barman backup ID.
 
-This example recovers a new PGDGroup from a specific backupID of the
+This example recovers a new PGD group from a specific backupID of the
 `pgdgroup-backup-1` PGD node:
 
 ```yaml

product_docs/docs/postgres_distributed_for_kubernetes/1/samples.mdx

@@ -4,7 +4,7 @@ originalFilePath: 'src/samples.md'
 ---
 
 !!! Important
-    The available dxamples are for demonstration and
+    The available examples are for demonstration and
     experimentation purposes only.
 
 These examples are configuration files for setting up

product_docs/docs/postgres_distributed_for_kubernetes/1/security.mdx

@@ -14,7 +14,7 @@ analyzed at three layers: code, container, and cluster.
 
 !!! Seealso "About the 4C's Security Model"
     See [The 4C's Security Model in Kubernetes](https://www.enterprisedb.com/blog/4cs-security-model-kubernetes)
-    blog article to get a better understanding and context of the approach EDB
+    blog article for a better understanding and context of the approach EDB
     takes with security in EDB Postgres Distributed for Kubernetes.
 
 ## Code
@@ -25,8 +25,7 @@ including security problems. EDB uses a popular open-source linter for Go called
 GolangCI-Lint can run several linters on the same source code.
 
 One of these is [Golang Security Checker](https://github.com/securego/gosec), or `gosec`.
-`gosec` is a linter that scans the abstract syntactic tree of the source against a set of rules aimed at
-the discovery of well-known vulnerabilities, threats, and weaknesses hidden in
+`gosec` is a linter that scans the abstract syntactic tree of the source against a set of rules aimed at discovering well-known vulnerabilities, threats, and weaknesses hidden in
 the code. These threads include hard-coded credentials, integer overflows, SQL injections, and others.
 
 !!! Important
@@ -36,7 +35,7 @@ the code. These threads include hard-coded credentials, integer overflows, SQL i
 
 ## Container
 
-Every container image that's part of EDB Postgres Distributed for Kubernetes is automatically built by way of CI/CD pipelines following every commit.
+Every container image that's part of EDB Postgres Distributed for Kubernetes is built by way of CI/CD pipelines following every commit.
 Such images include not only those of the operator but also of the operands, specifically every supported PostgreSQL version.
 In the pipelines, images are scanned with:
 
@@ -65,16 +64,16 @@ The following guidelines and frameworks were taken into account for container-le
 ## Cluster
 
 Security at the cluster level takes into account all Kubernetes components that
-form both the control plane and the nodes, as well as the applications that run in
-the cluster (PostgreSQL included).
+form both the control plane and the nodes as well as the applications that run in
+the cluster, including PostgreSQL.
 
-### Role Based Access Control (RBAC)
+### Role-based access control (RBAC)
 
 The operator interacts with the Kubernetes API server with a dedicated service
 account called pgd-operator-controller-manager. In Kubernetes this account is installed
 by default in the `pgd-operator-system` namespace. A cluster role
 binds between this service account and the pgd-operator-controller-manager
-cluster role that defines the set of rules/resources/verbs granted to the operator.
+cluster role that defines the set of rules, resources, and verbs granted to the operator.
 
 RedHat OpenShift directly manages the operator RBAC entities by way of [Operator
 Lifecycle
@@ -105,12 +104,12 @@ namespaced resources.
 `secrets`
 : Unless you provide certificates and passwords to your data nodes,
   the operator adopts the "convention over configuration" paradigm by
-  self-provisioning random-generated passwords and TLS certificates, and by
+  self-provisioning random-generated passwords and TLS certificates and by
   storing them in secrets.
 
 `serviceaccounts`
 : The operator needs to create a service account to
-  enable the PGDGroup recovery job to retrieve the backup objects from
+  enable the `PGDGroup` recovery job to retrieve the backup objects from
   the object store where they reside.
 
 `services`
@@ -164,8 +163,8 @@ EDB Postgres Distributed for Kubernetes doesn't require privileged mode for cont
 The PostgreSQL containers run as the postgres system user. No component requires running as root.
 
 Likewise, volumes access doesn't require privileged mode or root privileges.
-Proper ermissions must be assigned by the Kubernetes platform or administrators.
-The PostgreSQL containers run with a read-only root filesystem (that is, no writable layer).
+Proper permissions must be assigned by the Kubernetes platform or administrators.
+The PostgreSQL containers run with a read-only root filesystem, that is, no writable layer.
 
 The operator explicitly sets the required security contexts.
 
@@ -180,7 +179,7 @@ and SELinux context.
     article.
 
 !!! Warning "Security context constraints and namespaces"
-    As stated by [Openshift documentation](https://docs.openshift.com/container-platform/latest/authentication/managing-security-context-constraints.html#role-based-access-to-ssc_configuring-internal-oauth),
+    As stated in the [Openshift documentation](https://docs.openshift.com/container-platform/latest/authentication/managing-security-context-constraints.html#role-based-access-to-ssc_configuring-internal-oauth),
     SCCs aren't applied in the default namespaces (`default`, `kube-system`,
     `kube-public`, `openshift-node`, `openshift-infra`, `openshift`). Don't use them
     to run pods. CNP clusters deployed in those namespaces
@@ -207,7 +206,7 @@ The current implementation of EDB Postgres Distributed for Kubernetes creates
 passwords for the postgres superuser and the database owner.
 
 As far as encryption of passwords is concerned, EDB Postgres Distributed for Kubernetes follows
-the default behavior of PostgreSQL: starting from PostgreSQL 14,
+the default behavior of PostgreSQL: starting with PostgreSQL 14,
 `password_encryption` is by default set to `scram-sha-256`. On earlier
 versions, it's set to `md5`.
 

product_docs/docs/postgres_distributed_for_kubernetes/1/ssl_connections.mdx

@@ -1,5 +1,5 @@
 ---
-title: 'Client TLS/SSL Connections'
+title: 'Client TLS/SSL connections'
 originalFilePath: 'src/ssl_connections.md'
 ---
 

product_docs/docs/postgres_distributed_for_kubernetes/1/use_cases.mdx

@@ -13,7 +13,7 @@ at the same time and need to run in a traditional environment such
 as a VM.
 
 The following is a summary of the basic considerations. See the
-[EDB Postgres for Kubernetes documentation](https://www.enterprisedb.com/docs/postgres_for_kubernetes/latest/use_cases/)
+[EDB Postgres for Kubernetes documentation](/postgres_for_kubernetes/latest/use_cases/)
 for more detail.
 
 ## Case 1: Applications inside Kubernetes
@@ -24,20 +24,20 @@ namespace inside a Kubernetes cluster.
 ![Application and Database inside Kubernetes](./images/apps-in-k8s.png)
 
 The application, normally stateless, is managed as a standard deployment,
-with multiple replicas spread over different Kubernetes node, and internally
+with multiple replicas spread over different Kubernetes nodes and internally
 exposed through a ClusterIP service.
 
 The service is exposed externally to the end user through an Ingress and the
 provider's load balancer facility by way of HTTPS.
 
 ## Case 2: Applications outside Kubernetes
 
-Another possible use case is to manage your Postgres Distributed database inside
+Another possible use case is to manage your PGD database inside
 Kubernetes while having your applications outside of it, for example, in a
-virtualized environment. In this case, Postgres Distributed is represented by an IP
+virtualized environment. In this case, PGD is represented by an IP
 address or host name and a TCP port, corresponding to the defined Ingress
 resource in Kubernetes.
 
-The application can still benefit from a TLS connection to Postgres Distributed.
+The application can still benefit from a TLS connection to PGD.
 
 ![Application outside Kubernetes](./images/apps-outside-k8s.png)

product_docs/docs/postgres_distributed_for_kubernetes/1/using_pgd.mdx

@@ -1,19 +1,19 @@
 ---
-title: 'Managing EDB Postgres Distributed databases'
+title: 'Managing EDB Postgres Distributed (PGD) databases'
 originalFilePath: 'src/using_pgd.md'
 ---
 
 As described in the [architecture document](architecture.md),
 EDB Postgres Distributed for Kubernetes is an operator created to deploy
-Postgres Distributed (PGD) databases.
+PGD databases.
 It provides an alternative over deployment with TPA, and by leveraging the
 Kubernetes ecosystem, it can offer self-healing and declarative control.
 The operator is also responsible of the backup and restore operations.
 See [Backup](backup.md).
 
 However, many of the operations and control of PGD clusters aren't
 managed by the operator.
-The pods created by EDB Postgres Distributed for Kubernetes come with
+The pods created by EDB Postgres Distributed for Kubernetes come with the
 [PGD CLI](https://www.enterprisedb.com/docs/pgd/latest/cli/) installed. You can use
 this tool, for example, to execute a switchover.
 
@@ -41,7 +41,7 @@ location-a-proxy-0     1/1     Running   0             2h
 location-a-proxy-1     1/1     Running   0             2h
 ```
 
-The proxy nodes have `proxy` in the name. Choose one and get a command
+The proxy nodes have `proxy` in the name. Choose one, and get a command
 prompt in it:
 
 ```shell
@@ -91,19 +91,19 @@ location-a-3 1403922770 location-a data ACTIVE        ACTIVE       Up     3
 
 ## Accessing the database
 
-In the [use cases](use_cases.md), you can find a discussion on using the
+In [Use cases](use_cases.md) is a discussion on using the
 database within the Kubernetes cluster versus from outside. In
 [Connectivity](connectivity.md), you can find a discussion on services,
 which is relevant for accessing the database from applications.
 
 However you implement your system, your applications must use the proxy
-service to connect to reap the benefits of Postgres Distributed and
+service to connect to reap the benefits of PGD and
 of the increased self-healing capabilities added by the EDB Postgres Distributed
 for Kubernetes operator.
 
 !!! Important
     As per the EDB Postgres for Kubernetes defaults, data nodes are
-    created with a database called `app`, owned by a user named `app`, in
+    created with a database called `app` and owned by a user named `app`, in
     contrast to the `bdrdb` database described in the EDB Postgres
     Distributed documentation. You can configure these values
     in the `cnp` section of the manifest.
@@ -121,7 +121,7 @@ kubectl exec -n my-namespace -ti location-a-1-1 -- psql
 ```
 
 In the familiar territory of psql, remember that the default
-created database is named `app` (see warning above).
+created database is named `app` (see previous warning).
 
 ```terminal
 postgres=# \c app