TLS and WebSocket support in NodeRED instance Ingress (the one created by kubernetes.js)

[adaptivegarage]

Hi,
is there any reason that I might be overlooking in kubernetes.js for not to support TLS and WebSocket in ingressTemplate and createIngress?

In order to get the NodeRED instances working on a K8s cluster one would need to adjust the two mentioned somehow along these lines:

const ingressTemplate = {
    apiVersion: 'networking.k8s.io/v1',
    kind: 'Ingress',
    metadata: {
        // name: "k8s-client-test-ingress",
        // namespace: 'flowforge',
        annotations: {
            // ***** Added:
            // nginx.org/websocket-services: "k8s-client-test-service"
        }
    },
    spec: {
        rules: [
            {
                // host: "k8s-client-test" + "." + "ubuntu.local",
                http: {
                    paths: [
                        {
                            pathType: 'Prefix',
                            path: '/',
                            backend: {
                                service: {
                                    // name: 'k8s-client-test-service',
                                    port: { number: 1880 }
                                }
                            }
                        }
                    ]
                }
            }
        ],
        // ***** Added:
        tls: [
            {
                hosts: [
                    // "k8s-client-test" + "." + "ubuntu.local"
                ]
            }
        ]
    }
}

const createIngress = async (project, options) => {
    const prefix = project.safeName.match(/^[0-9]/) ? 'srv-' : ''

    const localIngress = JSON.parse(JSON.stringify(ingressTemplate))
    localIngress.metadata.name = project.safeName
    // ***** Added:
    localIngress.metadata.annotations['nginx.org/websocket-services'] = `${prefix}${project.safeName}`
    localIngress.spec.rules[0].host = project.safeName + '.' + options.domain
    localIngress.spec.rules[0].http.paths[0].backend.service.name = `${prefix}${project.safeName}`
    // ***** Added:
    localIngress.spec.tls[0].hosts.push(project.safeName + '.' + options.domain)

    return localIngress
}

[hardillb]

Hello,

We haven't had a need for the either of these just yet with the configurations we've been running with.

All the ingress controllers have automatically worked with WebSockets without the need for an annotation.

And for the TLS we have configured the controller to redirect all traffic to the https port and we've been doing TLS termination at the Ingress Controller with a wildcard certificate, so no need for the tls section or to use things like CertManager just yet.

I hope to merge some changes in the next release that will allow the specifying of extra annotations to make ingress objects which would include the first point.

I'll have a think about the options for setting tls

[adaptivegarage]

Hello,

We haven't had a need for the either of these just yet with the configurations we've been running with.

All the ingress controllers have automatically worked with WebSockets without the need for an annotation.

And for the TLS we have configured the controller to redirect all traffic to the https port and we've been doing TLS termination at the Ingress Controller with a wildcard certificate, so no need for the tls section or to use things like CertManager just yet.

I hope to merge some changes in the next release that will allow the specifying of extra annotations to make ingress objects which would include the first point.

I'll have a think about the options for setting tls

Hi,
thanks for getting back to me.

WebSocket: I am not familiar with all Ingress controllers but Nginx from Nginx (CE edition). And this one requires the annotation to be present in order to support the WS connections. Without the annotation the NodeRED applications complain on failed WS connections.

TLS: I understand that it may work in the scenario you mention. However, in our environment (and I believe we wouldn't be alone) the TLS section needs to be explicitly configured for every Ingress in every namespace. We cannot reconfigure the environment to work as you describe.

Could I perhaps hope that you might consider these suggestions in any near future, or would you appreciate a pull request, that I would take care of, or would you rather suggest that we make our own patch?

Thanks,
regards
Roman

[dfulgham]

I was having this same issue with websockets, and by adding the annotation for nginx.org/websocket-services into the ingress for the node-red service fixed the issue. So I think there is something needed here.

[hardillb]

@dfulgham You can pass additional ingress annotations as part of the helm install by setting the value ingress.annotations

These should be added to all the instance ingress objects that are created.

[adaptivegarage]

@dfulgham You can pass additional ingress annotations as part of the helm install by setting the value ingress.annotations

These should be added to all the instance ingress objects that are created.

Hi, I would like to refresh and bring to your attention that my comment (and I believe the one from @dfulgham too) referred to the NodeRED instance ingress created by kubernetes.js, not the Flowforge ingress created by helmchart.

[hardillb]

@adaptivegarage those annoations also get added to both, they are added to the ingress template for the forge app here and get added as an environment variable here which is then picked up by the kubernetes driver here

[adaptivegarage]

@adaptivegarage those annoations also get added to both, they are added to the ingress template for the forge app here and get added as an environment variable here which is then picked up by the kubernetes driver here

Oh, I see. Thanks a lot, I'll give it a try.
My comment regarding the TLS section is, however, still valid, is that right?

[hardillb]

Yes, TLS entries do still need looking at.

There will be some overlap with some other work we need to look at soon to potentially support custom hostname/domains for instances.

[hardillb]

Cert-Manager TLS support to be added via #131