Не могу подключиться к внутреннему входу AKS на частной v- net из одноранговой v-сети

Question

У нас есть оригинальная сеть с количеством linux виртуальных машин с docker контейнерами роя. Мы переносим их в AKS, но это нужно сделать поэтапно. В настоящее время мы настроили вход для частного su bnet с внутренним входом ниже, как показано ниже, используйте следующий пример https://docs.microsoft.com/en-us/azure/aks/ingress-internal-ip

Проблема: - при подключении к оригиналу v- net Мы не можем подключиться к 10.3.0.4 на 2 su bnet, т.е. 10.0.0.12:80 -> 10.3.0.4:80. На тестовой ВМ на том же su bnet и кластере AKS Мы можем нормально подключиться к 10.3.0.4.

Странные вещи, которые мы можем подключить с оригинального v- net к концу службы точка в ni c, то есть 10.0.0.12:80 -> 10.3.3.134:80/.

Это не решение, поскольку мы могли бы иметь несколько реплик.

Есть идеи, почему балансировщик нагрузки не виден оригиналу v- net?

Подключенные устройства в V- Net

original subnet
//10.0.0.0/24
10.0.0.0 - 10.0.0.255 (65536 addresses)
//10.0.1.0/24
10.0.1.0 - 10.0.1.255 (65536 addresses)

которые имеют установленный пиринг

aks subnet
10.3.0.0/16
10.3.0.0 - 10.3.255.255 (65536 addresses)

az aks create \
    --resource-group AKS_Workshop \
    --name workshop-aks-cluster \
    --network-plugin azure \
    --vnet-subnet-id "/subscriptions/../resourceGroups/AKS_Workshop/providers/Microsoft.Network/virtualNetworks/aksvnet/subnets/default" \
    --docker-bridge-address 172.17.0.1/16 \
    --dns-service-ip 10.4.0.2 \
    --service-cidr 10.4.0.0/16 \
    --generate-ssh-keys \
    --max-pods 96 \
    --node-vm-size Standard_DS2_v2

controller:
  service:
    loadBalancerIP: 10.3.0.4
    annotations:
      service.beta.kubernetes.io/azure-load-balancer-internal: "true"

helm install stable/nginx-ingress /
  --name backend-ingress /
  --namespace ingress -f ingress-basic.yaml 
  --set controller.nodeSelector."beta\.kubernetes\.io/os"=linux 
  --set defaultBackend.nodeSelector."beta\.kubernetes\.io/os"=linux

NAME                                            TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)                      AGE
aks-helloworld                                  ClusterIP      10.4.121.75   <none>        80/TCP                       25h
backend-ingress-nginx-ingress-controller        LoadBalancer   10.4.233.18   10.3.0.4      80:30904/TCP,443:32023/TCP   23h
backend-ingress-nginx-ingress-default-backend   ClusterIP      10.4.198.93   <none>        80/TCP                       23h
ingress-demo                                    ClusterIP      10.4.53.2     <none>        80/TCP                       25h

Name:              ingress-demo
Namespace:         ingress
Labels:            <none>
Annotations:       <none>
Selector:          app=acs-helloworld-saucy-antelope
Type:              ClusterIP
IP:                10.4.53.2
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.3.3.134:80
Session Affinity:  None
Events:            <none>

Answer 1

Оказывается, проблема связана с тем, что 2 v- net находятся в разных регионах. После того, как я создал v- net в том же регионе, у меня не было проблем с попаданием во внутреннюю конечную точку балансировщика нагрузки, так как он говорит, что вы можете добраться до внутренней конечной точки, но если вы установите количество реплик для своей балансировочной машины, вы можете нажать только одна из конечных точек делает ее бессмысленной

VNet пиринг

Что такое VNet пиринг?

VNet пиринг (или пиринг виртуальной сети) позволяет вам подключаться к виртуальным сетям. Пиринговое соединение VNet между виртуальными сетями позволяет вам конфиденциально маршрутизировать трафик c между ними через адреса IPv4. Виртуальные машины в одноранговых виртуальных сетях могут взаимодействовать друг с другом, как если бы они находились в одной сети. Эти виртуальные сети могут находиться в одном и том же регионе или в разных регионах (также известный как глобальный VNet пиринг). VNet пиринговые соединения также можно создавать для Azure подписок.

Можно ли создать пиринговое соединение с VNet в другом регионе?

Да , Глобальный пиринг VNet позволяет вам взаимодействовать с виртуальными сетями в разных регионах. Глобальный пиринг VNet доступен во всех Azure опубликованных c регионах, облачных регионах Китая и правительственных облачных регионах. Вы не можете глобально сопоставлять регионы Azure publi c с областями национального облака.

Каковы ограничения, связанные с глобальными VNet пирингом и балансировщиками нагрузки?

Если две виртуальные сети в двух разных регионах работают в режиме пиринга по глобальному VNet пирингу, вы не сможете подключиться к ресурсам, которые находятся за балансировщиком нагрузки Basi c через внешний IP-адрес балансировщика нагрузки. Это ограничение не существует для стандартного балансировщика нагрузки. Следующие ресурсы могут использовать балансировщики нагрузки Basi c, что означает, что вы не можете получить к ним доступ через внешний интерфейс IP балансировщика нагрузки через глобальный VNet пиринг. Однако вы можете использовать глобальный пиринг VNet для непосредственного доступа к ресурсам через их частные VNet IP-адреса, если это разрешено.

ВМ позади Basi c Балансировщики нагрузки Наборы масштабов виртуальных машин с Basi c Балансировщики нагрузки Redis Cache Application Gateway (v1) SKU Service Fabric SQL Управление API MI Доменная служба Active Directory (ADDS) Logi c Приложения HDInsight Azure Среда обслуживания пакетных приложений

Вы можете подключиться к этим ресурсам через ExpressRoute или VNet -to- VNet через VNet Шлюзы.