일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- Benchmarks
- slow query
- Grafana
- Leaderboard
- blue-green
- 동등성
- 0 replica
- spring boot
- Salting
- Helm
- Strimzi
- Debezium
- docket
- virtualservice
- keda
- istio
- Database
- logback
- propogation
- hammerDB
- Kafka
- minreplica
- traceId
- Kubernetes
- MSSQL
- SW 마에스트로
- 스프링부트
- eks
- zset
- yml
- Today
- Total
김태오
쿠버네티스 환경에서 로드밸런서 비용 Istio Gateway로 쌀먹하기 본문
EKS에 떠있는 쿠버네티스의 트래픽을 관리할 때, 본래 서비스로 향하는 트래픽을 라우팅하기 위해 모듈 각각에 ALB를 하나씩 두어 트래픽을 각각 관리한다.
ingress:
enabled: true
className: "alb"
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/subnets: {서브넷명시}
alb.ingress.kubernetes.io/certificate-arn: {arn명시}
alb.ingress.kubernetes.io/ssl-redirect: '443'
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
가령 이런식이다.
values 파일에 arn(SSL을 위한 certificate), port등을 선언하여 ALB를 AWS에 띄운다.
여기서 문제는, 모든 로드밸런서(ALB)에 각각 시간별 요금이 책정되기 때문에 모듈이 늘어감에 따라 발생 비용이 커진다는 것이다. 트래픽이 아무리 작은 모듈(개발서버, 릴리즈서버 등)이라 할지라도 LCU가 다르지 않다면 로드밸런서 사용 비용은 같아 큰 손해를 본다는 느낌을 지울 수 없다.
하여 여기에 Istio Gateway + VirtualService를 사용하는 패턴을 도입할 수 있는데, Gateway 하나만을 선언하여 모든 모듈로 가능 트래픽을 NLB 하나만 두어 중심에서 관리할 수 있다.
우선 Global Gateway를 선언하자. 예시는 helm charts를 사용하였다.
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
name: global-gateway
namespace: istio-system
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- {host1}
- {host2}
tls:
httpsRedirect: true
- port:
number: 443
name: http-443
protocol: HTTP
hosts:
- {host1}
- {host2}
hosts section에 사용중인 모듈의 host를 모조리 때려박자.
다음으로 각 모듈에 VirtualService가 필요하다.
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: {module-name}
spec:
hosts:
- {host1}
- {host2}
gateways:
- istio-system/global-gateway
http:
- match:
- headers:
Host:
exact: {host1}
route:
- destination:
host: {app1}
port:
number: 8080
- match:
- headers:
Host:
exact: {host2}
route:
- destination:
host: {app2}
port:
number: 8080
이제 로드밸런서에 달려야 하는 cert들을 선언해줘야 한다. 이는 호스트별로 고유하므로 모든 cert를 하나의 Gateway(NLB)에 때려박아줘야 한다.
{
"metadata": {
"annotations": {
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internet-facing",
"service.beta.kubernetes.io/aws-load-balancer-ssl-cert": "{arn1}, {arn2} ....",
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "http",
"service.beta.kubernetes.io/aws-load-balancer-ssl-ports": "443"
}
}
}
이걸 다음 명령어로 패치해주면 된다.
kubectl patch svc istio-ingressgateway -n istio-system --patch-file {json명}
조심해야 할 것은 무엇일까?
우선 SPOF가 생긴다는 것이다. NLB에 문제가 생기면 모든 모듈로 향해야 하는 트래픽에 장애가 생기고 다운타임이 생긴다. 이런 부분은 레플리카로 해결해야 할 것이다.
다음으로 Quota에 부딛히는 것을 조심해야 하니, https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-limits.html 공식문서를 살펴보고 Target limit, cert limit, connection limit 등을 확인해볼 필요가 있다.
'Kubernetes' 카테고리의 다른 글
Keda를 사용한 pod replica 0으로 scale in 하기 (4) | 2024.10.09 |
---|