Project: CloudNativePG (App Definition and Development / Database)
File: README.md

](https://landscape.cncf.io/?item=app-definition-and-development--database--cloudnativepg) ][latest-release] ][license] ][documentation] ][stackoverflow] CloudNativePG is a comprehensive open source platform designed to seamlessly manage databases within Kubernetes environments, covering the entire operational lifecycle from initial deployment to ongoing maintenance. The main component is the CloudNativePG operator. CloudNativePG was originally built and sponsored by . The best way to get started is with the section in the documentation. The goal of CloudNativePG is to increase the adoption of PostgreSQL, one of the most loved DBMS in traditional VM and bare metal environments, inside Kubernetes, thus making the database an integral part of the development process and GitOps CI/CD automated pipelines. CloudNativePG has been designed by Postgres experts with Kubernetes administrators in mind. Put simply, it leverages Kubernetes by extending its controller and by defining, in a programmatic way, all the actions that a good DBA would normally do when managing a highly available PostgreSQL database cluster. Since the inception, our philosophy has been to adopt a Kubernetes native approach to PostgreSQL cluster management, making incremental decisions that would answer the fundamental question: "What would a Kubernetes user expect from a Postgres operator?". The most important decision we made is to have the status of a PostgreSQL cluster directly available in the `Cluster` resource, so to inspect it through the Kubernetes API. We've fully embraced the operator pattern and eventual consistency, two of the core principles upon which Kubernetes is built for managing complex applications. As a result, the operator is responsible for managing the status of the `Cluster` resource, keeping it up to date with the information that each PostgreSQL instance manager regularly reports back through the API server. Changes to the cluster status might trigger, for example, actions like: a PostgreSQL failover where, after an unexpected failure of a cluster's primary instance, the operator itself elects the new primary, updates the status, and directly coordinates the operation through the reconciliation loop, by relying on the instance managers scaling up or down the number of read-only replicas, based on a positive or negative variation in the number of desired instances in the cluster, so that the operator creates or removes the required resources to run PostgreSQL, such as persistent volumes, persistent volume claims, pods, secrets, config maps, and then coordinates cloning and streaming replication tasks updates of the endpoints of the PostgreSQL services that applications rely on to interact with the database, as Kubernetes represents the single source of truth and authority updates of container images in a rolling fashion, following a change in the image name, by first updating the pods where replicas are running, and then the primary, issuing a switchover first The latter example is based on another pillar of CloudNativePG: immutable application containers - as explained in the . The above list can be

However, the gist is that CloudNativePG exclusively relies on the Kubernetes API server and the instance manager to coordinate the complex operations that need to take place in a business continuity PostgreSQL cluster, without requiring any assistance from an intermediate management tool responsible for high availability and failover management like similar open source operators. CloudNativePG also manages additional resources to help the `Cluster` resource manage PostgreSQL - currently `Backup`, `ClusterImageCatalog`, `ImageCatalog`, `Pooler`, and `ScheduledBackup`. Fully embracing Kubernetes means adopting a hands-off approach during temporary failures of the Kubernetes API server. In such instances, the operator refrains from taking action, deferring decisions until the API server is operational again. Meanwhile, Postgres instances persist, maintaining operations based on the latest known state of the cluster. CloudNativePG is exclusively focused on the PostgreSQL database management system maintained by the PostgreSQL Global Development Group (PGDG). We are not currently considering adding to CloudNativePG extensions or capabilities that are included in forks of the PostgreSQL database management system, unless in the form of extensible or pluggable frameworks. CloudNativePG doesn't intend to pursue database independence (e.g. control a MariaDB cluster). A list of publicly known users of the CloudNativePG operator is in . Help us grow our community and CloudNativePG by adding yourself and your organization to this list! March 21 2024, KubeCon Europe 2024 in Paris: (Gari Singh, Google & Gabriele Bartolini, EDB) March 19 2024, Data on Kubernetes Day at KubeCon Europe 2024 in Paris: (Gabriele Bartolini, EDB) 7 November 2023, KubeCon North America 2023 in Chicago: (Michelle Au, Google & Gabriele Bartolini, EDB) 27 October 2022, KubeCon North America 2022 in Detroit: (Chris Milsted, Ondat & Gabriele Bartolini, EDB) (March 2024) (February 2024) (September 2023) (August 2023) (December 2022) (May 2022) (April 2021) (June 2020) ](https://star-history.com/#cloudnative-pg/cloudnative-pg&Date) are trademarks or registered trademarks of the PostgreSQL Community Association of Canada, and used with their permission.* th (d for short) The type of test to run. Default value is `main`, available values are: push main pull_request schedule feature_type (type or ft for short) The label for the end-to-end test to be run, empty value means all labels. Default value is empty, available type are: log_level (ll for short) Defines the log value for cloudNativePG operator, which will be specified as the value for `--log-value` in the operator command. Default value is info and available values are: `error, warning, info, debug, trace` build_plugin (plugin or bp for short) Whether to run the build cnpg plugin job in the end-to-end test. Available values are true and false and default value is false. Example: Trigger an e2e test to run all test cases with `highest` test level, we want to cover most Kubernetes and Postgres metrics ``` /test -tl=0 d=schedule ``` Run smoke and upgrade test for the pull request ``` /test type=smoke,upgrade ``` In order to enable testing of Kubernetes volume snapshots on a local Kind Cluster, we are installing the `csi-hostpath-sc` storage class and the `csi-hostpath-snapclass` volume snapshot class.