Set Kubernetes Ingress Controller on AWS
Introduction:
Kubernetes Ingress is a powerful API object that allows you to manage external access to your Kubernetes services. An Ingress Controller is a software component that reads the Ingress resource information and configures the HTTP(S) load balancing rules accordingly.
Amazon Web Services (AWS) offers its own Ingress Controller for Kubernetes, called the AWS Load Balancer Controller. It is a Kubernetes controller that manages Elastic Load Balancers (ELBs) and Application Load Balancers (ALBs) on AWS.
In order to set up the AWS Load Balancer Controller for Kubernetes, you will need to follow these general steps:
- Install the AWS Load Balancer Controller using Kubernetes manifests or Helm charts.
- Configure the controller to use an IAM role or IAM user that has the appropriate permissions to manage load balancers on AWS.
- Define Ingress resources in your Kubernetes cluster to specify the routing rules and load balancing configurations for your services.
- Verify that the load balancer resources are created and configured correctly in AWS.
Here are more detailed steps to set up the AWS Load Balancer Controller on Kubernetes:
- Create an IAM policy and role for the AWS Load Balancer Controller
The AWS Load Balancer Controller requires an IAM policy and role to be created in order to manage the load balancers in your AWS account. You can create these resources manually or use an existing policy and role with the appropriate permissions. The AWS documentation provides sample IAM policies and roles that you can use as a starting point.
- Install the AWS Load Balancer Controller using Kubernetes manifests or Helm charts
You can install the AWS Load Balancer Controller using Kubernetes manifests or Helm charts. The manifests are YAML files that define the Kubernetes resources required to deploy the controller. The Helm charts provide a package manager for Kubernetes that simplifies the deployment and management of complex applications.
To install the controller using manifests, you can download the YAML files from the AWS documentation and apply them to your Kubernetes cluster using the kubectl apply
command.
To install the controller using Helm charts, you will need to first install Helm on your machine and then add the AWS Load Balancer Controller repository to Helm. You can then install the controller using the helm install
command.
- Configure the AWS Load Balancer Controller
Once the controller is installed, you will need to configure it to use the IAM policy and role that you created in step 1. You can do this by setting environment variables or using Kubernetes ConfigMaps. The AWS documentation provides more details on the configuration options for the controller.
- Define Ingress resources in Kubernetes
To use the AWS Load Balancer Controller, you will need to define Ingress resources in your Kubernetes cluster. An Ingress resource specifies the routing rules and load balancing configuration for your services. You can define Ingress resources using YAML files or using the kubectl create ingress
command.
- Verify the load balancer resources in AWS
Finally, you will need to verify that the load balancer resources are created and configured correctly in AWS. You can do this using the AWS Console or the AWS CLI. The AWS Load Balancer Controller should automatically create and manage the load balancer resources based on the Ingress resources defined in your Kubernetes cluster.
In conclusion, setting up the AWS Load Balancer Controller for Kubernetes involves installing and configuring the controller, defining Ingress resources in Kubernetes, and verifying the load balancer resources in AWS. Once set up, the controller provides a powerful and flexible way to manage external access to your Kubernetes services on AWS.
This article focuses on the following pointers:
- What is Kubernetes Ingress?
- Demo 1: Create a Kubernetes cluster on AWS
- Demo 2:Â Create an Ingress(nginx) loadbalancer controller
What is Kubernetes Ingress?
By now you would have understood that Kubernetes Ingress is a collection of routing rules that govern how external users access services running on the Kubernetes cluster.
Functionalities provided by Kubernetes Ingress:
- Layer 7 load balancing – As discussed above
- SSL Termination – Secure your connection with SSL termination
- Name-based virtual hosting – Defines routes to services based on incoming request’s hostnames. This allows you to run multiple services on the same IP address.
Let’s get further into the details. Ingress is split into two main parts – Ingress resources and ingress controller
- Ingress Resources
- Ingress Resources defines how you want the requests to the services to be routed. It contains the main routing rules.
- Ingress controller
- What ingress controller does is, it reads the ingress resource’s information and process the data accordingly. So basically, ingress resources contain the rules to route the traffic and ingress controller routes the traffic.
Routing using ingress is not standardized i.e. different ingress controller have different semantics (different ways of routing).
At the end of the day, you need to build your own ingress controller based on your requirements and implementations. Ingress is the most flexible and configurable routing feature available.
Demo 1: Create a Kubernetes cluster on AWS
The first thing that’s needed to deploy any kind of service/application on Kubernetes, is a cluster. Every cluster consists of one master and single or multiple nodes depending on the requirement. In this demo, I’m going to show you how to create a Kubernetes cluster on AWS.
Step 1: Create an instance, name it kubectl. We’re going to deploy the cluster using this instance. This instance only has the kubectl tool installed that will interact with the master, it does not have Kubernetes installed on it.
Note: We have three services in AWS that we’ll be using here – s3 bucket which stores all the files, EC2 which is used to create an instance and deploy the service and IAM which is used to configure permissions. These three pictures have no clue about each other’s existence and hence Roles come into the picture.
Step 2: Create a Role in the IAM section
Attach the appropriate policy to your Role (for this example admin access is given)
Next, it’ll ask you to add tags which are optional. In my case, I haven’t attached any tags.
Give your Role a name and review the policies assigned to it and then press Create role.
Step 3: Attach the role to the instance. Go to instance settings -> Attach/Replace IAM role -> attach the role you’ve created and then click on Apply.
Step 4: Once you’ve created the instance and attached the role, open the command emulator i.e. cmder or putty and connect to the AWS instance. I’ll be using cmder for this demo. Once you’ve connected to the instance, update the repository and install aws-cli using the following commands:
$ sudo apt-get install $ sudo apt-get install awscli
Step 5: Install and set up kubectl using the following commands:
$ sudo apt-get update && sudo apt-get install -y apt-transport-https $ curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - $ echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list $ sudo apt-get update $ sudo apt-get install -y kubectl
Step 6: Install Kops on the system using the following commands:
$ wget https://github.com/kubernetes/kops/releases/download/1.10.0/kops-linux-amd64 $ chmod +x kops-linux-amd64 $ mv kops-linux-amd64 /usr/local/bin/kops
Step 7: With Kops installed, you must configure a domain for your cluster to access it from outside. Create a hosted zone for it
Services-> Route53-> Hosted zones-> Create Hosted Zone
Add a domain name for your cluster, change the type from Public Hosted Zone to Private Hosted Zone for Amazon VPC and copy your instance VPC ID from the instance page to the VPC ID column and add the region you want to create your hosted zone in.
Copy the VPC ID
The above screenshot shows where to add Domain name and VPC ID
You can now see your Hosted Zone is created.
Step 8: Create a bucket as the same name as domain name using the following command:
$ aws s3 mb s3://kube-demo.com
Once you’ve created the bucket, execute the following command:
$ export KOPS_STATE_STORE=s3://kube-demo.com
Step 9: Before you create the cluster, you’ll have to create SSH public key.
$ ssh-keygen
Enter file where you want your key pair to be saved and create a password to access the ssh public key. In this case, I’ve chosen the default location and used no password.
Step 10: Now that you’ve created the SSH key, create the cluster using the following command:
$ kops create cluster –cloud=aws –zones=us-east-1a –name=useast1.kube-demo.com –dns-zone=kube-demo.com –-dns private
And then update the cluster
$ kops update cluster useast1.kube-demo.com
This will create the resources needed for your cluster to run. It will create a master and two node instances.
Now when you check your instances, you would see three new instances that would have got created. One of them will be your master node and the other two your worker nodes and TADA! Your cluster is created.
Your s3 bucket will now have some folder in it, which is basically your cluster configuration file.
Step 11: Now if you ssh into your master node and do a kubectl get nodes, you should find your nodes in the ready state.
$ ssh -i .ssh/id_rsa admin@ipv4-public-ip-of-master $ kubectl get nodes
Demo 2: Create an Ingress(nginx) loadbalancer controller
Step 1: The following command is mandatory for all configurations
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml
Step 2: Now the next command depends upon the environment you’re using your cluster in.
For this example we’re going to use AWS L4 configuration:
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/aws/service-l4.yaml $ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/aws/patch-configmap-l4.yaml
Step 3: Check your pods to see all the Ingress pods are up and running
$ kubectl get pods --all-namespaces
Step 4: Check the services to verify Ingress service is working
$ kubectl get svc --all-namspaces
Step 5: Now create a deployment like we did before
Here we’re using an httpd deployment as an example
Step 6: Create an httpd clusterip service
$ kubectl create service clusterip httpd --tcp=80:80
Step 7: Curl the service IP to make sure it is attached to the pods
$ curl <Cluster IP address>
Step 8: Now, create an ingress rule for your service so you can access the service at /test to route the external traffic.
$ vi ingress.yaml apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test-ing annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - http: paths: - path: /test backend: serviceName: httpd servicePort: 80
Step 9: Deploy the Ingress rule
$ kubectl apply -f ingress.yaml
Step 10: Now copy the Ingress service external IP and add /test to it in your browser to verify
This exact same thing can be done on other cloud platforms as well. I have used this Installation guide for my environment setup which also has a detailed explanation of the installations on other platforms.
Of course, this was a small demo of routing traffic but if implemented well, it can do wonders. Games like Pokémon Go are deployed on Kubernetes and uses Ingress. I’m sure all of you must have heard, if not played the highly trending game, Pokémon Go. Now the traffic shot up beyond the company’s expectations and the only reason they were able to handle so much traffic because of Kubernetes.