Traffic Management

Describes the various Istio features focused on traffic routing and control.

Traffic Management

Istio의 트래픽 라우팅 규칙을 사용하면 서비스 간 트래픽 흐름과 API 호출을 쉽게 제어할 수 있습니다. Istio는 circuit breaker, timeout, retry와 같은 서비스 수준 속성의 구성을 단순화하고, A/B 테스트, 카나리 롤아웃, 비율 기반 트래픽 분할을 통한 단계적 롤아웃과 같은 중요한 작업을 쉽게 설정할 수 있게 합니다. 또한 종속 서비스나 네트워크 장애에 대해 애플리케이션의 복원력을 높이는 즉시 사용 가능한 신뢰성 기능을 제공합니다.

Istio의 트래픽 관리 모델은 서비스와 함께 배포되는 Envoy 프록시에 의존합니다. 메시 서비스가 송수신하는 모든 트래픽(데이터 플레인 트래픽)은 Envoy를 통해 프록시되므로 서비스를 변경하지 않고도 메시 주변의 트래픽을 쉽게 지시하고 제어할 수 있습니다.

이 가이드에서 설명하는 기능의 작동 방식에 대한 자세한 내용은 아키텍처 개요에서 Istio의 트래픽 관리 구현에 대해 자세히 알아볼 수 있습니다. 이 가이드의 나머지 부분에서는 Istio의 트래픽 관리 기능을 소개합니다.

Istio 트래픽 관리 소개

메시 내에서 트래픽을 지시하기 위해 Istio는 모든 엔드포인트의 위치와 소속 서비스를 알아야 합니다. 자체 서비스 레지스트리를 채우기 위해 Istio는 서비스 디스커버리 시스템에 연결됩니다. 예를 들어, Kubernetes 클러스터에 Istio를 설치한 경우 Istio는 해당 클러스터의 서비스와 엔드포인트를 자동으로 감지합니다.

이 서비스 레지스트리를 사용하여 Envoy 프록시는 관련 서비스로 트래픽을 지시할 수 있습니다. 대부분의 마이크로서비스 기반 애플리케이션에는 서비스 트래픽을 처리하기 위한 여러 서비스 워크로드 인스턴스가 있으며, 이를 로드 밸런싱 풀이라고도 합니다. 기본적으로 Envoy 프록시는 least requests 모델을 사용하여 각 서비스의 로드 밸런싱 풀 전체에 트래픽을 분산시킵니다. 이 모델에서는 각 요청이 풀에서 무작위로 선택된 두 호스트 중 활성 요청이 적은 호스트로 라우팅됩니다. 이렇게 하면 가장 많이 로드된 호스트가 다른 호스트보다 더 이상 로드되지 않을 때까지 요청을 받지 않습니다.

Istio의 기본 서비스 디스커버리와 로드 밸런싱은 작동하는 서비스 메시를 제공하지만, Istio가 할 수 있는 모든 것과는 거리가 멉니다. 많은 경우 메시 트래픽에 대해 더 세밀한 제어를 원할 수 있습니다. A/B 테스트의 일환으로 새로운 버전의 서비스로 특정 비율의 트래픽을 보내거나, 서비스 인스턴스의 특정 하위 집합에 대한 트래픽에 다른 로드 밸런싱 정책을 적용하고 싶을 수 있습니다. 메시로 들어오거나 나가는 트래픽에 특별한 규칙을 적용하거나 메시의 외부 종속성을 서비스 레지스트리에 추가하고 싶을 수도 있습니다. Istio의 트래픽 관리 API를 사용하여 자체 트래픽 구성을 Istio에 추가하면 이 모든 작업과 더 많은 작업을 수행할 수 있습니다.

다른 Istio 구성과 마찬가지로 API는 Kubernetes 커스텀 리소스 정의(CRD)를 사용하여 지정되며, 예제에서 볼 수 있듯이 YAML을 사용하여 구성할 수 있습니다.

이 가이드의 나머지 부분에서는 각 트래픽 관리 API 리소스와 그 사용 방법을 살펴봅니다. 이러한 리소스는 다음과 같습니다:

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

Virtual services

Virtual services와 destination rules은 Istio의 트래픽 라우팅 기능의 핵심 구성 요소입니다. Virtual service를 사용하면 Istio 서비스 메시 내에서 요청이 서비스로 라우팅되는 방식을 구성할 수 있으며, Istio와 플랫폼에서 제공하는 기본 연결 및 검색 기능을 기반으로 합니다. 각 virtual service는 일련의 라우팅 규칙으로 구성되며, 이 규칙은 순서대로 평가되어 Istio가 virtual service에 대한 각 주어진 요청을 메시 내의 특정 실제 대상과 일치시킬 수 있도록 합니다. 사용 사례에 따라 메시에 여러 개의 virtual service가 필요하거나 전혀 필요하지 않을 수 있습니다.

Virtual services를 사용하는 이유

Virtual services는 Istio의 트래픽 관리를 유연하고 강력하게 만드는 데 중요한 역할을 합니다. 클라이언트가 요청을 보내는 위치와 실제로 요청을 구현하는 대상 워크로드를 강력하게 분리함으로써 이를 수행합니다. Virtual services는 또한 이러한 워크로드로 트래픽을 보내기 위한 다양한 트래픽 라우팅 규칙을 지정하는 풍부한 방법을 제공합니다.

이것이 왜 그렇게 유용할까요? Virtual services가 없으면 Envoy는 소개에서 설명한 대로 least requests 로드 밸런싱을 사용하여 모든 서비스 인스턴스 간에 트래픽을 분산시킵니다. 워크로드에 대해 알고 있는 정보를 사용하여 이 동작을 개선할 수 있습니다. 예를 들어, 일부는 다른 버전을 나타낼 수 있습니다. 이는 A/B 테스트에서 유용할 수 있으며, 다른 서비스 버전 간에 비율에 따라 트래픽 경로를 구성하거나 내부 사용자의 트래픽을 특정 인스턴스 집합으로 보내도록 구성할 수 있습니다.

Virtual service를 사용하면 하나 이상의 호스트 이름에 대한 트래픽 동작을 지정할 수 있습니다. Virtual service의 라우팅 규칙을 사용하여 Envoy에게 virtual service의 트래픽을 적절한 대상으로 보내는 방법을 알려줍니다. 라우팅 대상은 동일한 서비스의 다른 버전이거나 완전히 다른 서비스일 수 있습니다.

일반적인 사용 사례는 서비스 하위 집합으로 지정된 서비스의 다른 버전으로 트래픽을 보내는 것입니다. 클라이언트는 마치 단일 엔티티인 것처럼 virtual service 호스트로 요청을 보내고, Envoy는 virtual service 규칙에 따라 다른 버전으로 트래픽을 라우팅합니다. 예를 들어, "새 버전으로 20%의 호출을 보내거나" "이러한 사용자의 호출을 버전 2로 보냅니다". 이를 통해 예를 들어 새로운 서비스 버전으로 보내는 트래픽의 비율을 점진적으로 증가시키는 카나리 롤아웃을 생성할 수 있습니다. 트래픽 라우팅은 인스턴스 배포와 완전히 분리되어 있어, 새 서비스 버전을 구현하는 인스턴스의 수를 트래픽 라우팅을 전혀 참조하지 않고도 트래픽 부하에 따라 확장하거나 축소할 수 있습니다. 반면에 Kubernetes와 같은 컨테이너 오케스트레이션 플랫폼은 인스턴스 스케일링에 기반한 트래픽 분산만 지원하며, 이는 빠르게 복잡해집니다. Virtual services가 카나리 배포에 어떻게 도움이 되는지에 대해 Istio를 사용한 카나리 배포에서 자세히 알아볼 수 있습니다.

Virtual services를 사용하면 다음과 같은 작업도 수행할 수 있습니다:

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

• Gateway와 함께 트래픽 규칙을 구성하여 인그레스 및 이그레스 트래픽을 제어합니다.

일부 경우에는 이러한 기능을 사용하기 위해 destination rules도 구성해야 합니다. 여기서 서비스 하위 집합을 지정합니다. 서비스 하위 집합 및 기타 대상별 정책을 별도의 객체로 지정하면 virtual services 간에 이를 깔끔하게 재사용할 수 있습니다. 다음 섹션에서 destination rules에 대해 자세히 알아볼 수 있습니다.

Virtual service 예제

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

apiVersion: 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

The hosts field

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

hosts:
- reviews

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

Routing rules

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

Match condition

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

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

Destination

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

route:
- destination:
    host: reviews
    subset: v2

이 예제와 페이지의 다른 예제에서는 간단히 하기 위해 destination 호스트에 대해 Kubernetes 짧은 이름을 사용합니다. 이 규칙이 평가될 때, Istio는 라우팅 규칙을 포함하는 virtual service의 네임스페이스를 기반으로 도메인 접미사를 추가하여 호스트의 완전한 정규화된 이름을 얻습니다. 예제에서 짧은 이름을 사용하면 원하는 네임스페이스에서 예제를 복사하여 시도할 수 있습니다.

destination 섹션은 또한 이 규칙의 조건과 일치하는 요청이 이동할 Kubernetes 서비스의 subset을 지정합니다. 이 경우 v2라는 subset입니다. 서비스 subset을 정의하는 방법은 아래의 destination rules 섹션에서 자세히 설명합니다.

Routing rule precedence

라우팅 규칙은 위에서 아래로 순차적으로 평가되며, virtual service 정의의 첫 번째 규칙이 가장 높은 우선순위를 가집니다. 이 경우 첫 번째 라우팅 규칙과 일치하지 않는 모든 항목이 기본 대상으로 이동하도록 하고자 합니다. 두 번째 규칙에는 일치 조건이 없으며 단순히 트래픽을 v3 subset으로 보냅니다.

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

각 virtual service의 마지막 규칙으로 기본 "조건 없음" 또는 비율 기반 규칙을 제공하여 virtual service로의 트래픽이 항상 최소한 하나의 일치하는 라우트를 가지도록 하는 것이 좋습니다.

More about routing rules

라우팅 규칙은 특정 트래픽 subset을 특정 대상으로 라우팅하는 강력한 도구입니다. 트래픽 포트, 헤더 필드, URI 등을 기준으로 일치 조건을 설정할 수 있습니다. 예를 들어, 이 virtual service는 사용자가 http://bookinfo.com/에서 더 큰 virtual service의 일부인 것처럼 두 개의 별도 서비스를 보낼 수 있게 합니다. virtual service 규칙은 요청 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로 결합할 수 있습니다. 또한, 주어진 virtual service에 대해 여러 라우팅 규칙을 가질 수 있습니다. 이를 통해 단일 virtual service 내에서 라우팅 조건을 복잡하거나 단순하게 만들 수 있습니다. 일치 조건 필드와 가능한 값의 전체 목록은 HTTPMatchRequest 참조에서 찾을 수 있습니다.

일치 조건을 사용하는 것 외에도 트래픽을 비율 "weight"에 따라 분배할 수 있습니다. 이는 A/B 테스트 및 카나리 롤아웃에 유용합니다:

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

라우팅 규칙을 사용하여 트래픽에 대해 몇 가지 작업을 수행할 수도 있습니다. 예를 들어:

• 헤더 추가 또는 제거

• URL 재작성

• 이 대상으로의 호출에 대한 재시도 정책 설정

사용 가능한 작업에 대한 자세한 내용은 HTTPRoute 참조를 참조하십시오.

Destination rules

Virtual services와 함께, destination rules는 Istio의 트래픽 라우팅 기능의 중요한 부분입니다. Virtual services가 주어진 대상으로 트래픽을 라우팅하는 방법을 정의하는 반면, destination rules는 해당 대상으로의 트래픽에 대해 어떤 일이 발생하는지 구성합니다. Destination rules는 virtual service 라우팅 규칙이 평가된 후 적용되므로 트래픽의 "실제" 대상에 적용됩니다.

특히, destination rules를 사용하여 특정 서비스의 인스턴스를 버전별로 그룹화하는 등 명명된 서비스 subset을 지정할 수 있습니다. 그런 다음 이러한 서비스 subset을 virtual services의 라우팅 규칙에서 사용하여 서비스의 다양한 인스턴스로의 트래픽을 제어할 수 있습니다.

Destination rules는 또한 전체 대상 서비스나 특정 서비스 subset을 호출할 때 Envoy의 트래픽 정책을 사용자 정의할 수 있게 합니다. 예를 들어, 선호하는 로드 밸런싱 모델, TLS 보안 모드 또는 회로 차단기 설정 등을 지정할 수 있습니다. Destination rule 옵션의 전체 목록은 Destination Rule 참조에서 확인할 수 있습니다.

Load balancing options

기본적으로 Istio는 요청을 가장 적은 수의 요청을 가진 인스턴스에 분배하는 least requests 로드 밸런싱 정책을 사용합니다. Istio는 특정 서비스나 서비스 subset에 대한 요청에 대해 destination rules에서 지정할 수 있는 다음 모델도 지원합니다:

• Random: 요청을 풀의 인스턴스로 무작위로 전달합니다.

• Weighted: 요청을 특정 비율에 따라 풀의 인스턴스로 전달합니다.

• Round robin: 요청을 순서대로 각 인스턴스로 전달합니다.

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

Destination rule example

다음 예제 destination rule은 my-svc 대상 서비스에 대해 세 가지 다른 subset을 구성하며, 각각 다른 로드 밸런싱 정책을 사용합니다:

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

각 subset은 하나 이상의 labels를 기반으로 정의되며, Kubernetes에서는 객체(예: Pods)에 첨부된 키/값 쌍입니다. 이러한 라벨은 Kubernetes 서비스의 배포 시 metadata로 적용되어 다른 버전을 식별합니다.

이 destination rule은 subset을 정의하는 것 외에도 해당 대상의 모든 subset에 대한 기본 트래픽 정책과 해당 subset에 대해서만 재정의되는 subset별 정책을 모두 가지고 있습니다. 기본 정책은 subsets 필드 위에 정의되어 있으며, v1 및 v3 subset에 대해 간단한 랜덤 로드 밸런서를 설정합니다. v2 정책에서는 해당 subset 필드에 라운드 로빈 로드 밸런서를 지정합니다.