feat: namespace reflection

[kokou-egbewatt]

📌 Request

Currently, kubernetes-reflector reflects Secrets and ConfigMaps based on the presence of a specific label on each individual object:

reflector.v1.k8s.emberstack.com/reflection-allowed: "true"

While this works for broad or object-specific reflection, it becomes tedious and error-prone when you need to reflect only a small subset of resources from a namespace containing many Secrets/ConfigMaps.
At present, you must edit each object and apply the reflection-allowed label manually.

This is:

• Time-consuming for large namespaces.
• Prone to human oversight.
• Hard to manage when the namespace’s contents change often.

There’s no straightforward way to declare, at the namespace level, “these are the specific resources from this namespace that should be reflected elsewhere.”

---

💡 Proposed Solution

Introduce a namespace-level annotation to specify exactly which Secrets/ConfigMaps in that namespace should be reflected to other namespaces.

Example:

apiVersion: v1
kind: Namespace
metadata:
  name: source-namespace
  annotations:
    reflector.v1.k8s.emberstack.com/reflect-names: "secret-a,secret-b,my-config"

Behavior:

1. Reflector reads the reflect-names annotation from the namespace.
2. Parses the comma-separated list of names.
3. Reflects only those named Secrets/ConfigMaps from the namespace to target namespaces.
4. Ignores all other resources in the namespace unless they also match existing label-based reflection rules.
5. If both object-level labels and namespace-level annotations are present → namespace-level annotation takes precedence.

This approach allows targeted control without having to touch each source object individually.

---

🔄 Alternatives Considered

• Continue using object-level reflection-allowed labels → Still requires manual edits to each object.
• Run multiple Reflector instances → Inefficient, more moving parts.

---

📎 Additional Context

This change would:

• Simplify management of selective reflection.
• Reduce human error.
• Be especially helpful in multi-team environments where you can’t (or don’t want to) edit each individual resource.

---

📄 Example Manifest

Source Namespace with annotation:

apiVersion: v1
kind: Namespace
metadata:
  name: source-namespace
  annotations:
    reflector.v1.k8s.emberstack.com/reflect-names: "secret-a,secret-b,my-config"

Expected behavior:

• Only secret-a, secret-b, and my-config from source-namespace are reflected to allowed target namespaces.
• No need to apply reflection-allowed labels on those objects.
• Label-based rules still work for other cases but namespace annotation overrides them for the specified names.

[erhhung]

You seem to make a careful distinction between proposed namespace-level annotations and object-level labels, yet there is no behavior based on labels... the docs clearly state that it's only annotations on Secrets and ConfigMaps.

namespace-level annotation takes precedence

However, I think this logic is contrary to the customary logic that lower-level settings override higher-level "global" ones.

[github-actions]

Automatically marked as stale due to no recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cloudselva]

After downgrading to 9.0.311, it works as expected.