Kubernetes: AKS Ingress связывается только со стручками в одном узле и подсети

Question

У меня развернут кластер AKS kubernetes с 3 узлами (kubenet - это сетевое оверлейное устройство), при этом NGINX Ingress настроен на маршрутизацию на основе имен на модули.

У меня есть несколько идентичных приложений, развернутых под разнымиимена в кластере.

Я могу связаться с некоторыми приложениями через http, но не с другими.При ближайшем рассмотрении я вижу, что все приложения, к которым я могу обратиться, находятся на том же узле, что и входной контроллер, и в одной внутренней 172. * подсети.

Все приложения находятся в том же пространстве имен, что и входной контроллер.

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

Однако я не могу найти, какая соответствующая конфигурация позволила бы входу охватить все приложения независимо от того, к какому узлу и внутренней подсети они относятся;Я считаю, что это должно быть поведение по умолчанию в Kubernetes.

Как мне настроить это желаемое поведение?

Некоторые результаты теста:

 kubectl logs https-ingress-controller-6bc79d6c69-7ljkb  --namespace ingress-nginx --follow
-------------------------------------------------------------------------------
NGINX Ingress controller
  Release:    0.23.0
  Build:      git-be1329b22
  Repository: https://github.com/kubernetes/ingress-nginx
-------------------------------------------------------------------------------

W0611 14:37:06.679648       6 flags.go:213] SSL certificate chain completion is disabled (--enable-ssl-chain-completion=false)
nginx version: nginx/1.15.9
W0611 14:37:06.685012       6 client_config.go:549] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
I0611 14:37:06.685884       6 main.go:200] Creating API client for https://172.17.0.1:443
I0611 14:37:06.712278       6 main.go:244] Running in Kubernetes cluster version v1.14 (v1.14.0) - git (clean) commit 641856db18352033a0d96dbc99153fa3b27298e5 - platform linux/amd64
I0611 14:37:07.055688       6 nginx.go:261] Starting NGINX Ingress controller
I0611 14:37:07.066491       6 event.go:221] Event(v1.ObjectReference{Kind:"ConfigMap", Namespace:"ingress-nginx", Name:"tcp-services", UID:"56d2e0c2-8c47-11e9-8911-8272a7251f4e", APIVersion:"v1", ResourceVersion:"5775", FieldPath:""}): type: 'Normal' reason: 'CREATE' ConfigMap ingress-nginx/tcp-services
I0611 14:37:07.067855       6 event.go:221] Event(v1.ObjectReference{Kind:"ConfigMap", Namespace:"ingress-nginx", Name:"nginx-configuration", UID:"56cdccf4-8c47-11e9-8911-8272a7251f4e", APIVersion:"v1", ResourceVersion:"5774", FieldPath:""}): type: 'Normal' reason: 'CREATE' ConfigMap ingress-nginx/nginx-configuration
I0611 14:37:07.075165       6 event.go:221] Event(v1.ObjectReference{Kind:"ConfigMap", Namespace:"ingress-nginx", Name:"udp-services", UID:"56d6c9e3-8c47-11e9-8911-8272a7251f4e", APIVersion:"v1", ResourceVersion:"5776", FieldPath:""}): type: 'Normal' reason: 'CREATE' ConfigMap ingress-nginx/udp-services
I0611 14:37:08.159406       6 event.go:221] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"ingress-nginx", Name:"https-ingress", UID:"103260ed-8c4a-11e9-8911-8272a7251f4e", APIVersion:"extensions/v1beta1", ResourceVersion:"17054", FieldPath:""}): type: 'Normal' reason: 'CREATE' Ingress ingress-nginx/https-ingress
I0611 14:37:08.160481       6 backend_ssl.go:68] Adding Secret "ingress-nginx/chachingtls" to the local store
I0611 14:37:08.256541       6 nginx.go:282] Starting NGINX process
I0611 14:37:08.256572       6 leaderelection.go:205] attempting to acquire leader lease  ingress-nginx/ingress-controller-leader-nginx...
I0611 14:37:08.257345       6 controller.go:172] Configuration changes detected, backend reload required.
I0611 14:37:08.261914       6 status.go:148] new leader elected: nginx-ingress-controller-6674b5b5dc-nhjcc
I0611 14:37:08.328794       6 event.go:221] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"ingress-nginx", Name:"https-ingress", UID:"103260ed-8c4a-11e9-8911-8272a7251f4e", APIVersion:"extensions/v1beta1", ResourceVersion:"17059", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress ingress-nginx/https-ingress
I0611 14:37:08.391940       6 controller.go:190] Backend successfully reloaded.
I0611 14:37:08.392044       6 controller.go:200] Initial sync, sleeping for 1 second.
[11/Jun/2019:14:37:09 +0000]TCP200000.000

• Списокмодулей приложения в одном и том же пространстве имен:

NAME                                        READY   STATUS    RESTARTS   AGE   IP            NODE                       NOMINATED NODE   READINESS GATES
durian                                      1/1     Running   0          12m   172.18.0.14   aks-agentpool-82039614-0   <none>           <none>
https-ingress-controller-6bc79d6c69-mg7lm   1/1     Running   0          15m   172.18.2.11   aks-agentpool-82039614-2   <none>           <none>
kiwi                                        1/1     Running   0          12m   172.18.2.14   aks-agentpool-82039614-2   <none>           <none>
mango                                       1/1     Running   0          13m   172.18.2.12   aks-agentpool-82039614-2   <none>           <none>
mangosteen                                  1/1     Running   0          12m   172.18.2.13   aks-agentpool-82039614-2   <none>           <none>
orange                                      1/1     Running   0          12m   172.18.2.15   aks-agentpool-82039614-2   <none>           <none>

• другой внутренней сети и узла: время ожидания:

kubectl exec -ti https-ingress-controller-6bc79d6c69-mg7lm  /bin/bash -n ingress-nginx
www-data@https-ingress-controller-6bc79d6c69-7ljkb:/etc/nginx$
www-data@https-ingress-controller-6bc79d6c69-7ljkb:/etc/nginx$
www-data@https-ingress-controller-6bc79d6c69-7ljkb:/etc/nginx$ curl http://172.18.1.10:5678
^C

• той же внутренней сети и узла- ОК:

www-data@https-ingress-controller-6bc79d6c69-7ljkb:/etc/nginx$
www-data@https-ingress-controller-6bc79d6c69-7ljkb:/etc/nginx$
www-data@https-ingress-controller-6bc79d6c69-7ljkb:/etc/nginx$ curl http://172.18.2.9:5679
mango

• та же внутренняя сеть и узел - ОК:

www-data@https-ingress-controller-6bc79d6c69-7ljkb:/etc/nginx$ curl http://172.18.2.5:8080
<!-- HTML for static distribution bundle build -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <title>Swagger UI</title>
    <link rel="stylesheet" type="text/css" href="./swagger-ui.css" >
    <link rel="icon" type="image/png" href="./favicon-32x32.png" sizes="32x32" />
    <link rel="icon" type="image/png" href="./favicon-16x16.png" sizes="16x16" />
    <style>
      html

• другая внутренняя сеть / узел - время ожидания:

www-data@https-ingress-controller-6bc79d6c69-7ljkb:/etc/nginx$ curl http://172.18.1.9:5678

^C

Я уничтожил и повторно развернул кластер и приложения несколько раз с одинаковой конфигурацией и поведение такое же.

Answer 1

Похоже, что в случае сетевой модели kubenet при использовании уже существующих VNET и подсети (не выделенной для AKS) таблица маршрутизации с UDR для узлов AKS не присоединяется к подсети, в которой развернуты узлы.по умолчанию, что означает, что модули не могут связаться друг с другом через узлы.

Тот факт, что UDR необходимо настроить для kubenet, упоминается в документации Microsoft Azure, однако никаких инструкций по фактической настройке таблиц маршрутизации и UDR для AKS не приводится.

Необходимо создатьэти маршруты после присоединения таблицы маршрутизации к подсети AKS или добавления маршрутов к существующей таблице маршрутизации подсети (если таковая существует).

Решение описано здесь, оно в основном включает присоединение сгенерированной таблицы маршрутов по умолчанию.установкой AKS в подсеть AKS:

https://github.com/Azure/aks-engine/blob/master/docs/tutorials/custom-vnet.md

, т.е. настройте и запустите этот скрипт:

#!/bin/bash
rt=$(az network route-table list -g RESOURCE_GROUP_NAME_KUBE -o json | jq -r '.[].id')
az network vnet subnet update \
-g RESOURCE_GROUP_NAME_VNET \
--route-table $rt \
--ids "/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP_NAME_VNET/providers/Microsoft.Network/VirtualNetworks/KUBERNETES_CUSTOM_VNET/subnets/KUBERNETES_SUBNET"

Теперь я могу подключаться к модулямвсе узлы кластера через Ingress.

ПРИМЕЧАНИЕ. В качестве альтернативы можно вручную добавить UDR в любую существующую ранее таблицу маршрутизации, которую вы могли присоединить к предварительно созданной подсети AKS до развертывания AKS.

Answer 2

Для сети kubelet в AKS модули могут связываться друг с другом. Вы видите описание ниже:

С помощью kubenet узлы получают IP-адрес из виртуальной сети Azure. подсети. Модули получают IP-адрес с логически другого адреса пространство для подсети виртуальной сети Azure узлов. сеть Трансляция адресов (NAT) затем настраивается так, чтобы модули могли получать доступ к ресурсам в виртуальной сети Azure. IP-адрес источника Трафик NAT для основного IP-адреса узла.

Модули могут общаться с другими, проходить через узел с NAT. И только узлы могут получать маршрутизируемый IP-адрес. Вы можете посмотреть маршруты на портале так:

И Azure сделает все за вас. Это хорошо работает на моей стороне. Так что, если это не работает для вас. Тогда вы можете проверить, в порядке ли маршруты.

Вот скриншот, который проверяет связь для модулей в другом адресном пространстве: