|
| 1 | +--- |
| 2 | +title: "4.1.0" |
| 3 | +date: |
| 4 | +draft: false |
| 5 | +weight: 320 |
| 6 | +--- |
| 7 | + |
| 8 | +[Crunchy Data](https://www.crunchydata.com) announces the release of [PostgreSQL Operator](https://www.crunchydata.com/products/crunchy-postgresql-operator/) 4.1 on October 15, 2019. |
| 9 | + |
| 10 | +In addition to new features, such as dynamic namespace manage by the Operator and the ability to subscribe to a stream of lifecycle events that occur with PostgreSQL clusters, this release adds many new features and bug fixes. |
| 11 | + |
| 12 | +The Postgres Operator 4.1 release also includes the following software versions upgrades: |
| 13 | + |
| 14 | +- The PostgreSQL now uses versions 11.5, 10.10, 9.6.15, and 9.5.19. The PostgreSQL container now includes support for PL/Python. |
| 15 | +- pgBackRest is now 2.17 |
| 16 | +- pgMonitor now uses version 3.2 |
| 17 | + |
| 18 | +To build Postgres Operator 4.1, you will need to utilize buildah version 1.9.0 and above. |
| 19 | + |
| 20 | +Postgres Operator is tested with Kubernetes 1.13 - 1.15, OpenShift 3.11+, Google Kubernetes Engine (GKE), and VMware Enterprise PKS 1.3+. At present, Postgres Operator 4.1 is **not** compatible with Kubernetes 1.16. |
| 21 | + |
| 22 | +# Major Features |
| 23 | + |
| 24 | +## Dynamic Namespace Management |
| 25 | + |
| 26 | +Postgres Operator 4.1 introduces the ability to dynamically management Kubernetes namespaces from the Postgres Operator itself. [Kubernetes namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) provide the ability to isolate workloads within a Kubernetes cluster, which can provide additional security and privacy amongst users. |
| 27 | + |
| 28 | +The previous version of the Postgres Operator allowed users to add Kubernetes namespaces to which the Postgres Operator could deploy and manage clusters. Postgres Operator 4.1 expands on this ability by allowing the Operator to dynamically add and remove namespaces using the `pgo create namespace` and `pgo delete namespace` commands. |
| 29 | + |
| 30 | +This allows for several different deployment patterns for PostgreSQL clusters, including: |
| 31 | + |
| 32 | +- Deploying PostgreSQL clusters within a single namespace for an individual user |
| 33 | +- Deploying a PostgreSQL cluster into its own namespace |
| 34 | + |
| 35 | +Note that deleting a namespace in Kubernetes deletes all of the objects that reside within that namespace, **including active PostgreSQL clusters**. Ensure that you wish to delete everything inside a namespace before executing `pgo delete namespace`. |
| 36 | + |
| 37 | +This has also lead to a change in terms of how role-based access control (RBAC) is handled. Traditionally, RBAC permissions we added to the `ClusterRole` objects, but in order to support dynamic namespace management, the RBAC has been moved to the `Role` objects. |
| 38 | + |
| 39 | +If you would like to use the dynamic namespace feature Kubernetes 1.11 and OpenShift 3.11, you will also need to utilize the `add-targeted-namespace.sh` script that is bundled with Postgres Operator 4.1. To add a namespace to dynamically to your Postgres Operator deployment in Kubernetes 1.11, you first need to create the namespace with `kubectl` (e.g. `kubectl create namespace yournamespace`) and then run the `add-targeted-namespace.sh` script (`./add-targeted-namespace.sh yournamespace`). |
| 40 | + |
| 41 | +## Lifecycle Events |
| 42 | + |
| 43 | +Postgres Operator 4.1 now provides PostgreSQL lifecycle events that occur during the operation of a cluster. Lifecycle events include things such as when a cluster is provisioned, a replica is added, a backup is taken, a cluster fails over, etc. Each deployed PostgreSQL cluster managed by the PostgreSQL Operator will report back to the Operator around these lifecycle events via the NSQ distributed messaging platform. |
| 44 | + |
| 45 | +You can subscribe to lifecycle events by topic using the `pgo watch` command. For subscribe to all events for clusters under management, you can run `pgo watch alltopic`. Eventing can be disabled using the `DISABLE_EVENTING` environmental variable within the `postgres-operator` deployment. |
| 46 | + |
| 47 | +For more information, please read the [Eventing]({{< relref "/architecture/eventing.md" >}}) section of the documentation. |
| 48 | + |
| 49 | +# Breaking Changes |
| 50 | + |
| 51 | +## Containers |
| 52 | + |
| 53 | +- The `node_exporter` container is no longer shipped with the PostgreSQL Operator. A detailed explanation of how node-style metrics are handled is available in the "Additional Features" section. |
| 54 | + |
| 55 | +## API |
| 56 | + |
| 57 | +- The `pgo update cluster` API endpoint now uses a HTTP `POST` instead of `GET` |
| 58 | +- The user management endpoints (e.g. `pgo create user`) now use a HTTP `POST` instead of a `GET`. |
| 59 | + |
| 60 | +## Command-line interface |
| 61 | + |
| 62 | +- Removed the `-db` flag from `pgo create user` and `pgo update user` |
| 63 | +- Removed `--update-password` flag from the `pgo user` command |
| 64 | + |
| 65 | +## Installation |
| 66 | + |
| 67 | +- Changed the Ansible installer to use `uninstall` and `uninstall-metrics` tags instead of `deprovision` and `deprovision-metrics` respectively |
| 68 | + |
| 69 | +## Builds |
| 70 | + |
| 71 | +- The `Makefile` now uses `buildah` for building the containers instead of `Docker`. The PostgreSQL Operator can be built with buildah v1.9.0 and above. |
| 72 | + |
| 73 | +# Additional Features |
| 74 | + |
| 75 | +## General PostgreSQL Operator Features |
| 76 | + |
| 77 | +- PostgreSQL Operator users and roles can now be dynamically managed (i.e. `pgouser` and `pgorole`) |
| 78 | + |
| 79 | +- Readiness probes have been added to the `apiserver` and `scheduler` and is now included in the new `event` container. The `scheduler` uses a special `heartbeat` task to provide its readiness. |
| 80 | + |
| 81 | +- Added the `DISABLE_TLS` environmental variable for `apiserver`, which allows the API server to run over HTTP. |
| 82 | + |
| 83 | +- Added the `NOAUTH_ROUTES` environmental variable for `apiserver`, which allows useres to bypass TLS authentication on certain routes (e.g. `/health`). At present, only `/health` can be used in this variable. |
| 84 | + |
| 85 | +- Services ports for the postgres\_exporter and pgBadger are now templated so a user can now customize them beyond the defaults. |
| 86 | + |
| 87 | +## PostgreSQL Upgrade Management |
| 88 | + |
| 89 | +- The process to perform a minor upgrade on a PostgreSQL deployment was modified in order to minimize downtime. Now, when a `pgo upgrade cluster` command is run, the PostgreSQL Operator will upgrade all the replicas to the desired version of PostgreSQL before upgrading the primary container. If `autofail` is enabled, the PostgreSQL Operator will failover to a pod that is already updated to a newer version, which minimizes downtime and allows the cluster to upgrade to the desired, updated version of PostgreSQL. |
| 90 | + |
| 91 | +- `pgo upgrade` now supports the `--all` flag, which will upgrade every single PostgreSQL cluster managed by the PostgreSQL Operator (i.e. `pgo upgrade --all`) |
| 92 | + |
| 93 | +## PostgreSQL User Management |
| 94 | + |
| 95 | +- All user passwords are now loaded in from Kubernetes Secrets. |
| 96 | +- `pgo create user --managed` now supports any acceptable password for PostgreSQL |
| 97 | +- Improved error message for calling the equivalent `pgo show user` command when interfacing with the API directly and there are no clusters found for th euser. |
| 98 | + |
| 99 | +## Monitoring |
| 100 | + |
| 101 | +- Updated the Grafana dashboards to use those found in pgMonitor v3.2 |
| 102 | +- The `crunchy-collect` container now connects to PostgreSQL using a password that is stored in a Kubernetes secret |
| 103 | +- Introduced support for collecting host-style metrics via the cAdvisor installations that are installed and running on each Kubelet. This requires for the `ClusterRole` to have the `nodes` and `nodes/metrics` resources granted to it. |
| 104 | + |
| 105 | +## Logging |
| 106 | + |
| 107 | +- Updated logging to provide additional details of where issues occurred, including file and line number where the issue originated. |
| 108 | + |
| 109 | +## Installation |
| 110 | + |
| 111 | +- The Ansible installer `uninstall` tag now has the option of preserving portions of the previous installation |
| 112 | +- The Ansible installer supports NFS and hostpath storage options |
| 113 | +- The Ansible installer can now set the fsgroup for the `metrics` tag |
| 114 | +- The Ansible installer now has the same configuration options as the bash installer |
| 115 | +- The Ansible installer now supports a separate RBAC installation |
| 116 | +- Add a custom security context constraint (SCC) to the Ansible and bash installers that is applied to pods created by the Operator. This makes it possible to customize the control permissions for the PostgreSQL cluster pods managed by the Operator |
| 117 | + |
| 118 | +# Fixes |
| 119 | + |
| 120 | +- Fixed a bug where `testuser` was always created even if the username was modified in the `pgo.yaml` |
| 121 | +- Fixed the `--expired` flag for `pgo show user` to show the number of days until a user's password expires |
| 122 | +- Fixed the workflow for `pgo benchmark` jobs to show completion |
| 123 | +- Modify the create a cluster via a custom resource definition (CRD) to use pgBackRest |
| 124 | +- Fixed an issue with the `pgpool` label when a `pg_dump` is performed by calling the REST API |
| 125 | +- Fixed the `pgo load` example, which previous used a hardcoded namespace. This has changed with the support of dynamic namespaces. |
0 commit comments