Невозможно создать сервис Kubernetes с помощью AWS Elastic LoadBalancer

Я создал балансировщик нагрузки приложения aws myservices и получил следующее DNS-имя, указанное в консоли aws - internal-myservices-987070943.us-east-1.elb.amazonaws.com

У меня также есть целевые группы, созданные и показанные ниже в разделе Описание - Имя как myservices-LB, Протокол как HTTPS, порт как 443, Тип цели как экземпляр, Балансировщик нагрузки как мои услуги На вкладке Цели я могу видеть Зарегистрированные целевые объекты, показывающие мой идентификатор экземпляра как i- 02dbf9b3a7d9163e7 с портом 443 и другими деталями ... Этот идентификатор экземпляра - мой экземпляр ec2, который я настроил как главный узел моего кластера kubernetes.

На самом деле как мой loadbalancer, так и экземпляры EC2 находятся в одном VPC.

Теперь со своего локального компьютера я могу получить доступ к этому URL-адресу https://internal-myservices-987070943.us-east-1.elb.amazonaws.com Я сделал следующее: 1) не выполнялась проверка работоспособности порта HTTPS 443 и 2) Установлен веб-сервер nginx в моем экземпляре EC2. Таким образом, установка nginx и открытие порта SSL автоматически решают проблему проверки работоспособности, и я могу просматривать внутренний URL-адрес LB с помощью https.

Но все же моя основная проблема создания балансировщика нагрузки с использованием kubernetes svc не решена :( Он все еще показывает <pending> для EXTERNAL_IP. Я сомневаюсь, поскольку и экземпляр EC2, и LB находятся в одном VPC, почему нет traceroute internal-myservices-987070943.us-east -1.elb.amazonaws.com не отслеживает его? Я получаю все * * * для всех 30 переходов. Но с моего локального компьютера я могу успешно отследить его. Так вот почему он не создает внешний IP-адрес?

Я сделал все необходимое для интеграции облака AWS с кубернетами ..

1) Мое имя хоста главного и рабочего узлов в кластере куба совпадает с именами DNS экземпляра EC2.

2) Добавлены теги для инстансов EC2 и в сервисе kubelet

3) Добавлены теги облачной конфигурации для POD'ов kube-api и kube-controller-manager

4) Я вижу elasticloadbalancing: * Действие с Allow for my policy в AWS для моей роли.

Также мне интересно, как это, когда nginx, установленный в моем экземпляре EC2, может получить доступ к моему LoadBalancer, но Traceroute не может получить к нему доступ.

Можно ли получить прямой доступ к моему сервису с помощью Loadbalancer, который я создал вручную через консоль AWS? Может быть, с NodePort или ingress что ли .. ??

Так что я застрял в этом :( Пожалуйста, помогите ..


comment
Добавлены теги cloud-config для kube-api и kube-controller-manager Я полагаю, вы имеете в виду аргумент --cloud-config, но вы также добавили аргумент --cloud-provider=aws?   -  person mdaniel    schedule 03.02.2019
comment
Да, это тоже было добавлено   -  person Gopi    schedule 03.02.2019
comment
Тогда только журналы диспетчера контроллеров (и / или apiserver) будут сообщать, что не так с вызовами API, необходимыми для подготовки ELB для этого Service, который застрял в <pending>   -  person mdaniel    schedule 03.02.2019
comment
Я вижу только эти, относящиеся к AWS, в журналах контроллеров - 1 aws.go: 1041] Создание облачного провайдера AWS 1 aws.go: 1007] Зона не указана в файле конфигурации; запрос службы метаданных AWS. Кроме того, я не вижу эту политику в моей роли Я .. Действие: s3: *, Ресурс: [Arn: AWS: s3 ::: kubernetes- * может ли это быть проблемой?   -  person Gopi    schedule 03.02.2019
comment
Теперь, по прошествии некоторого времени, я вижу, что этот журнал ниже начал происходить .. 1 controller manager.gi:208] ошибка при построении контекста контроллера: поставщик облачных услуг не может быть инициализирован: не удалось запустить облачного поставщика aws: экземпляр ошибки поиска i-02dbf9b3a7d9163e7: ошибка при перечислении экземпляров AWS: \ RequestError: сбой отправки запроса \\ nпричина: Сообщение ec2.us-east1. amazonaws.com: наберите tcp 54.239.28.168:443 тайм-аут ввода-вывода \   -  person Gopi    schedule 03.02.2019
comment
Я действительно упомянул в ваш предыдущий вопрос, что это так. очень вероятно, что проблема с группой безопасности или брандмауэром, так как большинство тайм-аутов подключения обычно   -  person mdaniel    schedule 03.02.2019
comment
Но тогда, если это проблема брандмауэра, как я могу получить доступ к своему AWS LB через https-порт 443, который, в свою очередь, вызывает мой сервер nginx, установленный в моем экземпляре ec2, с включенным https-портом 443 и обслуживающий мне страницу index.html?   -  person Gopi    schedule 03.02.2019
comment
Это ваш вопрос, вы должны доказать нам, что это не проблема с брандмауэром, потому что тайм-аут ввода-вывода при попытке связаться с AWS API точно не является нормальным состоянием дела   -  person mdaniel    schedule 03.02.2019


Ответы (1)


Мне пришлось установить прокси как переменную env внутри yaml kube-controller. Кроме того, чтобы это работало, нужно было установить IP-адрес метаданных ec2 в переменной no_proxy.

person Gopi    schedule 06.02.2019