Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Helm chart: option to provide different services for different ports #274

Open
tomasgareau opened this issue Feb 3, 2021 · 1 comment
Open

Comments

@tomasgareau
Copy link

Currently, the Helm chart for VerneMQ allows the user to select a Service type (.Values.service.type) and ports to expose through that service (.Values.service.mqtt, .Values.service.mqtts, etc.,). This service exposes all the ports with enabled: true under .Values.service.

It would be nice to be able to specify different service types for different ports. The use-case I have in mind would be:

  • exposing MQTTS via a LoadBalancer service
  • exposing MQTT via a ClusterIP service

That way, I can communicate externally with TLS/SSL, but use an unencrypted connection within my cluster. An added bonus would be making it easier to debug/view MQTT messages by kubectl port-forward'ing the MQTT ClusterIP service.

Alternatively, this is something I can do by manually creating a service after deployment:

apiVersion: v1
kind: Service
metadata:
  name: vernemq-plain
  namespace: default
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/instance: vernemq
    app.kubernetes.io/name: vernemq
  ports:
  - name: mqtt
    port: 1883
    protocol: TCP
    targetPort: mqtt

but I'd have to manually set the selector labels rather than having them filled out by templated values.

@JeremyTheocharis
Copy link
Contributor

I have a similar issue: I want to have different ports, e.g., 1883 and 1884, for ClusterIP and LoadBalancer. I am currently creating a Pull Request, which allows at least to disable the standard service template.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants