Add more picutres and improve upon the pgo Client Docs

This adds more pictures to explain the various architectures supported
by the PostgreSQL Operator, and contains a massive rewrite and reorg
of the pgo Client documentation.

Author: Jonathan S. Katz

hugo/content/Upgrade/_index.md

@@ -40,4 +40,4 @@ In this example, we are upgrading a cluster from PostgreSQL 11.5 to 11.6 using t
 
 `pgo upgrade mycluster --ccp-image-tag=centos7-11.6-4.2.0`
 
-For more information, please see the `pgo upgrade` documentation [here.] ( {{< relref "operatorcli/cli/pgo_upgrade.md" >}})
+For more information, please see the `pgo upgrade` documentation [here.] ( {{< relref "pgo-cli/reference/pgo_upgrade.md" >}})

hugo/content/advanced/direct-api-calls.md

@@ -11,7 +11,7 @@ The API can also be accessed by interacting directly with the API server. This c
 
 The most basic example of this interaction is getting the version of the API server. You can send a GET request to `$PGO_APISERVER_URL/version` and this will send back a json response including the API server version. This is important because the server version and the client version must match. If you are using `pgo` this means you must have the correct version of the client but with a direct call you can specify the client version as part of the request.
 
-The API server is setup to work with the pgo command line interface so the parameters that are passed to the server can be found by looking at the related flags. For example, the series parameter used in the `create` example below is the same as the `-e, --series` flag that is described in the [pgo cli docs](https://access.crunchydata.com/documentation/postgres-operator/4.2.0/operatorcli/cli/pgo_create_cluster/).
+The API server is setup to work with the pgo command line interface so the parameters that are passed to the server can be found by looking at the related flags. For example, the series parameter used in the `create` example below is the same as the `-e, --series` flag that is described in the [pgo cli docs](https://access.crunchydata.com/documentation/postgres-operator/4.2.0/pgo-cli/reference/pgo_create_cluster/).
 
 ###### Get API Server Version
 ```

hugo/content/architecture/disaster-recovery.md

@@ -25,7 +25,7 @@ allowing them to replay old WAL logs
 - ...and of course, allowing for one to take full, differential, and incremental
 backpus and perform full and point-in-time restores
 
-![PostgreSQL Operator pgBackRest Integration](/operator-backrest-integration.png)
+![PostgreSQL Operator pgBackRest Integration](/images/postgresql-cluster-dr-base.png)
 
 The PostgreSQL Operator leverages a pgBackRest repository to facilitate the
 usage of the pgBackRest features in a PostgreSQL cluster. When a new PostgreSQL
@@ -89,7 +89,7 @@ The PostgreSQL Operator supports the ability to perform a full restore on a
 PostgreSQL cluster as well as a point-in-time-recovery using the `pgo restore`
 command. Note that both of these options are **destructive** to the existing
 PostgreSQL cluster; to "restore" the PostgreSQL cluster to a new deployment,
-please see the [Clone](/architecture/clone/) section.
+please see the [Clone](/pgo-cli/common-tasks/#clone-a-postgresql-cluster) section.
 
 The `pgo restore` command lets you specify the point at which you want to
 restore your database using the `--pitr-target` flag with the `pgo restore`
@@ -111,13 +111,18 @@ provided for the primary instance. This may have been set with the
 - A Kubernetes Job is created that will perform a pgBackRest restore operation
 to the newly allocated PVC. This is facilitated by the `pgo-backrest-restore`
 container image.
+
+![PostgreSQL Operator Restore Step 1](/images/postgresql-cluster-restore-step-1.png)
+
 - When restore Job successfully completes, a new Deployment for the PostgreSQL
 cluster primary instance is created. A recovery is then issued to the specified
 point-in-time, or if it is a full recovery, up to the point of the latest WAL
 archive in the repository.
 - Once the PostgreSQL primary instance is available, the PostgreSQL Operator
 will take a new, full backup of the cluster.
 
+![PostgreSQL Operator Restore Step 2](/images/postgresql-cluster-restore-step-2.png)
+
 At this point, the PostgreSQL cluster has been restored. However, you will need
 to re-enable autofail if you would like your PostgreSQL cluster to be
 highly-available. You can re-enable autofail with this command:
@@ -136,18 +141,20 @@ The PostgreSQL Operator Scheduler is essentially a [cron](https://en.wikipedia.o
 server that will run jobs that it is specified. Schedule commands use the cron
 syntax to set up scheduled tasks.
 
+![PostgreSQL Operator Schedule Backups](/images/postgresql-cluster-dr-schedule.png)
+
 For example, to schedule a full backup once a day at 1am, the following command
 can be used:
 
 ```shell
-pgo create schedule hacluster --schedule="1 * * * *" \
+pgo create schedule hacluster --schedule="0 1 * * *" \
   --schedule-type=pgbackrest  --pgbackrest-backup-type=full
 ```
 
 To schedule an incremental backup once every 3 hours:
 
 ```shell
-pgo create schedule hacluster --schedule="*/3 * * * *" \
+pgo create schedule hacluster --schedule="0 */3 * * *" \
   --schedule-type=pgbackrest  --pgbackrest-backup-type=incr
 ```
 
@@ -163,7 +170,7 @@ For example, using the above example of taking a nightly full backup, you can
 specify a policy of retaining 21 backups using the following command:
 
 ```shell
-pgo create schedule hacluster --schedule="1 * * * *" \
+pgo create schedule hacluster --schedule="0 1 * * *" \
   --schedule-type=pgbackrest  --pgbackrest-backup-type=full \
   --schedule-opts="--repo1-retention-full=21"
 ```

hugo/content/architecture/high-availability.md

@@ -22,6 +22,8 @@ hardware upgrade, or other maintenance.
 
 Fortunately, the Crunchy PostgreSQL Operator is prepared for this.
 
+![PostgreSQL Operator High-Availability Overview](/images/postgresql-ha-overview.png)
+
 The Crunchy PostgreSQL Operator supports a distributed-consensus based
 high-availability (HA) system that keeps its managed PostgreSQL clusters up and
 running, even if the PostgreSQL Operator disappears. Additionally, it leverages

hugo/content/architecture/overview.md

@@ -73,7 +73,7 @@ create a high-availability PostgreSQL cluster that has a single replica,
 supports having backups in both a local storage area and Amazon S3 and has
 built-in metrics and connection pooling, similar to:
 
-![PostgreSQL HA Cluster](/images/postgresql-cluster-ha-s3.svg)
+![PostgreSQL HA Cluster](/images/postgresql-cluster-ha-s3.png)
 
 We can accomplish that with a single command:
 
@@ -165,11 +165,10 @@ accessing the Kubernetes Pods to perform given actions.
 For a detailed analysis, please see
 [Using Kubernetes Deployments for Running PostgreSQL](https://info.crunchydata.com/blog/using-kubernetes-deployments-for-running-postgresql).
 
-# More Architecture Information
+# Additional Architecture Information
 
 There is certainly a lot to unpack in the overall architecture of the Crunchy
-PostgreSQL Operator. For more information on the architectures of various
-components of the PostgreSQL Operator, read onward, or follow one of the links
-below:
-
-- [High-Availability](/architecture/high-availability)
+PostgreSQL Operator. Understanding the architecture will help you to plan
+the deployment model that is best for your environment. For more information on
+the architectures of various components of the PostgreSQL Operator, please read
+onward!

hugo/content/architecture/provisioning.md

@@ -7,7 +7,7 @@ weight: 100
 
 What happens when the Crunchy PostgreSQL Operator creates a PostgreSQL cluster?
 
-![PostgreSQL HA Cluster](/images/postgresql-cluster-ha-s3.svg)
+![PostgreSQL HA Cluster](/images/postgresql-cluster-ha-s3.png)
 
 First, an entry needs to be added to the `Pgcluster` CRD that provides the
 essential attributes for maintaining the definition of a PostgreSQL cluster.