대부분의 트래픽(99% 등)을 항상 하나의 포드로 리디렉션하는 로드 밸런서 설정에 문제가 있습니다. 기본적으로 인프라는 그림과 같습니다.이 다이어그램에. 목표는 nginx 또는 Google 로드 밸런서에서 고정 세션을 활성화해야 하며 내 트래픽은 사용 가능한 포드에 동일하게 배포되는 것입니다.
간단히 말해서 클러스터에는 2개의 RC와 2개의 서비스가 있습니다. nginx 포드 1개는 Google Loadbalancer(nginx-lb) 뒤에 제공되고 또 다른 로드 밸런서(app-lb)는 2개의 앱 포드로 트래픽의 균형을 유지합니다. 제가 생각한 구성은 다음과 같습니다.
nginx-lb: nginx-lb를 다음으로 설정했습니다.
sessionAffinity: None지금externalTrafficPolicy: Local은 고정 세션이 필요하지 않다고 생각하기 때문에 꼭 필요합니다.사용자의 IP를 통과. 이 시점에서 들어오는 모든 트래픽은 동일하게 처리되지만 설정을 통해 사용자의 IP를 보존하려고 합니다externalTrafficPolicy: Local.nginx: nginx 자체가 활성화되었습니다.ngx_http_realip_module사용자의 IP를 계속 전달하기 위해 여기에서는 아직 고정 세션이 필요하지 않다고 생각하기 때문에 여기서는 ip_hash를 사용하지 않았습니다. 다시 말하지만, nginx-lb와 마찬가지로 들어오는 모든 트래픽을 전달하려고 시도하지만 사용자의 IP는 보존하려고 합니다. 여기서 nginx는 주로 프록시 및 SSL 핸들러용입니다.
sessionAffinity: ClientIPapp-lb: 그런 다음 고정 세션을 활성화한 app-lb로 이동합니다externalTrafficPolicy: Cluster.로드 밸런싱. 저는 이것이 ClientIP에 의한 실제 로드 밸런싱이 발생하는 곳이라고 믿습니다. 왜냐하면 이것이 뒤에 2개의 포드가 있고/알고 있는 유일한 서비스이기 때문입니다.
하루 동안 실행 중이지만 여전히 하나의 Pod로 리디렉션되는 약 50명의 사용자를 대상으로 이 구성을 테스트했습니다. 반면 다른 Pod는 첫 번째 Pod에 비해 CPU 및 메모리 사용량이 낮아 유휴 상태입니다.
설정에 대해 묻고 싶습니다. 내가 달성하려는 목표가 제대로 이루어지고 있나요? 누락된 구성이 있나요? 모든 의견을 높이 평가하겠습니다.
추신. 내가 이해한 것에서 더 많은 사실을 추가하기 위해 전체 질문을 다시 작성했지만 기본적으로 다른 표현을 사용하는 원래 질문과 여전히 관련이 있습니다.
답변1
를 사용하고 있기 때문에 이런 일이 발생합니다. sessionAffinity: ClientIP이는 서비스에 대한 선호도이며 IP 기반이므로 서비스는 로드 밸런서의 IP를 가져오고 사용해 보세요. sessionAffinity: None고정 세션을 사용하려면 nginx 수신 컨트롤러를 사용하세요.
답변2
모바일이나 노트북보다 더 많은 수의 클라이언트에서 앱을 테스트해 보셨나요?
어쩌면 여러 Google 컴퓨팅 엔진 인스턴스에서 테스트할 수도 있습니다.
고정 세션과 로드 밸런싱을 모두 구현하고 있으므로 ip_hash두 장치가 동일한 Pod에서 제공될 확률이 50%이며 페이지를 다시 로드하더라도 IP를 변경할 때까지 항상 동일한 Pod에서 제공됩니다.
ip-hash를 사용하면 클라이언트의 IP 주소가 해싱 키로 사용되어 클라이언트의 요청에 대해 서버 그룹에서 어떤 서버를 선택해야 하는지 결정합니다. 이 방법을 사용하면 해당 서버를 사용할 수 없는 경우를 제외하고 동일한 클라이언트의 요청이 항상 동일한 서버로 전달됩니다. http://nginx.org/en/docs/http/load_balancing.html