:_mod-docs-content-type: CONCEPT

// Module included in the following assemblies:
//
// deploying/assembly_deploy-tasks-prep.adoc

[id='con-deploy-operator-best-practices-{context}']
= Planning your Cluster Operator deployment

[role="_abstract"]
To support a stable and reliable Strimzi deployment, follow the best practices in this section. 
Run a single Cluster Operator per Kubernetes cluster, choose an appropriate watch strategy, and isolate components within watched namespaces to reduce the risk of conflicts and unexpected behavior.

== Avoiding deployment conflicts 

[role="_abstract"]
A single operator is capable of managing multiple Kafka clusters across different namespaces. 
Deploying multiple instances of the Cluster Operator, particularly with different versions, introduces the following risks: 

Resource conflicts:: 
Conflicts over cluster-scoped resources like Custom Resource Definitions (CRDs) and ClusterRoles, leading to unpredictable behavior.
This conflict occurs even when the operators are deployed in separate namespaces.
Version incompatibility:: Different operator versions can create compatibility issues with the Kafka clusters they manage. 
New Strimzi releases may introduce features, bug fixes, or other changes that are not backward-compatible. 

.Approach to avoid risks
 
To avoid these risks, the recommended approach to deploying the Cluster Operator is as follows:

Run a single Cluster Operator::
Deploy only one Cluster Operator per Kubernetes cluster. 
Consider a dedicated namespace::
Install the Cluster Operator in its own namespace, separate from the Kafka components it manages.
This separation is most useful when the operator is configured to watch multiple namespaces, but it can also help prevent uncontrolled growth of resources in a single namespace.
Keep everything updated::
Regularly update Strimzi and the version of Kafka it manages so that you have the latest features, bug fixes, and enhancements.

== Choosing namespace watch options

[role="_abstract"]
You configure the Cluster Operator to watch for changes to xref:con-operators-namespaces-{context}[Kafka resources] in specific namespaces. 

You can configure the operator to watch:

* xref:deploying-cluster-operator-{context}[A single selected namespace]
* xref:deploying-cluster-operator-to-watch-multiple-namespaces-{context}[A specific list of multiple namespaces]
* xref:deploying-cluster-operator-to-watch-whole-cluster-{context}[All namespaces in the cluster]

Choosing to watch a specific list of multiple namespaces can have the biggest impact on performance due to increased processing overhead. 
To optimize performance, the recommended modes are to either watch a single namespace for focused monitoring or all namespaces for a comprehensive view of the entire cluster.

== Isolating components in watched namespaces

After deploying the Cluster Operator, it begins watching specified namespaces for changes to Kafka resources. 
To reduce risks and maintain reliability, isolate component types within each watched namespace. 
Each namespace should contain only one instance of a given component type, such as one Kafka cluster, to avoid the following types of issues:

* Conflicting resource names
* Ambiguity in access management
* Topic and user name collisions
* Unpredictable behavior during upgrades or recovery