How to Build Kubernetes Nginx Ingress Controller

NGINX Ingress controller works with both NGINX and NGINX Plus and supports the standard Ingress features - content-based routing and TLS/SSL termination...

By default, pods of Kubernetes services are not accessible from the external network, but only by other pods within the Kubernetes cluster. Kubernetes has a built‑in configuration for HTTP load balancing, called Ingress, that defines rules for external connectivity to Kubernetes services. Users who need to provide external access to their Kubernetes services create an Ingress resource that defines rules, including the URI path, backing service name, and other information. The Ingress controller can then automatically program a frontend load balancer to enable Ingress configuration. The NGINX Ingress Controller for Kubernetes is what enables Kubernetes to configure NGINX and NGINX Plus for load balancing Kubernetes services.


Ingress is the built‑in Kubernetes load‑balancing framework for HTTP traffic. With Ingress, you control the routing of external traffic. When running on public clouds like AWS or GKE, the load-balancing feature is available out of the box. You don’t need to define Ingress rules. In this post, I will focus on creating Kubernetes Nginx Ingress controller running on Vagrant or any other non-cloud based solution, like bare metal deployments. I deployed my test cluster on Vagrant, with kubeadm.

Create a Sample App Deployment

For this lab, let’s create two simple web apps based on dockersamples/static-site docker image. Those are Nginx containers that display application name which will help us to identify which app we are accessing. The result, both apps accessible through load balancer:

Sample App Deployment

Here is the app deployment resource, the two same web apps with a different name and two replicas for each:



And same for services:



Next, we’ll create above resources:


Create Nginx Ingress Controller

If you prefer Helm, installation of the Nginx Ingress controller is easier. This article is the hard way, but you will understand the process better.


All resources for Nginx Ingress controller will be in a separate namespace, so let’s create it:



The first step is to create a default backend endpoint. Default endpoint redirects all requests which are not defined by Ingress rules:



And to create a default backend service:



We will create those resources in ingress namespace:



Then, we need to create a Nginx config to show a VTS page on our load balancer:



And here is the actual Nginx Ingress controller deployment:


 cat > nginx-ingress-controller-deployment.yaml <<EOF apiVersion: extensions/v1beta1 kind: Deployment metadata:  name: nginx-ingress-controller spec:  replicas: 1  revisionHistoryLimit: 3  template:  metadata:  labels:  app: nginx-ingress-lb  spec:  terminationGracePeriodSeconds: 60  serviceAccount: nginx  containers:  - name: nginx-ingress-controller  image:  imagePullPolicy: Always  readinessProbe:  httpGet:  path: /healthz  port: 10254  scheme: HTTP  livenessProbe:  httpGet:  path: /healthz  port: 10254  scheme: HTTP  initialDelaySeconds: 10  timeoutSeconds: 5  args:  - /nginx-ingress-controller  - --default-backend-service=\$(POD_NAMESPACE)/default-backend  - --configmap=\$(POD_NAMESPACE)/nginx-ingress-controller-conf  - --v=2  env:  - name: POD_NAME  valueFrom:  fieldRef:  fieldPath:  - name: POD_NAMESPACE  valueFrom:  fieldRef:  fieldPath: metadata.namespace  ports:  - containerPort: 80  - containerPort: 18080 EOF 


Notice the \--v=2 argument, which is a log level and it shows the Nginx config diff on start. Don’t create Nginx controller yet.


Kubernetes and RBAC

Before we create Ingress controller and move forward you might need to create RBAC rules. Clusters deployed with kubeadm have RBAC enabled by default:


 cat > nginx-ingress-controller-roles.yaml <<EOF apiVersion: v1 kind: ServiceAccount metadata:  name: nginx --- kind: ClusterRole apiVersion: metadata:  name: nginx-role rules: - apiGroups:  - ""  resources:  - configmaps  - endpoints  - nodes  - pods  - secrets  verbs:  - list  - watch - apiGroups:  - ""  resources:  - nodes  verbs:  - get - apiGroups:  - ""  resources:  - services  verbs:  - get  - list  - update  - watch - apiGroups:  - extensions  resources:  - ingresses  verbs:  - get  - list  - watch - apiGroups:  - ""  resources:  - events  verbs:  - create  - patch - apiGroups:  - extensions  resources:  - ingresses/status  verbs:  - update --- kind: ClusterRoleBinding apiVersion: metadata:  name: nginx-role roleRef:  apiGroup:  kind: ClusterRole  name: nginx-role subjects: - kind: ServiceAccount  name: nginx  namespace: ingress EOF  kubectl create -f nginx-ingress-controller-roles.yaml -n=ingress 


So now you can create Ingress controller also:


⚡ kubectl create -f nginx-ingress-controller-deployment.yaml -n=ingress 


If you check your pods, you should get something like this:


Check your Pods

Create Ingress Rules for Applications

Everything is ready now. The last step is to define Ingress rules for load balancer status page:


 cat > nginx-ingress.yaml <<EOF apiVersion: extensions/v1beta1 kind: Ingress metadata:  name: nginx-ingress spec:  rules:  - host:  http:  paths:  - backend:  serviceName: nginx-ingress  servicePort: 18080  path: /nginx_status EOF 


And Ingress rules for sample web apps:


 cat > app-ingress.yaml <<EOF apiVersion: extensions/v1beta1 kind: Ingress metadata:  annotations: /  name: app-ingress spec:  rules:  - host:  http:  paths:  - backend:  serviceName: appsvc1  servicePort: 80  path: /app1  - backend:  serviceName: appsvc2  servicePort: 80  path: /app2 EOF 


Notice the / annotation. We are using /app1 and /app2 paths, but the apps don’t exist there. This annotation redirects requests to the /. You can create both ingress rules now:


⚡ kubectl create -f nginx-ingress.yaml -n=ingress ⚡ kubectl create -f app-ingress.yaml 

Expose Nginx Ingress Controller

The last step is to expose nginx-ingress-lb deployment for external access. We will expose it with NodePort, but we could also use ExternalIPs here:


 cat > nginx-ingress-controller-service.yaml <<EOF apiVersion: v1 kind: Service metadata:  name: nginx-ingress spec:  type: NodePort  ports:  - port: 80  nodePort: 30000  name: http  - port: 18080  nodePort: 32000  name: http-mgmt  selector:  app: nginx-ingress-lb EOF  kubectl create -f nginx-ingress-controller-service.yaml -n=ingress 


If you are running everything on VirtualBox, as I do, forward ports 30000 and 32000 from one Kubernetes worker node to localhost:


VBoxManage modifyvm "worker_node_vm_name" --natpf1 "nodeport,tcp,,30000,,30000" ⚡ VBoxManage modifyvm "worker_node_vm_name" --natpf1 "nodeport2,tcp,,32000,,32000" 


Also add domain to hosts file:


echo "" | sudo tee -a /etc/hosts 


You can verify everything by accessing at those endpoints: 

NOTE: You can access apps using DNS name only, not IP directly!

Any other endpoint redirects the request to default backend. Ingress controller is functional now, and you could add more apps to it. For any problems during the setup, please leave a comment. Don’t forget to share this post if you find it useful.


Having an Ingress is the first step towards the more automation on Kubernetes. Now, you can have automatic SSL with Let’s encrypt to increase security also. If you don’t want to manage all those configuration files manually, I suggest you look into Helm. Installing Ingress controller would be only one command. Stay tuned for the next one.

Subscribe to our newsletter
Sign up here to get the latest news, updates and special offers delivered directly to your inbox.
You can unsubscribe at any time

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More