Traffic Management

트래픽 관리

Istio의 트래픽 라우팅 규칙을 사용하면 서비스 간의 트래픽 흐름과 API 호출을 쉽게 제어할 수 있습니다. Istio는 서킷 브레이커, 타임아웃, 재시도와 같은 서비스 수준 속성의 구성을 단순화하고, A/B 테스트, 카나리아 롤아웃, 백분율 기반 트래픽 분할을 통한 단계적 롤아웃과 같은 중요한 작업을 쉽게 설정할 수 있습니다. 또한 종속 서비스나 네트워크의 장애에 대해 애플리케이션의 탄력성을 높이는 데 도움이 되는 기본 제공 안정성 기능도 제공합니다.Istio의 트래픽 관리 모델은 서비스와 함께 배포되는 Envoy 프록시에 의존합니다. 메시 서비스가 주고받는 모든 트래픽(데이터 플레인 트래픽)은 Envoy를 통해 프록시되므로, 서비스를 변경하지 않고도 메시 주변의 트래픽을 쉽게 지시하고 제어할 수 있습니다.이 가이드에 설명된 기능이 어떻게 작동하는지 자세히 알고 싶다면, 에서 Istio의 트래픽 관리 구현에 대해 자세히 알아볼 수 있습니다. 이 가이드의 나머지 부분에서는 Istio의 트래픽 관리 기능을 소개합니다.

Istio 트래픽 관리 소개

메시 내에서 트래픽을 지시하려면 Istio는 모든 엔드포인트가 어디에 있고 어떤 서비스에 속하는지 알아야 합니다. Istio는 자체 서비스 레지스트리를 채우기 위해 서비스 검색 시스템에 연결합니다. 예를 들어, Kubernetes 클러스터에 Istio를 설치한 경우 Istio는 해당 클러스터의 서비스와 엔드포인트를 자동으로 감지합니다.이 서비스 레지스트리를 사용하여 Envoy 프록시는 관련 서비스로 트래픽을 지시할 수 있습니다. 대부분의 마이크로서비스 기반 애플리케이션에는 서비스 트래픽을 처리하기 위해 각 서비스 워크로드의 여러 인스턴스가 있는데, 이를 로드 밸런싱 풀이라고도 합니다. 기본적으로 Envoy 프록시는 최소 요청 모델을 사용하여 각 서비스의 로드 밸런싱 풀에 트래픽을 분산합니다. 여기서 각 요청은 풀에서 무작위로 선택한 두 개의 호스트 중 활성 요청이 더 적은 호스트로 라우팅됩니다. 이런 방식으로 가장 많이 로드된 호스트는 다른 호스트만큼 로드되지 않을 때까지 요청을 받지 않습니다.Istio의 기본 서비스 검색 및 로드 밸런싱은 작동하는 서비스 메시를 제공하지만, Istio가 할 수 있는 모든 것과는 거리가 멉니다. 많은 경우 메시 트래픽에 대해 더 세분화된 제어를 원할 수 있습니다. A/B 테스트의 일환으로 새 버전의 서비스에 특정 비율의 트래픽을 지시하거나, 특정 서비스 인스턴스 하위 집합에 대한 트래픽에 다른 로드 밸런싱 정책을 적용할 수 있습니다. 또한 메시로 들어오거나 나가는 트래픽에 특별한 규칙을 적용하거나, 메시의 외부 종속성을 서비스 레지스트리에 추가할 수도 있습니다. Istio의 트래픽 관리 API를 사용하여 Istio에 자체 트래픽 구성을 추가하면 이 모든 작업과 그 이상을 수행할 수 있습니다.다른 Istio 구성과 마찬가지로 API는 Kubernetes 사용자 정의 리소스 정의(CRD)를 사용하여 지정되며, 예제에서 볼 수 있듯이 YAML을 사용하여 구성할 수 있습니다.이 가이드의 나머지 부분에서는 트래픽 관리 API 리소스 각각과 그것으로 할 수 있는 작업을 살펴봅니다. 이러한 리소스는 다음과 같습니다:

또한 이 가이드에서는 API 리소스에 내장된 일부 네트워크 복원력 및 테스트 기능에 대한 개요도 제공합니다.

가상 서비스

가상 서비스는 목적지 규칙과 함께 Istio의 트래픽 라우팅 기능의 핵심 구성 요소입니다. 가상 서비스를 사용하면 Istio 서비스 메시 내에서 서비스로 요청을 라우팅하는 방법을 구성할 수 있으며, Istio와 플랫폼에서 제공하는 기본 연결 및 검색 기능을 기반으로 합니다. 각 가상 서비스는 순서대로 평가되는 라우팅 규칙 집합으로 구성되어 있어, Istio가 가상 서비스에 대한 각 요청을 메시 내의 특정 실제 대상과 매칭할 수 있습니다. 사용 사례에 따라 메시에 여러 개의 가상 서비스가 필요하거나 전혀 필요하지 않을 수 있습니다.

가상 서비스를 사용하는 이유는 무엇일까요?

가상 서비스는 Istio의 트래픽 관리를 유연하고 강력하게 만드는 데 핵심적인 역할을 합니다. 이는 클라이언트가 요청을 보내는 위치와 실제로 요청을 구현하는 대상 워크로드를 강력하게 분리함으로써 이루어집니다. 또한 가상 서비스는 해당 워크로드로 트래픽을 보내기 위한 다양한 트래픽 라우팅 규칙을 지정하는 풍부한 방법을 제공합니다.이것이 왜 유용할까요? 가상 서비스가 없으면 소개에서 설명한 대로 Envoy는 모든 서비스 인스턴스 간에 최소 요청 로드 밸런싱을 사용하여 트래픽을 분산합니다. 워크로드에 대해 알고 있는 내용으로 이 동작을 개선할 수 있습니다. 예를 들어, 일부는 다른 버전을 나타낼 수 있습니다. 이는 A/B 테스트에서 유용할 수 있는데, 여기서는 서로 다른 서비스 버전에 걸쳐 백분율을 기준으로 트래픽 경로를 구성하거나 내부 사용자의 트래픽을 특정 인스턴스 집합으로 보내고 싶을 수 있습니다.가상 서비스를 사용하면 하나 이상의 호스트 이름에 대한 트래픽 동작을 지정할 수 있습니다. 가상 서비스의 라우팅 규칙을 사용하여 Envoy에게 가상 서비스의 트래픽을 적절한 대상으로 보내는 방법을 알려줍니다. 경로 대상은 동일한 서비스의 다른 버전이거나 완전히 다른 서비스일 수 있습니다.일반적인 사용 사례는 서비스 하위 집합으로 지정된 서비스의 다른 버전으로 트래픽을 보내는 것입니다. 클라이언트는 마치 단일 엔터티인 것처럼 가상 서비스 호스트에 요청을 보내고, Envoy는 가상 서비스 규칙에 따라 트래픽을 다른 버전으로 라우팅합니다. 예를 들어 "호출의 20%는 새 버전으로 이동" 또는 "이러한 사용자의 호출은 버전 2로 이동"과 같은 식입니다. 이를 통해 예를 들어 새 서비스 버전으로 전송되는 트래픽 비율을 점진적으로 늘리는 카나리아 롤아웃을 생성할 수 있습니다. 트래픽 라우팅은 인스턴스 배포와 완전히 분리되어 있어, 새 서비스 버전을 구현하는 인스턴스 수는 트래픽 라우팅을 전혀 참조하지 않고 트래픽 부하에 따라 확장 및 축소될 수 있습니다. 대조적으로 Kubernetes와 같은 컨테이너 오케스트레이션 플랫폼은 인스턴스 스케일링을 기반으로 하는 트래픽 분산만 지원하므로 빠르게 복잡해집니다. Istio를 사용한 카나리아 배포에서 가상 서비스가 카나리아 배포에 어떻게 도움이 되는지 자세히 알아볼 수 있습니다.가상 서비스를 사용하면 다음과 같은 작업도 할 수 있습니다:

단일 가상 서비스를 통해 여러 애플리케이션 서비스 처리. 예를 들어 메시가 Kubernetes를 사용하는 경우 특정 네임스페이스의 모든 서비스를 처리하도록 가상 서비스를 구성할 수 있습니다. 단일 가상 서비스를 여러 "실제" 서비스에 매핑하는 것은 모놀리식 애플리케이션을 서비스 소비자가 전환에 적응할 필요 없이 별개의 마이크로서비스로 구축된 복합 서비스로 전환하는 데 특히 유용합니다. 라우팅 규칙은 "monolith.com의 이러한 URI에 대한 호출은 마이크로서비스 A로 이동"과 같이 지정할 수 있습니다. 아래 예제 중 하나에서 이것이 어떻게 작동하는지 확인할 수 있습니다.
게이트웨이와 함께 트래픽 규칙을 구성하여 수신 및 발신 트래픽을 제어합니다.

경우에 따라 이러한 기능을 사용하려면 대상 규칙도 구성해야 합니다. 여기서 서비스 하위 집합을 지정하기 때문입니다. 별도의 객체에서 서비스 하위 집합 및 기타 대상별 정책을 지정하면 가상 서비스 간에 이를 깔끔하게 재사용할 수 있습니다. 다음 섹션에서 대상 규칙에 대해 자세히 알아볼 수 있습니다.

가상 서비스 예제

다음 가상 서비스는 요청이 특정 사용자로부터 오는지 여부에 따라 요청을 서비스의 다른 버전으로 라우팅합니다.

textapiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v3

hosts 필드

hosts 필드는 가상 서비스의 호스트, 즉 이러한 라우팅 규칙이 적용되는 사용자 주소 지정 가능한 대상을 나열합니다. 이것은 클라이언트가 서비스에 요청을 보낼 때 사용하는 주소입니다.

hosts:
- reviews

가상 서비스 호스트 이름은 IP 주소, DNS 이름 또는 플랫폼에 따라 완전한 도메인 이름(FQDN)으로 암시적 또는 명시적으로 확인되는 짧은 이름(예: Kubernetes 서비스 짧은 이름)일 수 있습니다. 또한 와일드카드("*") 접두사를 사용하여 일치하는 모든 서비스에 대한 단일 라우팅 규칙 집합을 만들 수 있습니다. 가상 서비스 호스트는 실제로 Istio 서비스 레지스트리의 일부일 필요가 없으며, 단순히 가상 대상일 뿐입니다. 이를 통해 메시 내부에 라우팅 가능한 항목이 없는 가상 호스트에 대한 트래픽을 모델링할 수 있습니다.

라우팅 규칙

http 섹션에는 가상 서비스의 라우팅 규칙이 포함되어 있으며, hosts 필드에 지정된 대상으로 전송된 HTTP/1.1, HTTP2 및 gRPC 트래픽을 라우팅하기 위한 일치 조건과 작업을 설명합니다(tcp 및 tls 섹션을 사용하여 TCP 및 종료되지 않은 TLS 트래픽에 대한 라우팅 규칙을 구성할 수도 있음). 라우팅 규칙은 트래픽을 보내려는 대상과 사용 사례에 따라 0개 이상의 일치 조건으로 구성됩니다.

일치 조건

예제의 첫 번째 라우팅 규칙에는 조건이 있으므로 match 필드로 시작합니다. 이 경우 "jason" 사용자의 모든 요청에 이 라우팅을 적용하려고 하므로 headers, end-user 및 exact 필드를 사용하여 적절한 요청을 선택합니다.

- match:
  - headers:
      end-user:
        exact: jason

대상

route 섹션의 destination 필드는 이 조건과 일치하는 트래픽의 실제 대상을 지정합니다. 가상 서비스의 호스트와 달리 대상의 호스트는 Istio의 서비스 레지스트리에 존재하는 실제 대상이어야 합니다. 그렇지 않으면 Envoy는 트래픽을 보낼 위치를 알 수 없습니다. 이는 프록시가 있는 메시 서비스이거나 서비스 항목을 사용하여 추가된 비 메시 서비스일 수 있습니다. 이 경우 Kubernetes에서 실행 중이며 호스트 이름은 Kubernetes 서비스 이름입니다:

route:
- destination:
    host: reviews
    subset: v2

이 페이지의 이 예제와 다른 예제에서는 간단히 하기 위해 대상 호스트에 Kubernetes 짧은 이름을 사용합니다. 이 규칙이 평가될 때 Istio는 호스트의 정규화된 이름을 얻기 위해 라우팅 규칙이 포함된 가상 서비스의 네임스페이스를 기반으로 도메인 접미사를 추가합니다. 예제에서 짧은 이름을 사용한다는 것은 복사하여 원하는 네임스페이스에서 시도할 수 있다는 것을 의미합니다.destination 섹션은 또한 이 규칙의 조건과 일치하는 요청을 보내려는 이 Kubernetes 서비스의 하위 집합을 지정합니다. 이 경우 v2라는 하위 집합입니다. 아래의 대상 규칙 섹션에서 서비스 하위 집합을 정의하는 방법을 볼 수 있습니다.

라우팅 규칙 우선순위

라우팅 규칙은 위에서 아래로 순차적으로 평가되며, 가상 서비스 정의의 첫 번째 규칙에 가장 높은 우선순위가 부여됩니다. 이 경우 첫 번째 라우팅 규칙과 일치하지 않는 모든 것을 두 번째 규칙에 지정된 기본 대상으로 보내려고 합니다. 이 때문에 두 번째 규칙에는 일치 조건이 없고 트래픽을 v3 하위 집합으로만 지시합니다.

- route:
  - destination:
      host: reviews
      subset: v3

가상 서비스에 대한 트래픽이 항상 하나 이상의 일치하는 경로를 갖도록 하려면 각 가상 서비스의 마지막 규칙으로 이와 같은 기본 "조건 없음" 또는 가중치 기반 규칙(아래 설명)을 제공하는 것이 좋습니다.

라우팅 규칙에 대한 더 자세한 내용

위에서 보았듯이 라우팅 규칙은 특정 트래픽 하위 집합을 특정 대상으로 라우팅하는 강력한 도구입니다. 트래픽 포트, 헤더 필드, URI 등에 대한 일치 조건을 설정할 수 있습니다. 예를 들어, 이 가상 서비스를 사용하면 사용자가 http://bookinfo.com/의 더 큰 가상 서비스의 일부인 것처럼 ratings와 reviews라는 두 개의 별도 서비스로 트래픽을 보낼 수 있습니다. 가상 서비스 규칙은 요청 URI를 기반으로 트래픽을 일치시키고 요청을 적절한 서비스로 보냅니다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
  - bookinfo.com
  http:
  - match:
    - uri:
        prefix: /reviews
    route:
    - destination:
        host: reviews
  - match:
    - uri:
        prefix: /ratings
    route:
    - destination:
        host: ratings

일부 일치 조건의 경우 정확한 값, 접두사 또는 정규식을 사용하여 선택할 수도 있습니다.동일한 match 블록에 여러 일치 조건을 추가하여 조건을 AND로 연결하거나, 동일한 규칙에 여러 일치 블록을 추가하여 조건을 OR로 연결할 수 있습니다. 또한 주어진 가상 서비스에 대해 여러 라우팅 규칙을 가질 수 있습니다. 이를 통해 단일 가상 서비스 내에서 라우팅 조건을 원하는 만큼 복잡하거나 단순하게 만들 수 있습니다. 일치 조건 필드의 전체 목록과 가능한 값은 HTTPMatchRequest 참조에서 찾을 수 있습니다.일치 조건을 사용하는 것 외에도 백분율 "가중치"로 트래픽을 분산할 수 있습니다. 이는 A/B 테스트 및 카나리아 롤아웃에 유용합니다:

spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 75
    - destination:
        host: reviews
        subset: v2
      weight: 25

또한 라우팅 규칙을 사용하여 트래픽에 대해 일부 작업을 수행할 수 있습니다. 예를 들면:

헤더 추가 또는 제거
URL 재작성
이 대상에 대한 호출에 대한 재시도 정책 설정

사용 가능한 작업에 대해 자세히 알아보려면 HTTPRoute 참조를 참조하세요.

대상 규칙

가상 서비스와 함께 대상 규칙은 Istio의 트래픽 라우팅 기능의 핵심 부분입니다. 가상 서비스를 주어진 대상으로 트래픽을 라우팅하는 방법으로 생각할 수 있고, 그런 다음 대상 규칙을 사용하여 해당 대상에 대한 트래픽에 어떤 일이 발생하는지 구성합니다. 대상 규칙은 가상 서비스 라우팅 규칙이 평가된 후에 적용되므로 트래픽의 "실제" 대상에 적용됩니다.특히 대상 규칙을 사용하여 버전별로 주어진 서비스의 모든 인스턴스를 그룹화하는 등 명명된 서비스 하위 집합을 지정합니다. 그런 다음 가상 서비스의 라우팅 규칙에서 이러한 서비스 하위 집합을 사용하여 서비스의 다른 인스턴스에 대한 트래픽을 제어할 수 있습니다.대상 규칙을 사용하면 전체 대상 서비스 또는 특정 서비스 하위 집합을 호출할 때 선호하는 로드 밸런싱 모델, TLS 보안 모드 또는 서킷 브레이커 설정과 같은 Envoy의 트래픽 정책을 사용자 지정할 수도 있습니다. 대상 규칙 참조에서 대상 규칙 옵션의 전체 목록을 볼 수 있습니다.

로드 밸런싱 옵션

기본적으로 Istio는 요청 수가 가장 적은 인스턴스에 요청이 분산되는 최소 요청 로드 밸런싱 정책을 사용합니다. Istio는 또한 특정 서비스 또는 서비스 하위 집합에 대한 요청에 대해 대상 규칙에 지정할 수 있는 다음 모델도 지원합니다.

무작위: 요청이 풀의 인스턴스에 무작위로 전달됩니다.
가중치: 요청이 특정 백분율에 따라 풀의 인스턴스에 전달됩니다.
라운드 로빈: 요청이 순서대로 각 인스턴스에 전달됩니다.

각 옵션에 대한 자세한 내용은 Envoy 로드 밸런싱 문서를 참조하세요.

대상 규칙 예제

다음 예제 대상 규칙은 my-svc 대상 서비스에 대해 서로 다른 로드 밸런싱 정책을 가진 세 가지 다른 하위 집합을 구성합니다:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-destination-rule
spec:
  host: my-svc
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN
  - name: v3
    labels:
      version: v3

각 하위 집합은 하나 이상의 labels을 기반으로 정의되며, Kubernetes에서는 Pod와 같은 객체에 연결되는 키/값 쌍입니다. 이러한 레이블은 Kubernetes 서비스의 배포에서 다른 버전을 식별하기 위해 metadata로 적용됩니다.하위 집합을 정의하는 것 외에도 이 대상 규칙에는 이 대상의 모든 하위 집합에 대한 기본 트래픽 정책과 해당 하위 집합에 대해서만 이를 재정의하는 하위 집합별 정책이 있습니다. subsets 필드 위에 정의된 기본 정책은 v1과 v3 하위 집합에 대해 간단한 무작위 로드 밸런서를 설정합니다. v2 정책에서는 해당 하위 집합의 필드에 라운드 로빈 로드 밸런서가 지정됩니다.

게이트웨이

게이트웨이를 사용하여 메시에 들어오고 나가는 트래픽을 관리하여 메시에 들어오거나 나가길 원하는 트래픽을 지정할 수 있습니다. 게이트웨이 구성은 서비스 워크로드와 함께 실행되는 사이드카 Envoy 프록시가 아닌 메시 가장자리에서 실행되는 독립형 Envoy 프록시에 적용됩니다.Kubernetes Ingress API와 같이 시스템에 들어오는 트래픽을 제어하는 다른 메커니즘과 달리 Istio 게이트웨이를 사용하면 Istio의 트래픽 라우팅의 모든 기능과 유연성을 활용할 수 있습니다. Istio의 Gateway 리소스는 노출할 포트, TLS 설정 등과 같은 4-6계층 로드 밸런싱 속성만 구성할 수 있기 때문입니다. 그런 다음 동일한 API 리소스에 애플리케이션 계층 트래픽 라우팅(L7)을 추가하는 대신 일반 Istio 가상 서비스를 게이트웨이에 바인딩합니다. 이를 통해 기본적으로 Istio 메시의 다른 데이터 플레인 트래픽과 마찬가지로 게이트웨이 트래픽을 관리할 수 있습니다.게이트웨이는 주로 인그레스 트래픽을 관리하는 데 사용되지만 이그레스 게이트웨이를 구성할 수도 있습니다. 이그레스 게이트웨이를 사용하면 메시를 떠나는 트래픽에 대해 전용 종료 노드를 구성할 수 있어 어떤 서비스가 외부 네트워크에 액세스할 수 있는지 또는 액세스해야 하는지 제한하거나 예를 들어 메시에 보안을 추가하기 위해 이그레스 트래픽의 안전한 제어를 활성화할 수 있습니다. 또한 게이트웨이를 사용하여 순수 내부 프록시를 구성할 수도 있습니다.Istio는 사용할 수 있는 일부 사전 구성된 게이트웨이 프록시 배포(istio-ingressgateway 및 istio-egressgateway)를 제공합니다. 데모 설치를 사용하는 경우 둘 다 배포되고 기본 프로필을 사용하는 경우 인그레스 게이트웨이만 배포됩니다. 이러한 배포에 자체 게이트웨이 구성을 적용하거나 자체 게이트웨이 프록시를 배포 및 구성할 수 있습니다.

게이트웨이 예제

다음 예제는 외부 HTTPS 인그레스 트래픽에 대한 가능한 게이트웨이 구성을 보여줍니다:

textapiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: ext-host-gwy
spec:
  selector:
    app: my-gateway-controller
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - ext-host.example.com
    tls:
      mode: SIMPLE
      credentialName: ext-host-cert

이 게이트웨이 구성을 통해 ext-host.example.com의 HTTPS 트래픽이 443 포트에서 메시로 들어올 수 있지만 트래픽에 대한 라우팅은 지정하지 않습니다. 라우팅을 지정하고 게이트웨이가 의도한 대로 작동하려면 다음 예제와 같이 가상 서비스의 gateways 필드를 사용하여 게이트웨이를 가상 서비스에 바인딩해야 합니다:

textapiVersion: networking.istio.io/v1alpha3
kind: VirtualService 
metadata:
  name: virtual-svc
spec:
  hosts:
  - ext-host.example.com
  gateways:
  - ext-host-gwy

그런 다음 외부 트래픽에 대한 라우팅 규칙으로 가상 서비스를 구성할 수 있습니다.

PreviousConcepts NextPage

Last updated 10 months ago