Создание и настройка кластера Служба Azure Kubernetes (AKS) для использования виртуальных узлов с помощью Azure CLI
Виртуальные узлы обеспечивают сетевое взаимодействие между модулями pod, работающими в кластерах Экземпляры контейнеров Azure (ACI) и AKS. Чтобы обеспечить эту связь, создайте подсеть виртуальной сети и назначите делегированные разрешения. Виртуальные узлы работают только с кластерами AKS, созданными с помощью сетевого взаимодействия уровня Расширенный (Azure CNI). По умолчанию кластеры AKS создаются с помощью сетевого взаимодействия уровня Базовый (kubenet). В этой статье показано, как создать виртуальную сеть и подсети, а затем развернуть кластер AKS, использующий сетевое взаимодействие уровня "Расширенный".
В этой статье показано, как использовать Azure CLI для создания и настройки ресурсов виртуальной сети и кластера AKS с поддержкой виртуальных узлов.
Подготовка к работе
Внимание
Прежде чем использовать виртуальные узлы с AKS, ознакомьтесь с ограничениями виртуальных узлов AKS и ограничениями виртуальной сети ACI. Эти ограничения влияют на расположение, конфигурацию сети и другие сведения о конфигурации кластера AKS и виртуальных узлов.
Вам нужен поставщик услуг ACI, зарегистрированный в вашей подписке. Вы можете проверить состояние регистрации поставщика ACI с помощью
az provider list
команды.az provider list --query "[?contains(namespace,'Microsoft.ContainerInstance')]" -o table
Поставщик Microsoft.ContainerInstance должен иметь состояние Registered, как показано в следующем примере выходных данных.
Namespace RegistrationState RegistrationPolicy --------------------------- ------------------- -------------------- Microsoft.ContainerInstance Registered RegistrationRequired
Если поставщик отображается как NotRegistered, зарегистрируйте поставщика с помощью .
az provider register
az provider register --namespace Microsoft.ContainerInstance
При использовании Azure CLI в этой статье требуется Azure CLI версии 2.0.49 или более поздней. Чтобы узнать версию, выполните команду
az --version
. Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI 2.0. Вы также можете использовать Azure Cloud Shell.
Запуск Azure Cloud Shell
Azure Cloud Shell — это бесплатная интерактивная оболочка, с помощью которой можно выполнить действия, описанные в этой статье. Он содержит стандартные средства Azure, предварительно установленные и настроенные.
Чтобы открыть Cloud Shell, выберите Попробовать в правом верхнем углу блока кода. Cloud Shell можно также запустить в отдельной вкладке браузера, перейдя на страницу https://shell.azure.com/bash. Нажмите кнопку Копировать, чтобы скопировать блоки кода. Вставьте код в Cloud Shell и нажмите клавишу "ВВОД", чтобы выполнить его.
Создание или изменение группы ресурсов
Группа ресурсов Azure — это логическая группа, в которой развертываются и управляются ресурсы Azure.
Создайте группу ресурсов с помощью
az group create
команды.az group create --name myResourceGroup --location eastus
Создание виртуальной сети
Внимание
Для виртуального узла требуется настраиваемая виртуальная сеть и связанная подсеть. Его нельзя связать с той же виртуальной сетью, что и кластер AKS.
Создайте виртуальную сеть с помощью
az network vnet create
команды. В следующем примере создается виртуальная сеть с именем myVnet с префиксом адреса 10.0.0.0/8 и подсетью myAKSubnet. Префикс адреса этой подсети по умолчанию — 10.240.0.0/16.az network vnet create \ --resource-group myResourceGroup \ --name myVnet \ --address-prefixes 10.0.0.0/8 \ --subnet-name myAKSSubnet \ --subnet-prefix 10.240.0.0/16
Создайте дополнительную подсеть для виртуальных узлов с помощью
az network vnet subnet create
команды. В следующем примере создается подсеть с именем myVirtualNodeSubnet с префиксом адреса 10.241.0.0/16.az network vnet subnet create \ --resource-group myResourceGroup \ --vnet-name myVnet \ --name myVirtualNodeSubnet \ --address-prefixes 10.241.0.0/16
Создание кластера AKS с управляемым удостоверением
Получите идентификатор подсети
az network vnet subnet show
с помощью команды.az network vnet subnet show --resource-group myResourceGroup --vnet-name myVnet --name myAKSSubnet --query id -o tsv
Создайте кластер AKS с помощью
az aks create
команды и замените<subnetId>
идентификатор, полученный на предыдущем шаге. В следующем примере создается кластер с именем myAKSCluster с пятью узлами.az aks create \ --resource-group myResourceGroup \ --name myAKSCluster \ --node-count 5 \ --network-plugin azure \ --vnet-subnet-id <subnetId> \ --generate-ssh-keys
Через несколько минут команда завершается и возвращает сведения о кластере в формате JSON.
Дополнительные сведения об управляемых удостоверениях см. в разделе "Использование управляемых удостоверений".
Включение надстройки виртуальных узлов
Включите виртуальные узлы с помощью
az aks enable-addons
команды. В следующем примере используется подсеть с именем myVirtualNodeSubnet , созданная на предыдущем шаге.az aks enable-addons \ --resource-group myResourceGroup \ --name myAKSCluster \ --addons virtual-node \ --subnet-name myVirtualNodeSubnet
Подключение к кластеру
Настройте
kubectl
подключение к кластеруaz aks get-credentials
Kubernetes с помощью команды. На этом шаге скачиваются учетные данные и настраивается интерфейс командной строки Kubernetes для их использования.az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
Проверьте подключение к кластеру с помощью
kubectl get
команды, которая возвращает список узлов кластера.kubectl get nodes
В следующем примере выходных данных показан один узел виртуальной машины, созданный и виртуальный узел для Linux, virtual-node-aci-linux:
NAME STATUS ROLES AGE VERSION virtual-node-aci-linux Ready agent 28m v1.11.2 aks-agentpool-14693408-0 Ready agent 32m v1.11.2
Развертывание примера приложения
Создайте файл
virtual-node.yaml
и скопируйте в него следующий код YAML. YAML запланирует контейнер на узле, определив элемент nodeSelector и толерацию.apiVersion: apps/v1 kind: Deployment metadata: name: aci-helloworld spec: replicas: 1 selector: matchLabels: app: aci-helloworld template: metadata: labels: app: aci-helloworld spec: containers: - name: aci-helloworld image: mcr.microsoft.com/azuredocs/aci-helloworld ports: - containerPort: 80 nodeSelector: kubernetes.io/role: agent beta.kubernetes.io/os: linux type: virtual-kubelet tolerations: - key: virtual-kubelet.io/provider operator: Exists - key: azure.com/aci effect: NoSchedule
Запустите приложение с помощью
kubectl apply
команды.kubectl apply -f virtual-node.yaml
Получите список модулей pod и запланированный узел с помощью
kubectl get pods
команды с аргументом-o wide
.kubectl get pods -o wide
Модуль pod запланирован на виртуальном узле virtual-node-aci-linux, как показано в следующем примере выходных данных:
NAME READY STATUS RESTARTS AGE IP NODE aci-helloworld-9b55975f-bnmfl 1/1 Running 0 4m 10.241.0.4 virtual-node-aci-linux
Группа pod получает внутренний IP-адрес из подсети виртуальной сети Azure, которая делегирована для использования с виртуальными узлами.
Примечание.
При использовании образов, хранящихся в Реестре контейнеров Azure, настройте и используйте секрет Kubernetes. Текущее ограничение виртуальных узлов заключается в том, что вы не можете использовать встроенную проверку подлинности субъекта-службы Microsoft Entra. Если вы не используете секрет, модули pod, запланированные на виртуальные узлы, не будут запускаться и сообщат об ошибке HTTP response status code 400 error code "InaccessibleImage"
.
Тестирование группы pod на виртуальном узле
Проверьте модуль pod, запущенный на виртуальном узле, перейдя в демонстрационное приложение с веб-клиентом. Так как группа pod получает внутренний IP-адрес, вы можете быстро проверить это подключение с другой группой pod в том же кластере AKS.
Создайте тестовый модуль pod и подключите к нему сеанс терминала с помощью следующей
kubectl run -it
команды.kubectl run -it --rm testvk --image=mcr.microsoft.com/dotnet/runtime-deps:6.0
Установите
curl
в модуле pod с помощьюapt-get
.apt-get update && apt-get install -y curl
Доступ к адресу модуля pod,
curl
например http://10.241.0.4. Укажите собственный внутренний IP-адрес, показанный в предыдущейkubectl get pods
команде.curl -L http://10.241.0.4
Отобразится демонстрационное приложение, как показано в следующем сокращенном примере выходных данных:
<html> <head> <title>Welcome to Azure Container Instances!</title> </head> [...]
Закройте сеанс подключения терминала к проверяемой группе pod, выполнив
exit
. После завершения сеанса модуль pod удаляется.
Удаление виртуальных узлов
Удалите модуль pod, запущенный
aci-helloworld
на виртуальном узле, с помощьюkubectl delete
команды.kubectl delete -f virtual-node.yaml
Отключите виртуальные узлы с помощью
az aks disable-addons
команды.az aks disable-addons --resource-group myResourceGroup --name myAKSCluster --addons virtual-node
Удалите ресурсы виртуальной сети и группу ресурсов, выполнив следующие команды.
# Change the name of your resource group, cluster and network resources as needed RES_GROUP=myResourceGroup AKS_CLUSTER=myAKScluster AKS_VNET=myVnet AKS_SUBNET=myVirtualNodeSubnet # Get AKS node resource group NODE_RES_GROUP=$(az aks show --resource-group $RES_GROUP --name $AKS_CLUSTER --query nodeResourceGroup --output tsv) # Get network profile ID NETWORK_PROFILE_ID=$(az network profile list --resource-group $NODE_RES_GROUP --query "[0].id" --output tsv) # Delete the network profile az network profile delete --id $NETWORK_PROFILE_ID -y # Grab the service association link ID SAL_ID=$(az network vnet subnet show --resource-group $RES_GROUP --vnet-name $AKS_VNET --name $AKS_SUBNET --query id --output tsv)/providers/Microsoft.ContainerInstance/serviceAssociationLinks/default # Delete the service association link for the subnet az resource delete --ids $SAL_ID --api-version 2021-10-01 # Delete the subnet delegation to Azure Container Instances az network vnet subnet update --resource-group $RES_GROUP --vnet-name $AKS_VNET --name $AKS_SUBNET --remove delegations
Следующие шаги
В этой статье вы запланировали модуль pod на виртуальном узле и назначили частный внутренний IP-адрес. В качестве альтернативы вы можете создать развертывание службы и направлять трафик в группу pod через подсистему балансировки нагрузки или контроллер входящего трафика. Дополнительные сведения см. в статье Создание контроллера входящего трафика в Службе Azure Kubernetes (AKS).
Виртуальные узлы — это зачастую лишь один из компонентов, необходимых для масштабирования решения в AKS. Дополнительные сведения о таких решениях см. в следующих статьях:
Azure Kubernetes Service