Интеграция существующего Azure VNET в кластер Kubernetes с использованием ACS-Engine

Поскольку развертывание кластера k8s в портале Azure не позволяет мне подключить к нему существующий Azure VENT, я использую ACS-Engine. Сетевая среда k8s по умолчанию выглядит следующим образом:

Private VNet    10.0.0.0/8
Master Subnet   10.240.255.0/24
Agent Subnet    10.240.0.0/24
Pod CIDR        10.244.0.0/16
Service CIDR    10.0.0.0/16

То, что я хочу достичь, это так:

Private VNet    10.25.0.0/24
Master Subnet   10.25.0.0/27
Agent Subnet    10.25.0.32/27
Pod CIDR        10.25.0.64/27
Service CIDR    10.0.0.0/16 (Default by ACS) 

Для этого я сначала создал Azure VNET (acs-vnet) с адресным пространством 10.25.0.0/24. Вместе я создал две подсети "msubnet" и "asubnet" 10.25.0.32/27 и 10.25.0.64/27. Также я изменил шаблон json следующим образом:

 "properties": {
    "orchestratorProfile": {
      "orchestratorType": "Kubernetes",
      "orchestratorVersion": "1.6.2",
      "kubernetesConfig": {
        "clusterSubnet": "10.25.0.64/27"
      }
    },
    "masterProfile": {
      "count": 1,
      "dnsPrefix": "acsengine",
      "vmSize": "Standard_D2_v2",
      "vnetSubnetId": "/subscriptions/...../resourceGroups/.../providers/.../subnets/msubnet",
      "firstConsecutiveStaticIP": "10.25.0.5"
    },
    "agentPoolProfiles": [
      {
        "name": "agent",
        "count": 2,
        "vmSize": "Standard_A1",
        "availabilityProfile": "AvailabilitySet",
        "vnetSubnetId": "/subscriptions/.../resourceGroups/.../providers/.../subnets/asubnet",
        "osType": "Windows"
      }
    ],

Однако оказалось, что мастер не готов из-за того, что PID CIDR не назначен:

user@k8s-master-0000000-0:~$ kubectl get node
NAME                    STATUS     AGE       VERSION
10000acs9001            Ready      31m       v1.6.0-alpha.1.2959+451473d43a2072
k8s-master-10008476-0   NotReady   34m       v1.6.2

И когда я запустил "kubectl описать узел", он показал

  Ready                 False   Wed, 14 Jul 2017 04:40:38 +0000         Wed, 14 Jul 2017 04:12:03 +0000         KubeletNotReady                 runtime network not ready: NetworkReady=false ginNotReady message:docker: network plugin is not ready: Kubenet does not have netConfig. This is most likely due to lack of PodCIDR

С этим результатом я подозреваю, что это может из-за размера подсети, назначенной для CIDR POD. Поэтому я попробовал еще два случая.

Случай I

Private VNet    10.25.0.0/16
Master Subnet   10.25.0.0/24
Agent Subnet    10.25.1.0/24
Pod CIDR        10.25.2.0/24
Service CIDR    10.0.0.0/16 (Default by ACS) 

Случай II

Private VNet    10.24.0.0/14
Master Subnet   10.25.0.0/24
Agent Subnet    10.25.1.0/24
Pod CIDR        10.24.0.0/16
Service CIDR    10.0.0.0/16 (Default by ACS) 

В случае I это не удается, поскольку 10.25.2.0/24 назначается только мастеру, но не агентам. Более того, появляется следующее сообщение. Я проверяю, что это не проблема с субъектом службы, и проверил в Azure, что созданный маршрут Azure не имеет определенных маршрутов.

“NoRouteCreated    RouteController failed to create a route”

Во втором случае на этом этапе все работает нормально.

С этим результатом, мои вопросы:

  1. Существует ли минимальный размер подсети, который должен быть назначен для CIDR POD?

  2. Если я хочу подключить VNET, скажем, 20.0.0.0/8 к кластеру, но не исходный с 10.0.0.0/8, какие шаги нужно предпринять? Будет ли изменение значения "$env:VIP_CIDR=\"10.0.0.0/8\"\n\n "в сгенерированном файле справки azuredeploy.json?

  3. Если я добавлю vnetSubnetId для интеграции моего существующего VNET в мой кластер k8s, скажем, 20.0.0.0/16, будут ли какие-либо конфликты с предварительно выделенным 10.0.0.0/8? (насколько я понимаю, этот частный VNET неизвестен Azure SDN?)

  4. У меня есть виртуальная машина в моей существующей среде VNET, и я хотел бы подключиться к службе в Azure, используя VIP (CIDR службы, неизвестный Azure SDN). Какие-либо предложения к этому?

Был бы признателен за любые идеи.

0 ответов

Другие вопросы по тегам