사절. 1. 소개

인사말! 이것은 "특사는 무엇입니까?", "왜 필요한가요?"라는 질문에 답하는 짧은 기사입니다. 그리고 "어디부터 시작해야 할까요?"

이게 뭐지?

Envoy는 고성능과 가용성에 초점을 맞춘 C++로 작성된 L4-L7 밸런서입니다. 한편으로 이것은 어떤 면에서 nginx 및 haproxy와 유사하며 성능면에서 비슷합니다. 반면에 마이크로서비스 아키텍처에 더 중점을 두고 있으며 zuul 또는 traefik과 같은 Java 및 Go 밸런서보다 나쁘지 않은 기능을 갖추고 있습니다.

haproxy/nginx/envoy의 비교표는 절대적인 진실이라고 주장하지 않지만 일반적인 그림을 제공합니다.

Nginx에
힙합
사절
Traefik

github의 별
11.2k/미러
1.1k/미러
12.4k
27.6k

쓰여진
C
C
C + +
go

API
아니
소켓 전용/푸시
데이터플레인/풀
당겨

활성 상태 확인
아니
예
예
예

오픈 트레이싱
외부 플러그인
아니
예
예

JWT
외부 플러그인
아니
예
아니

신장
루아/C
루아/C
루아/C++
아니

무엇을 위해

이 프로젝트는 초기 단계이기 때문에 누락된 부분이 많으며 일부는 초기 알파 버전입니다. 하지만 사절역시 젊기 때문에 빠르게 발전하고 있으며 이미 동적 구성, 기성 필터, 자신만의 필터를 작성하기 위한 간단한 인터페이스 등 많은 흥미로운 기능을 갖추고 있습니다.
적용 분야는 다음과 같지만 먼저 2가지 안티패턴이 있습니다.

• 정적 반동.

사실은 현재 이 순간에도 사절 캐싱 지원이 없습니다. 구글 사람들이 이것을 시도하고 있습니다 고치기. 이 아이디어는 내년에 한 번 구현될 예정입니다. 사절 RFC 준수의 모든 미묘함(동물원 헤더)과 특정 구현을 위한 인터페이스를 만듭니다. 하지만 지금은 알파도 아니고 아키텍처에 대한 논의가 진행 중입니다. PR open (PR 기사를 쓰는 동안 PR이 멈췄지만 이 점은 여전히 ​​관련이 있습니다).

지금은 정적용으로 nginx를 사용하세요.

• 정적 구성.

사용하셔도 되지만 사절 그런 목적으로 만들어진 것이 아닙니다. 정적 구성의 기능은 노출되지 않습니다. 많은 순간이 있습니다:

yaml에서 구성을 편집할 때 개발자가 장황하다고 꾸짖고 nginx/haproxy 구성이 덜 구조적이지만 더 간결하다고 생각하게 됩니다. 그게 요점입니다. Nginx와 Haproxy의 구성은 직접 편집할 수 있도록 생성되었으며, 사절 코드에서 생성을 위해. 전체 구성은 다음에 설명되어 있습니다. 프로토 버프, proto 파일에서 생성하는 것은 실수하기가 훨씬 더 어렵습니다.

Canary, b/g 배포 시나리오 등은 일반적으로 동적 구성에서만 구현됩니다. 나는 이것이 정적으로 이루어질 수 없다고 말하는 것이 아닙니다. 우리 모두는 그것을 합니다. 하지만 이를 위해서는 밸런서에서 목발을 착용해야 합니다. 사절 포함

Envoy가 꼭 필요한 작업:

• 복잡하고 역동적인 시스템의 트래픽 밸런싱. 여기에는 서비스 메시가 포함되지만 반드시 유일한 것은 아닙니다.
• 분산 추적 기능, 복잡한 인증 또는 다음에서 사용할 수 있는 기타 기능에 대한 필요성 사절 즉시 사용 가능하거나 편리하게 구현되지만 nginx/haproxy에서는 lua 및 모호한 플러그인으로 둘러싸여 있어야 합니다.

필요한 경우 둘 다 고성능을 제공합니다.

이거 어떻게 작동 시켜요

Envoy는 Docker 이미지로만 바이너리로 배포됩니다. 이미지에는 이미 정적 구성의 예가 포함되어 있습니다. 그러나 우리는 구조를 이해하기 위해서만 관심이 있습니다.

envoy.yaml 정적 구성

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  host_rewrite: www.google.com
                  cluster: service_google
          http_filters:
          - name: envoy.router
  clusters:
  - name: service_google
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    # Comment out the following line to test on v6 networks
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: service_google
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: www.google.com
                port_value: 443
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.api.v2.auth.UpstreamTlsContext
        sni: www.google.com

동적 구성

우리는 어떤 문제에 대한 해결책을 찾고 있나요? 로드된 상태에서 로드 밸런서 구성을 다시 로드할 수는 없으며 "작은" 문제가 발생합니다.

• 구성 검증.

구성은 클 수도 있고 매우 클 수도 있습니다. 한 번에 모두 과부하하면 어딘가에서 오류가 발생할 가능성이 높아집니다.

• 오래 지속되는 연결.

새 리스너를 초기화할 때 이전 리스너에서 실행 중인 연결을 관리해야 합니다. 변경이 자주 발생하고 연결이 오래 지속되는 경우 타협점을 찾아야 합니다. 안녕하세요, nginx의 kubernetes 수신입니다.

• 활성 상태 확인.

활성 상태 확인이 있는 경우 트래픽을 보내기 전에 새 구성에서 이를 모두 다시 확인해야 합니다. 업스트림이 많으면 시간이 걸립니다. 안녕하세요 하프록시입니다.

이 문제는 어떻게 해결됩니까? 사절풀 모델에 따라 구성을 동적으로 로드함으로써 별도의 부분으로 나누고 변경되지 않은 부분을 다시 초기화하지 않을 수 있습니다. 예를 들어, 다시 초기화하는 데 비용이 많이 들고 거의 변경되지 않는 리스너가 있습니다.

구성 사절 (위 파일에서) 다음과 같은 엔터티가 있습니다.

• 경청자 — 특정 IP/포트에 리스너가 걸려 있습니다.
• 가상 호스트 - 도메인 이름별 가상 호스트
• 길 - 균형 규칙
• 클러스터 — 균형 매개변수가 있는 업스트림 그룹
• 엔드 포인트 — 업스트림 인스턴스 주소

이러한 각 엔터티와 다른 엔터티는 동적으로 채워질 수 있습니다. 이를 위해 구성은 구성이 수신될 서비스의 주소를 지정합니다. 서비스는 REST 또는 gRPC일 수 있으며, gRPC가 바람직합니다.

서비스 이름은 각각 LDS, VHDS, RDS, CDS 및 EDS로 지정됩니다. 동적 리소스를 정적 ​​리소스에 지정할 수 없다는 제한 사항을 제외하고 정적 구성과 동적 구성을 결합할 수 있습니다.

대부분의 작업에서는 마지막 세 가지 서비스를 구현하는 것으로 충분합니다. 이를 ADS(Aggregated Discovery Service)라고 합니다. 자바 소스의 개체만 채우면 되는 gRPC 데이터플레인의 기성 구현이 있습니다.

구성은 다음 형식을 취합니다.

envoy.yaml 동적 구성

dynamic_resources:
  ads_config:
    api_type: GRPC
    grpc_services:
      envoy_grpc:
        cluster_name: xds_clr
  cds_config:
    ads: {}
static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
          stat_prefix: ingress_http
          rds:
            route_config_name: local_route
            config_source:
              ads: {}
          http_filters:
          - name: envoy.router
  clusters:
  - name: xds_clr
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: xds_clr
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: xds
                port_value: 6565

시작할 때 사절 이 구성을 사용하면 제어 평면에 연결하고 RDS, CDS 및 EDS 구성을 요청하려고 시도합니다. 상호 작용 프로세스가 어떻게 발생하는지 설명됩니다. 여기에.

즉, 사절 요청되는 리소스 유형, 노드의 버전 및 매개변수를 나타내는 요청을 보냅니다. 이에 대한 응답으로 리소스와 버전을 수신하며, 제어 평면의 버전이 변경되지 않은 경우 응답하지 않습니다.
4가지 상호작용 옵션이 있습니다:

• 모든 유형의 리소스에 대한 하나의 gRPC 스트림, 리소스의 전체 상태가 전송됩니다.
• 별도의 스트림, 완전한 상태.
• 하나의 스트림, 증분 상태.
• 별도의 스트림, 증분 상태.

증분 xDS를 사용하면 제어 영역과 제어 영역 간의 트래픽을 줄일 수 있습니다. 사절, 이는 대규모 구성과 관련이 있습니다. 그러나 요청에는 구독 취소 및 구독을 위한 리소스 목록이 포함되어 있어 상호 작용이 복잡해집니다.

우리의 예에서는 RDS, CDS, EDS 및 비증분 모드에 대한 하나의 스트림인 ADS를 사용합니다. 증분 모드를 활성화하려면 다음을 지정해야 합니다. api_type: DELTA_GRPC

요청에 노드 매개변수가 포함되어 있으므로 다양한 인스턴스에 대해 다양한 리소스를 제어 플레인으로 보낼 수 있습니다. 사절, 이는 서비스 메시 구축에 편리합니다.

워밍업

에 사절 시작 시 또는 제어 영역에서 새 구성을 수신할 때 리소스 준비 프로세스가 시작됩니다. 리스너 워밍업과 클러스터 워밍업으로 구분됩니다. 첫 번째는 RDS/LDS에 변경이 있을 때 시작되고, 두 번째는 CDS/EDS가 있을 때 시작됩니다. 이는 업스트림만 변경되면 리스너가 다시 생성되지 않음을 의미합니다.

워밍업 프로세스 중에 제한 시간 동안 제어 영역에서 종속 리소스가 예상됩니다. 시간 초과가 발생하면 초기화가 실패하고 새 리스너가 포트에서 수신 대기를 시작하지 않습니다.
초기화 순서: EDS, CDS, 활성 상태 확인, RDS, LDS. 활성 상태 확인이 활성화되면 상태 확인이 한 번 성공한 후에만 트래픽이 업스트림으로 이동합니다.

리스너가 다시 생성된 경우 이전 리스너는 DRAIN 상태가 되고 모든 연결이 닫히거나 제한 시간이 만료된 후 삭제됩니다. --drain-time-s, 기본값은 10분입니다.

계속 될거야.

출처 : habr.com