Docker & Kubernetes : Nginx Ingress Controller for Dashboard service on Minikube

bogotobogo.com site search:

Introduction

The Dashboard of Minikube is not externally accessible (via http://mydashboard.com for example) and we get it internally.

In this post, on Minikube, we'll setup name based (hostname) Ingress rules and enable Ingress controller. With the setup, we'll be able to access the Dashboard externally. The Ingress controller takes over and then it will follow through the rules and forward requests to kubernetes-dashboard service. Also, we'll map Minikube's IP to a CNAME in our local /etc/hsots file.

What is Ingress Controller?

Just like any other application, Ingress controllers are pods. They're part of the cluster and can see other pods and being inside the cluster themselves, we still need to expose them to the outside via a Service with a type of either NodePort or LoadBalancer.

While Ingress resources defines how we want the requests to the services to be routed via routing rules, Ingress controller processes (actually reouts) the ingress resource's information.

The controller, having the ability to inspect HTTP requests (layer 7), directs a client to the correct pod based on characteristics it finds, such as the URL path (URI) or the domain name (hostname).

Installing Nginx Ingress Controller on Minikube

In this post, we'll learn how to use Nginx Ingress Controller that comes with Minikube.

At the end, we will get our dashboard using domain name (dashboard.info) instead of using something like this: http://127.0.0.1:51617/api/v1/namespaces/kubernetes-dashboard/services...:

In addition to installing the Nginx Ingress Controller, we'll configure Ingress resources as kind: Ingress using yaml file and set an url to spec.rules.host: dashboard.info as routing rules in the file. After the configuration, because the dashboard.info is not registered domain, we map the ip of the Ingress service to dashboard.info in /etc/hosts file as an entry point.

Let's start our minikube:

$ minikube start --vm=true  --driver=hyperkit
minikube v1.13.0 on Darwin 10.13.3
 KUBECONFIG=/Users/kihyuckhong/.kube/config
Using the hyperkit driver based on user configuration
Starting control plane node minikube in cluster minikube
Creating hyperkit VM (CPUs=2, Memory=2200MB, Disk=20000MB) ...
Preparing Kubernetes v1.19.0 on Docker 19.03.12 ...
Verifying Kubernetes components...
Enabled addons: default-storageclass, storage-provisioner
Done! kubectl is now configured to use "minikube" by default

Note that we explicitly specified the driver in the command. Without the driver flag, minikube may opt not to use vm and insist on using Docker. Most likely it happens because first time we ran it with --driver=docker option (either explicitly or implicitly) and it has been saved in our Minikube profile. To fix this we will probably need to remove our Minikube instance (minikube delete) and then start it again with --vm=true option (without the --driver option).

To install the NGINX Ingress controller in Kubebernetes cluster on Minikube, all we have to do is enabling it using the following command:

$ minikube addons enable ingress
Verifying ingress addon...
The 'ingress' addon is enabled

It automatically starts Kubernetes Nginx implementation of Ingress Controller.

Now we can see an ingress-nginx-controller pod is up and running in kube-system namespace:

$ kubectl get pods -n kube-system
NAME                                        READY   STATUS      RESTARTS   AGE
coredns-66bff467f8-r9fxd                    1/1     Running     0          3m1s
etcd-minikube                               1/1     Running     0          3m4s
ingress-nginx-admission-create-tctgw        0/1     Completed   0          2m4s
ingress-nginx-admission-patch-6bwhd         0/1     Completed   0          2m4s
ingress-nginx-controller-69ccf5d9d8-r7724   1/1     Running     0          2m4s
kube-apiserver-minikube                     1/1     Running     0          3m4s
kube-controller-manager-minikube            1/1     Running     0          3m4s
kube-proxy-l29xr                            1/1     Running     0          3m1s
kube-scheduler-minikube                     1/1     Running     0          3m4s
storage-provisioner                         1/1     Running     0          3m4s

Creating Ingress rules

$ kubectl get ns
NAME                   STATUS   AGE
default                Active   11m
kube-node-lease        Active   11m
kube-public            Active   11m
kube-system            Active   11m
kubernetes-dashboard   Active   24s

The kubernetes-dashboard is for internal (we know it because the service Type is ClusterIP) and it's not externally accessible:

$ kubectl get all -n kubernetes-dashboard
NAME                                            READY   STATUS    RESTARTS   AGE
pod/dashboard-metrics-scraper-dc6947fbf-rw5tv   1/1     Running   0          4m40s
pod/kubernetes-dashboard-6dbb54fd95-k85gz       1/1     Running   0          4m40s

NAME                                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/dashboard-metrics-scraper   ClusterIP   10.106.255.59    <none>        8000/TCP   4m40s
service/kubernetes-dashboard        ClusterIP   10.107.136.213   <none>        80/TCP     4m40s

NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/dashboard-metrics-scraper   1/1     1            1           4m41s
deployment.apps/kubernetes-dashboard        1/1     1            1           4m41s

NAME                                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/dashboard-metrics-scraper-dc6947fbf   1         1         1       4m41s
replicaset.apps/kubernetes-dashboard-6dbb54fd95       1         1         1       4m41s

Note: we may not get anything regarding the info about the kubernetes-dashboard until we run the following:

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml   
namespace/kubernetes-dashboard configured
serviceaccount/kubernetes-dashboard configured
service/kubernetes-dashboard configured
secret/kubernetes-dashboard-certs configured
secret/kubernetes-dashboard-csrf configured
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
secret/kubernetes-dashboard-key-holder configured
configmap/kubernetes-dashboard-settings configured
role.rbac.authorization.k8s.io/kubernetes-dashboard configured
clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard configured
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard configured
The ClusterRoleBinding "kubernetes-dashboard" is invalid: roleRef: Invalid value: rbac.RoleRef{APIGroup:"rbac.authorization.k8s.io", Kind:"ClusterRole", Name:"kubernetes-dashboard"}: cannot change roleRef

As we can see in the output from kubectl get all -n kubernetes-dashboard command, the pod and service for the Dashboard are already running.

So, all we have to do is setting up Ingress rules in order to access it via hostname.

Here is the dashboard-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: dashboard-ingress
  namespace: kubernetes-dashboard
spec:
  rules:
  - host: dashboard.info
    http:
      paths:
        - pathType: Prefix
          path: "/"
          backend:
            service:
              name: kubernetes-dashboard
              port:
                number: 80

The rules basically forwarding every request for dashboard.info to internal kubernetes-dashboard service. Note that the namespace kubernetes-dashboard is within the same as the pod/kubernetes-dashboard-6dbb54fd95-k85gz and the service/kubernetes-dashboard reside.

Create the ingress rules:

$ kubectl apply -f dashboard-ingress.yaml
ingress.networking.k8s.io/dashboard-ingress created  

$ kubectl get ingress -n kubernetes-dashboard
NAME                CLASS    HOSTS            ADDRESS        PORTS   AGE
dashboard-ingress   <none>   dashboard.info   192.168.64.7   80      108s

We need to put the information into /etc/hosts:

192.168.64.7    dashboard.info

With this setup, any requests coming to Minikube cluster, the Ingress controller takes over and then it will follow through the rules and forward those requests (dashboard.info) to Kubernetes internal service which is kubernetes-dashboard.

Now if we go to a browser and type in the domain name, dashboard.info. We can see the same page that we saw at the beginning of this post.

Ingress default backend

If none of the hosts or paths match the HTTP request in the Ingress rules, the traffic is routed to our default backend.

$ kubectl describe ingress dashboard-ingress -n kubernetes-dashboard
Name:             dashboard-ingress
Namespace:        kubernetes-dashboard
Address:          192.168.64.7
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
  Host            Path  Backends
  ----            ----  --------
  dashboard.info  
                     kubernetes-dashboard:80 (172.17.0.3:9090)
Annotations:      Events:
  Type            Reason  Age   From                      Message
  ----            ------  ----  ----                      -------
  Normal          CREATE  37m   nginx-ingress-controller  Ingress kubernetes-dashboard/dashboard-ingress
  Normal          UPDATE  37m   nginx-ingress-controller  Ingress kubernetes-dashboard/dashboard-ingress

For example, "404 page not found" response when the path is not defined in any of Ingress objects:

This post addressed the simplest case and did not setup https (TLS).

For more info about the Ingress, please check out this page: https://kubernetes.io/docs/concepts/services-networking/ingress/:

It has the info about fanout configuration routes traffic from a single IP address to more than one Service (single host).
configuration routes for subdomains (multiple hosts).
TLS

Refs