This repo is a documentation of steps taken to create an ALB Ingress Controller on Amazon EKS.
eksctl create cluster \
--managed \
--name sandbox-cluster
The command above creates a VPC with 3 public subnets, and 3 private subnets. The ALB Ingress Controller will need to know which subnets any new ALB it creates should service. Normally these are the public subnets.
NOTE: Change
sandbox-cluster
to your cluster name if you changed it from above.
For all the subnets in the VPC, make sure they are tagged accordingly:
- Key:
kubernetes.io/cluster/sandbox-cluster
- Value:
shared
Identify the 3 public subnets in the VPC, and confirm they are tagged as well:
- Key:
kubernetes.io/role/elb
- Value:
1
Identify the 3 private subnets so that Kubernetes knows it can use these for internal LBs, and confirm the following tag:
- Key:
kubernetes.io/role/internal-elb
- Value:
1
eksctl utils associate-iam-oidc-provider \
--region <your-region> \
--cluster sandbox-cluster \
--approve
All actions performed in your AWS account are subject to IAM permissions, and your (eventual) ALB Ingress Controller is no exception. Before the controller can create ALBs on your behalf, it needs to be granted the appropriate permissions to do so.
In this step, we're creating an IAM policy with the sufficient permissions to do what the ALB Ingress Controller should be able to do (e.g. create ALBs).
We'll use this policy in later steps to grant permissions to the controller.
IMPORTANT: Note down the ARN of the policy that you create.
aws iam create-policy \
--policy-name ALBIngressControllerPolicy \
--policy-document https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/iam-policy.json
arn:aws:iam::214400071163:policy/ALBIngressControllerPolicy
We'll use these entities to attach the IAM policy above to our controller.
kubectl apply -f \
https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/rbac-role.yaml
Our service account above will assume this IAM role, which will then grant the permissions it holds onto whatever uses the service account.
eksctl create iamserviceaccount \
--region ap-southeast-1 \
--name alb-ingress-controller \
--namespace kube-system \
--cluster sandbox-cluster \
--attach-policy-arn <the policy ARN from above> \
--override-existing-serviceaccounts \
--approve
Finally, we deploy the actual controller into the cluster.
kubectl apply -f \
https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/alb-ingress-controller.yaml
We'll need to configure the controller a bit more before it can run properly.
kubectl edit deployment.apps/alb-ingress-controller -n kube-system
In the editor that opens, add the --cluster-name=sandbox-cluster
line to the manifest.
If you are running your EKS cluster on Fargate, then you'll also need to add the --aws-vpc-id
and --aws-region
lines.
Your manifest should look something like this:
spec:
containers:
- args:
- --ingress-class=alb
- --cluster-name=sandbox-cluster
- --aws-vpc-id=vpc-03468a8157edca5bd # :: only on Fargate
- --aws-region=ap-southeast-1 # :: only on Fargate
kubectl get pods -n kube-system
for i in namespace deployment service ingress; do
kubectl apply -f \
https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.4/docs/examples/2048/2048-$i.yaml
done
Wait a few minutes for the ALB to provision. Since this is the first time the ALB is being created, it'll take a few minutes for it to come online.
Additions to the ALB after this point should be much faster.
After a few minutes, get the ingress URL:
kubectl get ingress/2048-ingress -n 2048-game
And visit the URL specified by ADDRESS
on your browser.