Почему моя служба Kubernetes иногда работает только на EKS?

В некоторых случаях у нас есть Услуги, которые не получают ответа при попытке доступа к ним. Например, Chrome показывает ERR_EMPTY_RESPONSE, и иногда мы получаем и другие ошибки, например 408, которые, я уверен, возвращаются из ELB, а не из самого нашего приложения.

После продолжительного исследования, включая ssh'ing в самих узлах, эксперименты с балансировщиками нагрузки и многое другое, мы все еще не уверены, на каком уровне проблема существует: либо в самом Kubernetes, либо в сервисах поддержки от Amazon EKS (ELB или иначе)

  • Кажется, что только порт экземпляра (данных) узла является тем, который имеет проблему. Проблемы, кажется, приходят и уходят периодически, что заставляет нас верить, что это не что-то очевидное в наших манифестах или конфигурациях докеров kubernetes, а скорее что-то другое в базовой инфраструктуре. Иногда служба и пакет будут работать, но возвращайтесь и утром это будет сломано. Это наводит нас на мысль, что проблема связана с перераспределением пакетов в kubernetes, возможно, вызванным чем-то в AWS (изменение балансировщика нагрузки, автоматическое изменение групповых изменений и т. Д.) Или чем-то в самом kubernetes, когда он перераспределяет пакеты по другим причинам.
  • Во всех случаях, которые мы видели, порт проверки работоспособности продолжает работать без проблем, поэтому kubernetes и aws считают, что все в порядке и не сообщают о каких-либо сбоях.
  • Мы видели, что некоторые модули работали на узле, в то время как другие не работали на этом же узле.
  • Мы убедились, что kube-proxy работает, и что вывод iptables-save является "одинаковым" между двумя работающими модулями. (то же самое означает, что все, что не является уникальным, например, IP-адреса и порты, одинаково и соответствует тому, что они должны быть относительно друг друга). (мы использовали эти инструкции, чтобы помочь с этими инструкциями: https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/
  • Из ssh на самом узле, для модуля, который выходит из строя, мы МОЖЕМ получить доступ к модулю (то есть к самому приложению) через все возможные ip/ порты, которые ожидаются.
    • 10. адрес самого узла на порте данных экземпляра.
    • 10. адрес модуля (контейнера Docker) на порте приложения.
    • 172. адрес??? на порте приложения (мы не уверены, что это за ip или как до него доходит маршрут ip, так как это другая подсеть, чем адрес 172 интерфейса docker0).
  • Из ssh на другом узле для сбойного модуля мы не можем получить доступ к сбойному модулю ни на каких портах (ERR_EMPTY_RESPONSE). Похоже, это то же самое поведение, что и балансировка обслуживания / нагрузки.

Что еще может вызвать такое поведение?

Источник

1 ответ

После долгих расследований мы столкнулись с рядом проблем: * Наше приложение не всегда ведет себя так, как мы ожидали. Всегда проверяйте это сначала. * В нашем манифесте Kubernetes Service мы указали externalTrafficPolicy: Local, что, вероятно, должно работать, но вызывало у нас проблемы. (Это было с использованием Classic Load Balancer) service.beta.kubernetes.io/aws-load-balancer-type: "clb", Так что, если у вас есть проблемы с CLB, либо удалите externalTrafficPolicy или явно установите его в значение по умолчанию "Cluster".

Итак, наш манифест сейчас: kind: Service apiVersion: v1 metadata: name: apollo-service annotations: service.beta.kubernetes.io/aws-load-balancer-type: "clb" service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:REDACTED" service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443" service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"
spec: externalTrafficPolicy: Cluster selector: app: apollo ports: - name: http protocol: TCP port: 80 targetPort: 80 - name: https protocol: TCP port: 443 targetPort: 80 type: LoadBalancer

Источник

Добавление 

service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"

Исправлено для меня

Источник
Другие вопросы по тегам