search

tigera / operator

Kubernetes operator for installing Calico and Calico Enterprise
Apache License 2.0
186 stars 140 forks source link

Allow defining API Server and Operator installation namespace #1759

Open difrost opened 2 years ago

difrost commented 2 years ago

Expected Behavior

One can define target deployment namespace via Operators chart values.yaml.

Current Behavior

Currently namespace seem to be hardcoded to calico-apiserver and the only way to install it into different namespace is to exclude it from operator management and install separately from tweaked manifest.

Same applies to Operator - charts must be tweaked in order to force installation into namespace other than tigera-operator.

Possible Solution

Utilise the ApiServerSpec to handle installation location (and possibly all related params like resource limits).

Respect helm defined namespace in Operator templates.

Context

In environments with strict naming convention one must be able to specify target namespace for the API Server and Operator deployment.

Your Environment

tmjd commented 2 years ago

The operator is an opinionated install and I don't expect that we will add allow specifying the namespaces the operator deploys to. There is already this issue https://github.com/projectcalico/calico/issues/4812 on updating the helm chart to deploy to different namespaces, it is on the repo that the helm chart is created from. @caseydavenport do you agree that we won't be adding configuration to specify namespaces that the operator deploys components to? At least not without a compelling use case on why the current namespaces can't be used.

caseydavenport commented 2 years ago

Utilise the ApiServerSpec to handle installation location (and possibly all related params like resource limits).

I'm not aware of a compelling reason to enable this, but if you could explain your situation with a bit more detail it might help me understand why you need this.

Respect helm defined namespace in Operator templates.

I understand this one, and personally would like to see us do it. I haven't had time yet to dig in and fully come up with a plan for how that might work, though. It's not currently a super high priority for us.

difrost commented 2 years ago

Sorry I was pulled in into other tasks... let me describe why I personally need this.

We are building multi tenant clusters and need a clear segregation of who owns what. The boundaries are set based on the namespace, precisely naming patterns. That said all *-system namespaces are considered a platform components and managed by single team.

I can contribute with necessary changes. For now the only quotation I've got: Is there a requirement for operator to run in defined namespace? If not I'll try to make it customizable.

caseydavenport commented 2 years ago

Naively I would consider Calico to be a platform component, but I understand if organizationally the team running Calico is separate from the platform team.

There is no technical requirement that the operator run in a pre-defined namespace, but there is an organizational one from our side. Namely, as maintainers it complicates the support matrix and design space if we need to consider any arbitrary namespace / set of namespaces that users may have chosen.

caseydavenport commented 2 years ago

Respect helm defined namespace in Operator templates.

Update on this one in particular - v3.23 will allow specification of the --namespace flag to helm, and it will be respected.

As for specifying the namespaces deployed by the operator (e.g., calico-system and calico-apiserver), that's not something I'm entirely sure about just yet.

We want to enforce best practice here, and we believe the best-practice for installing Calico is to use namespaces as isolation boundaries between distinct subsystems.

xref: https://github.com/projectcalico/calico/issues/5876