Kubernetes 서비스 메시 비교

마이크로서비스 아키텍처 및 컨테이너화에 대해 논의할 때 프로덕션에서 입증된 도구 세트 중 하나가 최근 몇 년 동안 가장 많은 관심을 끌었습니다. 바로 서비스 메시입니다.

실제로 마이크로서비스 아키텍처와 Kubernetes(종종 “K8s”로 양식화됨)는 확장 가능한 앱의 표준이 되어 서비스 간 통신 관리 문제를 뜨거운 주제로 만들고 서비스 메시는 매력적인 솔루션입니다. 나 자신은 특히 Linkerd, Istio 및 이전 형태의 Ambassador에서 서비스 메시를 사용했습니다. 그러나 서비스 메시는 정확히 무엇을 합니까? 어떤 것을 사용하는 것이 가장 좋습니까? 하나를 사용해야 하는지 여부를 어떻게 알 수 있습니까?

이러한 질문에 답하려면 서비스 메시가 개발된 이유를 이해하는 것이 좋습니다. 역사적으로 기존 IT 인프라에는 단일체로 실행되는 애플리케이션이 있었습니다. 하나의 서비스가 하나의 서버에서 실행되었습니다. 더 많은 용량이 필요한 경우 솔루션은 더 큰 시스템을 프로비저닝하여 수직으로 확장하는 것이었습니다.

이 접근 방식의 한계에 도달한 거대 기술 회사는 애플리케이션 서버 및 데이터베이스 계층에서 로드 밸런서를 분리하는 3계층 아키텍처를 빠르게 채택했습니다. 이 아키텍처는 어느 정도 확장 가능했지만 애플리케이션 계층을 마이크로서비스로 나누기로 결정했습니다. 이러한 서비스 간의 통신은 애플리케이션을 확장하기 위해 모니터링하고 보호하는 데 중요해졌습니다.

서비스 간 통신을 허용하기 위해 이러한 회사는 사내 라이브러리를 개발했습니다. Twitter의 Finagle, Netflix의 Hystrix, Google의 Stubby(2016년에 gRPC가 됨). 이러한 라이브러리는 서비스 간 보안, 대기 시간, 모니터링 및 로드 밸런싱과 같은 마이크로서비스 아키텍처에서 발생하는 문제를 해결하는 것을 목표로 했습니다. 그러나 여러 언어로 된 종속성으로 큰 라이브러리를 관리하는 것은 복잡하고 시간이 많이 걸립니다.

결국 이러한 유형의 라이브러리는 사용하기 쉽고 가벼운 프록시로 대체되었습니다. 이러한 프록시는 애플리케이션 계층과 외부적으로 독립적이며 애플리케이션에 대해 투명할 수 있으며 업데이트, 유지 관리 및 배포가 더 쉽습니다. 따라서 서비스 메시가 탄생했습니다.

서비스 메시란 무엇입니까?

서비스 메시는 서비스 간의 통신을 제어하기 위한 소프트웨어 인프라 계층입니다. 일반적으로 두 가지 구성 요소로 구성됩니다.

1. 애플리케이션 근처에서 통신을 처리하는 데이터 플레인 . 일반적으로 이것은 앞에서 설명한 것처럼 네트워크 프록시 세트로 애플리케이션과 함께 배포됩니다.
2. 서비스 메시의 "두뇌"인 제어 평면 . 제어 평면은 구성을 푸시하고 서비스 검색을 보장하며 관찰 가능성을 중앙 집중화하기 위해 프록시와 상호 작용합니다.

서비스 메시에는 서비스 간 통신에 대한 세 가지 주요 목표가 있습니다.

1. 연결성
2. 보안
3. 관찰 가능성

연결성

서비스 메시 아키텍처의 이러한 측면은 서비스 검색 및 동적 라우팅을 허용합니다. 또한 재시도, 시간 초과, 회로 차단 및 속도 제한과 같은 통신 탄력성 을 다룹니다.

서비스 메시의 주요 기능은 로드 밸런싱 입니다. 프록시에 의해 메시되는 모든 서비스는 라운드 로빈, 랜덤 및 최소 요청과 같은 서비스 간의 로드 밸런싱 정책 구현을 허용합니다. 이러한 정책은 서비스 메시에서 각 서비스 앞에 작은 로드 밸런서가 있는 것처럼 원래 요청을 수신할 복제본을 결정하는 데 사용하는 전략입니다.

마지막으로 서비스 메시는 트래픽 이동 및 미러링의 형태로 라우팅 제어 를 제공합니다.

보안

기존 마이크로서비스 아키텍처에서 서비스는 암호화되지 않은 트래픽으로 서로 통신합니다. 오늘날 암호화되지 않은 내부 트래픽은 특히 퍼블릭 클라우드 인프라 및 제로 트러스트 네트워크의 경우 보안 측면에서 나쁜 관행으로 간주됩니다.

하드웨어를 직접 제어할 수 없는 클라이언트 데이터의 개인 정보를 보호하는 것 외에도 내부 트래픽을 암호화 하면 시스템 위반 시 추가 복잡성의 환영 계층이 추가됩니다. 따라서 모든 서비스 메시는 서비스 간 통신, 즉 모든 프록시 간 통신을 위해 상호 TLS(mTLS) 암호화를 사용합니다.

서비스 메시는 특정 환경 및 서비스를 대상으로 하는 정책을 기반으로 트래픽을 허용하거나 거부하는 복잡한 인증 정책 매트릭스를 시행할 수도 있습니다.

관찰 가능성

서비스 메시의 목표는 서비스 간 통신에 대한 가시성을 제공하는 것입니다. 서비스 메시는 네트워크를 제어하여 관찰 가능성을 강화하여 계층 7 메트릭 을 제공하여 트래픽이 사용자 지정 가능한 임계값에 도달할 때 자동 경고 를 허용합니다.

일반적으로 Jaeger 또는 Zipkin과 같은 타사 도구 또는 플러그인에서 지원하는 이러한 제어를 통해 HTTP 추적 헤더를 삽입하여 추적할 수도 있습니다.

서비스 메시 이점

서비스 메시는 마이크로서비스 아키텍처로 인한 운영 부담을 일부 상쇄하기 위해 만들어졌습니다. 마이크로서비스 아키텍처에 대한 경험이 있는 사람들은 매일 운영하는 데 상당한 양의 작업이 필요하다는 것을 알고 있습니다. 마이크로서비스의 잠재력을 최대한 활용하려면 일반적으로 무엇보다도 중앙 집중식 로깅, 구성 관리 및 확장성 메커니즘을 처리하기 위한 외부 도구가 필요합니다. 서비스 메시를 사용하면 이러한 기능과 설정 및 통합이 표준화 됩니다.

특히 서비스 메시 관찰 가능성은 매우 다양한 디버깅 및 최적화 방법을 제공합니다. 서비스 간 교환에 대한 세분화되고 완전한 가시성 덕분에 엔지니어, 특히 SRE는 가능한 버그 및 시스템 구성 오류를 보다 신속하게 해결할 수 있습니다. 서비스 메시 추적을 사용하면 시스템 진입(로드 밸런서 또는 외부 프록시)에서 스택 내부의 개인 서비스에 이르기까지 요청을 추적할 수 있습니다. 로깅을 사용하여 요청을 매핑하고 각 서비스에서 발생하는 대기 시간을 기록할 수 있습니다. 최종 결과: 시스템 성능에 대한 자세한 통찰력 .

트래픽 관리는 새 버전의 서비스를 정식 출시하기 전에 다음과 같은 강력한 가능성을 제공합니다.

1. 작은 비율의 요청을 다시 라우팅 합니다.
2. 더욱이 프로덕션 요청을 새 버전으로 미러링 하여 실시간 트래픽으로 동작을 테스트합니다.
3. A/B는 모든 서비스 또는 서비스 조합을 테스트 합니다.

서비스 메시는 위의 모든 시나리오를 간소화하여 생산 과정에서 발생하는 모든 상황을 쉽게 방지 및/또는 완화할 수 있도록 합니다.

Kubernetes 서비스 메시 비교

여러 면에서 서비스 메시는 마이크로서비스 아키텍처를 위한 궁극적인 도구 세트입니다. 그들 중 다수는 최고의 컨테이너 오케스트레이션 도구 중 하나인 Kubernetes에서 실행됩니다. 오늘 Kubernetes에서 실행되는 세 가지 주요 서비스 메시인 Linkerd(v2), Istio 및 Consul Connect를 선택했습니다. 또한 Kuma, Traefik Mesh 및 AWS App Mesh와 같은 다른 서비스 메시에 대해서도 논의할 것입니다. 현재 사용 및 커뮤니티 측면에서 덜 유명하지만 여기에서 검토하고 일반적으로 계속 주시할 만큼 충분히 유망합니다.

사이드카 프록시에 대한 간략한 참고 사항

모든 Kubernetes 서비스 메시가 동일한 아키텍처 접근 방식을 사용하는 것은 아니지만 일반적인 방법은 사이드카 패턴을 활용하는 것입니다. 여기에는 기본 애플리케이션에 프록시(사이드카)를 연결하여 애플리케이션의 인바운드 및 아웃바운드 네트워크 트래픽을 가로채고 규제하는 작업이 포함됩니다. 실제로 이것은 애플리케이션 컨테이너의 수명 주기를 따를 각 애플리케이션 포드의 보조 컨테이너를 통해 Kubernetes에서 수행됩니다.

서비스 메시에 대한 사이드카 접근 방식에는 두 가지 주요 이점이 있습니다.

• 사이드카 프록시는 런타임 및 애플리케이션의 프로그래밍 언어와도 독립적입니다.
  • 이는 스택 전체에서 서비스 메시가 사용되는 곳이면 어디든지 서비스 메시의 모든 기능을 쉽게 활성화할 수 있음을 의미합니다.
• 사이드카에는 애플리케이션과 동일한 수준의 권한 및 리소스 액세스 권한이 있습니다.
  • 사이드카는 기본 애플리케이션 코드베이스에 모니터링을 통합할 필요 없이 기본 애플리케이션에서 사용하는 리소스를 모니터링하는 데 도움이 될 수 있습니다.

그러나 사이드카는 애플리케이션에 직접적인 영향을 미치기 때문에 혼합된 축복입니다.

• 사이드카 초기화는 애플리케이션의 시작 메커니즘을 교착 상태로 만들 수 있습니다.
• 사이드카 프록시는 애플리케이션에 잠재적인 대기 시간을 추가합니다.
• 사이드카 프록시는 또한 대규모 비용이 들 수 있는 리소스 공간을 추가합니다.

이러한 장점과 단점을 감안할 때 사이드카 접근 방식은 서비스 메시 커뮤니티에서 자주 논의되는 주제입니다. 즉, 여기에서 비교한 6개의 서비스 메시 중 4개는 Envoy 사이드카 프록시를 사용하고 Linkerd는 자체 사이드카 구현을 사용합니다. Traefik Mesh는 디자인에 사이드카를 사용하지 않습니다.

링커드 리뷰

2017년에 데뷔한 Linkerd는 시장에서 가장 오래된 서비스 메시입니다. Buoyant(전 Twitter 엔지니어 2명이 시작한 회사)가 만든 Linkerd v1은 Finagle과 Netty를 기반으로 했습니다.

Linkerd v1은 완전한 생산 준비가 된 서비스 메시였기 때문에 시대를 앞서간 것으로 설명되었습니다. 동시에 리소스 사용 측면에서 약간 무거웠습니다. 또한 문서의 상당한 격차로 인해 프로덕션 환경에서 설정하고 실행하기가 어려웠습니다.

이를 통해 Buoyant는 완전한 생산 모델로 작업하고 경험을 쌓고 지혜를 적용할 기회를 가졌습니다. 그 결과 2018년에 출시된 완전한 Linkerd 재작성 회사인 Conduit이 탄생했으며 그해 말에 Linkerd v2로 이름이 변경되었습니다. Linkerd v2는 몇 가지 강력한 개선 사항을 가져왔습니다. Linkerd v1에 대한 Buoyant의 활발한 개발은 오래전에 중단되었기 때문에 이 기사의 나머지 부분에서 "Linkerd"에 대한 언급은 v2를 참조합니다.

완전 오픈 소스인 Linkerd는 데이터 플레인에 대해 Rust로 작성된 수제 프록시와 제어 플레인에 대해 Go로 작성된 소스 코드에 의존합니다.

연결성

링커드 프록시에는 재시도 및 시간 초과 기능이 있지만 이 글을 쓰는 시점에서 회로 차단이나 지연 주입은 없습니다. Ingress 지원은 광범위합니다. Linkerd는 다음 수신 컨트롤러와의 통합을 자랑합니다.

• 트라에픽
• 엔진엑스
• GCE
• 대사
• 글루
• 윤곽
• 콩

Linkerd의 서비스 프로필은 향상된 라우팅 기능을 제공하여 사용자 메트릭, 재시도 조정 및 시간 제한 설정을 모두 경로별로 제공합니다. 로드 밸런싱과 관련하여 Linkerd는 자동 프록시 삽입, 자체 대시보드 및 Grafana에 대한 기본 지원을 제공합니다.

보안

Linkerd의 mTLS 지원은 자동 일일 키 순환과 마찬가지로 초기 설정이 자동이라는 점에서 편리합니다.

관찰 가능성

기본적으로 Linkerd 통계 및 경로는 CLI를 통해 관찰할 수 있습니다. GUI 측에서 옵션에는 미리 만들어진 Grafana 대시보드와 기본 Linkerd 대시보드가 ​​포함됩니다.

Linkerd는 Prometheus의 인스턴스에 연결할 수 있습니다.

추적은 OpenTelemetry(이전 OpenCensus)를 수집기로 사용하고 Jaeger가 자체적으로 추적하는 애드온을 통해 활성화할 수 있습니다.

설치

링커드 설치는 Kubernetes의 리소스에 주석을 추가하여 수행되는 사이드카 프록시를 주입하여 수행됩니다. 이에 대해 두 가지 방법이 있습니다.

1. Helm 차트 사용. (많은 경우 Helm은 Kubernetes 리소스에 대한 구성 및 템플릿 관리자입니다.)
2. Linkerd CLI를 설치한 다음 이를 사용하여 Linkerd를 클러스터에 설치합니다.

두 번째 방법은 설치 스크립트를 다운로드하고 실행하는 것으로 시작합니다.

 curl -sL https://run.linkerd.io/install | sh

거기에서 Linkerd CLI 도구 linkerd 는 나머지 Linkerd를 설치하고 앱 클러스터 및 제어 평면과 상호 작용하는 데 도움이 되는 유용한 도구 키트를 제공합니다.

linkerd check --pre 는 Linkerd 설치에 필요한 모든 예비 검사를 실행하여 잠재적인 Linkerd 설치가 아직 작동하지 않을 수 있는 이유에 대한 명확하고 정확한 로그를 제공합니다. --pre 없이 이 명령은 설치 후 디버깅에 사용할 수 있습니다.

다음 단계는 다음을 실행하여 클러스터에 Linkerd를 설치하는 것입니다.

 linkerd install | kubectl apply -f -

그런 다음 Linkerd는 리소스 풋프린트가 매우 작은 다양한 구성 요소를 설치합니다. 따라서 그들 자신은 마이크로 서비스 접근 방식을 가지고 있습니다.

• CLI와 대시보드가 ​​상호 작용하는 공개 API를 제공하는 linkerd-controller
• linkerd-identity , mTLS 구현을 위한 인증 기관 제공
• linkerd-proxy-injector , 포드 구성을 변경하여 프록시 주입을 처리합니다.
• linkerd-web 은 내부 Linkerd 구성 요소뿐만 아니라 배포 및 포드 모니터링을 허용하는 대시보드를 제공합니다.

Linkerd는 대부분의 구성을 CRD( CustomResourceDefinitions )를 기반으로 합니다. 이것은 Kubernetes 애드온 소프트웨어를 개발할 때 모범 사례로 간주됩니다. 이는 Kubernetes 클러스터에 플러그인을 영구적으로 설치하는 것과 같습니다.

일부 일반적인 신화로 인해 Linkerd 사용자가 실제로 추구하는 것일 수도 있고 아닐 수도 있는 분산 추적을 추가하려면 linkerd-collector 및 linkerd-jaeger를 사용하는 또 다른 단계가 필요합니다. 이를 위해 먼저 구성 파일을 만듭니다.

 cat >> config.yaml << EOF tracing: enabled: true EOF

추적을 활성화하려면 다음을 실행합니다.

 linkerd upgrade --config config.yaml | kubectl apply -f -

사이드카 프록시를 기반으로 하는 모든 서비스 메시와 마찬가지로 추적을 활성화하려면 애플리케이션 코드를 수정해야 합니다. 이것의 대부분은 단순히 추적 헤더를 전파하기 위해 클라이언트 라이브러리를 추가하는 것입니다. 그런 다음 각 서비스에 포함되어야 합니다.

SMI(Service Mesh Interface) 호환 API를 통해 노출되는 Linkerd의 트래픽 분할 기능은 이미 카나리아 릴리스를 허용합니다. 그러나 이를 자동화하고 트래픽 관리를 수행하려면 Flagger와 같은 외부 도구도 필요합니다.

Flagger는 Linkerd가 "황금" 메트릭 이라고 부르는 "요청 볼륨, 성공률 및 대기 시간 분포"를 평가하는 점진적 전달 도구입니다. (원래 Google SRE는 황금 신호 라는 용어를 사용했고 네 번째 신호인 포화도 포함했지만 Linkerd에서는 CPU 및 메모리 사용량과 같이 직접 액세스할 수 없는 측정항목이 필요하기 때문에 이를 다루지 않습니다.) Flagger는 트래픽을 분할하면서 이를 추적합니다. 피드백 루프를 사용하여; 따라서 자동화된 메트릭 인식 카나리아 릴리스를 구현할 수 있습니다.

설치 프로세스를 자세히 살펴보고 나면 Linkerd 서비스 메시가 작동하도록 하고 일반적으로 원하는 기능을 활용하기 위해 적어도 12개의 서비스를 실행하는 것으로 끝나는 것이 쉽다는 것이 분명해졌습니다. 즉, 다른 서비스 메시보다 설치 시 Linkerd에서 더 많은 것을 제공합니다.

링커드 서비스 메시 요약

장점:

Linkerd는 내부 도구인 Finagle에서 작업하고 나중에 Linkerd v1에서 배운 두 명의 전 Twitter 엔지니어인 제작자의 경험을 활용합니다. 최초의 서비스 메시 중 하나인 Linkerd는 번성하는 커뮤니티(Slack의 사용자 수는 5,000명 이상이고 활성 메일링 리스트와 Discord 서버가 있음)와 광범위한 문서 및 자습서 세트를 보유하고 있습니다. Linkerd는 Nordstrom, eBay, Strava, Expedia 및 Subspace와 같은 대기업에서 채택한 것으로 입증된 바와 같이 버전 2.9 릴리스와 함께 성숙했습니다. Linkerd에 대해 Buoyant의 유료 엔터프라이즈급 지원을 사용할 수 있습니다.

단점:

Linkerd 서비스 메시를 최대한 활용하려면 꽤 강력한 학습 곡선이 있습니다. Linkerd는 Kubernetes 컨테이너 내에서만 지원됩니다(즉, VM 기반 "범용" 모드가 없음). Linkerd 사이드카 프록시는 Envoy가 아닙니다. 이렇게 하면 Buoyant가 적절하다고 생각하는 대로 조정할 수 있지만 Envoy가 제공하는 고유한 확장성은 제거됩니다. 또한 Linkerd가 회로 차단, 지연 주입 및 속도 제한에 대한 지원이 누락되었음을 의미합니다. Linkerd 컨트롤 플레인을 쉽게 제어하기 위해 특정 API가 노출되지 않습니다. (하지만 gRPC API 바인딩을 찾을 수 있습니다.)

Linkerd는 사용성과 설치 용이성 면에서 v1 이후로 큰 발전을 이루었습니다. 공식적으로 노출된 API가 없다는 것은 눈에 띄는 누락입니다. 그러나 잘 고려된 문서 덕분에 Linkerd의 기본 기능을 쉽게 테스트할 수 있습니다.

영사 연결 검토

우리의 다음 서비스 메시 경쟁자인 Consul Connect는 독특한 하이브리드입니다. HashiCorp의 Consul은 수년 동안 사용되어 온 분산 아키텍처용 키-값 스토리지로 더 잘 알려져 있습니다. Consul이 완전한 서비스 도구 제품군으로 진화한 후 HashiCorp는 그 위에 서비스 메시인 Consul Connect를 구축하기로 결정했습니다.

하이브리드 특성에 대해 정확하려면 다음을 수행합니다.

Consul Connect 데이터 플레인은 C++로 작성된 Envoy를 기반으로 합니다. Consul Connect의 제어 평면은 Go로 작성되었습니다. 키-값 저장소인 Consul KV가 지원하는 부분입니다.

대부분의 다른 서비스 메시와 마찬가지로 Consul Connect는 애플리케이션 포드 내부에 사이드카 프록시를 삽입하여 작동합니다. 아키텍처 측면에서 Consul Connect는 에이전트 와 서버 를 기반으로 합니다. 기본적으로 Consul Connect는 포드 반친화성을 지정하는 StatefulSet 으로 3~5개의 서버를 사용하여 고가용성(HA)을 갖습니다. 포드 반선호도는 분산 소프트웨어 시스템의 포드가 동일한 노드(서버)에서 끝나지 않도록 하여 단일 노드가 실패할 경우 가용성을 보장하는 방식입니다.

연결성

이 분야에서 Consul Connect를 돋보이게 하는 것은 많지 않습니다. 그것은 모든 서비스 메시가 하는 것 (상당히 많음)과 경로 기반 라우팅, 트래픽 이동 및 로드 밸런싱을 위한 레이어 7 기능을 제공합니다.

보안

다른 서비스 메시와 마찬가지로 Consul Connect는 기본 mTLS 기능을 제공합니다. 또한 Consul과 Vault(HashiCorp에서도 제공) 간의 기본 통합을 제공하며, 이는 클러스터에서 인증서를 관리하고 서명하기 위해 CA 제공자로 사용할 수 있습니다.

관찰 가능성

Consul Connect는 Envoy를 사이드카 프록시로 통합하여 레이어 7 기능을 제공하는 가장 일반적인 관찰 가능성 접근 방식을 취합니다. 메트릭을 가져오도록 Consul Connect의 UI를 구성하려면 기본 제공 구성 파일을 변경하고 Prometheus와 같은 메트릭 공급자를 활성화해야 합니다. 관련 서비스별 메트릭을 표시하도록 일부 Grafana 대시보드를 구성할 수도 있습니다.

설치

Consul Connect는 Helm 차트를 사용하여 Kubernetes 클러스터에 설치됩니다.

 helm repo add hashicorp https://helm.releases.hashicorp.com

UI를 활성화하거나 Consul Connect 모듈이 사이드카 프록시를 삽입하도록 하려면 default values.yaml 을 수정해야 합니다.

 helm install -f consul-values.yml hashicorp hashicorp/consul

구성원에게 문의하고 다양한 노드를 확인하기 위해 Consul은 컨테이너 중 하나로 exec 한 다음 CLI 도구 consul 을 사용할 것을 권장합니다.

Consul이 제공하는 즉시 사용 가능한 웹 UI를 제공하려면 kubectl port-forward service/hashicorp-consul-ui 18500:80 실행하십시오.

Consul Connect 서비스 메시 요약

장점:

• 영사는 HashiCorp의 지원을 받습니다. 프리미엄 제품으로서 엔터프라이즈급 지원을 제공하는 기능이 추가된 엔터프라이즈 버전도 있습니다. 개발 팀 경험 측면에서 Consul은 시장에서 가장 오래된 도구 중 하나입니다.
• Consul은 견고한 엔터프라이즈 커뮤니티를 보유하고 있으며 50,000개의 노드가 있는 인프라에서 실행되는 것으로 알려져 있습니다. 또한 2014년부터 출시되어 시장에 비해 성숙한 제품입니다.
• Consul Connect는 기본 지원 덕분에 VM 내에서 잘 실행됩니다.
• Consul Connect를 사용하면 최상위 기술 회사에서 사전 서비스 메시 구현만큼 깊이 있는 앱 통합을 달성할 수 있습니다. 이는 완전히 문서화된 라이브러리 수준 API의 노출 덕분입니다.

단점:

• Consul Connect는 다른 서비스 메시보다 학습 곡선이 더 가파르고 시각적 대시보드 및 메트릭을 실행하기 위해 더 많은 조정이 필요합니다.
• HashiCorp의 문서는 간단하지 않으므로 사용자가 올바르게 구성하기 위해 파고들고 실험해야 합니다.
• 트래픽 관리 문서는 찾기 어렵고 대부분 Envoy 문서에 대한 링크로 구성되어 있으며 특히 Consul Connect 트래픽 관리에 대한 세부 정보를 제공하지 않습니다.
• Consul Connect의 SMI 인터페이스는 아직 실험 단계입니다.

Consul Connect는 엔터프라이즈급 제품을 찾는 사람들에게 매우 좋은 선택이 될 수 있습니다. HashiCorp는 제품의 품질로 유명하며 Consul Connect도 예외는 아닙니다. 여기에서 다른 서비스 메시와 비교하여 두 가지 강력한 이점을 볼 수 있습니다. 엔터프라이즈 버전에 대한 회사의 강력한 지원과 모든 종류의 아키텍처(Kubernetes뿐만 아니라)에 사용할 수 있는 도구입니다.

이스티오 리뷰

2017년 5월 Google, IBM 및 Lyft는 Istio를 발표했습니다. Istio가 서비스 메시 도구 경쟁에 뛰어들었을 때 기술 분야에서 매우 좋은 노출을 얻었습니다. 작성자는 버전 1.9까지 사용자 피드백을 기반으로 기능을 추가했습니다.

Istio는 당시 경쟁사보다 중요한 새 기능인 자동 로드 밸런싱, 오류 주입 등을 약속했습니다. 이로 인해 커뮤니티에서 많은 관심을 얻었지만 아래에서 자세히 설명하겠지만 Istio를 사용하는 것은 결코 쉬운 일이 아닙니다. Istio는 프로덕션에 적용하기가 특히 복잡한 것으로 인식되었습니다.

역사적으로 Istio 프로젝트는 소스 코드 변경 측면에서 자주 돌아다녔습니다. 컨트롤 플레인에 마이크로서비스 아키텍처를 채택한 Istio는 이제 (버전 1.5부터) 모놀리식 아키텍처로 다시 이동했습니다. Istio가 중앙 집중화로 돌아간 이유는 마이크로서비스가 운영자가 모니터링하기 어렵고 코드베이스가 너무 중복되며 프로젝트가 조직적 성숙도에 도달했기 때문에 더 이상 많은 소규모 팀이 사일로에서 작업할 필요가 없었기 때문입니다.

그러나 그 과정에서 Istio는 가장 많은 양의 공개 GitHub 문제 중 하나로 악명을 얻었습니다. 이 글을 쓰고 있는 현재, 그 수는 약 800개 이슈가 열려 있고 약 12,000개 이슈가 닫혀 있습니다. 문제 수는 속일 수 있지만 이 경우 이전에 고장난 기능과 ​​통제 불가능한 리소스 사용 측면에서 의미 있는 개선을 나타냅니다.

연결성

Istio는 Consul Connect 및 Linkerd에 비해 트래픽 관리에 상당히 강합니다. 이는 요청 라우팅, 오류 주입, 트래픽 이동, 요청 시간 초과, 회로 차단, 서비스 메시에 대한 수신 및 송신 트래픽 제어와 같은 광범위한 하위 기능 제공 덕분입니다. 가상 서비스 및 대상 규칙의 개념은 트래픽 관리 측면에서 매우 완벽합니다.

그러나 이러한 모든 가능성은 학습 곡선과 함께 Kubernetes 클러스터의 새 리소스 관리와 함께 제공됩니다.

보안

Istio는 인증과 권한 부여라는 두 가지 주요 축을 포함하는 포괄적인 보안 관련 도구 세트를 자랑합니다. Istio는 다양한 범위(워크로드별, 네임스페이스 전체 또는 메시 전체)에서 다양한 수준의 정책을 시행할 수 있습니다. 이러한 모든 보안 리소스는 AuthorizationPolicy 또는 PeerAuthentication 과 같은 Istio CRD를 통해 관리됩니다.

표준 mTLS 지원 외에도 Istio는 암호화되지 않은 트래픽을 수락하거나 거부하도록 구성할 수도 있습니다.

관찰 가능성

여기에서 Istio는 서비스 메시에 대한 확실한 통찰력을 제공하는 여러 유형의 원격 측정을 통해 즉시 사용할 수 있습니다. 메트릭은 4가지 황금 신호(대기 시간, 트래픽, 오류 및 어느 정도는 포화도)를 기반으로 합니다.

특히 Istio는 컨트롤 플레인 자체에 대한 메트릭을 제공합니다. 또한 추적을 가능하게 하는 Jaeger, Lightstep 및 Zipkin과의 명시적 호환성을 자랑하는 분산 추적 및 액세스 로그를 제공합니다.

기본 대시보드는 없지만 Kiali 관리 콘솔에 대한 공식 지원이 있습니다.

설치

설치는 공식 단계를 따르면 간단합니다. 또한 Istio는 기본적으로 베타 기능으로 GKE에 통합되지만 GKE는 최신 모놀리스 버전이 아닌 이전 마이크로서비스 버전인 Istio 1.4.X를 사용합니다.

기본 설치는 최신 릴리스를 다운로드하는 것으로 시작됩니다.

 curl -L https://istio.io/downloadIstio | sh -

새로 생성된 istio-* 폴더로 cd ing한 후 istioctl 유틸리티 도구를 사용할 수 있도록 경로에 추가할 수 있습니다.

 export PATH=$PWD/bin:$PATH

여기에서 istioctl을 통해 Kubernetes 클러스터에 istioctl 를 설치할 수 있습니다.

 istioctl install

그러면 default 프로필로 Istio가 설치됩니다. istioctl 프로필을 사용하면 다른 설치 구성을 만들고 필요한 경우 둘 사이를 전환할 수 있습니다. 그러나 단일 프로필 시나리오에서도 일부 CRD를 수정하여 Istio 설치를 세부적으로 사용자 지정할 수 있습니다.

Istio 리소스는 트래픽 관리가 제대로 이루어졌는지 확인하기 위해 최소한 VirtualService , DestinationRule 및 Gateway 와 같은 여러 종류의 CRD를 관리해야 하므로 관리하기가 더 어려워집니다.

• VirtualService 리소스는 요청에 적용되는 서비스 및 다양한 라우팅 규칙을 선언하는 구성입니다.
• DestinationRule 리소스는 대상별 트래픽 정책을 그룹화하고 시행하는 데 사용됩니다.
• Gateway 리소스는 인바운드 및 아웃바운드 서비스 메시 트래픽을 관리하기 위해 생성됩니다(예: 추가 Envoy 프록시이지만 사이드카가 아닌 에지에서 실행).

의미론적 세부사항은 이 리뷰의 범위를 벗어나지만, 이들 각각이 함께 작동하는 것을 보여주는 빠른 예를 살펴보겠습니다. products 이라는 서비스가 있는 전자 상거래 웹사이트가 있다고 가정합니다. VirtualService 는 다음과 같을 수 있습니다.

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: products-route namespace: ecommerce spec: hosts: - products # interpreted as products.ecommerce.svc.cluster.local http: - match: - uri: prefix: "/listv1" - uri: prefix: "/catalog" rewrite: uri: "/listproducts" route: - destination: host: products # interpreted as products.ecommerce.svc.cluster.local subset: v2 - route: - destination: host: products # interpreted asproducts.ecommerce.svc.cluster.local subset: v1

해당 DestinationRule 은 다음과 같을 수 있습니다.

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: products spec: host: products trafficPolicy: loadBalancer: simple: RANDOM # or LEAST_CONN or ROUND_ROBIN subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 - name: v3 labels: version: v3

마지막으로 Gateway :

 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: cert-manager-gateway namespace: istio-system spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"

이 세 가지 파일이 있으면 Istio 설치가 기본 트래픽을 처리할 준비가 됩니다.

Istio 서비스 메시 요약

장점:

• 다양한 서비스 메시 중에서 Istio는 이 글을 쓰는 현재 가장 큰 온라인 커뮤니티를 보유하고 있습니다. 주요 경쟁자 중 하나인 Stack Overflow의 결과가 10배 이상인 이 제품은 웹에서 가장 많이 언급되는 서비스 메시입니다. GitHub 기여자도 마찬가지로 Linkerd를 능가합니다.
• Istio는 Kubernetes 및 VM 모드를 모두 지원합니다. 후자는 버전 1.9의 베타 버전입니다.

단점:

• Istio는 두 가지 의미에서 무료가 아닙니다.
  • 문서를 읽고 설정하고 제대로 작동하고 유지 관리하는 데 필요한 시간 측면에서 요구 사항이 높습니다. 인프라 규모와 서비스 수에 따라 Istio가 완전히 작동하고 프로덕션에 통합되기까지 몇 주에서 몇 달의 정규 작업이 소요됩니다.
  • 또한 상당한 양의 리소스 오버헤드가 추가됩니다. 즉, 초당 요청(RPS) 1,000개당 Envoy 컨테이너에 대해 350밀리코어(mCPU)가 필요합니다. 컨트롤 플레인 자체도 리소스를 소모할 수 있습니다. (이전에는 리소스 사용량을 예측하기 어려웠지만 노력 istiod 는 1 vCPU 및 1.5GB 메모리를 사용하여 안정화되었습니다.)
• Linkerd와 달리 기본 관리 대시보드가 ​​없습니다.
• Istio는 자체 수신 게이트웨이를 사용해야 합니다.
• Istio 제어 평면은 Kubernetes 컨테이너 내에서만 지원됩니다(즉, Istio의 데이터 평면과 달리 VM 모드가 없음).

Istio는 기술 대기업이 함께 모여 그들이 직면한 문제를 해결하기 위한 오픈 소스 프로젝트를 만든 좋은 예입니다. Istio 프로젝트 전체가 자체적으로 구조화되고(마이크로서비스에서 모놀리스 아키텍처로의 전환을 상기하면서) 많은 초기 문제를 해결하는 데 시간이 걸렸습니다. 오늘날 Istio는 서비스 메시에서 기대할 수 있는 모든 것을 수행하고 있으며 크게 확장할 수 있습니다. 그러나 이러한 모든 가능성에는 생산 환경에서의 사용을 지원하기 위한 지식, 작업 시간 및 컴퓨팅 리소스 측면에서 가파른 요구 사항이 따릅니다.

쿠마 퀵 리뷰

Kong이 만든 후 오픈 소스로 제공되는 Kuma는 2020년 말에 1.0에 도달했습니다. 어느 정도는 첫 번째 서비스 메시가 다소 무겁고 작동하기 어려운 데 대한 응답으로 만들어졌습니다.

기능 목록은 매우 모듈화되어 있음을 시사합니다. Kuma의 기본 아이디어는 Kubernetes 또는 기타 인프라에서 이미 실행 중인 애플리케이션과의 통합을 지향하는 것입니다.

• 트래픽 관리 영역에서 Kuma는 결함 주입 및 회로 차단과 같은 공통 서비스 메시 기능을 제공합니다.
• 서비스 간 mTLS 암호화 외에도 데이터 플레인과 컨트롤 플레인 간의 교환은 데이터 플레인 프록시 토큰 을 통해 Kuma에서 보호됩니다.
• 관찰 가능성 은 지표, 추적 및 로깅에 대한 다양한 트래픽 정책을 통해 Kuma에서 정의됩니다.
• 제어 평면의 포트 5653에서 실행되는 자체 DNS 확인자 덕분에 Kuma를 통해 서비스 검색 을 사용할 수 있습니다.
• Kuma는 다중 메시 기능 에 중점을 둡니다. 여러 Kubernetes 클러스터 또는 VM 환경을 다중 구역 배포 유형을 사용하여 공통 Kuma 클러스터로 쉽게 결합할 수 있습니다.
• Kuma는 기존 Kong 사용자를 위해 Kong Gateway와 쉽게 통합됩니다 .

Kuma의 범용(Kubernetes가 아닌) 버전에는 PostgreSQL이 종속성으로 필요하며 Kong의 CTO는 SMI 지원에 특히 반대했습니다. 그러나 Kuma는 처음부터 멀티클라우드 및 멀티클러스터 배포에 대한 아이디어로 개발되었으며 대시보드에는 이를 반영합니다.

Kuma는 서비스 메시 공간에서 아직 어리지만 지금까지 프로덕션 사용 사례가 거의 없지만 흥미롭고 유망한 경쟁자입니다.

Traefik 메쉬 빠른 검토

원래 Maesh라는 이름을 가진 Traefik Mesh(Traefik Labs)는 서비스 메시 툴링 경쟁에서 또 다른 신인입니다. 프로젝트 임무는 사용 및 구성을 쉽게 만들어 서비스 메시를 민주화하는 것입니다. 세심한 Traefik Proxy에 대한 개발자의 경험은 개발자를 이를 달성할 수 있는 최고의 위치에 놓았습니다.

• Traefik Mesh의 트래픽 관리 기능에는 회로 차단 및 속도 제한이 포함됩니다.
• 관찰 가능성 측면에서 Traefik Mesh는 기본 OpenTracing 지원 및 즉시 사용 가능한 메트릭(표준 설치에는 자동으로 Prometheus 및 Grafana 포함)이 있어 설정 시간이 절약됩니다.
• mTLS를 제외하고 보안 을 위해 사양은 SMI를 준수하며 Traefik Mesh는 액세스 제어를 통해 트래픽 권한을 미세 조정할 수 있습니다.

Traefik Mesh를 사용하려면 클러스터에 CoreDNS를 설치해야 합니다. (Azure는 1.12부터 기본적으로 CoreDNS를 사용했지만 GKE는 이 글을 쓰는 시점에서 kube-dns로 기본 설정됩니다. 즉, 이 경우에 중요한 추가 단계가 포함됩니다.) 또한 멀티클러스터 기능도 부족합니다.

즉, Traefik Mesh는 사이드카 삽입을 사용하지 않는다는 점에서 서비스 메시 비교 내에서 고유합니다. 대신 모든 노드에 DaemonSet으로 배포되어 서비스 간에 프록시 역할을 하므로 비침습적입니다. 전반적으로 Traefik Mesh는 설치 및 사용이 간단합니다.

AWS App Mesh 빠른 검토

클라우드 제공업체의 세계에서 AWS는 Kubernetes(또는 특히 EKS)와 함께 플러그인할 수 있는 기본 서비스 메시를 구현했지만 다른 서비스도 구현한 최초의 기업입니다. AWS App Mesh는 2018년 11월에 출시되었으며 AWS는 그 이후로 이를 반복하고 있습니다. AWS App Mesh의 주요 이점은 기존 AWS 에코시스템과 시장 위치입니다. AWS 전반에 걸친 큰 커뮤니티는 계속해서 AWS의 사용과 유용성을 주도할 것입니다.

• AWS App Mesh의 트래픽 관리 에는 일반적인 기능 외에 회로 차단이 포함됩니다.
• AWS App Mesh는 AWS에서 호스팅하므로 완전 관리형 서비스 이므로 리소스 사용량이나 제어 평면 가용성에 대해 걱정할 필요가 없습니다.
• Observability in AWS App Mesh can be done through Prometheus or AWS X-Ray.

The project is not open source, doesn't support SMI, and there's not much info online about HA standards for the control plane. AWS App Mesh is more complex to set up than other Kubernetes-native service meshes and has very little community online (24 answers on Stack Overflow, 400 stars on GitHub) but that's because users are meant to benefit from AWS support.

AWS App Mesh has native integration with AWS, starting with EKS and extending to other AWS services like ECS (Fargate) and EC2. Unlike Traefik Mesh, it has multicluster support. Plus, like most service meshes, it's based on injecting Envoy, the battle-tested sidecar proxy.

Kubernetes Service Mesh Comparison Tables

The six Kubernetes service mesh options presented here have a few things in common:

• Protocol support : They all work with HTTP, HTTP/2, gRPC, TCP, and WebSockets.
• They all have basic security in the form of mTLS between proxies by default.
• Service meshes, by design, provide some form of load balancing .
• These six, at least, also include a request retrying option among their traffic management features.
• Lastly, service discovery is a core feature of any service mesh.

But there are certainly differences worth highlighting when it comes to service mesh infrastructure, traffic management, observability, deployment, and other aspects.

하부 구조

교통 관리

관찰 가능성

* OpenCensus and OpenTracing merged into OpenTelemetry in 2019, but you might find Linkerd articles referring to OpenCensus, as well as Istio and Traefik Mesh articles referring to OpenTracing.

전개

Other Service Mesh Considerations

Should We Use a Kubernetes Service Mesh?

Now that we have seen what service meshes are, how they work, and the multitude of differences between them, we can ask: Do we need a service mesh?

That's the big question for SREs and cloud engineers these past few years. Indeed, microservices bring operational challenges in network communication that a service mesh can solve. But service meshes, for the most part, bring their own challenges when it comes to installation and operation.

One problem we can see emerging in many projects is that with service meshes, there is a gap between the proof-of-concept stage and the production stage. That is, it's unfortunately rare for companies to achieve staging environments that are identical to production in every aspect; with service meshes involving crucial infrastructure, scale- and edge-related effects can bring deployment surprises.

Service meshes are still under heavy development and improvement. This could actually be attractive for teams with high deployment velocities—those who have mastered “the art of staying state-of-the-art” and can closely follow the development cycle of cloud-native tools.

For others, though, the pace of service mesh evolution could be more of a pitfall. It would be easy enough to set up a service mesh but then forget about the need to maintain it. Security patches may go unapplied or, even if remembered, may carry with them unplanned issues in the form of deprecated features or a modified set of dependencies.

There's also a notable cost in terms of manpower to set up a service mesh in production. It would be a sensible goal for any team to evaluate this and understand if the benefits from a service mesh would outweigh the initial setup time. Service meshes are hard, no matter what the “easy” demo installations show.

In short, service meshes can solve some of the problems typical to projects deployed at scale but may introduce others, so be prepared to invest time and energy. In a hypothetical infrastructure involving 25 microservices and load of five queries per second, I would recommend having at least one person (preferably two) dedicated for at least a month to preparing a proof of concept and validating key aspects before thinking about running it in production. Once it's set up, anticipate the need for frequent upgrades—they will impact a core component of your infrastructure, namely network communications.

Kubernetes Service Meshes: A (Complex) Evolution in Scalable App Architecture

We've seen what service meshes are: a suite of tooling to answer new challenges introduced by microservices architecture. Through traffic management, observability, service discovery, and enhanced security, service meshes can reveal deep insights into app infrastructure.

There are multiple actors on the market, sometimes promoted by GAFAM et al., that have in some cases open-sourced or promoted their own internal tooling. Despite two different implementation types, service meshes will always have a control plane—the brain of the system—and a data plane, made of proxies that will intercept the requests of your application.

Reviewing the three biggest service meshes (Linkerd, Consul Connect, and Istio) we have seen the different strategies they've chosen to implement and the advantages they bring. Linkerd, being the oldest service mesh on the market, benefits from its creators' experience at Twitter. HashiCorp, for its part, offers the enterprise-ready Consul Connect, backed by a high level of expertise and support. Istio, which initially garnered ample attention online, has evolved into a mature project, delivering a feature-complete platform in the end.

But these actors are far from being the only ones, and some less-talked-about service meshes have emerged: Kuma, Traefik Mesh, and AWS App Mesh, among others. Kuma, from Kong, was created with the idea of making the service mesh idea “simple” and pluggable into any system, not just Kubernetes. Traefik Mesh benefited from experience with the preexisting Traefik Proxy and made the rare decision to eschew sidecar proxies. Last but not least, AWS decided to develop its own version of the service mesh, but one that relies on the dependable Envoy sidecar proxy.

In practice, service meshes are still hard to implement. Although service mesh benefits are compelling, their impact, critically, cuts both ways: Failure of a service mesh could render your microservices unable to communicate with each other, possibly bringing down your entire stack. A notorious example of this: Incompatibility between a Linkerd version and a Kubernetes version created a complete production outage at Monzo, an online bank.

Nonetheless, the whole industry is structuring itself around Kubernetes and initiatives like the Microsoft-spearheaded SMI, a standard interface for service meshes on Kubernetes. Among numerous other projects, the Cloud Native Computing Foundation (CNCF) has the Envoy-based Open Service Mesh (OSM) initiative, which was also originally introduced by Microsoft. The service mesh ecosystem remains abuzz, and I predict a champion emerging in the coming years, the same way Kubernetes became the de facto container orchestration tool.