[쿠버 뿌셔 02] Endpoint - 외부 패킷이 Pod로 가기까지의 여정

쿠버네티스 외부에서 들어오는 요청은 어떻게 Pod까지 도달하게 될까요?

원래 제가 기존에 알고 있던 부분은 아래와 같은 간단한 3단계였습니다.

Ingress -> Service -> Pod

그럼 실제로 어떻게 패킷이 흘러갈까요?

구성은 아래와 같다고 정의합니다.

• EKS 환경
• Ingress controller: aws loadbalancer controller
• service : nginx-svc
• ingress : nginx-ing
• deployment : nginx-deploy (replicas:2)
• 도메인 URL: ray-ops.com/index

상황: 클라이언트가 "http://rayops.com:80/nginx" 으로 접근을 시도하여 쿠버네티스 LoadBalancer Service 까지 도달

제가 잘못알고 있던 부분은 Ingress -> Service가 아니였습니다.

Client가 http://ray-ops.com/index 에 접근하면, ray-ops.com 도메인의 DNS를 resolve 하여, 해당 IP 로 접근하게 됩니다.(ALB IP에 해당)
이후 패킷은 Lodbalancer의 리스너로 접근하게 됩니다. 해당 리스너의 규칙(Ingress 리소스 규칙)에 따라 대상그룹(POD IP)로 트래픽이 흐르게 됩니다.

Endpoint가 뭔데?

Service 리소스 생성시에 Selector로 설정한 Pod IP의 모음이라고 보면 됩니다.
nginx-ingress 생성시 backend service로 nginx-svc를 설정한다면 endpoint리소스가 생성되면서,
nginx-svc의 selector가 바라보고 있는 2개 replicas POD(nginx-deploy)를 가르키게 됩니다.
그리고 해당 엔드포인트 들은 AWS LoadBalancer Controller가 해당 내용들을 확인하여 -> AWS Application Loadbalancer의 대상그룹으로 등록이됩니다.

HTTP Ingress: AWS Loadblanacer Conroller 와 Nginx Ingress Controller의 차이점

AWS Loadbalancer Controller의 경우

• EKS 내부의 변화를 확인해서(service, ingres) 실제 AWS환경의 ELB서비스와 싱크를 맞추어줍니다.
• ingress가 생성되면, 해당 Ingress에 매핑된 Service의 Endpoint를 변경등을 확인하여 ELB서비스를 배포하고 설정을 Ingress와 동일하게 합니다.
• 패킷의 흐름의 경우 앞의 AWS LB에서 바로 POD로 가는 형태입니다.

Nginx Ingres Controller의 경우

• Kubernetes내부의 Ingress 리소스를 확인하여 Controller내부의 "nginx.conf"의 프록시를 설정합니다.
• 외부 패킷의 흐름이 Kubernetes 내부의 Ingress Controller에서 Pod로 가는 형태입니다.

Nginx Ingress Controller의 접근 방식

참고 문서: https://kubernetes.io/ko/docs/concepts/services-networking/service/