Kubernetes: Up and Running, 제3판

15장. 서비스 메시

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

컨테이너에 이어 서비스 메시라는 용어는 Cloud 네이티브 개발의 대명사가 되었습니다. 그러나 컨테이너와 마찬가지로 서비스 메시도 상용 제품뿐만 아니라 다양한 오픈 소스 프로젝트를 포괄하는 광범위한 용어입니다. Cloud 네이티브 아키텍처에서 서비스 메시의 일반적인 역할을 이해하는 것이 유용합니다. 이 장에서는 서비스 메시가 무엇인지, 다양한 소프트웨어 프로젝트에서 서비스 메시를 구현하는 방법, 마지막으로 가장 중요한 것은 덜 복잡한 아키텍처와 비교하여 서비스 메시를 애플리케이션에 통합하는 것이 합당한 경우를 보여드립니다.

참고

많은 추상적인 Cloud 네이티브 아키텍처 다이어그램에서는 Cloud 네이티브 아키텍처에 서비스 메시가 필요한 것처럼 보입니다. 이는 사실이 아닙니다. 서비스 메시 도입을 고려할 때는 종속성 목록에 새로운 구성 요소(일반적으로 타사에서 제공하는)를 추가하는 복잡성과 균형을 맞춰야 합니다. 대부분의 경우, 애플리케이션의 요구 사항을 충족하는 경우 기존 Kubernetes 리소스에 단순히 의존하는 것이 더 쉽고 안정적입니다.

앞서 서비스 및 인그레스(Ingress)와 같은 Kubernetes의 다른 네트워킹 기본 요소에 대해 설명한 바 있다. Kubernetes의 핵심에 이러한 네트워킹 기능이 존재하는데, 네트워킹 계층에 추가 기능(및 복잡성)을 주입해야 하는 이유는 무엇일까요? 근본적으로는 이러한 네트워킹 기본 요소를 사용하는 소프트웨어 애플리케이션의 필요에 따라 결정됩니다.

Kubernetes 코어의 네트워킹은 실제로 애플리케이션을 대상으로만 인식합니다. 서비스 및 인그레스 리소스 모두 특정 파드 집합으로 트래픽을 라우팅하는 레이블 선택기가 있지만, 그 외에는 이러한 리소스가 제공하는 추가 기능이 상대적으로 거의 없습니다. HTTP 로드 밸런서로서 Ingress는 이보다 조금 더 나아갔지만, 기존의 다양한 구현에 맞는 공통 API를 정의해야 하는 과제로 인해 Ingress API의 기능이 제한됩니다. 진정한 "클라우드 네이티브" HTTP 라우팅 API는 어떻게 베어메탈 네트워킹 디바이스에서부터 클라우드 네이티브 개발을 고려하지 않고 구축된 퍼블릭 클라우드 API에 이르기까지 다양한 로드 밸런서 및 프록시와 호환될 수 있을까요?

실제로 Kubernetes의 코어 외부에서 서비스 메시 API를 개발하는 것은 이러한 도전의 결과입니다. 인그레스 API는 외부 세계의 HTTP(S) 트래픽을 Cloud 네이티브 애플리케이션으로 가져옵니다. 기존 인프라와 호환될 필요가 없는 Kubernetes의 클라우드 네이티브 애플리케이션 내에서 서비스 메시 API는 추가적인 클라우드 네이티브 네트워킹 기능을 제공합니다. 그렇다면 이러한 기능은 무엇일까요? 대부분의 서비스 메시 구현에서 제공하는 세 가지 일반적인 기능은 네트워크 암호화 및 권한 부여, 트래픽 쉐이핑, 통합 가시성입니다. ...