Блог

Я новичок в «посланнике». Я боролся в течение недели с ошибкой ниже. Поэтому мой нисходящий поток(сервер, который запрашивает некоторые данные/обновление) получает ответ:

 Status code: 503  Headers: ... Server:"envoy" X-Envoy-Response-Code-Details:"upstream_reset_before_response_started{connection_failure}" X-Envoy-Response-Flags: "UF,URX"  Body: upstream connect error or disconnect/reset before headers. reset reason: connection failure  

С другой стороны, мой восходящий поток отключается(контекст отменяется). А вышестоящая служба вообще не возвращает 503 кода.

Вся сеть работает по протоколу http1.

Мой посланник.ямл:

 admin:  access_log_path: /tmp/admin_access.log  address:  socket_address: { address: 0.0.0.0, port_value: 9901 }   static_resources:  listeners:  - name: listener_0  address:  socket_address: { address: 0.0.0.0, port_value: 80 }  filter_chains:  - filters:  - name: envoy.filters.network.http_connection_manager  typed_config:  "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager  stat_prefix: ingress_http  codec_type: http1  route_config:  name: local_route  virtual_hosts:  - name: local_service  domains: [ "*" ]  response_headers_to_add: # added for debugging  - header:  key: x-envoy-response-code-details  value: "%RESPONSE_CODE_DETAILS%"  - header:  key: x-envoy-response-flags  value: "%RESPONSE_FLAGS%"  routes:  - match: # consistent routing  safe_regex:  google_re2: { }  regex: SOME_STRANGE_REGEX_FOR_CONSISTENT_ROUTING  route:  cluster: consistent_cluster  hash_policy:  header:  header_name: ":path"  regex_rewrite:  pattern:  google_re2: { }  regex: SOME_STRANGE_REGEX_FOR_CONSISTENT_ROUTING  substitution: "\1"  retry_policy: # attempt to avoid 503 errors by retries  retry_on: "connect-failure,refused-stream,unavailable,cancelled,resource-exhausted,retriable-status-codes"  retriable_status_codes: [ 503 ]  num_retries: 3  retriable_request_headers:  - name: ":method"  exact_match: "GET"   - match: { prefix: "/" } # default routing (all routes except consistent)  route:  cluster: default_cluster  retry_policy: # attempt to avoid 503 errors by retries  retry_on: "connect-failure,refused-stream,unavailable,cancelled,resource-exhausted,retriable-status-codes"  retriable_status_codes: [ 503 ]  retry_host_predicate:  - name: envoy.retry_host_predicates.previous_hosts  host_selection_retry_max_attempts: 3  http_filters:  - name: envoy.filters.http.router   clusters:  - name: consistent_cluster  connect_timeout: 0.05s  type: STRICT_DNS  dns_refresh_rate: 1s  dns_lookup_family: V4_ONLY  lb_policy: MAGLEV  health_checks:  - timeout: 1s  interval: 1s  unhealthy_threshold: 1  healthy_threshold: 1  http_health_check:  path: "/health"  load_assignment:  cluster_name: consistent_cluster  endpoints:  - lb_endpoints:  - endpoint:  address:  socket_address:  address: consistent-host  port_value: 80    - name: default_cluster  connect_timeout: 0.05s  type: STRICT_DNS  dns_refresh_rate: 1s  dns_lookup_family: V4_ONLY  lb_policy: ROUND_ROBIN  health_checks:  - timeout: 1s  interval: 1s  unhealthy_threshold: 1  healthy_threshold: 1  http_health_check:  path: "/health"  outlier_detection: # attempt to avoid 503 errors by ejecting unhealth pods  consecutive_gateway_failure: 1  load_assignment:  cluster_name: default_cluster  endpoints:  - lb_endpoints:  - endpoint:  address:  socket_address:  address: default-host  port_value: 80  

Я также попытался добавить журналы:

 access_log:  - name: accesslog  typed_config:  "@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog  path: /tmp/http_access.log  log_format:  text_format: "[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%" %RESPONSE_CODE% %CONNECTION_TERMINATION_DETAILS% %RESPONSE_FLAGS% %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%" "%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%"n"  filter:  status_code_filter:  comparison:  op: GE  value:  default_value: 500  runtime_key: access_log.access_error.status  

Это ничего мне не дало, потому %CONNECTION_TERMINATION_DETAILS% что всегда пусто (» -«), а флаги ответов я уже видел в заголовках в последующих ответах.

Я увеличился connect_timeout в два раза (0,01 с -gt; 0,02 с -gt;gt; 0,05 с). Это совсем не помогло. И другие службы(по прямой маршрутизации) нормально работают с таймаутом подключения 10 мс. Кстати, все работает хорошо после повторного развертывания в течение примерно 20 минут наверняка.

Надеюсь услышать ваши идеи, что это может быть и где мне следует копаться)

P. S: Я также иногда получаю ошибки проверки работоспособности(в журналах), но я понятия не имею, почему. И все без посланника работало хорошо(без ошибок, без тайм-аутов): проверка работоспособности, прямые запросы и т.д.

Я столкнулся с аналогичной проблемой при запуске envoy в качестве контейнера docker. В конце концов, причиной была отсутствующая --network host опция в docker run команде, которая привела к тому, что кластеры не были видны из контейнера docker envoy. Может быть, это вам тоже поможет?