Kubernetes Needs to Take a Lesson from Portainer on Ease-of-Use
Not two years ago, I could easily deploy a Kubernetes application and make it available outside of the cluster. That same process no longer works. To be more specific, I seriously struggle with getting Kubernetes applications and services to be accessible from a LAN.
It shouldn’t be this hard.
Seriously.
And even the Kubernetes documentation is of little help. What seemed to have worked a few months ago fails. And every piece of third-party documentation I’ve come across is either broken, outdated, or neglects some important step required to publish an app or service beyond the cluster.
It’s frustrating, to say the least.
Here’s an example of how I used to be able to do this. I’ll demonstrate with the InfluxDB time series database.
On your Kubernetes controller, create a new YAML file with the command:
|
1 |
nano influxdb.yml |
In that file, paste the following:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
apiVersion: v1 kind: Pod metadata: name: influxdb spec: hostNetwork: true containers: - name: influxdb image: influxdb The important bit here is: hostNetwork: true |
The important bit there is hostNetwork: true.
Save and close the file.
To deploy the InfluxDB pod, I would issue the command:
|
1 |
kubectl create -f influxdb.yml |
To test the outside access of the InfluxDB pod, I must find out which node the pod was deployed to with the command:
|
1 |
kubectl describe pods influxdb |
In the output, you would have seen a line such as this:
|
1 |
IP: 192.168.1.112 |
You could then test the connection with a command like:
|
1 |
curl -v http://IP:8086/ping |
Where IP was the IP address printed in the output above.
It worked every time.
Now? It doesn’t.
And I get it… technology evolves at a pace far faster than most of us can keep up. When a technology as important as Kubernetes continues to make such crucial changes and doesn’t help the user out with quality documentation to ease the transition, there’s a big problem. That big problem has never been so apparent as it is with Kubernetes.
As someone who is having to write about this technology on a regular basis, it can get very frustrating when something that once worked no longer does. To add insult to that injury, the current documentation does nothing to ease that frustration. There’s no, “Where you used to use hostNetwork: true, you’ll now use blah blah blah.”
That’s where Portainer comes in. I’ve made no bones about how this web-based GUI is my go-to for container management. And with the help of MicroK8s, deploying Portainer such that it manages a Kubernetes cluster is exponentially easier. But that simplicity isn’t limited to the deployment of the cluster and a fantastic web-based GUI. With the help of Portainer, I can deploy an application such that it’s accessible outside of the cluster with an ease Kubernetes itself cannot match.
Don’t believe me? Let me show you.
Requirements
To make this work, you need a running instance of Portainer. The best way of deploying is via MicroK8s, which I demonstrate in Kubernetes 101: Deploy Portainer to a MicroK8s Cluster. Once you have that ready, log in to Portainer, click the Local environment, and then click Applications in the left navigation. In the resulting window, click Add With Form, which will take you to the page where you can quickly craft a simple NGINX application to test this out. On that page, select the default namespace, name your application something like nginx-test, and type nginx in the Image field. Once you’ve done that, scroll down to where you see Publishing the Application (Figure 1).
-
Figure 1: This is the section that allows you to expose the application outside the cluster.
From the drop-down, select NodePort and then click Create Service. In the resulting section, fill out the following:
- Container Port: 80
- Service Port: 80
- Nodeport: 30088
Once you’ve done that, scroll down and click Deploy Application. Give the app a minute or so to deploy and then open a web browser to http://SERVER:30088 (Where SERVER is the IP address of your hosting server). If, during the creation of the app, you up the Instance Count to three, you can reach the NGINX server from any of the IP addresses associated with the Kubernetes cluster, such as:
- 192.168.1.70:30088
- 192.168.1.71:30088
- 192.168.1.72:30088
And that’s all there is to expose a Kubernetes app outside of the cluster with Portainer. This is exactly how easy the task should be, and the Kubernetes development community should take notice. As is, using Kubernetes is so challenging it seems the only people who truly get the technology are the developers and those who are paid to spend their entire workweek using and managing the technology. Because of that, the barrier to entry for Kubernetes is so challenging those who are new to the technology will always struggle to get it up and running.
However, I would say to those who are new to Kubernetes to just skip the command line and head right to Portainer. There is absolutely zero shame in wanting to use the technology but do so in such a way that won’t have you pulling your hair out or screaming into the void when things don’t work as they should.