How to direct different URLs to different services in Kubernetes

Kubernetes has the notion of an Ingress Controller, which can be used to set different paths to different Kubernetes services.

For example, from the documentation page at https://kubernetes.io/docs/concepts/services-networking/ingress/, you can define:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http:
      paths:
      - path: /testpath
        backend:
          serviceName: test
          servicePort: 80

it will send a request to <ip-address>/testpath to the test service.

Now, if you are doing this configuration in IBM Cloud Private (ICP), you need to change slightly the configuration above. Instead of specifying nginx.ingress.kubernetes.io/rewrite-target: /, you need to specify: ingress.kubernetes.io/rewrite-target: / . (Thanks, Chechu!)

However, Kubernetes Ingress has some other uses: fanout (distributing requests across multiple services) and name based virtual hosting.

In this blog, I want to explore the name based virtual hosting.

Sending different hostnames to different services

Let’s say you have the following applications and services deploying to your environment:

• Application: app1, Service: svc1
• Application: app2, Service: svc2

And let’s say you want to expose app1 as app1.myicp.com and app2 as (surprise!) app2.myicp.com

In this case, you can define the following Ingress rule in a file called applications.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-apps
spec:
  rules:
  - host: app1.myicp.com
    http:
      paths:
      - backend:
          serviceName: app1
          servicePort: 80
  - host: app2.myicp.com
    http:
      paths:
      - backend:
          serviceName: app2
          servicePort: 80

You can define this rule by running the following command:

kubectl apply -f applications.yaml

With this file, you can configure your DNS to send the requests to the node IP (proxy node, in the case of IBM Cloud Private). As long as the request comes the Host header (https://tools.ietf.org/html/rfc7230#section-5.4) configured, Kubernetes Ingress will route the request to the proper application and service.

Now, if you open your browse to app1.myicp.com or app2.myicp.com, you will the corresponding application. Pretty cool!

Conclusion

In this blog, I showed how to use name based virtual hosting Ingress to dispatch requests to different applications and services.

Bring your plan to the IBM Garage.
Are you ready to learn more about working with the IBM Garage? We’re here to help. Contact us today to schedule time to speak with a Garage expert about your next big idea. Learn about our IBM Garage Method, the design, development and startup communities we work in, and the deep expertise and capabilities we bring to the table.

Schedule a no-charge visit with the IBM Garage.