[SPRING] Docker Swarm 및 Kubernetes와 같은 Spring Cloud와 Orchestration 도구의 결합

Docker Swarm 및 Kubernetes와 같은 Spring Cloud와 Orchestration 도구의 결합

Cloud Cloud Netflix를 사용하여 구현 된 클라우드 기본 응용 프로그램이 있습니다.

따라서 응용 프로그램에서 유레카 서비스 검색을 사용하여 응용 프로그램의 다양한 서비스 인스턴스를 모두 관리하고 있습니다. 각 서비스 인스턴스가 다른 서비스 인스턴스와 통신하려고 할 때 Eureka를 사용하여 대상 서비스 (예 : IP 및 포트)에 대한 필수 정보를 가져옵니다.

서비스 오케스트레이션은 Docker Swarm 및 Kubernetes와 같은 도구를 사용하여 수행 할 수도 있습니다. Eureka가 수행하는 작업과 Docker Swarm 및 Kubernetes가 수행 할 수있는 작업간에 일부 중복이있는 것으로 보입니다.

예를 들어 Docker Swarm에서 5 개의 인스턴스로 서비스를 생성한다고 가정 해 보겠습니다. 따라서 떼는 5 가지 인스턴스가 항상 실행되고 실행되도록 보장합니다. 또한 응용 프로그램의 각 서비스는 내부적으로 유레카에게주기적인 하트 비트를 보내 그것이 아직 살아 있음을 보여줍니다. Docker와 Spring Cloud 자체의 두 가지 건강 상태 점검표가 있습니다.

또는 예를 들어 서비스 용 포트를 전체 swarm에 노출시켜 서비스 발견의 필요성을 제거 할 수 있습니다 (포트는 항상 분명합니다). 또 다른 예는 도커 내부의 라우팅 메시에 의해 수행되는로드 밸런싱과 리본 구성 요소 또는 유레카 자체에 의해 내부적으로 발생하는로드 밸런싱입니다. 이 경우 하드웨어 부하 분산 장치를 사용하면 3 계층로드 균형 조정 기능을 사용할 수 있습니다.

그래서이 도구들을 함께 사용하는 것이 합리적인지 알고 싶습니다. 이러한 기술을 조합하여 사용하면 응용 프로그램의 복잡성이 크게 증가하고 중복 될 수 있습니다.

읽어 주셔서 감사합니다!

해결법

1. ==============================

   1.당신은 그것이 중복 된 것처럼 보입니다. 개인적인 관찰에서, 나는 그 아키텍쳐의 각 계층이 자신의 특정한 방식으로로드 밸런싱을 처리해야한다고 생각한다. 결국 더 많은 비용을 들이지 않고 더 많은 유연성을 제공하게됩니다. 클라이언트 측로드 밸런싱 및 장애 조치 기능을 이용하려면 유레카가 있어야합니다. 주요 장점은 모든 기능을 이용하지 않으려는 경우가 아니라는 것입니다.

   당신은 그것이 중복 된 것처럼 보입니다. 개인적인 관찰에서, 나는 그 아키텍쳐의 각 계층이 자신의 특정한 방식으로로드 밸런싱을 처리해야한다고 생각한다. 결국 더 많은 비용을 들이지 않고 더 많은 유연성을 제공하게됩니다. 클라이언트 측로드 밸런싱 및 장애 조치 기능을 이용하려면 유레카가 있어야합니다. 주요 장점은 모든 기능을 이용하지 않으려는 경우가 아니라는 것입니다.

   컨테이너 오케스트레이션 수준로드 균형 조정은 응용 프로그램 수준 (Eureka)에있는 서비스 검색 조각과 일치하지 않는 응용 프로그램이나 서비스를위한 장소를 제공합니다.

   하드웨어 부하 분산 장치는 컨테이너 수준기 외부에서 부하 분산을 허용하는 또 다른 수준을 제공합니다.

   내가 사용했던 특정 유스 케이스는 AWS에서 Kubernetes 클러스터에 대해 Traefik과 Eureka (Spring Cloud)와 함께 사용되었습니다.

2. ==============================

   2.이미 응용 프로그램을 사용하고 있다면 Netflix 구성 요소를 제거하는 것보다 더 많은 노력과 위험이 따릅니다. 예를 들어 그런 다음 유레카를 유지 관리 할 필요가 없으며 업그레이드하는 것이 더 적은 것입니다. 그러나 이는 작업을 정당화 할 수 없으며 오케스트레이션 도구로 수행 할 수없는 작업에이 작업을 사용하는지 여부에 따라 달라집니다.

   이미 응용 프로그램을 사용하고 있다면 Netflix 구성 요소를 제거하는 것보다 더 많은 노력과 위험이 따릅니다. 예를 들어 그런 다음 유레카를 유지 관리 할 필요가 없으며 업그레이드하는 것이 더 적은 것입니다. 그러나 이는 작업을 정당화 할 수 없으며 오케스트레이션 도구로 수행 할 수없는 작업에이 작업을 사용하는지 여부에 따라 달라집니다.

   예를 들어로드 밸런싱 ( '헤드리스 서비스')으로 설정되지 않은 서비스에 연결하는 경우 서비스 내에서 리본을 원할 수 있습니다. (당신은 봄 구름 kubernetes 인큐베이터 프로젝트 또는 그 fabric8 동등한 도구에서 도구를 사용하여 이것을 할 수 있습니다.) 외부 서비스 (예 : kubernetes 클러스터 외부의 서비스)에 연결할 때 염두에 두어야 할 또 다른 상황은 다음과 같습니다. 로드 밸런싱 또는 속도 제한 및 리본 / 히스테리는 옵션이 될 수 있습니다. 로드 밸런싱 또는 속도 제한에 대한 요구 사항이 얼마나 미묘한가에 달려 있습니다.

   넷플 릭스에 대해 특별히 질문했지만, 넷플 릭스뿐만 아니라 다른 구성 요소도 포함하고 있다는 것을 분명히 밝히는 것이 좋습니다. 그리고 당신이 선택을해야 할 곳에 다른 부분이 겹쳐져 있습니다.

   나는 이것이 내가 가장 잘 알고있는 것이고 그것이 부분적으로 업계의 현재 여행 방향이라고 생각하기 때문에 부분적으로 득점을하기보다는 Kubernetes에 초점을 맞 춥니 다. 여기에서 kubernetes는 docker EE에서 사용할 수 있습니다. 나는 당신이 많은 비교 기사를 읽었지만 https://hackernoon.com/a-kubernetes-guide-for-docker-swarm-users-c14c8aa266cc가 특히 흥미로울 것 같아.

3. ==============================

   3.그래 너가 옳아. 우리는 Oracle Cloud 플랫폼과 Predix Cloud Foundry에 비슷한 Spring Cloud Netflix 애플리케이션을 배치했습니다. Kubernetes 클러스터를 여러 개 사용하는 경우 서비스 인스턴스가 여러 개이므로 리본로드 균형 조정을 사용해야합니다.

   그래 너가 옳아. 우리는 Oracle Cloud 플랫폼과 Predix Cloud Foundry에 비슷한 Spring Cloud Netflix 애플리케이션을 배치했습니다. Kubernetes 클러스터를 여러 개 사용하는 경우 서비스 인스턴스가 여러 개이므로 리본로드 균형 조정을 사용해야합니다.

   Kubernetes 또는 Docker Swarm 중 어느 것이 더 낫다고 말할 수는 없습니다. Kubernetes는 서비스 오케스트레이션에 더 많은 유연성을 제공하기 때문에 Kubernetes를 사용합니다.

from https://stackoverflow.com/questions/51482499/combination-of-spring-cloud-and-orchestration-tools-like-docker-swarm-and-kubern by cc-by-sa and MIT license