How to Install Kubernetes Ingress on a Raspberry Pi Cluster

… but not *just* a Raspberry Pi

Richard Youngkin
Better Programming

--

Photo by Tianshu Liu on Unsplash

This is the fourth article in a series describing the development and deployment of Kubernetes applications on a Raspberry Pi cluster. The previous article described how to install Kubernetes on a Raspberry Pi cluster. This article is about Kubernetes Ingress. The next article, Kubernetes Application Monitoring on a Raspberry Pi Cluster, covers setting up Prometheus, Grafana, and a Elasticsearch, Fluentd, and Kibana (EFK) stack on the cluster.

Despite the title, this article isn’t strictly oriented toward a Raspberry Pi deployment. The only thing that’s specific to a Raspberry Pi is the Docker image used for the the application used to test Ingress.

Overview

Ingress is a mechanism that allows clients in an external network to invoke services running in our Kubernetes cluster. There are other ways of accomplishing this in Kubernetes — e.g., kubectl expose…— NodePorts and load balancers. They each have pros and cons, but suffice it to say that Kubernetes Ingress provides additional capabilities that make it more attractive. These include:

  • Service discovery
  • Canary-release routing
  • Rate limiting
  • Circuit breaking
  • And much more …

There’s much more to all of this that I won’t cover. If you’re interested in a bit more detail, see “Kubernetes NodePort vs LoadBalancer vs Ingress? When should I use what?” The Kubernetes Ingress documentation is also a good place to learn more. In this series, we’re going to use Traefik as our Kubernetes Ingress controller.

I used “Kubernetes & Traefik 101” as the primary source of information for this article. Some of what I present here, though, is slightly different — but in important ways. Consider this article as the source of truth for installing Traefik and confirming the Traefik installation. I’ll call out the significant differences.

A Small Detour

Before we get to setting up Ingress into a Kubernetes cluster, we need to install Helm. It’s significantly easier to deploy Traefik as the Ingress controller if we use the Helm charts that have been developed for that purpose. We’ll also need Helm later in the series, so we’re not doing anything we don’t need to do.

Installing Helm on your Mac is straightforward:

brew install kubernetes-helm

Followed by:

helm repo add stable https://kubernetes-charts.storage.googleapis.com/

This will initialize the Helm repository with a set of common charts (like Traefik).

It’s important to note that the above installs and initializes Helm 3.x. Helm recently released 3.x. The installation of the prior major release, Helm 2.x, is a bit different. Some of the included references talk about Helm 2.x.

That’s it — now back to Traefik!

Setting Up Traefik

Installing the Traefik Ingress controller is relatively simple.

Note: This is different than the “Kubernetes & Traefik 101” reference.

helm install stable/traefik --name <your-name-here> --set dashboard.enabled=true,serviceType=NodePort,dashboard.domain=dashboard.traefik,rbac.enabled=true,externalIP=<pi-router-IP>,imageTag=1.7.12 --namespace kube-system

This is a relatively common way of installing Traefik. Here’s what the various parts of the above command mean:

  • stable/traefik is a Helm chart that describes how to deploy Traefik. The interesting thing about this is it references a multiarch Docker image, so we don’t have to worry about finding an arm image to install.
  • <your-name-here> is the name Helm will give to the deployment and will also be part of the Kubernetes resource names (e.g., the deployment name). On my cluster, I used the relatively boring name of my-traefik-release.
  • dashboard.enabled=true indicates that the Traefik dashboard should be available.
  • serviceType=NodePort indicates that external access to the dashboard is via a NodePort. More on this later.
  • dashboard.domain=dashboard.traefik specifies that the Traefik dashboard is configured to be reachable using dashboard.traefik as the host name (e.g., http://dashboard.traefik. We’ll be using this later to confirm the installation.
  • rbac.enabled means that Traefik is being configured for extended Kubernetes permissions. To be frank, I’m not quite sure why this is required, but it is.
  • externalIP=<pi-router-IP> is needed to expose the external address Traefik will be listening on. pi-router-IP references the external network IP address for our Pi Router. In “Setup a Raspberry Pi Cluster,” this is the kubemaster host at 10.0.0.100.
  • imageTag=1.7.12 installs a specific version of Traefik. If this isn’t specified, the latest image of Traefik will be installed. Traefik just released a new major version 2.x. Since this series was started before 2.x was released, and uses v1.7.12, I thought it best to stick with that version.
  • --namespace kube-systeminstalls Traefik into the kube-system namespace. This is somewhat arbitrary — you can change it if you like.

Here’s the output from my environment:

You can verify the installation by checking the deployment:

Note that the service my-traefik-release’s EXTERNAL-IP value is what we specified in the helm install ... command.

A final way of verifying the installation is to open the Traefik dashboard. Note that the service my-traefik-release has a type of NodePort. The service’s port(s) are 80:31214/TCP,443:30308/TCP. The port information is needed to create the URL for the dashboard. Per the port information, it’s located at http://dashboard.traefik:31214/dashboard/. Port 31214 comes from the HTTP external port as specified in 80:31214.

Note that 443:30308/TCP refers to HTTPS endpoints. It’s likely the ports from your installation will be different. To access the dashboard from curl or a browser, you’ll need to add the dashboard’s hostname to /etc/hosts. If you used a different IP address for your PI router, use that instead of 10.0.0.100.

10.0.0.100 dashboard.traefik

This is needed because Traefik is routing on the host name dashboard.traefik. An /etc/hosts entry is needed so the host name used in any requests can be resolved correctly. Here’s what the Traefik dashboard looks like on my cluster:

My Traefik dashboard at http://dashboard.traefik:31214

You can also see the helm deployment info via helm ls.

Testing the installation

Note: This is different than the “Kubernetes & Traefik 101” reference.

Finally we’ll want to test the installation by deploying a service that’ll use Traefik for Ingress. We’ll use the sample whoami app provided by Containous. Here is the YAML for creating the Ingress, service, and deployment. It’s very similar to “Kubernetes & Traefik 101,” but it uses an arm image for the whoami deployment.

The information specific to Traefik is the Ingress specification.

spec/rules is used to define the routing for the whoami service.

spec/rules/host defines the hostname that’ll be used in the service request, whoami.localhost in this case.

spec/rules/host/http:/paths/path is /. This specifies that any request to this host — e.g., http://<somehost>/ — will be routed to the whoami service.

spec/rules/host/http/paths/backend specifies serviceName: whoami-service. This references the service’s name from the Service specification.

servicePort: http references the named spec/ports/name in the Service specification, which is http.

One more step is required to hook everything up. As we did with the Traefik dashboard above, you’ll need to add the following line to your /etc/hosts file (assuming you used 10.0.0.100 as the address for your Pi router):

10.0.0.100 whoami.localhost

If all went well, the whoami service can be queried at http://whoami.localhost.

You can also do this in most browsers except Chrome. Chrome won’t use the /etc/hosts file.

Conclusion

That’s it. To review we:

  1. Installed Helm so we could use it to significantly simplify the Traefik installation.
  2. Installed Traefik, including setting up its dashboard.
  3. Tested Ingress using a simple application.

Resources

--

--