Proposal: Deploy dataplane pods into same namespace as the gateway operator

[jaynis]

Right now the operator deploys the stunner dataplane pods into the namespace where the kubernetes Gateway is located in and this seems to be hardcoded in the dataplane_util.go:

ObjectMeta: metav1.ObjectMeta{
    Name:      gw.GetName(),
    Namespace: gw.GetNamespace(),
    Labels: map[string]string{
        opdefault.OwnedByLabelKey:         opdefault.OwnedByLabelValue,
        opdefault.RelatedGatewayKey:       gw.GetName(),
        opdefault.RelatedGatewayNamespace: gw.GetNamespace(),
    },
    Annotations: map[string]string{
        opdefault.RelatedGatewayKey: types.NamespacedName{
            Namespace: gw.GetNamespace(),
            Name:      gw.GetName(),
        }.String(),
    },
},

The Gateway namespace is likely the namespace where the media applications stunner relays the traffic to are deployed to as well. I would like to hear the maintainers opinion about deploying the dataplane pods into the operator namespace (e.g. stunner-system) instead. I personally find this the cleaner approach because it separates stunner managed resources from the actual application resources. This is also how other gateway operators (for example the envoy gateway operator) do this.

[rg0now]

Our deployment model is taken from Istio. Frankly, it didn't even occur to us that we could do this in any other way.

My current (super-uniformed) view is that keeping the Gateway and the managed pods in the same namespace allows maximal freedom: if you really want to isolate STUNner just create a separate namespace (say, stunner) into which Gateways, and managed pods, are deployed. (I'm not saying this does not sometimes yield surprising results; I recall more than a couple of times being puzzled by the seemingly random (dis)appearance of pods in semi-random namespaces.)

I'd really love to learn more about the operational cons/pros of both ways. Currently I don't subscribe to the idea that "deploying the dataplane pods into the operator namespace" would be cleaner because "it separates stunner managed resources from the actual application resources". Does this make setting service accounts/RBAC rules simpler? Does our current model somehow fundamentally interfere with GitOps and ArgoCD? Can you please elaborate?

The current status is to keep the current model for v1. However, we are not entirely against rethinking this if convincing arguments come up along the way.

[jaynis]

Thank you for your detailed explanation. My proposal was surely not meant to be the one-and-only solution (therefore it was a proposal not a request). There are various ways how to solve this where none of them might be wrong but just different. If this was a deliberate design decision I am generally fine with this.

What I meant with "cleaner" is if I install an application into a certain namespace I want to decide what is going on there and dont want other applications except mine to do things there or even be deployed there. I mean this is the main purpose of namespaces right? Therefore I found the approach which envoy gateway uses, where system apps are hidden in a separate namespace regardless of the location of the Gateway, more appealing and was wondering whether it would fit here as well.

But I think you are right, this could be solved by simply moving the Gateway resources into a different namespace :+1: .

[rg0now]

This discussion seems to have petered out. I'd still be curious of the pros/cons of the operational models discussed here, please reopen if anything new comes up.