«az network publi c -ip create» и «az network publi c -ip list» показывают два разных IP-адреса - PullRequest
Новая
       24

«az network publi c -ip create» и «az network publi c -ip list» показывают два разных IP-адреса

0 голосов
/ 04 апреля 2020

Я промочил ноги от Kubernetes, и я использую AKS и Docker Hub. У меня есть приложение REST, настроенное через Docker Compose, которое состоит из девяти различных микросервисов, взаимодействующих друг с другом. Сейчас я пытаюсь развернуть это на AKS, потому что с точки зрения перехода от Docker Compose к Kubernetes, кажется, нет простого способа подключения сервисов через один экземпляр Minikube.

Тем не менее, мне нужны сервисы, чтобы иметь возможность звонить друг другу через REST, что привело меня к попытке настроить stati c IP на AKS. (К настоящему времени я мог бы слишком усложнить вещи, но все еще промокаю.) Это привело меня к этим двум командам: 

1. az network public-ip create --resource-group <resourceGroup> --name <sameAsValueOf_resourceGroup>
   --allocation-method static

2. az network public-ip list --resource-group <resourceGroup> --query [0].ipAddress --output tsv

Предположительно, команда list должна вернуть то же самое, что и команда create, но в моем случае это не так. Например, create может показывать 10.x.x.x в качестве значения publicIp.ipAddress, но сразу после этого list может возвращать 52.y.y.y.

Это полностью несовместимо с документацией Microsoft, и когда я пытаюсь включение любого IP в мой y8l k8s следующим образом приводит к тому, что EXTERNAL-IP застревает на <Pending>: 

apiVersion: v1
kind: Service
metadata:
  name: warehouse-microservice
spec:
  type: LoadBalancer
  loadBalancerIP: 10.x.x.x
  ports:
  - port: 80
  selector:
    app: warehouse-microservice

В вышеупомянутом yaml, включая spec.ports[0].nodePort, очевидно, что все разрушается. Однако, если я уберу spec.loadBalancerIP и , затем добавлю spec.ports[0].nodePort, все внезапно работает нормально, и Я могу получить доступ к услуге через внешний IP; просто IP выбирается случайным образом.

Так что мой вопрос: Почему create и list показывают два разных IP, несмотря на документацию MS, и как я могу заставить его работать хорошо Достаточно назначить стати c внешний IP?

1 Ответ

3 голосов
/ 05 апреля 2020

При создании нового кластера AKS за сценой создается несколько сетевых ресурсов (внутри MC_${RESOURCE_GROUP_NAME}${CLUSTER_NAME}${LOCATION} группы ресурсов). Одним из ресурсов является IP-адрес stati c publi c (аналогичный тому, который вы создаете с помощью команды CLI * 1047). Вы можете найти этот stati c IP внутри MC resource group => Load balancer => Frontend IP configuration.

Проблема связана с командой az network public-ip list --resource-group <resourceGroup> --query [0].ipAddress --output tsv.

эта команда возвращает первый Stati c Ip в данной группе ресурсов , поскольку --query указывает на первый объект внутри массива - [0].ipAddress, вы всегда получаете один и тот же IP-адрес, который является автоматически созданным IP-адресом.

Но, даже если вы выбрали правильный IP, вы все еще сталкивается с проблемой (), поскольку в документации упоминается, что - When multiple addresses are configured on the Azure Load Balancer, egress uses the first IP on that load balancer (Frontend IP Configuration).

Поэтому мы должны использовать первый IP-адрес stati c, созданный автоматически при создании кластер.

Сквозное решение, которое работало для меня:

  1. Получите IP-адрес stati c publi c: ( Вам не нужно создавать новый) 
EGRESS_IP=$(az network public-ip list --resource-group MC_${RESOURCE_GROUP_NAME}_${CLUSTER_NAME}_${LOCATION} --query '[0].ipAddress' --output tsv)
echo The egress ip address is: $EGRESS_IP
Создание службы со стати c IP: 
 cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  name: azure-egress
  namespace: ${NAMESPACE}
spec:
  loadBalancerIP: ${EGRESS_IP}
  type: LoadBalancer
  ports:
  - port: 80
EOF
Убедитесь, что служба запущена и работает (проверьте, что вы получаете external-ip, и он не застрял, это может занять 1-3 минуты): 
kubectl get svc -n ${NAMESPACE}
Чтобы убедиться, что выходная служба работает должным образом, мы будем использовать службу поиска DNS: 
kubectl run -it --rm aks-egress-ip-check -n ${NAMESPACE}--image=debian --generator=run-pod/v1
Запустить тест: 
apt-get update && \
apt-get install curl -y && \
curl -s checkip.dyndns.org
...