-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Namespace label to indicate a namespace managed by kyma #922
Comments
Relates to #864 |
Very good example is: Users are asked to not auto-instrument namesapces not owned by them. But how can they know that list? Example of a dynatrace CR configuration: namespaceSelector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: NotIn
values:
- kube-system
- kyma-system That list is not complete at all. Now imagine that this list gets replaced by something like: namespaceSelector:
matchExpressions:
- key: kyma-project.io/namespace
operator: In
values:
- managed |
+1 for having a label added by KLM.
KLM has to make sure that kyma-system namespace will get that label also. Modules that run outside of kyma-system have the namespaces in the deployment yaml , so it will work automatically. The only missing part is |
Even if the kube-system is managed by gardener, for end users the kube-system namespace is just part of the managed kyma offering and it will not be understandable why it should be treated separate in the namespaceSelector:
I suggest that KLM not only enriches the kyma-system namespace always but also kube-system. I adjusted the proposed decision to it. |
Issue was discussed with all relevant parties and no one objected, will close it as accepted |
The work items in KLM are:
|
Created on 2024.07.22 by Andreas Thaler (@a-thaler ).
Decision log
Proposed on 2024-07-22
Context
The different tools for Kyma like the CLI, Dashboard and also telemetry like to treat resources in a managed namespace differently. For example they might to show them "locked" so that novices will not modify them, or as in the case of telemetry, users like to exclude log collection from them as workloads running there are not in the interest of there operational duty.
The goal is to have a simple namespaceSelector in place to identify all managed namespaces, like:
Currently there is no easy way to figure out these managed namespaces, modules are spread across different namespaces, modules might be installed in a managed way or custom.
The goal is to have a unified way to know which namespaces are managed by the kyma lifecycle manager in order to smooth the user experience and have a better distinction between reponsibilities.
At the moment, the Kyma Lifecycle Manager already labels all applied resources (incl namespaces) with these labels:
Furthermore, it adds an addition to all resources indicating to not change them.
These labels not documented anywhere and probably not really part of any contract. Anyway, these should be re-used, condensed to one meaningful label and written down to make use of them by clients.
Furthermore, it should be mentioned that modules typically manage further resources which are then potentially become a "managed" resource as well. For these resources, we agreed already to have a consistent labelling as decided here.
However, these labels are defined by the modules itself and the module will not differ between if the module was installed in a managed way by the lifecycle manager or not. The "managed" flavor anyway is not so relevant for all kind of resources but mainly namespaces a a grouping element.
To overcome the problem with modules like "Istio" where a namespace gets created dynamically, a contract should be established that all namespaces owned by a module should be part of the moduleTemplate, so that they are known to the lifecycle manager and are getting labeled accordingly.
Gardener is labelling the kube-system namespace using:
Decision
Have a consistent labelling on namespace level which indicates that this namespace is under control of the Kyma Lifecycle Manager and with that is a kyma managed namespace. The user do not need to care about the operational health of components running inside this namespaces. The label is called
operator.kyma-project.io/managed-by: kyma
. It will replace the two labels already used by the lifecycle manager. The kyma-system and kube-system namespace will be labeled always.All namespaces owned by a module must be defined as part of the ModuleTemplate so that it becomes a "managed" one automatically, incl the istio-system namespace.
Consequences
The approach will allow the different tools to dynamically search or exclude for namespaces having the proposed label. Determined namespaces will be treated differently by the tooling..
The text was updated successfully, but these errors were encountered: