Невозможно предотвратить достижение конечной точки запросов после разрыва цепи.

Я пытаюсь проверить конфигурацию разрыва цепи linkerd, запрашивая через простую подверженную ошибкам конечную точку, развернутую как модуль в том же кластере k8s, где linkerd развернут как набор демонов.

Я заметил разрыв цепи, наблюдая за журналами, но когда я снова пытаюсь попасть в конечную точку, я все еще получаю ответ от конечной точки.

Настройка и тестирование

Я использовал приведенные ниже конфигурации для настройки linkerd и его конечной точки,

https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/linkerd-egress.yaml

https://raw.githubusercontent.com/zillani/kubex/master/examples/simple-err.yml

поведение конечной точки:

конечная точка всегда возвращает 500 внутренних ошибок сервера

настройка начисления сбоев: по умолчанию классификатор ответов: retryable5XX

прокси-завиток:

http_proxy=$(kubectl get svc l5d -o jsonpath="{.status.loadBalancer.ingress[0].*}"):4140 curl -L http://<loadblancer-ingress>:8080/simple-err

Наблюдения

<сильный>1. В метриках администратора

  "rt/outgoing/client/$/io.buoyant.rinet/8080/<loadbalancer-ingress>/connects" : 505,
  "rt/outgoing/client/$/io.buoyant.rinet/8080/<loadbalancer-ingress>/dtab/size.count" : 0,
  "rt/outgoing/client/$/io.buoyant.rinet/8080/<loadbalancer-ingress>/failed_connect_latency_ms.count" : 0,
  "rt/outgoing/client/$/io.buoyant.rinet/8080/<loadbalancer-ingress>/failure_accrual/probes" : 8,
  "rt/outgoing/client/$/io.buoyant.rinet/8080/<loadbalancer-ingress>/failure_accrual/removals" : 2,
  "rt/outgoing/client/$/io.buoyant.rinet/8080/<loadbalancer-ingress>/failure_accrual/removed_for_ms" : 268542,
  "rt/outgoing/client/$/io.buoyant.rinet/8080/<loadbalancer-ingress>/failure_accrual/revivals" : 0,
  "rt/outgoing/client/$/io.buoyant.rinet/8080/<loadbalancer-ingress>/failures" : 505,
  "rt/outgoing/client/$/io.buoyant.rinet/8080/<loadbalancer-ingress>/failures/com.twitter.finagle.service.ResponseClassificationSyntheticException" : 505,
  "rt/outgoing/client/$/io.buoyant.rinet/8080/<loadbalancer-ingress>/loadbalancer/adds" : 2,
  "rt/outgoing/client/$/io.buoyant.rinet/8080/<loadbalancer-ingress>/loadbalancer/algorithm/p2c_least_loaded" : 1.0,
  "rt/outgoing/client/$/io.buoyant.rinet/8080/<loadbalancer-ingress>/loadbalancer/available" : 2.0,

 "rt/outgoing/service/svc/<loadbalancer-ingress>:8080/failures" : 5,
  "rt/outgoing/service/svc/<loadbalancer-ingress>:8080/failures/com.twitter.finagle.service.ResponseClassificationSyntheticException" : 5,
  "rt/outgoing/service/svc/<loadbalancer-ingress>:8080/pending" : 0.0,
  "rt/outgoing/service/svc/<loadbalancer-ingress>:8080/request_latency_ms.count" : 0,
  "rt/outgoing/service/svc/<loadbalancer-ingress>:8080/requests" : 5,
  "rt/outgoing/service/svc/<loadbalancer-ingress>:8080/retries/budget" : 100.0,
  "rt/outgoing/service/svc/<loadbalancer-ingress>:8080/retries/budget_exhausted" : 5,
  "rt/outgoing/service/svc/<loadbalancer-ingress>:8080/retries/per_request.count" : 0,
  "rt/outgoing/service/svc/<loadbalancer-ingress>:8080/retries/total" : 500,
  "rt/outgoing/service/svc/<loadbalancer-ingress>:8080/success" : 0,

<сильный>2. В журнале

I 0518 10:31:15.816 UTC THREAD23 TraceId:e57aa1baa5148cc5: FailureAccrualFactorymarking connection to "$/io.buoyant.rinet/8080/<loadbalancer-ingress>" as dead.

Проблема

После того, как узел помечен как мертвый, новый запрос к компоновщику (та же самая команда http_proxy выше) достигает конечной точки и возвращает ответ.


person zillani    schedule 18.05.2017    source источник


Ответы (1)


Ответ на этот вопрос был дан на Форум сообщества Linkerd. Добавление ответа здесь также для полноты:

Когда срабатывает накопление отказов (прерыватель цепи), конечная точка переводится в состояние, называемое «Занят». На самом деле это не гарантирует, что конечная точка не будет использоваться. Большинство балансировщиков нагрузки (включая P2CLeastLoaded по умолчанию) просто выбирают самую работоспособную конечную точку. В случае, когда накопление сбоев сработало на всех конечных точках, это означает, что ему придется выбрать одну из них в состоянии «Занято».

person Kevin Lingerfelt    schedule 14.06.2017