[EKS] aws load balancer controller를 활용한 ingress 생성 방안 2가지
0. 작성 취지
aws load balancer controller
를 사용해서 ingress에 annotations를 기입해서 생성하면 alb가 생성되고, service로 annotations를 기입해서 생성하면 nlb가 생성된다.
나도 여태까지는 이러한 구성이 전혀 문제가 없다고 생각했다.
하지만 aws summit seoul 2024에 직접 참여해서 GS 리테일 Amazon EKS의 모든 것: 무중단 운영부터 배포 자동화까지를 듣고 나니까 “k8s의 자원인 ingress, service를 무조건 alb, nlb와 연결시키는 것이 마냥 좋은 것은 아니구나” 라는 깨달음을 얻게 되었다.
그 이유는 eks 무중단 업그레이드 때문이다.
eks 버전 업그레이드는 3개월마다 자주 있는 이벤트이지만 자주 있는 이벤트임에도 불구하고 업그레이드 난이도는 경우에 따라서 최상이다.
특히 24시간 365일 장애 없이 동작해야 하는 경우에는 더더욱이 그렇다.
기존에는 route53
의 기중치 기반을 활용해서 eks blue/green 버전 업그레이드를 진행했더라면 이제는 alb
자체를 독립적으로 두기 때문에 alb listener
가중치 기반으로 eks blue/green 버전 업그레이드를 진행할 수 있게 된다는 소리이다.
깨달음을 얻은 김에 직접 테스트 해보고 적용해보려고 한다.
1. 테스트
(❗️ 사전 조건으로 aws load balancer controller
가 반드시 설치되어 있어야 합니다.)
1-1. ingress + alb 종속적으로 생성
해당 테스트는 ingress를 생성하면 alb가 자동으로 생성되는 테스트이다.
1-1-1. k8s 자원 생성
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
namespace: test
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
namespace: test
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: nginx-ingress
namespace: test
annotations:
alb.ingress.kubernetes.io/load-balancer-name: ALB_NAME
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/subnets: "SUBNET_NAME, SUBNET_NAME"
alb.ingress.kubernetes.io/security-groups: SECURITY_GROUP_ID
alb.ingress.kubernetes.io/tags: Name=ALB_NAME
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/certificate-arn: ACM_ARN
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
alb.ingress.kubernetes.io/ssl-redirect: '443'
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginx-svc
port:
number: 80
deployment
, service
, ingress
모두 생성되는 예제이다.
(❗️ namespace는 test에 생성되는 예제입니다.)
실제 프로비저닝이 정상적으로 이루어진 모습을 확인할 수 있다.
1-1-2. alb 자원 확인
실제 alb가 정상적으로 생성되어 있는 화면이다.
사진 하단에 나와있는 resource map
에서도 target group
이 모두 healthy
로 출력되는 것을 확인할 수 있다.
1-1-4. 도메인 등록
route53에 CNAME으로 등록해준다.
(❗️ 링크를 참고하면 alb와 route53이 같은 aws account라면 a 레코드로 등록하는 것이 비용 측면에서 유리합니다.)
1-1-3. 동작 확인
curl -I -L http://alb-integrated.may30.xyz
위 명령어를 통해서 정상적인 redirect가 되었는지 확인할 수 있고 웹 브라우저에 도메인을 입력하면 자동으로 http -> https redirect을 확인할 수 있다.
다음 테스트를 위해서 리소스를 정리해준다.
1-2. ingress / alb 독립적으로 생성
(❗️ 사전 조건으로 aws load balancer controller
가 반드시 설치되어 있어야 합니다.)
1-2-1. alb 자원 생성
위 사진과 같이 alb를 직접 console에서 생성해준다.
(❗️ 테스트 후 삭제된 alb입니다.)
(❗️ alb를 독립적으로 생성할 시 target group은 임시로 생성해서 바인딩해주어야 하며 alb 생성 완료 후 삭제해주시면 됩니다.)
1-2-2. k8s 자원 생성
우선 위 사진과 같이 비어있는 target group을 생성해주어야 한다.
(❗️ 빨간색 네모 박스 확인할 수 있듯이 80 port로 생성해주어야 합니다.)
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
namespace: test
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
namespace: test
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
---
apiVersion: elbv2.k8s.aws/v1beta1
kind: TargetGroupBinding
metadata:
name: nginx-tgb
namespace: test
spec:
serviceRef:
name: nginx-svc
port: 80
targetGroupARN: TARGETGROUP_ARN
비어있던 target group에 성공적으로 연결된 모습을 확인할 수 있다.
1-2-3. alb redirect listener 추가
http -> https redirect 기능 구현을 위해서 listener를 추가한다.
1-2-4. 도메인 등록
마찬가지로 route53에 CNAME으로 등록해준다.
1-2-5. 동작 확인
curl -I -L http://alb-separated.may30.xyz
정상적으로 redirect가 되는 모습을 확인할 수 있다.
2. 마치며
ingress와 alb 자원을 분리시키는 테스트를 해보았다.
ingress와 alb 자원을 분리시키면 eks 버전 업그레이드에 상당한 장점으로 작용될 것으로 보인다.
왜 그렇게 생각하는지에 대해서 조만간 eks 버전 업그레이드의 방안 내용을 기술한 블로그를 올리도록 하겠다.
댓글남기기