Allow defining Service type

[nicolas-goudry]

Summary

Currently the CRD doesn’t allow defining the Service type, defaulting to a type of ClusterIP.

This is needed in order to support GKE Ingress, which do not allow to bound to a Service of type ClusterIP when container native load balancing is not used.

Steps to reproduce

• Create a GKE cluster without container native load balancing
• Deploy mattermost through the operator with following spec related to ingress:

ingressAnnotations:
  kubernetes.io/ingress.class: "gce"
ingressName: mattermost.mydomain.com

• Check created Ingress to see the following failure:

$ kubectl -n mattermost describe ing mattermost
Name:             mattermost
Namespace:        mattermost
Address:
Default backend:  default-http-backend:80 (x.x.x.x:8080)
Rules:
  Host                    Path  Backends
  ----                    ----  --------
  mattermost.mydomain.io
                          /   mattermost:8065 (x.x.x.x:8065)
Annotations:              kubernetes.io/ingress.class: gce
                          mattermost.com/last-applied: ...
                          nginx.ingress.kubernetes.io/proxy-body-size: 1000M
Events:
  Type     Reason     Age                From                     Message
  ----     ------     ----               ----                     -------
  Normal   Sync       91s (x2 over 91s)  loadbalancer-controller  Scheduled for sync
  Warning  Translate  9s (x15 over 91s)  loadbalancer-controller  Translation failed: invalid ingress spec: service "mattermost/mattermost" is type "ClusterIP", expected "NodePort" or "LoadBalancer"

Operator version used: 1.14.0
Mattermost version used: 5.37.2
Environment: GKE

Expected behavior

Being able to specify mattermost Service type, GKE Ingress would work.

Possible fixes

I’m not a Go developer, but I think this is the relevant code.

I thought at first that this feature might be enabled by the recent changes to Ingress management allowing to disable Ingress creation (triggered from this issue), but the problem is that the operator will continue to set a service of ClusterIP type.

Possible solutions that I can think of:

• allow disabling Service creation, falling back on user to create the service (easiest)
  • something like a boolean serviceEnabled
• allow setting Service type to NodePort, without trying to set ClusterIP to None (preferred)
  • serviceType property that can be set to:
    • headless (default)
    • clusterIP
    • nodePort
• allow setting Ingress parameters and useServiceLoadBalancer at the same time (this is not currently possible as the useServiceLoadBalancer takes precedence over Ingress parameters)

[Szymongib]

Thanks for the detailed explenation @nicolas-goudry. I will look into this.

As for the workaround, you should be able to just create another service pointing at Mattermost pods and customize it to your own demands.

[nicolas-goudry]

@Szymongib Thanks for your quick reply.

Regarding the workaround, your proposal is valid, but as of v1.14.0 I would still need to create another Ingress object than the one created by mattermost-operator, leaving me with:

• a Service object of type ClusterIP, created by operator, which will never be used
• an Ingress object, created by operator and forever stuck in Scheduled for sync state
• another Service object of type NodePort, created manually
• another Ingress object, created manually and bound to the manually created Service

It will be even better when the next version is released (with better Ingress management), then I would only need to disable the Ingress creation by mattermost-operator and create a NodePort Service object as well as a custom Ingress object, leaving me only with a ClusterIP Service which will never be used.

This is fine for now, but I’m looking forward to have this feature implemented 🙂

[gabrieljackson]

We are opening this feature request as a help wanted ticket for anyone interested in implementing it.