#amazon-web-services #kubernetes #amazon-ec2 #aws-security-group #aws-load-balancer
Вопрос:
У меня есть решение (база данных AnzoGraph), развернутое в моем кластере AWS Kubernetes (экземпляр EC2), и оно работало совершенно нормально. Внезапно это решение остановилось, и я больше не мог получить к нему доступ через DNS. Я протестировал решение, развернутое в моем кластере, с помощью команды переадресации портов kubectl, и они работают нормально (модули и службы), поэтому я предполагаю, что проблема связана с AWS Loadbalancer.
Чтобы получить доступ к приложению, нам нужно пройти по следующему пути: Запрос -> DNS ->> Балансировщик нагрузки AWS ->>> Сервисы ->>>> Модули.
Балансировщик нагрузки (классический) внутренний, поэтому он доступен только для меня или компании, использующей VPN. Каждый раз , когда я пытаюсь получить доступ к DNS, я не получаю ответа.
Есть идеи, как я могу это исправить ? или в чем именно заключается проблема ? как я могу устранить эту проблему и следить за трафиком на AWS ?
Большое спасибо за помощь!
Комментарии:
1. есть ли у вашего балансировщика нагрузки здоровые цели ниже по потоку, когда вы проверяете его в консоли AWS? Это похоже на проблему группы безопасности.
2. Как я могу точно проверить? (я новичок)
3. docs.aws.amazon.com/elasticloadbalancing/latest/classic/…
Ответ №1:
извини, что пропустил твой пост раньше.
давайте начнем с нескольких вопросов… Вы говорите, что используете k8s на AWS EC2, вы на самом деле используете EKS или используете другой стек k8s?
Также… вы упомянули, что получаете доступ к LB от вашего клиента (БД)/ вашего программного обеспечения с помощью DNS, разрешающего LB, а затем получаете доступ к базе данных AnzoGraph.
Я хочу убедиться, что решение на самом деле заключается в том, что DNS каждый раз разрешает LB через DNS. если у вас есть давно работающий сервис, и AWS изменяет IP-адрес LB, и ваш SW, возможно, кэшировал IP-адрес, вы не сможете подключиться к LB.
- в системе вы запускаете свое программное обеспечение для доступа к базе данных AnzoGraph … (Я предполагаю, что CentOS (7) )
- убедитесь, что у вас установлен dig (yum install bind-utils)
- dig {{ ваше DNS-имя вашего LB }} это на самом деле IP-адрес, к которому обращается ваш SW?
- изменился ли IP-адрес клиента? убедитесь, что LB SG разрешает доступ (https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html)
Я предполагаю, что вы получаете доступ к интерфейсному модулю базы данных AnzoGraph через 443? как вы пишете
«Я протестировал решение, развернутое в моем кластере, с помощью команды переадресации портов kubectl, и они работают нормально (модули и службы)».
нам, вероятно, не нужно искать журналы модулей. (если бы это было не так, LB, очевидно, также заблокировал бы трафик.)
Поэтому я согласен, что наиболее вероятной проблемой является (плохое) кэширование DNS или SG из-за того, что другой SRC-IP отклоняется классическим LB SG.
также для полноты картины .. пожалуйста, расскажите нам больше о вашем env.
- Изображение базы данных AnzoGraph
- Версия EKS/k8s
- используется штурвальная карта / оператор анзографа.
Лучший — Откровенный