Helm for Kubernetes. Setup ingress as API gateway.
The current chapter is the continuation of Helm exploration journey started with previous ones:
The input for the current chapter is here. The project has two Helm charts (RabbitMQ is maintained by Bitnami and hand crafted chart with naive REST API server communicating with RabbitMQ). It is unhandy to expose IP ports (with minikube service xxx or port forwarding) every time when access to RabbitMQ Management console or mine service endpoint is needed. Time to set up Kubernetes ingress, which allows reaching both servers all the time by providing routes.
The most popular Ingress implementation is with nginx server. Thus, in Helm chart world it will be ingress nginx chart. Fortunately, minikube has wrapped ingress implementation as addon, which needs to be enabled with the command:
As RabbitMQ Helm chart is maintained by Bitnami, it is time to dive into their documentation. As appears, Bitnami has a unified approach and, since I keep my unique settings in my-values.yaml, the new version of it is below:
Besides enabling ingress for RabbitMQ itself on line #6, line #7 sets accessing host (to be set up soon). With this, ‘good to go’ version of chart can be found here.
In fact, a tiny modification to allow permanent access to professionally maintained Helm chart service is the result of serious efforts from maintainer. But in this particular case, it is hidden from user. Luckily, there is the second hand-crafted chart where everything needs to be set up manually.
Remember, in the first chapter where heartbeat service Helm chart were created, the templates subfolder we mostly cleared from scaffolded files. Now it is a time to add modified version of Kubernetes ingress definition file:
#1..#2: standard definition of k8s resource of type Ingress
#6: start of routing rules defintion
#7: everything starting from here and down will be applicable when user talks to heartbeats.io domain
#10..#11: when prefix ‘/’ specified in domain (i.e., for each and every UrlPath user requests)
#14: route request to Kubernetes service with name heartbeat-webapp (it is defined in current Helm chat, in a sibling file)
#16: to port number 3000, which defined as k8s internal ClusterIP port in this service
With this, ‘good to go’ version of hand crafted Helm chart can be found here.
Let’s deploy both Helm charts (decrypt secrets locally if have not done so in a scope of previous chapter:
Exploring k8s namespace with Lens IDE:
Hovewer, the tab Ingresses is not empty anymore:
Two Ingress rule (one for RabbitMQ chart and one for heartbeats chart) is selfdescriptive. Moreover, it is possible to select heartbeats ingress, push the Edit button and find Ingress.yml file content entered 2 minutes ago:
The last stopper from accessing both services is the domain names specified in both Ingress. For RabbitMQ it is rabbitmq.heartbeats.io and heartbeats service heartbeats.io.
I use minikube installing on Windows (please, better to avoid using Windows for these researches, or get ready to google for set of tweak on running Kubernetes there) and for me IP 172.23.203.110 is where minikube has a gateway listening for incoming network request. As my intension is to check that both services can be accessed from local PC simultaneously, my plan is add that aliasing into famously hosts file.With the simple procedure, insert two new lines at the bottom:
and go to your browser.
For RabbitMQ console, please enter http://rabbitmq.heartbeats.io/ and enjoy with login screen of RabbitMQ console:
Do not forget, that in previous chapter, credentials were changed to superuser/superpassword.
For heartbeats service UI, please enter http://heartbeats.io/heartbeats (pardon for taftology, since domain is heartbets.io and internal implementation of HTTP server only has route /heartbeats) to see last entries service read from sibling RabbitMQ server:
Altogether, there is IP access to many Kubernetes services inside cluster and it is implemented with help of Ingress controller. Worth to mention that, heartbeats service communicates with RabbitMQ without leaving cluster via ClusterIP port specified on RabbitMQ side.
Establish access to internal Kubernetes cluster resources is one of the most popular task. In Helm charts world the need of accessing resources within professionally maintained charts is less frequent to see than to hand crafted one, since this type of resources are frequently wrapps Front or Backend services.
