Представление приложения kubernetes с помощью AWS Elastic LoadBalancer

Question

Представление приложения kubernetes с помощью AWS Elastic LoadBalancer

Я создал внутренний балансировочный балансировщик нагрузки приложения AWS и в консоли AWS показывает его состояние как активное. Обратите внимание, что я создал этот ALB, используя задание jenkins, и в задании я указал мой сервер экземпляров AWS EC2, который настроен как мой мастер kubernetes.

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

В консоли AWS под описанием, я могу видеть ниже детали -

DNS  internal-myservices-987070943.us-east-1.elb.amazonaws.com
Scheme  internal
Type  application
IP address type  ipv4

Тогда есть вкладка Слушатели, под которой я вижу Идентификатор слушателя с HTTPS: 443

Также показаны правила со следующими 2 правилами -

IF Path is /*  THEN Forward to myservices-LB
IF Requests otherwise not routed  THEN Forward to myservices-LB

Также я вижу другие вкладки, такие как Мониторинг, Интегрированные сервисы и Теги.

Теперь у меня есть кластер kubernetes со следующей службой, созданной с помощью Type: LoadBalancer - (Ссылка на источник: https://github.com/kenzanlabs/kubernetes-ci-cd/blob/master/applications/hello-kenzan/k8s/manual-deployment.yaml)

apiVersion: v1
Kind: Service
metadata:
 name: hello-kenzan
 labels:
 app: hello-kenzan
spec:
 ports:
  - port: 80
    targetPort: 80
 selector:
   app: hello-kenzan
   tier: hello-kenzan
 type: LoadBalancer

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: hello-kenzan
  labels:
    app: hello-kenzan
spec:
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: hello-kenzan
        tier: hello-kenzan
    spec:
      containers:
      - image: gopikrish81/hello-kenzan:latest
        name: hello-kenzan
        ports:
        - containerPort: 80
          name: hello-kenzan

После того, как я создал сервис с -

kubectl apply -f k8s/manual-deployment.yaml
kubectl get svc

Внешний IP-адрес отображается как <pending>Но так как я создал тип loadbalancer, почему он не создает ip?

К вашему сведению, я могу получить доступ к приложению, используя curl <master node>:<nodeport>Или даже я могу получить к нему доступ через прокси-сервер.

Таким образом, без созданного IP-адреса не будет возможности показать мое приложение с помощью DNS, верно? Пожалуйста, предложите, что я могу сделать, чтобы я мог предоставить свой сервис, используя DNS-имя internal-myservices-987070943.us-east-1.elb.amazonaws.com

Мне нужно, чтобы приложение отображалось с DNS-именем, таким как http://internal-myservices-987070943.us-east-1.elb.amazonaws.com/

заранее спасибо

ОБНОВЛЕНИЕ, как 29/1

Я следовал шагам ответа, как упомянуто в этом посте. Kube-controller-manager не запускается при использовании "cloud-provider=aws" с kubeadm

1) Я изменил файл "/etc/systemd/system/kubelet.service.d/10-kubeadm.conf", добавив приведенную ниже команду в разделе [Сервис]

Environment="KUBELET_EXTRA_ARGS=--cloud-provider=aws --cloud-config=/etc/kubernetes/cloud-config.conf

И я создал этот cloud-config.conf, как показано ниже:

[Global]
KubernetesClusterTag=kubernetes
KubernetesClusterID=kubernetes

Я не уверен, что означают этот тег и идентификатор, но когда я запускаю приведенную ниже команду, я вижу вывод с упоминанием clusterName как "kubernetes"

kubeadm config view

Затем я казнил,

systemctl daemon-reload
system restart kubelet

2) Затем, как уже упоминалось, я добавил --cloud-provider=aws в обоих kube-controller-manager.yaml и kube-apiserver.yaml

3) Я также добавил аннотацию ниже в manual-deploy.yaml моего приложения

annotations:
  service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0

https://github.com/kenzanlabs/kubernetes-ci-cd/blob/master/applications/hello-kenzan/k8s/manual-deployment.yaml

Теперь, когда я развернул с помощью kubectl apply -f k8s/manual-deployment.yaml сам стручок не создается, когда я проверил с kubectl get po --all-namespaces

Поэтому я попытался удалить шаг 2 выше и снова сделал развертывание, и теперь модуль успешно создается. Но все же это показывает <pending> для ВНЕШНЕГО IP, когда я сделал kubectl get svc

Я даже переименовал свой главный и рабочий узлы, чтобы они были такими же, как и в частном DNS-экземпляре EC2: ip-10-118-6-35.ec2.internal и ip-10-118-11-225.ec2.internal, как упомянуто ниже в посте и перенастроил кластер но все равно не повезло. https://medium.com/jane-ai-engineering-blog/kubernetes-on-aws-6281e3a830fe (в разделе "Правильные имена узлов")

Кроме того, в моих экземплярах EC2 я вижу прикрепленную роль IAM, и когда я вижу подробности этого, я вижу, что к этой роли применено 8 политик. И в одной из политик я вижу это ниже, и есть много других действий, которые я не публикую здесь.

{
   "Action": "elasticloadbalancing:*",
   "Resource": "*",
   "Effect": "Allow"
}

Я не знаю, если некоторые другие настройки мне не хватает. Пожалуйста, предложите!

ОБНОВЛЕНИЕ, как 30/1

Я сделал следующие дополнительные шаги, как упомянуто в этом блоге - https://blog.scottlowe.org/2018/09/28/setting-up-the-kubernetes-aws-cloud-provider/

1) Добавлены теги AWS для всех моих экземпляров EC2 (главного и рабочего узлов) как "kubernetes.io/cluster/kubernetes", а также для моей группы безопасности

2) Я не добавил apiServerExtraArgs, controllerManagerExtraArgs и nodeRegistration вручную в файле конфигурации. Но то, что я сделал, я полностью сбросил кластер, используя "sudo kubeadm reset -f" а затем я добавил это в conf файл kubeadm как на главном, так и на рабочем узлах -

Environment="KUBELET_EXTRA_ARGS=--cloud-provider=aws --cloud-config=/etc/kubernetes/cloud-config.conf

cloud-config.conf -

[Global]
KubernetesClusterTag=kubernetes.io/cluster/kubernetes
KubernetesClusterID=kubernetes

Затем выполняется как в главном, так и в рабочем узлах -

systemctl daemon-reload
system restart kubelet

3) Теперь я создал кластер, используя команду ниже в главном узле

sudo kubeadm init --pod-network-cidr=192.168.1.0/16 --apiserver-advertise-address=10.118.6.35

4) Тогда мне удалось успешно присоединить рабочий узел к кластеру и развернуть фланелевый CNI.

После этого узлы get показывали статус Ready.

Важно отметить, что в пути /etc/kubernetes/manifest есть файлы kube-apiserver.yaml и kube-controller-manager.yaml.

Когда я добавил --cloud-provider=aws в обоих этих файлах yaml моего развертывания не происходило, и pod вообще не создавался. Поэтому, когда я удалил тег --cloud-provider=aws от kube-apiserver.yaml, развертывания и модули были успешными.

И по просьбе Мэтью, когда я изменил yaml для kube-apiserver и kube-controller-manager, оба модуля снова были успешно созданы. Но поскольку модули не создавались, я удалил тег из kube-apiserver.yaml в одиночку.

Кроме того, я проверил журналы с kubectl logs kube-controller-manager-ip-10-118-6-35.ec2.internal -n kube-system

Но я не вижу каких-либо исключений или отклонений. Я вижу это в последней части -

IO130 19:14:17.444485    1 event.go:221] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"default", Name:"hello-kenzan", UID:"c........", APIVersion:"apps/v1", ResourceVersion:"16212", FieldPath:""}): type: 'Normal' reason: 'SuccessfulCreate' Created pod: hello-kenzan-56686879-ghrhj

Даже попытался добавить эту аннотацию ниже к manual-deploy.yaml, но все еще показывает то же самое <Pending>

service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0

Обновление как на 1/31

Наконец-то достигнут некоторый прогресс!! Проблема выглядит как сопоставление тегов. В отображении значения ключа для тегов aws у меня был ключ как KubernetesCluster и значение как k8s, но в файле конфигурации у меня был ключ, сопоставленный вместо значения.

Но теперь я вижу журналы в модуле kube-controller-manager -

`1 aws.go: 1041] Создание облачного провайдера AWS

1 aws.go:1007] Зона не указана в файле конфигурации; запрос сервиса метаданных AWS

1 controller manager.go:208] ошибка построения контекста контроллера: не удалось инициализировать провайдер облака: не удалось инициализировать провайдер облака "aws": экземпляр поиска ошибок i-02dbgfghjf3e7: "ошибка при перечислении экземпляров AWS: \"RequestError: сбой отправки запроса \ ncaused by: Post https://ec2.us-east-1.amazonaws.com/: dial tcp 54.239.28.176:443: тайм-аут ввода-вывода \"" `

Последнее обновление

Я не использовал прокси для *.amazonaws.com и, кажется, теперь подключаюсь. В этом смысле я говорю "похоже на подключение", проверяя журналы, которые я вижу только в журналах ниже, без той ошибки тайм-аута, которая возникала до добавления этого прокси-сервера. Я также удостоверился, что модуль контроллера перезапустился с моим редактированием и сохранением. И после этого я вижу ниже журналы -

`1 aws.go: 1041] Создание облачного провайдера AWS

1 aws.go:1007] Зона не указана в файле конфигурации; запрос сервиса метаданных AWS

Итак, я предполагаю, что мой контроллер может подключаться к облаку aws, верно? Но, к сожалению, все еще становится <pending> когда я снова создал свой сервис:(

Обновление от 01/02

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

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

Теперь, когда я пытаюсь получить доступ к DNS-имени LB напрямую с помощью URL-адреса - internal-myservices-987070943.us-east-1.elb.amazonaws.com/api/v1/namespace s/default/services, я получаю "Этот сайт может" не быть достигнут "

Принимая во внимание, что если я перенаправлю прокси с моего экземпляра главного узла, используя прокси-сервер kubectl - адрес 0.0.0.0 --accept-hosts '.*' И затем, если я получу прямой доступ к ip своего главного узла, как показано ниже, я смогу просмотреть - 10.118.6.35:8001/ API / v1 / пространств имен / по умолчанию / услуги

Разве невозможно получить доступ к службам kubernetes, развернутым как NodePort или Loadbalancer Type, чтобы они были доступны с использованием прямого DNS-имени AWS Loadbalancer?? Я даже проверил подключение, используя tracert internal-myservices-987070943.us-east-1.elb.amazonaws.com И я могу успешно достичь пункта назначения 10.118.12.196 за 18 прыжков

Но от моего экземпляра главного узла ec2 это не трассировка. Обычно у меня установлен прокси с помощью этой команды - "export {http, https, ftp} _proxy = http://proxy.ebiz.myorg.com/" И я могу получить доступ даже к внешним URL-адресам. Может ли это быть проблемой?

-1

kubernetes google-kubernetes-engine amazon-elb aws-application-load-balancer aws-load-balancer

Источник

user1253037 28 янв '19 в 20:34

1 ответ

Другие вопросы по тегам kubernetes google-kubernetes-engine amazon-elb aws-application-load-balancer aws-load-balancer

user225016 29 янв '19 в 07:46 2019-01-29 07:46 · Answer 1 · 2019-01-29 07:46

Вы объединяете две отдельные проблемы здесь.

Внешний IP-адрес отображается как Но, поскольку я создал тип loadbalancer, почему он не создает ip?

Предполагая, что это показывает <pending> достаточно долго для вас, чтобы составить так вопрос об этом означает, что ваш controller-manager стручки не имеют флагов командной строки --cloud-provider=aws и сопровождающие --cloud-config=/the/path/hereи / или не имеют роли экземпляра IAM, которая позволяет этим модулям создавать балансировщики нагрузки от вашего имени.

Однако, сказав, что: исправление, которое создаст новый LoadBalancer, и он не будет использовать ваш существующий ALB. Это вдвойне верно, потому что type: LoadBalancer создаст классический ELB, если не указано иное, чтобы сделать иначе

Я создал внутренний балансировочный балансировщик нагрузки приложения AWS и в консоли AWS показывает его состояние как активное. Обратите внимание, что я создал этот ALB, используя задание jenkins, и в задании я указал мой сервер экземпляров AWS EC2, который настроен как мой мастер kubernetes.

Прежде всего, как правило, вы должны опустить мастера из поворота, так как каждый NodePort предоставляется каждому работнику в вашем кластере, и почти никогда не требуется, чтобы вы увеличивали нагрузку и трафик, проходящий через ведущие в вашем кластере. Кроме того, если вы не настроили это иначе, действительные блоки, обслуживающие байты для службы, не будут жить на основных устройствах, и, таким образом, сетевой трафик в любом случае придется перенаправлять.

Кроме того, вы хотели бы изменить свой сервис, чтобы быть type: NodePortи укажите целевую группу ALB на этом порту:

spec:
 ports:
  - port: 80
    targetPort: 80
 selector:
   app: hello-kenzan
   tier: hello-kenzan
 type: NodePort

Вы можете включить nodePort: строфа в этом ports: Если вы хотите, или вы можете просто оставить его пустым, и kubernetes назначит его, очень вероятно, начиная с вершины NodePort Диапазон распределения портов и работы вниз. Вы можете узнать, какой он выбрал через kubectl get -o yaml svc hello-kenzan