Развертывание контроллера балансировки нагрузки AWS для сервиса EKS Fargate API

Контекст

Я пытаюсь развернуть контейнерную службу API в кластере EKS Fargate и заставить ее обслуживать запросы с внешних интернет-адресов в качестве сложного POC/опыта обучения. У меня возникли проблемы с пониманием того, как направить сетевой трафик в службу Fargate. Моим основным руководством для проекта являются эти два урока:

Но моя неопытность проявляется, когда дело доходит до принятия решения, следует ли мне попытаться настроить шлюз API, балансировщик нагрузки приложений, контроллер входа ALB или использовать контроллер балансировки нагрузки AWS, мои текущие попытки были с последним. У меня большая часть инфраструктуры и компонентов EKS/Fargate работает с использованием файлов Terraform и .yaml для использования с kubectl.

Настраивать

У меня есть следующее развертывание с одной конфигурацией Terraform, которая успешно развертывается:

  • VPC с частными и общедоступными подсетями, а также включенными шлюзами nat и vpn.
  • Кластер EKS с coredns, kube-proxy, vpc-cni и одним профилем Fargate, который выбирает пространство имен моего приложения и распределяет узлы по частным подсетям VPC.

У меня есть следующие конфигурации «.yaml», которые согласуются между различными попытками метода:

  • пространство имен.yaml (kind: Namespace)
  • развертывание.yaml (kind: Deployment)
  • развертывание_секрета.yaml (kind: Secret)
  • сервис.yaml (kind: Service,spec:type: NodePort)

Я рад опубликовать подробности любого из этих файлов, но этот пост уже очень длинный.

Проблема

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

После развертывания своей инфраструктуры с помощью Terraform, успешной настройки и установки контроллера AWS LB я создаю свое развертывание и сервис с помощью kubectl. Проблема начинается, когда я пытаюсь создать объект Ingress (?), предоставленная конфигурация выглядит так:

      ---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  namespace: my-namespace
  name: ingress-myapp
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  rules:
    - http:
        paths:
          - path: /*
            backend:
              serviceName: service-myapp
              servicePort: 80

Это возвращает ошибку, говорящуюerror: error validating "ingress.yaml":Я опустил детали, потому что это решено в этом вопросе , ведущем к этому запросу на включение . Я переконфигурировал файл, чтобы он соответствовал измененному определению конфигурации, которое теперь выглядит так:

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-myapp
  namespace: my-namesace
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/scheme: internet-facing
spec:
  defaultBackend:
    service:
      name: service-myapp
      port:
        number: 80
  rules:
    - http:
        paths:
          - path: /*
            backend:
              service:
                name: service-myapp
                port:
                  number: 80
            pathType: ImplementationSpecific

Это приводит к ошибке:

      Error from server (InternalError): error when creating "ingress.yaml": Internal error occurred: failed calling webhook "vingress.elbv2.k8s.aws": Post "https://aws-load-balancer-webhook-service.kube-system.svc:443/validate-networking-v1-ingress?timeout=10s": context deadline exceeded

Я последовал за этим постом , описывающим аналогичную проблему, поэтому я убедился, что все мои ссылки на LBC использовали версию 2.4.0, но это не повлияло на проблему. Я также просмотрел эти две темы (GitHub Issue и Reddit ), но изо всех сил пытаюсь понять, какое решение было в этих случаях.

Я делаю вывод, что некоторая часть процесса не может достичь внешнего адреса при проверке нового входного объекта/конфигурации, но я не уверен, какой компонент пытается сделать этот запрос и мешает ли это разрешению или сетевой проблеме. это. Любые указания или подсказки приветствуются!

Источник

0 ответов

Другие вопросы по тегам