Serving non HTTP protocols within OpenShift

Solution Verified - Updated -

Environment

  • Red Hat OpenShift Container Platform (RHOCP)
    • 4
  • Red Hat Openshift on AWS (ROSA)
    • 4
  • Azure Red Hat Openshift (ARO)
    • 4
  • Red Hat OpenShift Dedicated (OSD)
    • 4

Issue

  • Is it possible to serve non-HTTP traffic in OpenShift 4?
  • Can ARO and ROSA serve non-HTTP protocols?
  • Can be exposed applications like Redis externally to an OpenShift cluster?
  • What methods of exposing non-HTTP traffic are available to ARO and ROSA clusters?

Resolution

Openshift is designed to expose HTTP-style connections outside the cluster easily. This could be any of the following:

  • HTTP / HTTPS traffic for multiple web servers
  • Microservices
  • API

Which are all easily managed through OCP Custom Domain, Service and Route objects.

What is sometimes not clear is that any service/server can be exposed via OpenShift. Since the IngressController is more appropriate for web applications, other options for exposing non-HTTP traffic are:

The load balancer service is recommended for clusters installed in a Cloud Provider. It can be used also in other installations types like bare metal, but in that case the MetalLB Operator is required.

The following example provides simple steps on how to configure and expose a service/server which can be adapted for any other service. This verified example can be used as a known good example to identify other network issues that may be affecting another LoadBalancer service.

Example

  1. Download the tarfile attached to this solution.
  2. Un-tar the file

    $ tar -xvf lb-service.tar
    
  3. In a terminal, cd into lb-service directory and run the following to build and deploy the client/server apps.

    $ cd lb-service
    $ oc new-project lb-service
    

    ncat server

    $ oc new-build  -D "-" < \
       containers/server-ncat/Containerfile \
       --to server-ncat:latest \
    && oc wait --for=condition=complete \
       build/server-ncat-1 --timeout 5m \
    && oc new-app server-ncat:latest
    

    socat server

    $ oc new-build  -D "-" < \
       containers/server-socat/Containerfile \
       --to server-socat:latest \
    && oc wait --for=condition=complete \
       build/server-socat-1 --timeout 5m \
    && oc new-app server-socat:latest
    

    client

    $ oc new-build  -D "-" < \
       containers/client/Containerfile \
       --to client:latest \
    && oc wait --for=condition=complete \
       build/client-1 --timeout 5m \
    && oc new-app client:latest
    
  4. View the messages being sent to the socat server

    $ source bin/clusterResources
    
    $ oc logs $POD_SERVER_SOCAT -f
    
  5. Send a messages to the socat server app using the cluster IP. Since the cluster IP is only available from inside the cluster, it is needed to rsh into the client pod

    $ source bin/clusterResources \
    && sed \
       -e "s/{SERVICEIP}/$SVC_SOCAT_IP/" \
       -e "s/{sleep}//"  \
       bin/snd-msg  | oc rsh $POD_CLIENT
    
  6. Create the external Load Balancer Service

    $ oc create -f configs/svc-socat-lb.yml
    
  7. Confirm that the cloud platform has provided an external IP. If the EXTERNAL-IP is <pending>, wait for it to populate the cluster with the external IP

    $ oc get svc
    NAME              TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
    ...
    server-socat-lb   LoadBalancer   172.30.62.0      <pending>     4224:31841/TCP   9s
    
  8. Send messages to the socat server app using the external IP. Since this IP is external it can be done from any location that has access to to the external IP.

    From the client pod

    $ source bin/clusterResources \
    && sed \
       -e "s/{SERVICEIP}/$SVC_LB_SOCAT_IP_EXT/" \
       -e "s/{sleep}//"  \
       bin/snd-msg  | oc rsh $POD_CLIENT
    

    From a local machine

    $ let i=1
    $ while [[ $i -le 50 ]]
    do
       echo "########## msg $i" | /usr/bin/nc -w 1 20.241.220.82 4224 &
    
       let i=$i+1
    done
    

This procedure will show that non-http protocols will work with OpenShift 4, ARO and ROSA. If the procedure does not work then it highlights that other changes have been made to the network either to the cloud platform or the ARO/ROSA service. These changes will need to be modified for all this Load Balancer service to work

Clean up

$ oc delete deployment,build,svc,buildconfig,imagestream --all

$ oc delete project lb-service

Root Cause

The IngressController is more appropriate for HTTP protocol.

Attachments

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments