Create Ingress Controller

Table of contents

Create Ingress Controller
1. Ingrees Controller
2. Create AWS Load Balancer Controller
  1. Create AWS Load Balancer Controller
  2. Add Controller to Cluster

Ingrees Controller

In this lab, we will use AWS Load Balancer Controller for Ingress Controller.

The AWS ALB Ingress Controller has been rebranded to AWS Load Balancer Controller.

Ingress is a rule and resource object that defines how to handle requests, primarily when accessing from outside the cluster to inside the Kubernetes cluster. In short, it serve as a gateway for external requests to access inside of the cluster. You can set up it for load balancing for external requests, processing TLS/SSL certificates, routing to HTTP routes, and so on. Ingress processes requests from the L7.

In Kubernetes, you can also externally expose to NodePort or LoadBalancer type in Service object, but if you use a Serivce object without any Ingress, you must consider detailed options such as routing rules and TLS/SSL to all services. That’s why Ingress is needed in Kubernetes environment.

Ingress means the object that you have set up rules for handling external requests, and Ingress Controller is needed for these settings to work. Unlike other controllers that run as part of the kube-controller-manager, the ingress controller is not created with the cluster by nature. Therefore, you need to install it yourself.

Create AWS Load Balancer Controller

The AWS Load Balancer Controller manages AWS Elastic Load Balancers for a Kubernetes cluster. The controller provisions the following resources.

It satisfies Kubernetes Ingress resources by provisioning Application Load Balancers.
It satisfies Kubernetes Service resources by provisioning Network Load Balancers.

The controller was formerly named the AWS ALB Ingress Controller. There are two traffic modes supported by each type of AWS Load Balancer controller:

Instance(default): Register nodes in the cluster as targets for ALB. Traffic reaching the ALB is routed to NodePort and then proxied to the Pod.
IP: Register the Pod as an ALB target. Traffic reaching the ALB is routed directly to the Pod. In order to use that traffic mode, you must explicitly specify it in the ingress.yaml file with comments.

Create a folder named manifests in the root folder (for example, /home/ec2-user/environment/) to manage manifests. Then, inside the manifests folder, create a folder alb-controller to manage the manifest associated with the ALB Ingress Controller.

  cd ~/environment

  mkdir -p manifests/alb-ingress-controller && cd manifests/alb-ingress-controller

  # Final location
  /home/ec2-user/environment/manifests/alb-ingress-controller

Before deploying the AWS Load Balancer controller, we need to do some things. Because the controller operates over the worker node, you must make it accessible to AWS ALB/NLB resources through IAM permissions. IAM permissions can install IAM Roles for ServiceAccount or attach directly to IAM Roles on the worker node.

First, create IAM OpenID Connect (OIDC) identity provider for the cluster. IAM OIDC provider must exist in the cluster(in this lab, eks-demo) in order for objects created by Kubernetes to use service account which purpose is to authenticate to API Server or external services.
```
 eksctl utils associate-iam-oidc-provider \
 --region ${AWS_REGION} \
 --cluster eks-demo \
 --approve
```

Let’s find out a little more here.

The IAM OIDC identity provider you create can be found in Identity providers menu on IAM console or in the commands below.
Check the OIDC provider URL of the cluster through the commands below.
Result from the command have the following format:
```
https://oidc.eks.ap-northeast-2.amazonaws.com/id/8A6E78112D7F1C4DC352B1B511DD13CF
```
Copy the value after /id/ from the output above, then execute the command as shown below.
```
aws iam list-open-id-connect-providers | grep 8A6E78112D7F1C4DC352B1B511DD13CF
```
If the result appears, IAM OIDC identity provider is created in the cluster, and if no value appears, you must execute the creation operation again.

Create an IAM Policy to grant to the AWS Load Balancer Controller.

 curl -o iam-policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.4.4/docs/install/iam_policy.json

 aws iam create-policy \
 --policy-name AWSLoadBalancerControllerIAMPolicy \
 --policy-document file://iam-policy.json

Create ServiceAccount for AWS Load Balancer Controller.

 eksctl create iamserviceaccount \
 --cluster eks-demo \
 --namespace kube-system \
 --name aws-load-balancer-controller \
 --attach-policy-arn arn:aws:iam::$ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy \
 --override-existing-serviceaccounts \
 --approve

When deploying an EKS cluster, you can also add the IAM policy associated with the AWS Load Balancer Controller to the Worker node in the form of Addon. However, in this lab, we will conduct with the reference, here.

Also, please refer simple hands on lab about IAM roles for service accounts(IRSA ) in here.

Add Controller to Cluster

Add AWS Load Balancer controller to the cluster. First, install cert-manager to insert the certificate configuration into the Webhook. Cert-manager is an open source that automatically provisions and manages TLS certificates within a Kubernetes cluster.
```
 kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.5.4/cert-manager.yaml
```

Download Load balancer controller yaml file.

 wget https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases/download/v2.4.4/v2_4_4_full.yaml

In yaml file, edit cluster-name to eks-demo.

 vi v2_4_4_full.yaml

 spec:
     containers:
     - args:
         - --cluster-name=eks-demo # Insert EKS cluster that you created
         - --ingress-class=alb
         image: amazon/aws-alb-ingress-controller:v2.4.4

And remove the ServiceAccount yaml spec written in the yaml file. This is because we have already created a ServiceAccount for AWS Load Balancer Controller. Delete the contents below and save the yaml file.

After done.

Deploy AWS Load Balancer controller file.
```
 kubectl apply -f v2_4_4_full.yaml
```
Check that the deployment is successed and the controller is running through the command below. When the result is derived, it means success.
```
 kubectl get deployment -n kube-system aws-load-balancer-controller
```
In addition, the command below shows that service account has been created.
```
 kubectl get sa aws-load-balancer-controller -n kube-system -o yaml
```

Pods running inside the cluster for the necessary functions are called Addon. Pods used for add-on are managed by the Deployment, Replication Controller, and so on. And the namespace that this add-on uses is kube-system. Because the namespace is specified as kube-system in the yaml file, it is successfully deployed when the pod name is derived from the command above. You can also check the relevant logs with the commands below.

kubectl logs -n kube-system $(kubectl get po -n kube-system | egrep -o "aws-load-balancer[a-zA-Z0-9-]+")

Detailed property values are available with the commands below.

ALBPOD=$(kubectl get pod -n kube-system | egrep -o "aws-load-balancer[a-zA-Z0-9-]+")

kubectl describe pod -n kube-system ${ALBPOD}