Pod name conflicts across clusters under the deployment with same name

we are running the latest (1.31) k8s clusters in our cloud. we have more than 100 k8s clusters in total, and 2 federations.
the issue we encounter is: we have a FederatedDeployment(FD for short in later description) foo deployed on Federation, and the FD is synced into downstream clusters with the same name. then each cluster processes the Deployment independently and create ReplicaSet and corresponding Pod. in k8s, there are guarantees in single cluster for the uniqueness of Pod name(as duplicate Pods creation with same name is rejected by apiserver). but there are no guarantees on the uniqueness across clusters by the implementation:

kubernetes/pkg/registry/core/pod/strategy.go at v1.31.4 · kubernetes/kubernetes · GitHub

// Strategy is the default logic that applies when creating and updating Pod
// objects via the REST API.
var Strategy = podStrategy{legacyscheme.Scheme, names.SimpleNameGenerator}

kubernetes/staging/src/k8s.io/apiserver/pkg/storage/names/generate.go at v1.31.4 · kubernetes/kubernetes · GitHub

const (
	// TODO: make this flexible for non-core resources with alternate naming rules.
	maxNameLength          = 63
	randomLength           = 5
	MaxGeneratedNameLength = maxNameLength - randomLength
)

func (simpleNameGenerator) GenerateName(base string) string {
	if len(base) > MaxGeneratedNameLength {
		base = base[:MaxGeneratedNameLength]
	}
	return fmt.Sprintf("%s%s", base, utilrand.String(randomLength))
}

the implementation for the podStrategy implementation is static and doesn’t give the chance to do customization, which is different from the auth provider for clientconfig to auth.

can we have the podStrategy’s names generator as an interface and by default have the SimpleNameGenerator, and also gives the customization by GVK(group/version/kind) as in scheme.Scheme?

You can already name it anything you like, why do you need to mutate it at the strategy level (that’s deep within apiserver)?

You can literally name it differently.

You can use mutating webhooks.

Now you can use mutating admission policy.

I don’t understand what problem you are seeking to solve?

1 Like