You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit makes Cluster Roles optional within this PostgreSQL
Operator. This is specifically accomplished by introducing the
concept of namespace operating modes, which represent various modes of
operation of the Postgres Operator that dictate which namespace
capabilities are enabled (if any at all). The specific namespace mode
assigned to an Operator is determined based on the specific Cluster
Roles assigned to the postgres-operator Service Account. Therefore,
users can choose to install the Cluster Roles required for a desired
operating mode, and the Operator will automatically detect those roles
and enable or disable the proper namespace capabilities. This includes
allowing users to avoid the installation of any Cluster Roles
altogether, fully disabling namespace capabilities.
When the PostgreSQL Operator and all of its various components (i.e.
the apisever, scheduler, etc.) are run, the Kubernetes environment is
inspected to determine what cluster roles are currently assigned to the
pgo-operator Service Account (i.e. the Service Account running the Pod
the PostgreSQL Operator is running within). Based on the Cluster Roles
identified, one of the following namespace operating modes will be
enabled for the installation:
- "dynamic": Enables full dynamic namespace capabilities, in which the
Operator can create, delete and update any namespaces within the
Kubernetes cluster, while then also having the ability to create the
roles, role bindings and service accounts within those namespaces as
required for the Operator to create PG clusters. Additionally, while
in this mode the Operator can listen for namespace events (e.g.
namespace additions, updates and deletions), and then create or remove
controllers for various namespaces as those namespaces are added or
removed from the Kubernetes cluster and/or Operator install.
- "readOnly": In this mode the Operator is still able to listen for
namespace events within the Kubernetetes cluster, and then create and
run and/or remove controllers as namespaces are added, updated and
deleted. However, while in this mode the Operator is unable to create,
delete or update namespaces itself, nor can it create the RBAC it
requires in any of those namespaces to create PG clusters. Therefore,
while in a "readonly" mode namespaces must be pre-configured with the
proper RBAC, since the Operator cannot create the RBAC itself.
- "disabled": Disables namespace capabilities within the Operator
altogether. While in this mode the Operator will simply attempt to
work with the target namespaces specified during installation. If no
target namespaces are specified, then the Operator will be configured
to work within the namespace in which it is deployed. As with
"readonly", while in this mode namespaces must be pre-configured
with the proper RBAC, since the Operator cannot create the RBAC itself.
In support of this change, both the Ansible and Bash installers have
been updated to provide the user with a way of easily installing the
RBAC corresponding to each namespace operating mode. The specific
variables used to install the proper Cluster Roles and therefore enable
the desired namespace operating mode are as follows:
- Bash: PGO_NAMESPACE_MODE
- Ansible: namespace_mode
When using the above variables with either installer, the valid options
available are:
- "dynamic"
- "readonly"
- "disabled"
When any of the values are selected during installation, the proper
Cluster roles will be installed to enable the corresponding namespace
operating mode as described above. The default value for either
installer is "dynamic", which maintains the current default behavior
when installing the Operator.
And finally this commit also updates various controller logic. All
namespace informers now only listen for namespaces with the proper
"crunchydata" vendor label, as well as those labeled for the current
Operator install. Additionally, all namespace controllers how have a
resync interval of 10 minutes. Also, all controller manager functions
are now thread safe, while the Scheduler and Operator now share the
create the same type of namespace controller. Otherwise various other
controller cleanup and/or reogranization is included.
0 commit comments