Traffic Management

이스티오의 트래픽 라우팅 룰은 사용자가 서비스간 API 콜과 트래픽 흐름을 쉽게 컨트롤할 수 있게 해준다. 이스티오는 써킷 브레이커, 타임아웃, 리트라이같은 서비스 레벨의 설정을 단순화하며 퍼센트 기반의 트래픽 조절을 상요한 스테이지 롤아웃, 카나리 롤아웃, A/B 테스팅 같은 중요한 작업을 쉽게 설정할 수 있게 해준다. 또한 네트워크, 서비스로 인해 발생하는 장애로부터의 탄력적이게 운용할 수 있게 해주는 즉시 적용 가능한 신뢰성 기능들을 제공한다.

이스티오의 트래픽 매니지먼트 모델은 서비스와 같이 배포되는 엔보이 프록시로부터 제공된다. 메시 서비스에서 주고 받는 모든 트래픽은 엔보이로부터 프록시되고 사용자 서비스의 별도 수정 없이도 쉽게 컨트롤할 수 있게 해준다.

만약 이 가이드에서 설명한 기능이 어떻게 동작하는지 관심있다면, 이스티오 트래픽 매니저 구현과 관련된 더 자세한 내용을 아키텍쳐 오버뷰에서 볼 수 있다. 이 가이드 나머지 부분에선 이스티오의 트래픽 매니지먼트 기능에 대해 설명한다.

Introducing Istio traffic management

사용자의 메시안에서 트래픽을 컨트롤하기위해 이스티오는 모든 사용자의 서비스들과 그 서비스들이 가지는 엔트포인트에 대해서 알아야 한다. 서비스 레지스트리에 정보를 넣기 위해 이스티오는 서비스 디스커버리 시스템에 접속한다. 예를들어 만약 사용자가 이스티오를 쿠버네티스 클러스터에 설치했다면 이스티오는 클러스터내의 엔드포인트와 서비스들을 자동으로 감지한다.

서비스 레지시트리를 사용해서 엔보이는 관련 서비스로 트래픽을 전달한다. 대부분의 마이크로서비스 기반 애플리케이션은 서비스 트래픽을 핸들링하거나 또는 로드벨런싱등을 위해 개별 워크로드의 멀티 인스턴스를 가진다. 엔보이 프록시는 기본적으로 최소 요청 모델을 사용해서 서비스의 로드밸런싱 풀에 트래픽을 분산한다. 풀에 투 호스트가 랜덤으로 선택되어 더 적은 액티브 요청을 가지는 호스트로 라우팅된다. in this way the most heavily loaded host will not receive requests until it is no more loaded than any other host.

이스티오의 기본 서비스 디스커버리와 로드벨런싱은 서비스 메시를 가능하게 하지만 이것이 다는 아니다. 대부분의 사용자는 메시의 트레픽을 더 세밀하게 제어하고 싶어 한다. 사용자는 새로운 버전의 A/B 테스팅을 위해 트래픽을 특정 퍼센테이지로 지정하거나 또는 전체 서비스 인스턴스 중 특정 인스턴스들의 트래픽에 대한 특별한 로드벨런싱 룰을 적용하거나 등을 원할 수 있다. 이스티오는 이런 기능들을 트래픽 매니지먼트 API에서 트래픽 설정을 통하여 제공한다.

다른 이스티오 설정과 같이, yaml로 설정하는 쿠버네티스 커스텀 리소스 정의(CRDs)로 지정할 수 있다.

이 가이드의 남은 부분은 아래 나열된 트래픽 매니지먼트 API 리소스들을 설명하고 어떻게 하는지 알아본다.

Virtual services
Destination rules
Gateways
Service entires
Sidecars

이 가이드는 API 리소스에 포함되어있는 또한 네트워크 탄력성과 테스팅 기능도 살펴본다.

Virtual services

버츄얼 서비스는 데스티네이션 룰과 함께 이스티오의 트래픽 라우팅 기능의 핵심이다. 버츄얼 서비스는 이스티오와 플랫폼에의해 제공되는 기본 연결 및 검색을 기반으로 리퀘스트를 이스티오 서비스 메시에 속해있는 서비스에 어떻게 라우트할지 설정할 수 있도록 제공한다. 개별 버츄얼 서비스는 우선순위를 가지는 여러 라우팅 룰들의 집합이고 이스티오는 가상 서비스로의 요청을 메시상의 실제 목적지와 매칭시킨다. 사용자의 메시에따라 여러개의 버츄얼 서비스가 필요할수도, 필요없을수도 있다.

Why use virtual services?

버츄얼 서비스는 이스티오의 트래픽 매니지먼트를 유연하고 강력하게 만들어주는 핵심 기능이다. 실제 구현된 목적지의 워크로드를 클라이언트가 전송하는 리퀘스트로부터 강력하게 디커플링한다. 또한 워크로드로 트래픽을 전송하기 위한 다양한 트래픽 라우팅 룰을 정의하는 다양한 방법을 제공한다.

왜 이것이 유용할까? 버츄얼 서비스가 없다면 엔보이는 최소 요청 방식 로드밸런싱 방식을 상요한 트래픽 분산을 모든 서비스 인스턴스를 대상으로 수행한다. You can improve this behavior with what you know about the workloads. 예를들어 일부 서비스 인스턴스는 다른 버전일 수 있다. 이럴 경우, A/B 테스팅 상황에서 다른 서비스 버전으로 가는 트래픽을 퍼센트 기반의 설정으로 라우팅을 조절하거나 또는 내부 유저들은 특정 인스턴스들에게 트래픽을 받을 수 있도록 할 수 있다.

버츄얼 서비스를 통해 트래픽을 받을 호스트들의 이름을 지정할 수 도 있다. 버츄얼 서비스에서 제공하고는 라우팅 룰을 사용해서 엔보이에게 버츄얼 서비스의 트래픽을 적절한 목적지에 전송하도록 설정할 수 있다. 라우팅 목적지는 전혀 다른 서비스이거나 또는 같은 서비스의 다른 버전이 될 수도 있다.

일반적인 유즈케이스는 서비스의 다른 버전들로 트래픽을 보내는 것이다. 만약 싱글 엔티티라고 가정하면 클라이언트는 버츄얼 서비스 호스트로 요청을 보내면 엔보이는 그 트래픽을 버츄얼 서비스 룰에 따라 다른 버전으로 보내는 방식이다. 예를들어 “트래픽의 20%는 신규 버전으로 보낸다” 또는 “특정 유저의 요청은 버전2의 서비스가 처리한다’ 등이다. 이러한 방식은 사용자가 점진적으로 퍼센트를 조절하여 신규 버전으로 트래픽을 가도록 하는 카나리 배포를 할 수있도록 해준다. 트래픽을 라우팅하는 것은 완벽하게 인스턴스를 배포하는것과 별개로 분리되어있다. 이것은 신규 버전 서비스 인스턴스의 숫자를 트래픽 라우팅 참조 없이 트래픽에 따라 스케일 업 또는 다운을 할 수 있게 해준다. 쿠버넷과 같은 컨테이너 오케스트레이션 플랫폼은 인스턴스 스케일링 기반으로 트래픽을 분배하는 방식만 지원하기 때문에 매우 복잡하다. 어떻게 버츄얼 서비스가 카나리 배포를 지원하는지에 대해 Canary Deployment using Istio 문서를 통해 더 자세히 알 수 있다.

또한 버츄얼 서비스는 이런 기능들을 제공한다

단일 버츄얼 서비스에서 여러 애플리케이션 서비스를 컨트롤할 수 있다. 예를들어 쿠버네티스에 메시를 구축할 경우, 하나의 버츄얼 서비스에서 네임스페이스를 설정하고 그 네임스페이스에 속한 모든 서비스를 핸들링할 수 있다. 여러 실제 서비스를 하나의 버츄얼 서비스에 매핑하는 것은 특히 서비스를 사용하는 고객이 아무것도 모르는 상태에서 모놀리틱 애플리케이션을 마이크로서비스 환경으로 변환하는데 유용하다. 라우팅 룰을 사용해서 monolith.com을 호출하던 요청이 microservice A를 호출하도록 정의할수 있다. 이렇나 정보는 one of our examples below에서 확인할 수 있다.
[gateway]에서 인그레스, 이그레스 트래픽을 조정하는 트래픽 룰을 설정할 수 있다.

몇몇 경우에 이러한 기능들을 이용하기 위해서 데스티네이션 룰에 서비스의 서브셋들을 정의할 필요가 있다. 개별 오프젝트에 서비스 서브셋을 정의하고 대상별 정책을 정의하는것은 사용자가 버츄얼 서비스간에 이러한 정의들을 깔끔하게 재사용할 수 있게 해준다. 다음 섹션에서 데스테이션 룰을 사용하는 방법을 알아본다.

Viertual service example

아래는 버츄얼 서비스로 특정 유저가 보내는 요청을 각기 다른 버전으로 전송시키는 버츄얼 서비스 정의이다.

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 필드에서 버츄얼 서비스의 호스트들을 정의할 수 있다. 즉 사용자가 라우팅 룰을 적용할 수 있는 목적지이다. 여기 나열된 주소들은 클라이언트의 서비스 요청 대상이다.

hosts:
- reviews

버츄얼 서비스의 호스트 이름엔 아이피, DNS name, or, depending on the platform, a short name (such as a Kubernetes service short name) that resolves, implicitly or explicitly, to a fully qualified domain name (FQDN). 또한 와일드 카드(“*”) 프리픽스를 사용해서 사용자가 하나의 라우팅 룰 셋으로 모든 매칭되는 서비스르 컨트롤할 수 있다. 버츄얼 서비스 호스트는 실제 이스티오의 서비스 레지스트리는 아니며 간단한 가상 목적지이다. 이것은 사용자가 메시상의 라우팅 엔트리가 없는 가상 호스트의 트래픽을 모델링할 수 있다.

Routing roles

http 섹션은 버츄얼 서비스의 라우팅 룰을 정의한다. 라우팅 룰에선 조건에 만족하는지, HTTP/1.1 또는 HTTP2 인지, 호스트 필드에 나열된 목적지로 gRPC 트래픽을 보내는지 등을 설정할 수 있다. 또한 tcp, tls 섹션에선 TCP 및 unterminated TLS 트래픽을 설정할 수 있다. 라우팅 룰은 유즈케이스에 따라 조건을 사용해 어느 곳에 얼마나 트래픽을 전송하거나, 전송할지 설정하는 구성들로 이루어져있다.

Match condition

아래 예제의 첫번째 라우팅 룰은 match 필드로 조건을 정의한느 것으로 시작한다. 이 경우 모든 “jason” 유저의 모든 요청에 라우팅 룰이 적용되길 원하기 때문에 headers, end-user, exact 필드를 사용해서 적절한 요청을 선택한다.

Destination

라우트 섹션에서 destination 필드는 이 조건에 해댕하는 트래픽의 실제 목적지를 정의한다. 버츄얼 서비스의 host와는 다르게 이 목적지의 호스트는 이스티오의 서비스 레지스트리상에 존재하는 실제 목적지이여야하며 그렇지 않으면 엔보이는 트래픽을 어디로 보낼 지 알 수 없게 된다. 이러한 방식은 메시 서비스가 메시 서비스상에 ㅇ벗는 서비스 엔트리를 프록시할 수 있도록 해준다. 이 경우 쿠버네티스에서 사용하는 쿠버네티스 서비스 이름을 사용했다.

route:
- destination:
    host: reviews
    subset: v2

이 페이지의 예제에선 목적지 호스트의 이름으로 쿠버네티스의 short name을 사용했다. 룰이 평가될 때 이스티오는 호스트의 fully qualified name을 얻기 위한 라우팅 룰를 포함하고 있는 버츄얼 서비스의 네임스페이스를 기반으로 한 도메인 suffix를 추가한다. 사용자는 원하는 네임스페이스에 이 예제를 복사해서 사용해볼 수 있다.

short name을 사용하는 것은 목적지 호스트와 버츄얼 서비스가 실제 같은 쿠버네티스 네임스페이스에 있을 떄 유효하게 동작한다. 쿠버네티스의 short name은 misconfiguration이 될 수 있기 떄문에 실제 프로덕션에선 fully qualified host name을 사용하는 것을 추천한다.

destication 섹션에선 이 예제엇 v2 라는 이름을 사용한 것 처럼 사용자의 요청 조건을 매칭시킬 수 있는 쿠버네티스 서비스 서브셋을 지정할수도 있다. 이러한 서비스 서브셋을 정의하는 방식을 destinatio nrules에서 확인할 수 있다.

Routing rule precedence

라우팅룰은 위에서 아래로 순차적으로 평가된다. 버츄얼 서비스의 가장 첫 번째 룰은 가장 높은 우선순위를 가진다. In this case you want anything that doesn’t match the first routing rule to go to a default destination, specified in the second rule. Because of this, the second rule has no match conditions and just directs traffic to the v3 subset.

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

적어도 하나의 매칭되는 경로를 항상 가져서 트래픽을 보장할 수 있도록 버츄얼 서비스의 마지막 규칙을 “no condition” 또는 가중치 기반 룰을 사용하는 것을 추천한다.

More about routing rules

위에서 기술하였듯이, 라우팅룰은 특정 트래픽 셋을 특정 목적지로 라우팅하기 위한 강력한 도구이다. 포트, 헤더 필드, 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

매칭 조건으론 동일 조건, prefix, regex 등의 조건들도 사용할 수 있다.

조건들을 AND 연산 하기 위해 같은 match 블록에 여러 조건들을 추가하거나 또는 같은 룰 안에 여러 match 블록을 넣어 OR 조건을 만들 수 있다. 또한 특정 가상 서비스에 여러 라우팅 룰을 추가할수도 있다. 이 것은 하나의 버츄얼 서비스에서 간단하거나 또는 복잡한 조건들을 설정할 수 있도록 만들어준다. 조건 필드와 가능한 값에 대한 내용은 HttpMatchRequest레퍼런스에서 찾을 수 있다.

조건을 사용할 때 트래픽을 가중치 기반으로 분배할 수 있다. 이것은 A/B 텟흐팅, 카나리 배포 등에 배우 유용하다.

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

또한 라우팅 룰에서 트래픽을 조작할수 있다. 예를들어

헤더를 추가하거나 삭제
URL Rewrite
목적지 호출에 대한 retry policy 설정

추가 정보는 HttpRoute reference에서 확인할 수 있다.

Destination rules

버츄얼 서비스와 함께, 데스티네이션 룰은 이스티오의 트래픽 라우팅 기능 중 핵심 기능이다. 목적지로 트래픽을 라우팅하기 위한 설정을 버츄얼 서비스에서 했따면 라우팅 룰은 목적지의 트래픽에 일어나는 현상에 대해 설정한다. 데스티네이션 룰은 버츄얼 서비스에서 라우팅 룰이 평가되고 난 이후, 실제 목적지에 적용된다.

데스티네이션 룰에선 이름이 있는 서비스들의 서브셋을 정의한다. 예를들어 버전별 서비스 인스턴스를 그룹화할 수 있다. 그리고 버츄얼 서비스에서 여러 서비스들의 서브셋을 사용하여 서비스 인스턴스들에 대한 다른 드래픽을 컨트롤할 수 있다.

또한 TLS security mode, circuit breaker 설정, 로드밸런싱 모델 과같은, 특정 서비스 서브셋 또는 전체 목적지 서비스가 호출될 때 엔보이의 트래픽 정책을 수정할 수 있다. Destination Rule reference에서 데스테이션 룰 옵션에 대한 세부 사항을 확인할 수 있다.

Load balancing options

이스티오는 기본 로드밸런싱 정책으로 최소 요청 방식을 적용해 요청을 가장 적게 받은 인스턴스가 요청을 받도록 한다. 아래의 모델을 추가로 지원하며, 특정 서비스 또는 서비스 서브셋으로의 요청을 위한 데스티네이션 룰에서 이를 설정할 수 있다.

Random : 풀에 있는 인스턴스들에게 랜덤하게 요청을 포워딩한다.
Weighted : 특정 퍼센트에 따라 풀에 있는 인스턴스들에게 요청을 포워딩한다.
rount robin : 각각의 인스턴스들을 순찾거으로 포워딩한다.

각각의 옵션에 대한 정보는 Envoy load balancing documentation에서 확인할 수 있다.

Destination rule example

아래 예제는 각기 다른 로드밸런싱 정책을 가지는 my-svc 목적지 서비스를 위한 3개의 다른 서브셋 설정 데스티네이션 룰이다.

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를 기반으로 정의되며 이는 쿠버네티스에서 팟과 같은 오브젝트들에게 붙이는 key/value 쌍이다. 이 라벨들은 다양한 버전을 구분하기 위해 쿠버네티스 서비스의 deployment의 메타데이터로써 적용된다.

이 데스티네이션 룰은 서브셋을 정의했을 뿐만아니라 목적지를 위한 모든 서브셋에 대한 기본 트래픽 정책과 하위 집합에서 재정의하는 특정 서브셋을 위한 정책이 설정되어 있다. subsets 필드에서 보다시피 기본 정책인 랜덤 로드밸런싱 정책이 v1, v3 서브셋에 정의된다. v2 정책에서, 라운드 로빈 로드밸런서가 설정되었다.

Gateways

메시의 인바운드, 아웃바운드 트래픽을 관리하기 위해 게이트웨이를 사용할 수 있다. 이는 메시의 들어오고 나가는 트래픽을 정의한다. 게이트웨이 설정은 메시의 엣지에서 동작하는 독립형 엔보이 프록시들에 적용된다. 서비스 워크로드와 같이 실행되는 엔포이 사이드카 엔보이 프록시가 아니다.

쿠버네티스 인그레서 API와 같은 다른 진입 트래픽 컨트롤 시스템의 메커니즘과는 달리 이스티오의 게이트웨이는 이스티오의 트래픽 라우팅을 위한 강력하고 유연한 기능들을 사용할 수 있다. 노출 포트 설정, TLS 설정 과 같은 4-6 레이어 로드밸런싱 설정이 가능하기 때문이 이를 할 수 있다. 애플리케이션 계층의 트래픽 라우팅(L7)을 동일한 API 리소스에 추가하는 대신, 이스티오 버츄얼 서비스의 게이트웨이에 바인딩하면 기본적으로 게이트웨이 트래픽을 다른 데이터 플레인 트래픽 처럼 관리할 수 있다.

게이트웨이는 주로 인그레스 트래픽을 관리하기 위해 사용하지만, 이그레스 게이트웨이도 물론 가능하다. 이그리스 게이트웨이는 메시에서 나가는 트래픽의 출구 노드를 지정하고, 서비스가 사용할 수 있거나 또는 사용해야하는 외부 네트워크 엑세스를 제한할 수 있다. 또한 이그레스 트래픽 보안 설정을 활성화해서 메시에 보안 기능을 추가할 수 있다. 예를들어 내부 프록시를 구성할 수 있다.

이스티오는 미리 설정되어있는 게이트웨이 프록시 deployments(istio-ingressgateway, istio-egressgateway)를 사용할 수 있도록 제공하며 demo installation에서 제공하며 default profile에선 인그레스 게이트웨이가 설정되어있는 것을 볼 수 있다. 이러한 deployment를 게이트웨이에 적용하고 프록시를 설정, 배포해볼 수 있다.

Gateway example

아리 예제는 외부 HTTPS 인그레스 트래픽에 대한 게이트웨이 설정 예제이다.

apiVersion: 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 필드에서 할 수 있다.

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

이제 버츄얼 서비스가 외부 트래픽에 대한 라우팅 룰을 설정할 수 있게 되었다.

Service entires

이스티오에서 내부적으로 관리하는 서비스 레지스리에 엔트리를 추가하기 위해선 service entiry를 사용하면 된다. 서비스 엔트리를 추가하면 엔보이 프록시들은 트래픽을 마치 메시상의 서비스인 것 처럼 트래픽을 보낼 수 있다.서비스 엔트리를 설정하면 메시 외부에서 동작하는 서비스의 트래픽도 관리할 수 있게되며 다음 기능들을 포함한다.

web상의 api를 호출하거나 레거시 인프라 서비스들에게 트래픽을 전송하는 것 처럼 외부 목적지의 트래픽을 리다이렉트하거나 포워딩할 수 있다.
외부 목적지에대한 retry, timeout, fault injection 정책을 정의할 수 있다.
VM을 메시에 추가함으로써 메시 서비스를 VM에서 운용할 수 있다.

모든 외부 서비스를 서비스 엔트리에 추가할 필요 없이, 메시 서비스로써 사용할 외부 서비스들만 서비스 엔트리에 추가하면 된다. 기본적으로 이스티오는 엔보이 프록시가 알 수 없는 서비스에 대한 요청은 통과하도록 한다. 이렇게 등록하지 않을 경우 이스티오에서 제공하는 목적지 트래픽 컨트롤 기능은 사용할 수 없다.

Service entry example

아래 예제는 ext-svc.example.com 외부 디펜던시를 이스티오의 서비스 레지스트리에 추가하는 예제이다.

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: svc-entry
spec:
  hosts:
  - ext-svc.example.com
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  location: MESH_EXTERNAL
  resolution: DNS

hosts 필드를 사용해서 외부 리소스를 정의할 수 있으며 완전한 주소 또는 와일드카드 prefix를 사용한 도메인 이름을 사용할 수 있다.

메시의 다른 서비스에 대한 트래픽을 설정하는 것과 같은 방식으로, 보다 더 세부적인 방법으로 서비스 엔트리로 들어오는 트래픽을 정교하게 컨트롤하기위한 버츄얼 서비스, 데스티네이션 룰을 설정할 수 있다. 예를들어 아래 데스티네이션 룰은 서비스 엔트리에 선언한 외부 서비스인 ext-svc.example.com로 요청하는 것에 대한 TCP 커넥션 타임아웃을 조정하는 설정이다.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ext-res-dr
spec:
  host: ext-svc.example.com
  trafficPolicy:
    connectionPool:
      tcp:
        connectTimeout: 1s

더 자세한 설정은 Service Entiry reference에서 볼 수 있다.

Sidecars

관련된 워크로드에 대한 모든 포트를 허용하거나 또는 메시에 도달하는 모든 워크로드 트래픽을 전달하는 등 이런 기능들을 설정하기 위해 이스티오는 엔보이 프록시를 설정한다. sidecar 설정에서 아래 항목들을 할 수 있다.

엔보이 프록시가 허용할 프로토콜, 포트 셋을 정밀하게 제어
엔보이 프록시가 연결할 수 있는 서비스들을 제한

You might want to limit sidecar reachability like this in larger applications, where having every proxy configured to reach every other service in the mesh can potentially affect mesh performance due to high memory usage.

특정 네임스페이스의 모든 워크로드 또는 workloadSelector를 사용해서 특정 워크로드에 적용하기 위한 사이드카 설정을 정의할 수 있다. 예를들어 아래 사이드카 설정은 같은 이스티오 컨트롤 플레인과 같은 네임스페이스상에서 구동중인 서비스에 도달하는 모든 bookinfo 네임스페이스 상의 서비스들에 대한 사이드카 설정이다.

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: default
  namespace: bookinfo
spec:
  egress:
  - hosts:
    - "./*"
    - "istio-system/*"

더 자세한 것은 Sidecar reference를 참고해라

Network resilience and testing

이스티오는 메시상에서 드래픽을 조정하는 것 뿐만 아니라 런타임에도 유동적으로 설정이 간으한