How to schedule gateway pods to Linux nodes only?

[mloskot]

Hi,

I maintain a cluster on Azure Kubernetes Service with hybrid nodes, Linux and Windows.

I have successfully deployed kgateway 2.1 to my Flux-controlled cluster with Helm releases based on the following charts:

• oci://cr.kgateway.dev/kgateway-dev/charts/kgateway-crds
• oci://cr.kgateway.dev/kgateway-dev/charts/kgateway

where I also specified the values with

  values:
    nodeSelector:
      kubernetes.io/os: linux

Next, I attempted to creat kind: Gateway resource with listeners, but I noticed that the gateway pod gets scheduled to Windows nodes. I learned that I can create the GatewayParameters resource:

apiVersion: gateway.kgateway.dev/v1alpha1
kind: GatewayParameters
metadata:
  name: kgateway-parameters
  namespace: kgateway-system
spec:
  kube:
    podTemplate:
      nodeSelector:
        kubernetes.io/os: linux

and reference it from the kind: Gateway resource:

spec:
  infrastructure:
    parametersRef:
      kind: GatewayParameters
      group: gateway.kgateway.dev
      name: kgateway-parameters

This works!

However, is this the only way to specify nodeSelector or control gateway pods affinity?
Is there any other way, better or more recommended way?

[yuval-k]

In addition to nodeSelector You also have the affinity and tolerations fields under podTemplate (these have the same fields as the ones in the Pod spec).

[mloskot]

@yuval-k Thank you for the answer and I owe apologies for inexact formulation of my question, so I'm rush to correct myself.
In the part "is this the only way to (...)" I meant to ask "is GatewayParameters the only way to control gateway pods affinity".

I assume the GatewayParameters is the only mechanism available, am I correct?

[yuval-k]

Yes, currently GatewayParameters is the only option available (there's a bit of nuance here, but probably not relevant).

If that's a problem, perhaps open an issue explaining your use case?

[mloskot]

Yes, currently GatewayParameters is the only option available

That's very good to know, thank you!

If that's a problem, perhaps open an issue explaining your use case?

No, that is not a problem.

It's just that, having experience with numerous Helm-deployable controllers, I find that unusual or that my current knowledge and experience seems not transitive for kgateway :)

On reflection, I could have a complaint about an inconvenient inconsistency though: I install kgateway using Helm chart specified with nodeSelector: { "kubernetes.io/os": "linux" } in values, then why this setting is not applied globally? In other words, if user requires kgateway controller to be scheduled to Linux nodes, then user may expect that anay other kgateway-related pods will be scheduled to Linux nodes too.

[yuval-k]

The data plane and control plane pods can have different constraints.

For example, we've seen users deploy data-plane pods to specific ingress nodes. And the control plane nodes won't have these constraint.

[mloskot]

@yuval-k Gotcha. I missed the wider context indeed. Thanks a lot for all the clarifications.