Миграция модулей с разных хостов EC2 - PullRequest
Новая
       131

Миграция модулей с разных хостов EC2

1 голос
/ 10 июля 2020

Я новичок в AWS, Kubernetes, EKS и AppMe sh, но выполнял DevOps в предыдущих ролях.

Я беру на себя некоторый кластер K8, который использовал EKS, и обнаружил, что мы установили up NAT-шлюз, который помогает перенаправлять исходящий трафик c исходящий как единый IP-адрес (он нужен нам для внесения в белый список, так как это требуется сторонней внешней службе). Модули, размещенные на частном su bnet, работают нормально.

Но я обнаружил, что модули, размещенные на publi c su bnet, просто пропускают шлюз NAT, он использует Publi c DNS (IPv4 ) IP-адрес для исходящих вызовов, который у нас не работает, так как он не использует единственный шлюз NAT.

Итак, у меня есть несколько вопросов:

  1. Как мы выполняем миграцию Поды из Publi c su bnet Хосты в частные подсети Хосты?
  2. Следует ли нам использовать nodeSelector, Node affinity? Работают ли надписи на узлах?
  3. Я не уверен, почему у нас есть узлы в публикации c su bnet, но мы следовали этому руководству: https://docs.aws.amazon.com/eks/latest/userguide/create-public-private-vpc.html
  4. Если мы выберем полностью частные подсети, можем ли мы сделать исключение для такого сопоставления, чтобы разрешить некоторым модулям иметь конечные точки HTTP, которые будут открыты для входящего трафика c, оставаясь при этом в частных подсетях?
  5. Что вы порекомендуете нам обрабатывать, когда модулю / контейнеру необходимо использовать шлюз NAT для исходящего трафика c, но затем открывать конечные точки HTTP для входящего трафика c?

Note that currently, our EKS is by default set to all public, should we move to Public and private mode?

Заранее спасибо за все ответы!.

1 Ответ

2 голосов
/ 10 июля 2020

Как перенести поды из Publi c su bnet Hosts в Hosts частных подсетей? Должны ли мы использовать nodeSelector, привязку к узлу? Надписи на узлах работают?

Да. Используйте Node Affinity , что аналогично использованию nodeSelector. Вы можете выполнить последовательное изменение, обновив любой ресурс, который вы используете для управления своими модулями (например, Deployment, Statefulset, DaemonSet и т. Д. c). Если вы правильно настроили его при следующем запуске ваших модулей, они будут на частных хостах su bnet.

Я не уверен, почему у нас есть узлы в publi c su bnet, но мы следовали этому руководству: https://docs.aws.amazon.com/eks/latest/userguide/create-public-private-vpc.html

В руководстве написано publi c su bnet, поэтому логично, что он есть.

Если мы все же выберем полностью частные подсети, можем ли мы сделать исключение для такого сопоставления, чтобы разрешить некоторым модулям иметь конечные точки HTTP, которые будут доступны для входящего трафика c, оставаясь при этом в частных подсетях?

Да! вы можете создать внешний балансировщик нагрузки (ALB, NLB или ELB). Kubernetes также может управлять ими, если вы используете тип сервиса LoadBalancer . Вам понадобятся соответствующие аннотации в определениях ваших сервисов, чтобы получить то, что вы хотите.

Что вы порекомендуете нам обрабатывать, когда Pod / Container должен использовать шлюз NAT для исходящий трафик c, но затем открывая конечные точки HTTP для входящего трафика c?

Используйте внешний балансировщик нагрузки, который перенаправляет трафик c на ваш частный VP C с помощью службы Kubernetes введите LoadBalancer и используйте AWS шлюзы NAT для исходящего трафика rnet трафик c.

Отказ от ответственности: это всего лишь рекомендация, существуют другие комбинации и альтернативы.

...