Instalacja AWS Load Balancer Controller na klastrze EKS

Jak skonfigurować klaster EKS, aby móc w pełni korzystać z Application Load Balancer? W poniższym wpisie, przedstawię proces instalacji oraz konfiguracji kontrollera ALB, a na koniec sprawdzimy czy wszystko działa jak powinno.

Co potrzebne na start?

Aby zacząć pracę, potrzebujemy trzech rzeczy.
1. Utworzony klaster AWS EKS, jak go postawić opisywałem cały proces w innym poście: https://cloud-devops.pl/tworzenie-klastra-kubernetes-przy-pomocy-aws-eks/
2. Musimy utworzyć IAM OIDC provider dla naszego klastra, jak to zrobić odysłam do dokumentacji AWS: https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html
3. Dodatkowo potrzebujemy mieć skonfigurowane lokalnie AWS CLI, kubectx oraz zainstalowany Helm, który użyjemy do instalacji aws-load-balancer-controller

Zaczynamy!

W pierwszej kolejności, musimy uzyskać OIDC provider URL, uzyskamy go za pomocą polecenia

aws eks describe-cluster --name LearningCluster --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5

Adres z wyniku zapiszcie sobie gdziekolwiek, ponieważ będzie nam potrzebny za chwilę do dalszych prac.

Tworzenie IAM Role

Tworzymy sobie plik load-balancer-role-trust-policy.json, w którym będzie opisana nasza polityka

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::111111111111:oidc-provider/oidc.eks.eu-central-1.amazonaws.com/id/0F8A4524FB37048572277D14560C421C"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "oidc.eks.eu-central-1.amazonaws.com/id/0F8A4524FB37048572277D14560C421C:aud": "sts.amazonaws.com",
                    "oidc.eks.eu-central-1.amazonaws.com/id/0F8A4524FB37048572277D14560C421C:sub": "system:serviceaccount:kube-system:aws-load-balancer-controller"
                }
            }
        }
    ]
}

1. Identyfikator 111111111111 – zamieniamy na swój account ID.
2. Natomiast wszystkie wystąpienia oidc.eks.eu-central-1.amazonaws.com/id/0F8A4524FB37048572277D14560C421C zamieniamy na adres, który otrzymaliśmy w poprzednim kroku 🙂

Tworzymy rolę, przy pomocy polecenia

aws iam create-role --role-name AmazonEKSLoadBalancerControllerRole --assume-role-policy-document file://"load-balancer-role-trust-policy.json"

Teraz musimy sobie pobrać najnowszę politykę IAM dla kontrolera, pobieramy ją przy pomocy polecenia

curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.11.0/docs/install/iam_policy.json

A następnie tworzymy na podstawie pobranego pliku polityję IAM na AWS przy pomocy polecenia

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

Powyżej utworzoną politykę, musimy przypisać do wcześniej utworzonej roli, robimy to przy pomocy polecenia

aws iam attach-role-policy --policy-arn arn:aws:iam::177394270612:policy/AWSLoadBalancerControllerIAMPolicy --role-name AmazonEKSLoadBalancerControllerRole

Przedostatnim krokiem jest utworzenie service account dla ALB, więc utwórzmy sobie plik aws-load-balancer-controller-service-account.yaml, a w nim

apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/name: aws-load-balancer-controller
  name: aws-load-balancer-controller
  namespace: kube-system
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::111111111111:role/AmazonEKSLoadBalancerControllerRole

Jeżeli robiłeś wszystko zgodnie z tym co opisywałem, to w powyższym pliku wystarczy zmienić 111111111111, na swoje AccountId. Ostatnim krokiem jest dodanie powyższego manifestu, poprzez wykonanie polecenia

kubectl apply -f aws-load-balancer-controller-service-account.yaml

I na tym etapie, ostatnia rzecz jaka nam została, to instalacja kontrolera oraz test, czy wszystko działa.

Instalacja AWS Load Balancer Controller przy pomocy Helm

Zanim przejdziemy do instalacji kontrolera, musimy wykonać bardzo ważną rzecz, aby kontroler wiedział, jakich subnetów ma używać, dokładnie chodzi o otagowanie subnetów. Dokładnie chodzi o ty, aby publiczne subnety otagować w poniższy sposób

kubernetes.io/role/elb 	1 or ``
kubernetes.io/cluster/nazwa_klastra 	owned or shared

Natomiast prywatne

kubernetes.io/role/internal-elb 	1 or ``
kubernetes.io/cluster/nazwa_klastra 	owned or shared

Tag z nazwą klastra, jest zależny od tego jakiej wersji będziecie używać, zgodnie z dokumentacją:

The cluster tag is not required in versions v2.1.2 to v2.4.1, unless a cluster tag for another cluster is present.

W naszym wypadku jest to wersja v2.11.0, więc musimy dodać ten tag. Więcej informacji znajdziecie pod tym adresem https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/subnet_discovery/ oraz https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html

Ok, ostatnim krokiem do sukcesu jest instalacji kontrolera przy pomocy Helm, robimy to z pomocą polecenia

helm install aws-load-balancer-controller eks/aws-load-balancer-controller   -n kube-system   --set clusterName=LearningCluster   --set serviceAccount.create=false   --set serviceAccount.name=aws-load-balancer-controller --set vpcId=vpc-0a106d2b28f0a1b5c --set region=eu-central-1

Tutaj bardzo ważna rzecz, musimy ustawić swoje vpcId oraz region, aby instalacja przeszła pomyślnie. Jeżeli zrobiliśmy wszystko poprawnie, to poniższe polecenie

 k get po -n kube-system | grep aws-load-balancer-controller

Powinno nam zwrócić 2 rekordy ze statusem running, jak poniżej

Test kontrolera AWS Load Balancer

Ostatni krok jaki nam został to test, czy wszystko poprawnie skonfigurowaliśmy. W tym celu potrzebujemy utworzyć 3 pliki

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  selector:
    matchLabels:
      app: nginx-deploy
  template:
    metadata:
      labels:
        app: nginx-deploy
    spec:
      containers:
        - name: nginx-deploy
          image: nginx
          resources:
            limits:
              memory: "128Mi"
              cpu: "500m"
          ports:
            - containerPort: 80

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-deploy
spec:
  selector:
    app: nginx-deploy
  type: NodePort
  ports:
    - port: 80
      targetPort: 80

ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/tags: Environment=Dev
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:eu-central-1:177394270612:certificate/e4550623-fd28-4152-a303-d49a153effff
    alb.ingress.kubernetes.io/ssl-redirect: '443'
  labels:
    name: nginx-ingress
spec:
  ingressClassName: alb
  rules:
    - host: ingress.cloud-devops.eu
      http:
        paths:
          - pathType: Prefix
            path: "/"
            backend:
              service:
                name: nginx-deploy
                port:
                  number: 80

W powyższym ingresie trzba dokonać kilku zmian:

alb.ingress.kubernetes.io/certificate-arn – tutaj należy podać ARN do certyfikatu AWS waszej domeny
host: ingress.cloud-devops.eu – w tym miejscu należy podać domenę, na której ma otworzyć Wam się deploy

Jeżeli wszystko ok, to po wykonaniu polecenia

k get ingress

Powinniście zobaczyć podobny wynik do mojego

Dodawania LB chwilę trwa, więc trzeba się uzbroić w cierpliwość i międzyczasie, w Route53 o ile macie tam swoją domenę, trzeba dodać alias tzn przekierować domenę ustawioną w ingress, na DNS load balancera. Po tych wszystkich zabiegach, po wejściu pod adres domeny, powinniście zobaczyć poniższy ekran

To by było na tyle, odnośnie instalacji oraz konfiguracji kontrolera ALB na klastrze EKS. Mam nadzieję, że mój post komuś się przyda 🙂