mattermost-operator
mattermost-operator copied to clipboard
Allow defining Service type
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
- something like a boolean
- allow setting Service type to
NodePort
, without trying to setClusterIP
toNone
(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 theuseServiceLoadBalancer
takes precedence over Ingress parameters)
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.
@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 :slightly_smiling_face:
We are opening this feature request as a help wanted ticket for anyone interested in implementing it.