2016-09-22 1 views
9

kubernetes 포드의 클라이언트/서버로 파이썬에서 gRPC를 사용하고 있습니다 ... 동일한 유형의 여러 포드 (gRPC 서버)를 시작하고 클라이언트를 연결할 수 있기를 바랍니다. 그들 (무작위로).gRPC 클라이언트 측로드 밸런싱

서버 10 개를 발송하고 대상으로 '서비스'를 설정했습니다. 그런 다음 클라이언트에서 서비스의 DNS 이름에 연결했습니다. 즉, kubernetes가 부하 분산을 수행하고 임의의 서버 포드로 이동해야 함을 의미합니다. 실제로 클라이언트는 gRPC 기능을 호출합니다 (잘 작동합니다). 그러나 로그를 보면 모든 호출이 동일한 서버 포드로가는 것을 볼 수 있습니다.

클라이언트가 모든 종류의 DNS 캐싱을 수행하여 모든 호출이 동일한 서버로 전송된다고 가정합니다. 이 경우인가요? 어쨌든 그것을 사용 중지하고 "새로운"호출을 만들고 각 호출과 함께 DNS로 새 IP를 가져 오도록 동일한 스텁 클라이언트를 설정합니까?

매번 DNS 서버를 질의 할 때 발생할 수있는 오버 헤드에 대해 알고 있지만로드를 배포하는 것이 현재로서는 나에게 훨씬 중요합니다.

편집

아마 캐싱 문제 ... 단지 gRPC가 작동하는 방법이 될 수 있습니다. HTTP/2 및 지속적인 재사용 가능 연결. 각 통화 후에 "연결 해제"하는 방법은 없습니까?

답변

10

일을 어떻게 처리 할 것인지 기술하여 대답 할 기회를 갖도록하겠습니다.

클라이언트 측 : (권위있는 문서가 here을 찾을 수 있습니다) 다음과 같이 LB는 gRPC C 코어에서 작동 (모든 기초하지만 자바와 맛을 이동 또는 gRPC)

방법 클라이언트 측이다 LB는 목적에 따라 단순하고 "벙어리"로 유지됩니다. 우리가 복잡한 LB 정책을 구현하기 위해 선택한 방식은 외부 LB 서버를 사용하는 것입니다 (앞서 언급 한 문서에서 설명). 이 시나리오에는 관심이 없습니다. 대신 채널을 만들면 (기본) 선택 우선 LB 정책이 사용됩니다.

LB 정책에 대한 입력은 확인 된 주소의 목록입니다. DNS를 사용할 때 foo.com이 [10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.4]으로 해결되면 정책은 모든 정책에 대한 연결을 설정하려고 시도합니다. 성공적으로 연결하는 첫 번째 장치는이 연결될 때까지 선택한 하나가됩니다. 따라서 "pick-first"라는 이름. 더 긴 이름은 "가능한 한 오랫동안 그걸로 고수하십시오."하지만 아주 긴 파일명으로 만들어졌습니다 :). 선택 된 연결이 끊어지면 선택 우선 정책에 따라 다음에 성공적으로 연결된 주소 (내부적으로 "연결된 서브 채널"이라고 함)가 반환됩니다 (있는 경우). 다시 한번, 연결 상태를 유지하는 동안이 연결된 서브 채널을 계속 선택합니다.모두 실패하면 호출이 실패합니다.

여기에서의 문제는 본질적으로 끌어 오기 기반 인 DNS 해결이 1) 채널 생성시 및 2) 선택한 연결된 하위 채널의 연결 해제시에만 트리거된다는 점입니다.

지금 당장은 모든 요청에 ​​대해 새 채널을 만드는 것이 좋을 것입니다 (매우 비효율적이지만 설정이 주어진다면 그 트릭을 수행 할 것입니다).

2017 년 1 월에 변경된 사항 (https://github.com/grpc/grpc/issues/7818 참조)을 사용하면 클라이언트가 다른 LB 정책, 즉 라운드 로빈을 선택할 수 있습니다. 또한 클라이언트 구성에 "임의 화"비트를 도입하여 라운드 로빈을 수행하기 전에 주소를 임의로 뒤섞어 의도 한대로 효과적으로 달성 할 수 있습니다.

+0

상세한 답변 해 주셔서 감사합니다. 사실, 나는 이미 당신이 제안한 것과 각 요청에 대한 새로운 채널을 생성했습니다 (효율적이지는 않습니다). 귀하의 답변에서 나는 그것이 멈출 때까지 (사용 가능한 연결/사망/추락) 클라이언트가 두 번째 IP에 도착할 때까지 dns의 첫 번째 IP 만 요청을 받게된다는 것을 이해합니다. – Idan

+0

예. 변경 사항이있을 때까지 LB 정책으로 먼저 선택 대신 라운드 로빈을 선택할 수 있습니다. –

+0

여러 개의 gRPC 서버를 확장하는 데 일반적으로 해결책이 있습니까? 또는 클라이언트 측로드 균형 조정 –

1

바닐라 Kubernetes 서비스를 만든 경우 서비스에 자체로드 균형 조정 가상 IP가 있어야합니다 (kubectl get svc your-serviceCLUSTER-IP이 표시되는지 확인). 이 경우 DNS 캐시는 문제가되지 않아야합니다. 단일 가상 IP가 실제 백엔드간에 트래픽을 분할해야하기 때문입니다.

kubectl get endpoints your-service을 시도하여 서비스가 실제로 모든 백엔드를 알고 있는지 확인하십시오.

headless service이있는 경우 DNS 조회는 10 개의 IP (각 Pod에 하나씩)가있는 A 레코드를 반환합니다. 고객이 항상 A 레코드의 첫 번째 IP를 선택하면 보는 행동을 설명 할 수 있습니다.

+0

서버에 CLUSTER_IP가 있으며 '엔드 포인트 가져 오기'할 때 모든 엔드 포인트가 있음을 알 수 있습니다. 여전히 동일한 서버로 이동합니다. 나는 그것이 gRPC가 작동하는 방식일지도 모르고 HTTP/2의 연결 재사용이라고 생각한다. – Idan