AWS Load Balancer Controller — EKS com ALB!

Neste post, irei demonstrar como disponibilizar um balanceador de carga (ALB) através do Amazon Elastic Kubernetes Service (EKS), duas poderosas ferramentas disponíveis hoje dentro da Amazon Cloud.

O AWS Load Balancer Controller surgiu a partir da necessidade em que os arquitetos/engenheiros da nuvem AWS, tiveram ao manusear o serviço de Load Balancer, por seus clusters EKS! Em sua primeira etapa, seu nome era “ALB Ingress Controller”, acredito (opinião pessoal) que esta primeira escolha era pelo fato de que, o uso mais comum de “ingress” era (e ainda é) o NGINX Ingress Controller, que por muitas vezes (recomendado) e provisionado com um NLB (Network Load Balancer).

A forma que o controlador trabalha e bem simples de se entender: Ele cria e configura seus load-balancers através de manifestos kubernetes, conseguindo então criar um conjunto de regras baseadas em paths, hosts e etc. Para trabalhar com o controlador existem duas formas, sendo no modo instancia (roteando o tráfego aos nodes) e no modo IP (comum junto ao serviço Fargate ou quando configurado CNI). No primeiro modo, seus services precisam estar declarados como NodePort, seus aplicativos vão estar expostos por portas obtidas pelo node (afinal, o ALB e um balanceador de APLICAÇÃO, logo, ele precisa realizar o healthCheck na APLICAÇÃO) portanto, tome cuidado com sua estrutura de rede (security group, subnets e etc). Já na segunda opção, o tráfego e roteado direto ao POD, bem comum de ser utilizado junto ao serviço do AWS Fargate.

Bom, agora que estamos contextualizados, iremos seguir para a parte prática. Nesta documentação, não irei provisionar o cluster EKS, nem a parte de VPC, então para seguir com o tutorial, esteja com estes requisitos essenciais, prontos. E lembre-se, as subnets que vão hospedar o balanceador, precisam de algumas tags específicas, lembre-se de marca-lás.

Obs: Meu cluster EKS está na versão 1.24!

Passo N°1: INSTALE O EKSCTL em sua Bastion / host que irá interagir com o cluster.

Instalação em host Unix:

# for ARM systems, set ARCH to: `arm64`, `armv6` or `armv7`
ARCH=amd64
PLATFORM=$(uname -s)_$ARCH

curl -sLO “https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$PLATFORM.tar.gz"

# (Optional) Verify checksum
curl -sL “https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_checksums.txt" | grep $PLATFORM | sha256sum — check

tar -xzf eksctl_$PLATFORM.tar.gz -C /tmp && rm eksctl_$PLATFORM.tar.gz

sudo mv /tmp/eksctl /usr/local/bin

Passo N°2: De as permissões necessárias para o controlador, por meio de ServiceAccounts e IAM Roles/Policys:

Crie um IAM OIDC provider:

eksctl utils associate-iam-oidc-provider \ — region <region-code> \ — cluster <your-cluster-name> \ — approve

Faça o download da policy para o AWS Load Balancer Controller:

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

Crie uma nova policy a partir do arquivo baixado:

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

Crie a IAM role e a SA para o controlador:

eksctl create iamserviceaccount \ — cluster=<cluster-name> \ — namespace=kube-system \ — name=aws-load-balancer-controller \ — attach-policy-arn=arn:aws:iam::<AWS_ACCOUNT_ID>:policy/AWSLoadBalancerControllerIAMPolicy \ — override-existing-serviceaccounts \ — region <region-code> \ — approve

Perfeito, você concluíndo estas etapas com exito, já pode efetuar o deploy do controlador dentro do seu cluster! Caso queira conferir algum ponto, as IAM Roles e Policys podem ser vistas pelo painel da AWS, e a SA pode ser consultada na namespace kube-system.

Bom, agora temos duas opções de “deploy”, sendo pelo Helm Chart e por manifestos kubernetes. Neste documento, vou seguir com a implementação via manifesto.

Passo N°3: Instale o Cert-Manager:

A instalação e bem simples e necessária, pois o cert-manager fornecerá certificado para os webhooks:

kubectl apply — validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.5.4/cert-manager.yaml

Passo N4° Aplique o deployment do controllador.

Realize o download do arquivo YAML:

curl -Lo v2_4_7_full.yaml https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases/download/v2.4.7/v2_4_7_full.yaml

remova as linhas 561 & 569:

sed -i.bak -e ‘561,569d’ ./v2_4_7_full.yaml

Dentro do arquivo, substitua o parametro “your-cluster-name” dentro da seção de deployment, pelo nome do seu cluster.

Após concluir estas etapas, você pode aplicar o seu manifesto que o controlador irá ficar disponível. \o/

Por motivo de boas práticas, recomendo você a utilizar os parametros de ingressclass atráves de manifestos.

Agora, antes de criarmos nosso ALB, recomendo você, a criar manualmente um security Group que o balancer vai utilizar. Caso você não faça isso, o controlador vai criar um automaticamente, e em muito dos casos, acaba saindo dos padrões esperados (nomes,tags e etc). Nesta demo, eu criei um SG em minha VPC, que tem acesso liberado (ALL) nas portas TCP da rede. Com este ponto OK, podemos realizar a implementação de um aplicativo simples, escolhi o nginx para esta demo:

Aplico os seguintes YAMLS:

Service:

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: nginx
  name: nginx
spec:
  ports:
  - name: "80"
    port: 80 
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: NodePort

Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        ports:
        - containerPort: 80
        resources: {}

E A CEREJA DO BOLO, O INGRESS:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: nginx
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing ##Caso queira um ALB privado, declare esta anotação como Internal
    alb.ingress.kubernetes.io/target-type: instance
    alb.ingress.kubernetes.io/tags: Environment=teste,Team=Devops
      #kubernetes.io/ingress.class: alb ##Caso vc não utilize a implementacao do IngressClass, deve descomentar esta anotação e comentar o IngressClassName na seção SPEC abaixo:
    alb.ingress.kubernetes.io/security-groups: sg-0df9ba7c303b6ad62 ##ID DO SEU SECURITY GROUP
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: nginx 
              port:
                number: 80
      host: teste.oliveiragustavo.com.br

As anotações que podemos fazer neste ingresso são diversas, no exemplo procurei ser bem simples e objetivo. Você pode por exemplo, usar o mesmo ALB para disponibilizar diversos serviços com hosts (dns) diferentes com as anotações de grupo (alb.ingress.kubernetes.io/group.name), o controlador vai atuar da mesma maneira (expondo uma porta alta no node e criando um TargetGroup NOVO para receber e encaminhar o tráfego ao pod), também e possível associar certificados do ACM, regras TLS, regras de healthcheck e por ai vai. Recomendo muito também o uso da ingress class e ingress params, pois além de ajudar você a criar padrões de configuração, evitam que você tenha problemas com múltiplos controladores sendo executados no mesmo cluster.

Aplicando os YAMLS demonstrados aqui, o resultado não poderia ser outro, obtive sucesso na minha chamada HTTP para o serviço NGINX!!

Espero que este post tenha ajudado você que leu ate aqui, até mais!