[EKS] alb-ingress-controller 사용해보기

DevOps/Kubernetes

[EKS] alb-ingress-controller 사용해보기

Jen'_' 2021. 8. 31. 16:03

주의 사항

2022.08.10 수정

해당 블로그에서 설치하는 AWS ALB Ingress Controller는 v1.1 버전으로 deprecated 상태입니다.

최신 버전인 AWS Load Balancer Controller v2.4를 설치하는 것이 권장됩니다.

https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/

테스트 순서

EKS 클러스터 생성합니다
worker node 역할에 추가로 정책을 붙입니다
alb-ingress-controller 배포합니다
ingress, deployment, service 배포합니다
host에 따라 웹페이지가 바뀌는지 확인합니다

1. EKS 클러스터 생성

1
2
3
4
5
6

eksctl create cluster --name <CLUSTER_NAME> --version 1.18 --region ap-northeast-2 \
--nodegroup-name <NODE_NAME> --nodes 2 \
--ssh-access --ssh-public-key <KEYNAME> --node-type t3.medium --managed --spot \
--vpc-public-subnets=<SUBNET_ID>
Colored by Color Scripter

cs

nlb 실습 때와 똑같이 eks 클러스터를 생성하였습니다

(node type은 t3.medium으로 하세요 t3.micro로 했다가 파드 2개도 생성이 안됨...ㅎㅎ)

2. worker node 역할에 정책 추가

alb를 원활히 제어하기 위한 permission 부여하는 것입니다

정책 내용:

https://kubernetes-sigs.github.io/aws-load-balancer-controller/v1.1/examples/iam-policy.json

3. alb-ingress-controller 배포

https://kubernetes-sigs.github.io/aws-load-balancer-controller/v1.1/guide/controller/setup/

기술 문서에 나와있는 순서대로 컨트롤러를 배포합니다

alb-ingress-controller.yaml

위의 사진처럼 Deployment 내의 spec.containers.args 를 자신의 상황에 맞게 수정한 뒤 배포해줍니다.

컨트롤러가 시작되었는지 확인합니다

$ kubectl get all -n kube-system

컨트롤러까지 생성된 모습입니다

4. ingress, deployment, service 배포

alb를 생성하고 호스트 2개를 생성해서 호스트에 따라서 각각의 서비스로 라우팅 하도록 하겠습니다

ingress.yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
  namespace: kube-system
  annotations:
    kubernetes.io/ingress.class: alb 
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: instance
    alb.ingress.kubernetes.io/subnets: <ALB생성할 SUBNET_ID>    
spec:
  rules:
  - host: aaa.example.com # [1]
    http:
      paths:
      - path: /* # [2]
        backend:
          serviceName: apache-svc # [3]
          servicePort: 80
  - host: bbb.example.com
    http:
      paths:
      - path: /*
        backend:
          serviceName: nginx-svc
          servicePort: 80          
   
           
Colored by Color Scripter

cs

[1] host : 해당 도메인 이름으로 접근하라는 요청에 대해서 처리 규칙을 적용합니다. 실제 자신의 도메인을 사용해야 합니다.

[2] path: 해당 경로에 들어온 요청을 어느 서비스로 전달할 것인지 정의합니다. 위 예시에서는 모든 경로의 요청을 backend에 정의된 서비스로 전달합니다. 여러 개의 path를 정의해 경로를 처리할 수도 있습니다.

[3] serviceName, servicePort: path로 들어온 요청이 전달될 서비스와 포트입니다. 즉 위 예시에서는 /*경로로 들어온 요청을 apache-svc 서비스의 80 포트로 전달합니다.

apache.yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

apiVersion: apps/v1
kind: Deployment
metadata:
  name: apache-deployment
  namespace: kube-system
  labels:
    app: httpd
spec:
  replicas: 2
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      containers:
      - name: apache
        image: httpd
        ports:
        - containerPort: 80
 
---
apiVersion: v1
kind: Service
metadata:
  name: apache-svc
  namespace: kube-system
spec:
  selector:
    app: httpd
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30010
  type: NodePort        

cs

인그레스의 종착점이 될 디플로이먼트와 서비스도 생성해야 합니다

aaa.example.com으로 들어온 요청은 apache-svc으로 들어가고 apache 파드로 도착합니다

bbb.example.com으로 들어온 요청은 nginx-svc으로 들어가고 nginx 파드로 도착합니다(코드생략)

$ kubectl get ing -n kube-system

Ingress 가 생성된 후, 실제로 사용이 가능하기까지는 약 1~2분의 시간이 소요됩니다. 물리적으로 HTTP 로드밸런서를 생성하고, 이 로드밸런서가 서비스가 배포되어 있는 노드에 대한 HealthCheck를 완료하고 문제가 없으면 서비스를 제공하는데, HealthCheck 주기가 1분이기 때문에, 1~2분 정도를 기다려 주는 게 좋습니다.

$ kubectl get svc -n kube-system