In Kubernetes,
Ingress
allows external users and client applications access to HTTP services. Ingress
consists of two components.
Ingress Resource
is a collection of rules for the inbound traffic to reach Services. These are
Layer 7 (L7) rules that allow hostnames (and optionally paths) to be directed to
specific Services in Kubernetes. The second component is the
Ingress Controller
which acts upon the rules set by the Ingress Resource, typically via an HTTP or
L7 load balancer. It is vital that both pieces are properly configured to route
traffic from an outside client to a Kubernetes Service.

NGINX is a popular choice for an Ingress Controller for a variety of features:

This tutorial illustrates how to set up a
Deployment in Kubernetes
with an Ingress Resource using NGINX as the Ingress Controller to route/load
balance traffic from external clients to the Deployment. This tutorial explains how to accomplish the following:

Install Helm in Cloud Shell

If you already have Helm client and Tiller installed on your cluster, you can skip to the next section.

Helm is a tool that streamlines installing and managing Kubernetes applications and resources. Think of it like apt/yum/homebrew for Kubernetes. Use of helm charts is recommended since they are maintained and typically kept up-to-date by the Kubernetes community.

Installing Tiller with RBAC enabled

Starting with Kubernetes v1.8+, RBAC is enabled by default. Prior to installing tiller we need to ensure we have the correct ServiceAccount and ClusterRoleBinding configured for the tiller service. This allows tiller to be able to install services in the default namespace.
Run the following command to install the server side tiller to the Kubernetes cluster with RBAC enabled.

Expose the hello-app Deployment as a Service by running the following command:

kubectl expose deployment hello-app

service "hello-app" exposed

Deploying the NGINX Ingress Controller via Helm

Kubernetes platform allows for administrators to bring their own Ingress
Controllers instead of using the cloud provider's built-in offering.

The NGINX controller, deployed as a Service, must be exposed for external
access. This is done using Service type: LoadBalancer on the NGINX controller
service. On Kubernetes Engine, this creates a Google Cloud Network (TCP/IP) Load Balancer with NGINX
controller Service as a backend. Google Cloud also creates the appropriate
firewall rules within the Service's VPC to allow web HTTP(S) traffic to the load
balancer frontend IP address. Here is a basic flow of the NGINX ingress
solution on Kubernetes Engine.

NGINX Ingress Controller on Kubernetes Engine

Deploy NGINX Ingress Controller with RBAC enabled

If your Kubernetes cluster has RBAC enabled, from the Cloud Shell, deploy an NGINX controller Deployment and Service by running the following command:

Wait a few moments while the GCP L4 Load Balancer gets deployed. Confirm that the nginx-ingress-controller Service has been deployed and that you have an external IP address associated with the service. Run the following command:

Notice the second service, nginx-ingress-default-backend. The default
backend is a Service which handles all URL paths and hosts the NGINX controller
doesn't understand (i.e., all the requests that are not mapped with an Ingress
Resource). The default backend exposes two URLs:

/healthz that returns 200

/ that returns 404

Configure Ingress Resource to use NGINX Ingress Controller

An Ingress Resource object is a collection of L7 rules for routing inbound traffic to Kubernetes Services. Multiple rules can be defined in one Ingress Resource or they can be split up into multiple Ingress Resource manifests. The Ingress Resource also determines which controller to utilize to serve traffic. This can be set with an annotation, kubernetes.io/ingress.class, in the metadata section of the Ingress Resource. For the NGINX controller, use the value nginx as shown below:

annotations: kubernetes.io/ingress.class: nginx

On Kubernetes Engine, if no annotation is defined under the metadata section, the
Ingress Resource uses the GCP GCLB L7 load balancer to serve traffic. This
method can also be forced by setting the annotation's value to gceas shown below:

annotations: kubernetes.io/ingress.class: gce

Lets create a simple Ingress Resource YAML file which uses the NGINX Ingress Controller and has one path rule defined by typing the following commands:

touch ingress-resource.yaml
nano ingress-resource.yaml

Copy the contents of ingress-resource.yaml
into the editor, then press Ctrl-X, then press y, then press Enter to save
the file.

The kind: Ingress dictates it is an Ingress Resource object. This Ingress Resource defines an inbound L7 rule for path /hello to service hello-app on port 8080.

From the Cloud Shell, run the following command:

kubectl apply -f ingress-resource.yaml

Verify that Ingress Resource has been created. Please note that the IP address
for the Ingress Resource will not be defined right away (wait a few moments for the ADDRESS field to get populated):

kubectl get ingress ingress-resource

NAME HOSTS ADDRESS PORTS AGE
ingress-resource * 80 `

Test Ingress and default backend

You should now be able to access the web application by going to the EXTERNAL-IP/hello
address of the NGINX ingress controller (from the output of the kubectl get service nginx-ingress-controller above).

http://external-ip-of-ingress-controller/hello

To check if the default-backend service is working properly, access any path (other than
the path /hello defined in the Ingress Resource) and ensure you receive a 404
message. For example:

http://external-ip-of-ingress-controller/test

You should get the following message:

Clean Up

From the Cloud Shell, run the following commands:

Delete the Ingress Resource object.

kubectl delete -f ingress-resource.yaml

ingress "demo-ingress" deleted

Delete the NGINX Ingress helm chart.

helm del --purge nginx-ingress

release "nginx-ingress" deleted

Delete the app.

kubectl delete service hello-app
kubectl delete deployment hello-app

service "hello-app" deleted
deployment "hello-app" deleted

Delete the Kubernetes Engine cluster by running the following command:

gcloud container clusters delete nginx-tutorial

The following clusters will be deleted.
- [nginx-tutorial] in [us-central1-f]
Do you want to continue (Y/n)? y
Deleting cluster nginx-tutorial...done.
Deleted [https://container.googleapis.com/v1/projects/ameer-1/zones/us-central1-f/clusters/nginx-tutorial].

Delete the ingress_resource.yaml file by running the following command: