AWS EKS Loadbalancer controller
목차
EKS에 로드밸런서를 생성하면서 lb 서비스만 만들면 되는데 왜 컨트롤러를 생성하지? 라는 의문이든다.
로드밸런서 서비스만 있는경우와 컨트롤러가 있는경우 다음과 같은 차이가 있다.
- 로드 밸런서 서비스만 있는 경우:
- 사용자가 직접 로드 밸런서 리소스를 생성하고 관리해야 합니다.
- 로드 밸런서 리소스가 동적으로 생성되지 않으므로, 수동으로 관리되어야 합니다.
- 파드의 스케일링 및 상태 변경에 대한 자동 대응이 없으며, 사용자가 수동으로 로드 밸런서 리소스를 업데이트해야 합니다.
- 로드 밸런서 컨트롤러가 있는 경우:
- 로드 밸런서 컨트롤러는 사용자 대신에 로드 밸런서 리소스를 동적으로 생성하고 관리합니다.
- 파드의 생성, 삭제 또는 상태 변경과 같은 이벤트에 자동으로 반응하여 로드 밸런서 리소스를 조정합니다.
- 사용자는 직접적인 관리가 필요 없으며, 로드 밸런서의 관리가 쿠버네티스 클러스터에 의해 자동으로 처리됩니다.
보통 hpa 를 사용하게 되면 컨트롤러를 사용하게 된다.
공식문서에서는 다음과 같이 나와있다.
AWS Load Balancer 컨트롤러는 Kubernetes 클러스터에 대한 AWS Elastic Load Balancer를 관리합니다. 컨트롤러를 사용하여 클러스터 앱을 인터넷에 노출할 수 있습니다. 컨트롤러는 클러스터 서비스 또는 수신 리소스를 가리키는 AWS 로드 밸런서를 프로비저닝합니다.
https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/aws-load-balancer-controller.html
AWS controller 의 traffic 모드
인스턴스 모드
수신 트래픽은 ALB에서 시작하여 각 서비스의 NodePort를 통해 Kubernetes 노드에 도달합니다. 이는 수신 리소스에서 참조하는 서비스가 ALB에 도달하기 위해 에서 type:NodePort가 있어야 함을 의미합니다.
IP 모드
수신 트래픽은 ALB에서 시작하여 Kubernetes Pod에 직접 도달합니다. CNI는 ENI의 Secondary IP 주소를 통해 직접 액세스할 수 있는 POD IP를 지원해야 합니다.
AWS EKS loadbalancer workshop
https://awskocaptain.gitbook.io/aws-builders-eks/6.-aws-load-balancer-controller
https://www.eksworkshop.com/docs/fundamentals/exposing/loadbalancer/