Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
Over the last few years, we have received several reports (#236 and #8172) from people saying that the vitess-operator does not support multiple namespaces. Meaning, the operator only works when both the operator pod and the Vitess cluster are in the same K8S namespace.
The vitess-operator, like other Kubernetes operators built with the Operator SDK, uses the built-in
WATCH_NAMESPACE
environment variable to determine which namespaces to observe and manage. According to the Operator SDK documentation (docs), this variable accepts a comma-separated list of namespaces. Note that this detail is not explicitly documented in the vitess-operator documentation or the example scripts we provide, as this behavior is inherited from how Kubernetes operators work.We know the operator already sees and manages multiple namespaces thanks to
WATCH_NAMESPACE
, the rest of the code was also written in a way where every resources inside aVitessCluster
inherit the same namespace.Changes
In order to provide more clarity and better examples to our end-users I have modified the examples we provide. They now contain all the configuration required to run with two namespaces:
default
andexample
. Wheredefault
hosts the vitess-operator pod, andexample
the entire Vitess cluster. With this change I am also changing our E2E test scripts to create theexample
namespace and use-n example
as an option tokubectl
where applicable.The changes needed to run with multiple namespaces are the following:
The
WATCH_NAMESPACE
variable that we set inoperator.yaml
has to contain a comma-separated list of all the namespaces we want to have. (code)The
Role
namedvitess-operator
now has to become aClusterRole
in order to not be namespaced and allow the operator to manage resources across the entire K8S cluster. TheServiceAccount
namedvitess-operator
also have to be binded cluster-wide, using aClusterRoleBinding
instead of aRoleBinding
.The Vitess backup subcontroller,
VitessBackupStorage
, creates its own fork of thevitess-operator
pod, into a new pod located in the same namespace as theVitessCluster
. This new operator process only runs a single reconciling loop, a simplified version of the root operator process, which will watch and manage new backups in theVitessCluster
. To achieve this, it needs API access to these resources:VitessShards
,VitessBackups
andVitessBackupsStorages
. New RBAC have to be added allowing access to these resources, along with a newServiceAccount
in the target namespace (same namespace as theVitessCluster
). The new RBAC andServiceAccount
then have to be binded using aRoleBinding
.Documentation and
vitessio/vitess
ChangesTo avoid conflict and unnecessary work, once #658 has been merged along with its two follow-up PRs: vitessio/website#1946 and vitessio/vitess#17869 - I will work on creating the follow up PRs on the documentation repository and the
vitessio/vitess
repository to reflect the changes made in this PR.Related Issues