karmada-io / karmada

Open, Multi-Cloud, Multi-Cluster Kubernetes Orchestration
https://karmada.io
Apache License 2.0
4.41k stars 872 forks source link

Evaluate both native and custom Interpreters #5604

Open a7i opened 3 hours ago

a7i commented 3 hours ago

What would you like to be added:

Ability to execute both native and custom interpreters for a given kind

Why is this needed:

In https://github.com/karmada-io/karmada/pull/4766, I added support for retaining member-cluster Service Account UID and Token. We currently have a ResourceInterpreterCustomization for Secrets of type generic with a particular label, but because the target is only by apiVersion/kind, my custom interpreter takes over and never evaluates the built-in native interpreter.

I see two ways of solving this:

  1. Evaluate both native and custom interpreter -- this may lead to a change in behavior for users of karmada
  2. Ability to add label selector to ResourceInterpreterCustomization .spec.target
apiVersion: config.karmada.io/v1alpha1
kind: ResourceInterpreterCustomization
metadata:
  name: secret
spec:
  target:
    apiVersion: v1
    kind: Secret
  customizations:
    retention:
      luaScript: |
        function Retain(desiredObj, observedObj)
          if desiredObj.type == "kubernetes.io/service-account-token" then
            -- NOW I HAVE TO DUPLICATE THE LOGIC THAT IS IN THE NATIVE ONE
          elseif observedObj.metadata.labels["example.com/duplicate"] == "true" then
            if desiredObj.data ~= nil then
              if desiredObj.data["tls.crt"] ~= nil then
                desiredObj.data = observedObj.data
              end
            end
          end
          return desiredObj
        end
a7i commented 2 hours ago

If a custom interpreter is enabled [ref], it gets out early and never evaluates default [ref]