If you are fine with running this HAProsy on each node that is supposed to expose port 80/443 then consider running DaemonSet with hostNetwork: true. That will allow you to create pods that open 80 and 443 directly on node network. If you have a loadbalancer support in your cluster, you can instead use a Service of LoadBalancer type. It will forward from high node ports like ie. 32080 to your backing haproxy pods, and also automaticaly configure LB in front of it to give you an external IP and forward 80/443 from that IP to your high node ports (again, assuming your kube deployment supports use of LB services)

IBM Cloud has built-in solutions for load balancer and Ingress. The docs include sample YAMLs for both.

Load Balancer: https://console.bluemix.net/docs/containers/cs_loadbalancer.html#loadbalancer

Ingress: https://console.bluemix.net/docs/containers/cs_ingress.html#ingress

If you need tls termination or want to use a route rather than an IP address for accessing your HAProxy, then Ingress would be the best choice. If those options don't matter, then I'd suggest starting with the provided load balancer to see if that meets your needs.

Note, both load balancer and Ingress required a paid cluster. For lite clusters, only NodePort is available.

Here's a sample YAML that deploys IBM Liberty and exposes it via a load balancer service.

#If you are not logged into the US-South https://api.ng.bluemix.net 
region, change the image registry location to match your region.
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: ibmliberty-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: ibmliberty
    spec:
      containers:
      - name: ibmliberty
        image: registry.ng.bluemix.net/ibmliberty
---    
apiVersion: v1
kind: Service
metadata:
  name: ibmliberty-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: ibmliberty
  ports:
   - protocol: TCP
     port: 9080

NodePort

To keep the same image running in both environments then you can define a Deployment for the HAProxy containers and a Service to access them via a NodePort on the NodeIP or clusterIP. A NodePort is similar in concept to running docker run -p n:n.

The IP:NodePort would need to be accessable externally and HAProxy will take over from there. Here's a sample HAProxy setup that uses an AWS ELB to get external users to a Node. Most people don't recommend running services via NodePort because Kubernetes offers alternate methods that provide more integration.

LoadBalancer

A LoadBalancer is specifically for automatic configuration of a cloud providers load balancer service. I don't believe IBM Clouds load balancer has any support in Kubernetes, maybe IBM have added something in? If they have you could use this instead of a NodePort to get to your Service.

Ingress

If you are running Docker locally and Kubernetes externally you've kind of thrown consistency out the window already so you could setup Ingress with an Ingress Controller based on HAProxy, there's a few available:

• https://github.com/appscode/voyager
• https://github.com/jcmoraisjr/haproxy-ingress

This gives you the standard Kubernetes abstraction of how to manage ingress for a service but using HAProxy underneath. This will not be your HAProxy image though, it's likely you can configure the same things for the HAProxy Ingress as you do in your HAProxy image.

Voyagers docco is pretty good:

apiVersion: voyager.appscode.com/v1beta1
kind: Ingress
metadata:
  name: test-ingress
  namespace: default
spec:
  rules:
  - host: appscode.example.com
    http:
      paths:
      - path: '/test'
        backend:
          serviceName: test-service
          servicePort: '80'
          backendRules:
          - 'acl add_url capture.req.uri -m beg /test-second'
          - 'http-response set-header X-Added-From-Proxy added-from-proxy if add_url'