Context menu to expose a `Deployment` as a `Route` or `Ingress`.

[datho7561]

It would be nice to expose a running service to the internet using a Route (in the case of OpenShift) or Ingress (in the case of other Kubernetes distributions).

Here's how to create a Route in OpenShift, given that $NAME_OF_DEPLOYMENT is a deployment that's in the current name:

oc expose deployment $NAME_OF_DEPLOYMENT

Here's an example of an Ingress yaml in Kubernetes:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wildwest-backend-ingress
spec:
  defaultBackend:
    service:
      name: wildwest-backend-app
      port:
        number: 8080

The values we will have to change depending on the deployment are:

• metadata.name to the name of the deployment but with the suffix -ingress to help distinguish it
• spec.defaultBackend.service.name to the name of the deployment
• spec.defaultBackend.service.port.number to the port that the deployment exposes its service on

In order to create the ingress, you will need to run oc apply -f ingress-definition.yaml.

A few final thoughts:

1. It might also be possible to include the route or ingress in the devfile by embedding the YAML using the additional Kubernetes resources feature. For instance, this is how odo creates ServiceBindings:

   // ...
   components:
   - kubernetes:
   inlined: |
     apiVersion: binding.operators.coreos.com/v1alpha1
     kind: ServiceBinding
     metadata:
       creationTimestamp: null
       name: my-binding
     spec:
       application:
         group: apps
         kind: Deployment
         name: using-go-app
         version: v1
       bindAsFiles: true
       detectBindingResources: true
       services:
       - group: postgres-operator.crunchydata.com
         id: my-binding
         kind: PostgresCluster
         name: example-postgres
         namespace: default
         resource: postgresclusters
         version: v1beta1
     status:
       secret: ""
   name: my-binding
   // ...

   The benefit of this approach is that, if I understand correctly, odo will manage the lifecycle of this Kubernetes object by creating it when dev is started and deleting it when dev is stopped

2. A final aspect of this change is that we should alert the user that this will expose the service to the public if the cluster is capable of exposing services to the public, and require an additional confirmation in order to do this. We shouldn't try to detect if the cluster is capable of exposing public endpoints, since that is really difficult. Instead we should always show this warning.

3. Not all Kubernetes clusters are capable of creating an ingress. They require an ingress controller. On minikube the ingress controller that is automatically set up is the nginx one. Maybe we should hide the UI option if the cluster is not OpenShift and doesn't have an ingress controller set up?

[datho7561]

I have a POC of the Route portion of this working

[datho7561]

I ran into some issues while trying to get similar functionality for Ingresses to work:

• You need an IngressController in order to successfully create ingresses. Many Kubernetes clusters intended for local development, such as minikube and kind, require additional configuration in order to set up an IngressController.
• Clusters provisioned on cloud providers tend to use a LoadBalancer instead of Ingresses
• I couldn't figure out how to get Ingresses to work on crc

[datho7561]

I messed up, we don't actually need this to get the Wild West demo application working.

[datho7561]

Why I've changed my mind and think this isn't a good idea

[datho7561]

I've changed my mind again: I think we should support Routes but not Ingress:

• This is an OpenShift extension. Most of the users who install it are probably using an OpenShift cluster. We can easily hide the feature if the cluster is not OpenShift
• Routes are fairly easy to support
• Ingress is difficult to support:
  • There are many setup steps needed to get Ingress working. These setup steps vary from cluster to cluster.
  • Ingresses work by specifying a different path for each endpoint instead of a different subdomain, so they are are not analogous to Routes
  • I haven't been able to get Ingress working on an OpenShift cluster

[datho7561]

@vrubezhny You mentioned wanting more issues to work on. What do you think of this issue?

We only need to make it work for OpenShift clusters, so we can use Routes