3장 Istio’s data plane: Envoy Proxy

김진원·2025년 4월 19일

envoy

Istio

목록 보기

3/16

CloudNet@에서 진행하는 Istio Study 2주차 3장 내용입니다.

📕 이번 Chapter에서 다루는 내용

Istio의 Envoy 동작 이해

Envoy 기능 알아보기

Envoy 정적 설정

Envoy Admin API로 분석 및 디버깅

3.1 What is the Envoy proxy?

Envoy란?

Envoy는 분산 시스템에서 애플리케이션 네트워킹 문제를 해결하기 위해 lyft에서 개발했습니다.
2017년 9월에 CNCF에 합류했고, C++로 작성되어 성능과 안정적인 목표이기 때문입니다.

다음은 Envoy의 2가지 중요한 원칙입니다.

애플리케이션에게 네트워크는 투명해야 한다. 네트워크 및 애플리케이션 문제가 발생할 때는 문제의 원인을 파악하기 쉬워야 한다.
The network should be transparent to applications. When network and application problems do occur it should be easy to determine the source of the problem. - Envoy announcement

Envoy는 Proxy이므로, Proxy를 먼저 알아야 합니다.
아래 그림은 Client와 Server 사이에 위치하는 중개 구성 요소이다.

또한, 아래 그림처럼 여러 서비스에 대한 로그 밸런싱을 처리하여, 문제가 있는 백엔드 서비스를 우회하게 라우팅하거나 보호할 수 있다.

Envoy는 기본적으로 HTTP 1.1, HTTP 2, gRPC 등을 이해할 수 있고, 요청 수준 타임아웃, 재시도, 재시도별 타임아웃, 서킷 브레이커와 기타 복원력 동작을 추가할 수 있다.

기본 프로토콜 외에도 MongoDB, DynamoDB, AMQP 같은 비동기 프로토콜용 필터도 작성돼 왔다.

애플리케이션 트래픽이 Envoy를 통과하여 Telemetry도 수집이 가능하여, 특정 서비스의 처리량과 오류율도 확인할 수 있다.

Envoy는 애플리케이션의 외부에서 동작하므로, 개발자가 네트워크 문제를 고려하지 않아도 되도록 설계되었습니다.

3.1.1 Envoy's core features

Envoy concepts as a high level

Listeners

애플리케이션이 연결할 수 있는 외부 세계로 포트를 노출한다.
Port 번호 80에 대한 리스터는 트래픽을 받고, 설정된 동작을 해당 트래픽에 적용한다.

Routes

리스너로 들어오는 트래픽을 처리하는 라우팅 규
요청이 /catalog 에 일치하면 그 트래픽을 catalog 클러스터로 보내는 식이다.

Cluster

엔보이가 트래픽을 라우팅할 수 있는 특정 업스트림 서비스, 예를 들어 catalog-v1 과 catalog-v2 는 별도 클러스터일 수 있고,
루트는 catalog 서비스의 v1이나 v2로 트래픽을 보내는 방법에 대한 규칙을 지정할 수 있다.

Envoy가 L7 트래픽에 수행하는 작업을 개념적으로 설명한 것이다.

트래픽은 Downstream에서 Listener로 들어오며, Cluster 중 하나로 Routing, Cluster는 Upstream으로 보내는 역할이다.

아래는 Envoy가 제공하는 기능들이다.

1. Service Discovery

런타임별로 전용 라이브러리를 사용할 필요 없이, 엔보이는 서비스 디스커버를 자동으로 수행할 수 있다.
Envoy가 디스커버리 API에서 서비스 엔드포인트를 찾도록 설정하기만 하면, 애플리케이션은 서비스 엔드포인트를 찾는 방법을 몰라도 된다.
디스커버리 API는 다른 일반적인 서비스 디스커버리 API(like HashiCorp Consul, Apache ZooKeeper, Netflix Eureka, and so on)를 래핑하는 데 사용할 수 있는 단순한 REST API 이다.

2. Load Balancing

Envoy의 로드 밸런싱 알고리즘에서 흥미로운 기능 중 하나는 지역 인식 locality-aware 로드 밸런싱이다.
다음 로드 밸런싱 알고리듬들을 기본적으로 제공
Random
(Weighted) Round robin
Weighted, least request
Consistent hashing (sticky) : Ring hash, Maglev

3. Traffic and Request Routing

Envoy는 HTTP 1.1과 HTTP 2 같은 애플리케이션 프로토콜을 이해할 수 있으므로 정교한 라우팅 규칙을 사용해 트래픽을 특정 백엔드 클러스터로 보낼 수 있다.
가상 호스트 매핑과 콘텍스트 경로 context-path 라우팅 같은 기본적인 리버스 프록시 라우팅을 처리할 수 있고, 또한 헤더 및 우선순위 기반 라우팅, 라우팅 재시도 및 타임아웃, 오류 주입까지도 수행할 수 있다.

4. Traffic Shifting and Shadowing Capabilites

비율 기반(즉, 가중치 적용) 트래픽 분할 splitting / 전환 shifting 을 지원한다.
이 기능을 활용해 애자일 팀은 카나리 릴리스와 같이 위험을 완화하는 CD 기술을 사용할 수 있다.
트래픽의 사본을 만들어 ‘보내고 망각하는 fire and forget’ 방식으로 트래픽을 엔보이 클러스터에 섀도잉 shadowing 할 수 있다.
이 섀도잉 기능을 트래픽 분할과 같은 것으로 생각할 수 있지만, 업스트림 클러스터가 보는 요청은 라이브 트래픽의 복사본이다.
따라서 라이브 운영 환경 트래픽에 영향을 주지 않고 섀도잉한 트래픽을 서비스의 새 버전으로 라우팅할 수 있다.

5. Network Resilience

특정 종류의 복원력 문제를 맡길 수는 있지만, 그 파라미터를 설정하고 잘 조정하는 것은 애플리케이션의 책임이라는 점을 유의해야 한다.
요청 타임아웃과 요청 수준 재시도(재시도별 타임아웃 포함)을 자동으로 수행할 수 있다.
이런 재시도 동작은 네트워크 불안정이 간간히 요청에 영향을 줄 때 매우 유용한다.
반면에 재시도 증폭은 연쇄 장애로 이어질 수 있어 엔보이에서는 재시도 동작을 제한할 수 있다.
또한 애플리케이션 수준 재시도는 여전히 필요할 수 있으며 엔보이가 완전히 대체할 수 없다.

6. HTTP/2 and gRPC

HTTP/2 는 단일 커넥션에서 여러 요청을 처리하고 서버 푸시, 스트리밍, 요청 백프레셔 backpressure 를 지원하도록 HTTP 프로토콜을 크게 개선한 버전이다.
Envoy는 처음부터 HTTP/1.1 과 HTTP/2 프록시로 개발돼 다운스트림과 업스트림 모두에게 각 프로토콜을 프록시할 수 있다.

7. Observability with Metrics Collection

Envoy는 서버에 호출하는 다운스트림 시스템, 서버 그 자체, 서버가 요청을 보내는 업스트림 클러스터에 대한 여러 측면(디멘션 dimentsion) 을 추척한다.
Envoy의 통계는 카운터, 게이지, 히스토그램으로 추적된다.

설정 가능한 어댑터와 형식을 사용해 통계를 내보내는데, 아래는 지원 목록이다.

StatsD
Datadog; DogStatsD
Hystrix formatting
Generic metrics service

8. Observability with Distributed Tracing

엔보이는 트레이스 스팬을 오픈트레이싱 OpenTracing 엔진에 보고해 호출 그래프 내 트래픽 흐름, 홉, 지연 시간을 시각화할 수 있다.
한편 필요한 집킨 헤더를 전파하는 것은 애플리케이션의 역할이며, 이는 가벼운 래퍼 wrapper 라이브러리로 수행할 수 있다.
엔보이는 서비스 간 호출을 연관시킬 목적으로 x-request-id 헤더를 생성하며, 트레이싱이 시작될 때 initial **x-b3*** 헤더를 만들 수도 있다.
애플리케이션이 전파해야 하는 헤더는 다음과 같다.
- x-b3-traceid
- x-b3-spanid
- x-b3-parentspanid
- x-b3-sampled
- x-b3-flags

9. Automatic TLS Termination and Origination

엔보이는 특정 서비스로 향하는 TLS 트래픽을 종료 terminate 시킬 수 있다. 클러스터의 에지와 서비스 메시 내부의 프록시 모두에서 가능하다.
더 흥미로운 기능은 애플리케이션 대신 엔보이가 업스트림 클러스터로 TLS 트래픽을 시작할 수도 있다는 것이다.
즉, 엔터프라이즈 개발자와 운영자가 언어별 설정과 키스토어 또는 트러스터 스토어를 만지작거리지 않아도 된다.
요청 경로에 엔보이가 있으면 TLS, 심지어 mTLS 까지도 자동으로 얻을 수 있다.

10. Rate Limiting

복원력이 중요한 측면은 보호받는 리소스로의 접근을 차단하거나 제한할 수 있는 기능이다.

11. Extending Envoy

Envoy의 핵심은 프로토콜(7계층) 코덱(필터 filter 라고 부름)을 구축할 수 있는 바이트 처리 엔진이다.

3.1.2 Comparing Envoy to other proxies

Envoy의 장점은 애플리케이션이나 서비스 프록시 역할을 한다는 데 있다.
Envoy가 다른 프록시에 비해 특히 뛰어난 영역은 아래와 같다.
- Extensibility with WebAssembly
- Open community
- Modular codebase built for maintenance and extension
- HTTP/2 support (upstream and downstream)
- Deep protocol metrics collection
- C++ / non-garbage-collected
- Dynamic configuration, no need for hot restarts

3.2 Configuring Envoy

JSON/YAML 형식 설정 파일로 구동된다.
설정 파일은 리스너, 루트, 클러스터뿐 아니라 Admin API 활성화 여부, 액세스 로그 저장 위치, 트레이싱 엔진 설정 등 서버별 설정도 지정한다.
최신 버전이고, Istio가 사용하는 v3를 사용합니다. 설정 API는 gRPC를 사용합니다.
API 호출 시 스트리밍 기능을 사용해 엔보이 프록시가 올바른 설정으로 수렴하는 데 걸리는 시간을 줄 일 수 있다. 프록시가 주기적으로 폴링하는 대신 서버가 업데이트를 엔보이에 푸시할 수 있어 API를 폴링할 필요가 없어진다.

3.2.1 Static configuration

Envoy의 설정 파일을 이용해 리스너, 라우팅 규칙, 클러스터를 지정할 수 있다.

static_resources:
  listeners: # (1) 리스너 정의
  - name: httpbin-demo
    address:
      socket_address: { address: 0.0.0.0, port_value: 15001 }
    filter_chains:
    - filters:
      - name:  envoy.filters.network.http_connection_manager # (2) HTTP 필터
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: ingress_http
          http_filters:
          - name: envoy.filters.http.router
          route_config: # (3) 라우팅 규칙
            name: httpbin_local_route
            virtual_hosts:
            - name: httpbin_local_service
              domains: ["*"] # (4) 와일드카드 가상 호스트
              routes:
              - match: { prefix: "/" }
                route:
                  auto_host_rewrite: true
                  cluster: httpbin_service # (5) 클러스터로 라우팅
  clusters:
    - name: httpbin_service # (6) 업스트림 클러스터
      connect_timeout: 5s
      type: LOGICAL_DNS
      dns_lookup_family: V4_ONLY
      lb_policy: ROUND_ROBIN
      load_assignment:
        cluster_name: httpbin
        endpoints:
        - lb_endpoints:
          - endpoint:
              address:
                socket_address:
                  address: httpbin
                  port_value: 8000

설정이 뜻하는 내용을 서술하자면,

15001 포트에 소켓을 열고 필터 체인을 붙이는 리스너 선언
필터는 Envoy의 http_connection_manager에 라우팅 지시문을 설정
라우팅 지시문은 와일드카드(*)로 모든 가상 호스트를 매칭하는 것으로, 모든 트래픽을 httpbin_service 클러스터로 라우팅
설정의 마지막 부분은 httpbin_service 클러스터에 커넥션 속성을 정의
업스트림 httpbin 서비스와 통신할 때 엔드포인트 서비스 디스커버리에 LOGICAL_DNS 를, 로드 밸런싱 알고리듬으로 ROUND_ROBIN 을 사용하도록 지정

Envoy는 다양한 설정을 xDS API로 동적으로 설정할 수 있다.

3.2.2 Dynamic Configuration

특정 API군을 사용해 다운타임이나 재시작 없이 설정을 실시간으로 업데이트할 수 있다.
올바른 디스커버리 서비스 API를 가리키는 간단한 부트스트랩 설정 파일만 있으면 나머지 설정은 동적으로 이뤄진다

아래는 동적 설정에 사용하는 API 목록이다.

Listener discovery service (LDS)
- 엔보이가 자신이 어떤 리스너를 노출해야 한느지 쿼리할 수 있게 하는 API
Route discovery service (RDS)
- 리스너 설정의 일부로, 사용할 루트를 지정한다. 정적 설정이나 동적 설정을 사용할 때 LDS의 부분집합이다.
Cluster discovery service (CDS)
- 엔보이가 클러스터 목록과 각 클러스터용 설정을 찾을 수 있는 API
Endpoint discovery service (EDS)
- 클러스터 설정의 일부로, 특정 클러스터에 어떤 엔드포인트를 사용해야 하는지 지정한다. CDS의 부분집합니다.
Secret discovery service (SDS)
- 인증서를 배부하는 데 사용하는 API
Aggregate discovery service (ADS)
- 나머지 API에 대한 모든 변경 사항을 직렬화된 스트림으로 제공한다. 이 API 하나로 모든 변경 사항을 순차적으로 가져올 수 있다.

이 API들을 통틀어 xDS 서비스라고 부른다.

한 가지 유념해야 할 점은 Envoy의 xDS API는 궁극적 일관성 eventual consistency 을 전제로 구축됐으며 궁극적으로는 올바른 구성으로 수렴한다는 것이다.
트래픽을 클러스터 foo로 라우팅하는 새 루트가 RDS로 업데이트됐는데, 이 클러스터 foo를 포함한 CDS 업데이트는 아직 수행되지 않았을 수 있다. 이 경우 CDS가 업데이트될 때까지 라우팅 오류가 발생할 수 있다.

https://blog.naver.com/alice_k106/222000680202 (원본 출처 EnvoyCon)

이런 순서에 따른 경쟁 상태 race condition 를 해결하기 위해 도입한 것이 ADS 이다. Istio는 프록시 설정 변경을 위해 ADS를 구현한다.

https://blog.naver.com/alice_k106/222000680202 (원본 출처 EnvoyCon)

아래 설정으로 리스너를 명시하지 않고, Envoy에게 LDS API를 통해 런타임에 올바른 리스너 설정 값을 찾으라 지시한다.
그렇지만 클러스터 하나는 명시적으로 설정하고 있는데, LDS API가 위치한 클러스터다.

dynamic_resources:
  lds_config: # Configuration for listeners (LDS) 리스너용 설정
    api_config_source:
      api_type: GRPC
      grpc_services:
        - envoy_grpc: # Go to this cluster for the listener API. 이 클러스터로 이동해 리스너 API를 확인하자
            cluster_name: xds_cluster

clusters: 
- name: xds_cluster # gRPC cluster that implements LDS. LDS를 구현하는 gRPC 클러스터
  connect_timeout: 0.25s
  type: STATIC
  lb_policy: ROUND_ROBIN
  http2_protocol_options: {}
  hosts: [{ socket_address: {
    address: 127.0.0.3, port_value: 5678 }}]

3.3 Envoy in action

간단한 httpbin 서비스를 통해 실습을 진행합니다.
필요한 Docker image를 다운 받습니다.

docker pull envoyproxy/envoy:v1.19.0
docker pull curlimages/curl
docker pull mccutchen/go-httpbin

실습 아키텍처

httpbin 서비스 실행

# mccutchen/go-httpbin 는 기본 8080 포트여서, 책 실습에 맞게 8000으로 변경
# docker run -d -e PORT=8000 --name httpbin mccutchen/go-httpbin -p 8000:8000
docker run -d -e PORT=8000 --name httpbin mccutchen/go-httpbin 
docker ps

# curl 컨테이너로 httpbin 호출 확인
docker run -it --rm --link httpbin curlimages/curl curl -X GET http://httpbin:8000/headers

# 결과
{
  "headers": {
    "Accept": [
      "*/*"
    ],
    "Host": [
      "localhost:8000"
    ],
    "User-Agent": [
      "curl/8.7.1"
    ]
  }
}

아래 설정은 15001포트로 리스너를 노출하고 트래픽을 클러스터 httpbin_service로 라우팅한다.

static_resources:
  listeners:
  - name: httpbin-demo
    address:
      socket_address: { address: 0.0.0.0, port_value: 15001 }
          stat_prefix: ingress_http
			...
              routes:
              - match: { prefix: "/" }
                route:
                  auto_host_rewrite: true
                  cluster: httpbin_service
  clusters:
    - name: httpbin_service
      connect_timeout: 5s
      type: LOGICAL_DNS
      dns_lookup_family: V4_ONLY
      lb_policy: ROUND_ROBIN
      load_assignment:
        cluster_name: httpbin
        endpoints:
        - lb_endpoints:
          - endpoint:
              address:
                socket_address:
                  address: httpbin
                  port_value: 8000

Proxy를 호출하면, 연결된 httpbin 서비스로 전송되고 새로운 헤더도 추가된다.

X-Envoy-Expected-Rq-Timeout-Ms
X-Request-Id

# 터미널2
docker run -it --rm --link proxy curlimages/curl curl -X GET http://proxy:15001/headers
{
  "headers": {
    "Accept": [
      "*/*"
    ],
    "Host": [
      "httpbin"
    ],
    "User-Agent": [
      "curl/8.13.0"
    ],
    "X-Envoy-Expected-Rq-Timeout-Ms": [
      "15000" # 15000ms = 15초
    ],
    "X-Forwarded-Proto": [
      "http"
    ],
    "X-Request-Id": [
      "8d08bd8e-7899-42e1-bf74-7a3381a2494a"
    ]
  }
}

두 번째 헤더인 X-Envoy-Expected-Rq-Timeout-Ms는 업스트림 서비스에 대한 힌트로, 요청이 15,000ms 후에 타임아웃될 것으로 기대한다는 의미다.

아래 정적 설정으로 15초를 1초로 변경할 수 있다.

              - **match**: { prefix: "/" }
                route:
                  auto_host_rewrite: true
                  cluster: httpbin_service
                  **timeout: 1s**

아래는 Envoy Admin API(TCP 15000) 를 통해 delay 설정합니다.

docker run -it --rm --link proxy curlimages/curl curl -X POST http://proxy:15000/logging
docker run -it --rm --link proxy curlimages/curl curl -X POST http://proxy:15000/logging?http=debug

docker run -it --rm --link proxy curlimages/curl curl -X GET http://proxy:15001/delay/0.5
docker run -it --rm --link proxy curlimages/curl curl -X GET http://proxy:15001/delay/1
docker run -it --rm --link proxy curlimages/curl curl -X GET http://proxy:15001/delay/2

3.3.1 Evnoy's Admin API

엔보이의 Admin API를 사용하면 프록시 동작에 대한 통찰력을 향상시킬 수 있고, 메트릭과 설정에 접근할 수 있다.

#
docker run --name proxy --link httpbin envoyproxy/envoy:v1.19.0 --config-yaml "$(cat ch3/simple_change_timeout.yaml)"

# admin API로 Envoy stat 확인 : 응답은 리스너, 클러스터, 서버에 대한 통계 및 메트릭
docker run -it --rm --link proxy curlimages/curl curl -X GET http://proxy:15000/stats

# retry 통계만 확인
docker run -it --rm --link proxy curlimages/curl curl -X GET http://proxy:15000/stats | grep retry
cluster.httpbin_service.circuit_breakers.default.rq_retry_open: 0
cluster.httpbin_service.circuit_breakers.high.rq_retry_open: 0
cluster.httpbin_service.retry_or_shadow_abandoned: 0
cluster.httpbin_service.upstream_rq_retry: 0
cluster.httpbin_service.upstream_rq_retry_backoff_exponential: 0
cluster.httpbin_service.upstream_rq_retry_backoff_ratelimited: 0
cluster.httpbin_service.upstream_rq_retry_limit_exceeded: 0
cluster.httpbin_service.upstream_rq_retry_overflow: 0
cluster.httpbin_service.upstream_rq_retry_success: 0
...

# 다른 엔드포인트 일부 목록들도 확인
docker run -it --rm --link proxy curlimages/curl curl -X GET http://proxy:15000/certs # 머신상의 인증서
docker run -it --rm --link proxy curlimages/curl curl -X GET http://proxy:15000/clusters # 엔보이에 설정한 클러스터
docker run -it --rm --link proxy curlimages/curl curl -X GET http://proxy:15000/config_dump # 엔보이 설정 덤프
docker run -it --rm --link proxy curlimages/curl curl -X GET http://proxy:15000/listeners # 엔보이에 설정한 리스너
docker run -it --rm --link proxy curlimages/curl curl -X POST http://proxy:15000/logging # 로깅 설정 확인 가능
docker run -it --rm --link proxy curlimages/curl curl -X POST http://proxy:15000/logging?http=debug # 로깅 설정 편집 가능
docker run -it --rm --link proxy curlimages/curl curl -X GET http://proxy:15000/stats # 엔보이 통계
docker run -it --rm --link proxy curlimages/curl curl -X GET http://proxy:15000/stats/prometheus # 엔보이 통계(프로메테우스 레코드 형식)

3.3.2 Envoy request retries

httpbin 요청을 일부러 실패시켜 엔보이가 어떻게 요청을 자동으로 재시작하는지 살펴보자.

먼저 retry_policy 를 사용하도록 설정 파일을 업데이트 한다.

              - match: { prefix: "/" }
                route:
                  auto_host_rewrite: true
                  cluster: httpbin_service
                  retry_policy:
                      retry_on: 5xx  # 5xx 일때 재시도
                      num_retries: 3 # 재시도 횟수

httpbin 호출 시에 HTTP 500 응답을 받으며, 결과를 보면 Envoy가 요청을 제시도하여 통계값이 3으로 표시된다.
(cluster.httpbin_service.upstream_rq_retry: 3)

docker run -p 15000:15000 --name proxy --link httpbin envoyproxy/envoy:v1.19.0 --config-yaml "$(cat ch3/simple_retry.yaml)"
docker run -it --rm --link proxy curlimages/curl curl -X POST http://proxy:15000/logging?http=debug

# /stats/500 경로로 프록시를 호출 : 이 경로로 httphbin 호출하면 오류가 발생
docker run -it --rm --link proxy curlimages/curl curl -X GET http://proxy:15001/status/500

# 호출이 끝났는데 아무런 응답도 보이지 않는다. 엔보이 Admin API에 확인
docker run -it --rm --link proxy curlimages/curl curl -X GET http://proxy:15000/stats | grep retry
...
cluster.httpbin_service.retry.upstream_rq_500: 3
cluster.httpbin_service.retry.upstream_rq_5xx: 3
cluster.httpbin_service.retry.upstream_rq_completed: 3
cluster.httpbin_service.retry_or_shadow_abandoned: 0
cluster.httpbin_service.upstream_rq_retry: 3
...

실습 종료

docker rm -f proxy && docker rm -f httpbin

3.4 How Envoy fits with Istio

Envoy는 Istio의 기능 대부분에서 핵심 역할 맡으며, Proxy로서 Service Mesh에 매우 적합하다.

보조 구성 요소의 필요성

1. 동적 설정 지원

Envoy의 기능 덕분에 정적 설정 파일이나 런타임에 리스너, 엔드포인트, 클러스터를 찾기 위한 xDS 디스커버리 서비스를 사용해 서비스 프록시를 설정할 수 있다는 사실을 확인했다.
Istio는 istiod 컨트롤 플레인 구성 요소에서 이 xDS API들을 구현한다.

아래 그림은 Istiod가 Kubernetes API를 사용해 VirtualService 등의 Istio 설정을 읽고 Proxy를 동적으로 설정하는 모습이다.

2. 메트릭, 텔레메트리 내보내기

Istio는 프로메테우스 같은 시계열 시스템과 통합하도록 데이트 플레인을 설정한다.
우리는 Envoy가 어떻게 분산 트레이싱 스팬을 오픈트레이싱 엔진에 보낼 수 있는지, Istio가 어떻게 스팬을 그 위치로 보낼 수 있는지도 봤다.

3. TLS 조정

마지막으로 Envoy는 메시 내의 서비스로 향하는 TLS 트래픽을 종료하고 시작할 수 있다.
그렇게 하려면 인증서를 생성, 서명, 로테이션하는 보조 인프라가 필요하다.
Istio는 이를 istiod 구성 요소를 통해 제공한다.

Result

Istio의 구성 요소와 엔보이 프록시는 강력한 서비스 메시를 구현하는 데 함께 기여한다.
이제부터 Envoy를 Istio Proxy라 부르며, 그 기능들을 Istio의 API를 통해 살펴볼 것이다.
그렇지만 실제로는 많은 것이 Envoy가 제공하고 구현하는 것임을 이해하자.

We'll call Envoy an Istio proxy

# Summary

Envoy는 애플리케이션이 애플리케이션 수준의 동작에 사용할 수 있는 프록시입니다.
Envoy는 이스티오의 데이터 플레인입니다.
Envoy는 클라우드 신뢰성 문제(네트워크 장애, 토폴로지 변경, 탄력성)를 일관되고 정확하게 해결하는 데 도움을 줄 수 있습니다.
Envoy는 런타임 제어를 위해 동적 API를 사용합니다(Istio는 이를 사용합니다).
Envoy는 애플리케이션 사용 및 프록시 내부에 대한 강력한 지표와 정보를 많이 노출합니다.

김진원

네

이전 포스트

2장 이스티오 첫 걸음

다음 포스트