Доступ к услуге через балансировщик нагрузки в кластере AKS - PullRequest
Новая
       4

Доступ к услуге через балансировщик нагрузки в кластере AKS

0 голосов
/ 31 октября 2018

У меня настроен кластер, в котором все службы (и связанные с ними модули / контейнеры) развернуты в частной подсети. Один из этих модулей представляет пользовательский интерфейс приложения, и я определил балансировщик нагрузки с общедоступным ip для предоставления доступа к пользовательскому интерфейсу. По крайней мере, это мое намерение. Когда я ввожу в браузере URL-адрес с IP-адресом балансировщика нагрузки, запросы не поступают в контейнер пользовательского интерфейса. Я предполагаю, что я что-то настроил неправильно, и некоторые советы будут оценены. Определение службы пользовательского интерфейса выглядит следующим образом: 

    apiVersion: apps/v1beta1
    kind: Deployment
    metadata: {name: myui, namespace: gem}
    spec:
      replicas: 1
      template:
        metadata:
          labels: {app: myui}
        spec:
          containers:
            image: myblobstore.azurecr.io/myui:latest
            imagePullPolicy: Always
            name: myui
            ports:
            - {containerPort: 80}
    ---
    apiVersion: v1
    kind: Service
    metadata: {name: myapp, namespace: gem}
    spec:
      loadBalancerIP: 40.123.124.125
      ports:
      - {name: '80', port: 80}
      selector: {app: myui}
      type: LoadBalancer

Я также определил правило в своей группе безопасности сети, которое я намеревался разрешить трафику от балансировщика нагрузки достигать целевого контейнера: 

    65001    AzureLoadBalancerInBound   Any  Any  AzureLoadBalancer  Any  Allow

Трафик не попадает в контейнер UI. Какая дополнительная конфигурация мне нужна, чтобы заставить это работать?

Обновление: вот конечные точки для моего кластера: 

$ kubectl get endpoints -n gem
NAME                ENDPOINTS                       AGE
...
myui                10.0.2.22:80                    176m
...

И чтобы завершить картину, вот дополнительная информация: 

$ kubectl get pods -n gem -o wide
NAME                                 READY   STATUS             RESTARTS   AGE    IP          NODE                  NOMINATED NODE
...
myui-99c55f8d4-2thzv                 1/1     Running            0          ...

$ kubectl get svc -n gem -o wide
NAME                TYPE           CLUSTER-IP   EXTERNAL-IP     PORT(S)             AGE    SELECTOR
...
myui                LoadBalancer   10.1.0.94    40.123.124.125  80:32246/TCP        3h1m   app=myui
...

$ kubectl describe svc/myui -n gem
Name:                     myui
Namespace:                gem
Labels:                   <none>
Annotations:              kubectl.kubernetes.io/last-applied-configuration:
                            {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"myui","namespace":"gem"},"spec":{"loadBalancerIP":"40.123.124,125"...
Selector:                 app=myui
Type:                     LoadBalancer
IP:                       10.1.0.94
IP:                       40.123.124.125
LoadBalancer Ingress:     40.123.124.125
Port:                     80  80/TCP
TargetPort:               80/TCP
NodePort:                 80  32246/TCP
Endpoints:                10.0.2.22:80
Session Affinity:         None
External Traffic Policy:  Cluster

Питер

1 Ответ

0 голосов
/ 12 ноября 2018

В итоге решение состояло в том, чтобы просто убедиться, что используемая группа сетевой безопасности имеет открытые порты 80 и 443 для прохождения интернет-трафика. У меня было две разные группы безопасности, и я подумал, что мой балансировщик нагрузки будет использовать ту, которую я определил как свою «публичную» группу безопасности, у которой действительно были открыты порты 80 и 443. Вместо этого он использовал мою другую группу безопасности, и мне пришлось добавить соответствующие правила в эту группу.

...