Azure Container Instances (ACI) позволяют запускать контейнеры, не беспокоясь об инфраструктуре. Мы можем дать образ контейнера, и ACI с радостью запустит контейнер и даже обеспечит внешним IP-адресом. Когда ручное вмешательство необходимо только при запуске контейнеров, это называется «беcсерверные контейнеры». ACI отлично подходит для пакетных рабочих нагрузок или долгосрочных контейнеров, где мы не хотим иметь дело с инфраструктурой.

ACI обеспечивает низкоуровневый блок построения инфраструктуры для запуска контейнеров. Мы можем думать о нем как о ВМ (виртуальная машина), но вместо запуска образа виртуальной машины он запускает образ контейнера.

Один интересный пример того, как ACI можно использовать в сочетании с контейнерным оркестром, – это экспериментальный ACI-коннектор для Kubernetes. Когда он установлен в кластере Kubernetes, ACI-коннектор создает виртуальные узлы в кластере. Они ведут себя как узлы с неограниченной мощностью. На них мы можем планировать запуск подов (pods), но фактически они будут выполняться как группы контейнеров в ACI.

Возможно, однажды ACI Connector станет основой, позволяющей «бессерверному Kubernetes»… строить кластер в Kubernetes Azure Container Service (AKS), который не имеет физических узлов

Недавно в ACI Connector для Kubernetes была добавлена поддержка контейнеров Windows, и сегодня мы рассмотрим, как использовать ACI Connector для запуска контейнеров Windows.

Настройка Azure Container Service для кластера Kubernetes (AKS)

Создать управляемый кластер Kubernetes в Azure с использованием AKS невероятно просто. Запустите эти команды CLI Azure:

$ az group create -n antchu-aks-temp
$ az aks create -g antchu-aks-temp -n antchu-aks-temp -c 1 -l eastus -k 1.8.2

Это создает группу ресурсов и ресурс AKS. Мы установили размер пула агентов в 1, его местоположение в eastus и версию Kubernetes 1.8.2.
После того как кластер готов, мы можем использовать CLI Azure для установки последнего CLI Kubernetes (kubectl) и загрузить файл конфигурации для нашего кластера:

$ az aks install-cli
$ az aks get-credentials -g antchu-aks-temp -n antchu-aks-temp

Теперь мы видим один узел в кластере.

$ kubectl get nodes
NAME                        STATUS    ROLES     AGE       VERSION
aks-agentpool1-16617890-0   Ready     agent     2m        v1.8.2

Установка ACI-коннектора для Kubernetes

Создадим группу ресурсов

Перед установкой ACI-коннектора необходимо создать группу ресурсов, в которую будут развертываться ресурсы ACI:

$ az group create -n antchu-aci-temp -l eastus
{
  "id": "/subscriptions/<subscription-id>/resourceGroups/antchu-aci-temp",
  "location": "eastus",
  "managedBy": null,
  "name": "antchu-aci-temp",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null
}

Обратите внимание на идентификатор новой группы ресурсов.

Создание первичного сервиса

Затем нужно создать первичный сервис, который ACI-коннектор будет использовать для создания экземпляров контейнера, управления и их удаления во вновь созданной группе ресурсов. Первичному сервису необходимо назначить роль контрибьютора в группе ресурсов. Чтобы создать первичный сервис и назначить ему роли, мы запускаем следующую команду, используя полный идентификатор группы ресурсов на предыдущем шаге:

$ az ad sp create-for-rbac -n antchu-aks-aci-temp --role contributor --scopes <resource-group-id>
{
  "appId": "<app-id>",
  "displayName": "antchu-aks-aci-temp",
  "name": "http://antchu-aks-aci-temp",
  "password": "<password>",
  "tenant": "<tenant-id>"
}

Обратите внимание на возвращаемые значения свойств appId, password и tenant.

Установка ACI-коннектора

ACI-коннектор доступен как образ на Docker Hub. Чтобы получить поддержку Windows, нужно использовать сборку canary. Создайте следующий файл aci-connector.yaml. Он определяет deployment Kubernetes с одним контейнером, который запускает контейнер из образа microsoft/aci-connector-k8s:canary:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: aci-connector
  namespace: default
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: aci-connector
    spec:
      containers:
      - name: aci-connector
        image: microsoft/aci-connector-k8s:canary
        imagePullPolicy: Always
        env:
        - name: AZURE_CLIENT_ID
          value: <tenant-id>
        - name: AZURE_CLIENT_KEY
          value: <app-id>
        - name: AZURE_TENANT_ID
          value: <tenant-id>
        - name: AZURE_SUBSCRIPTION_ID
          value: <subscription-id>
        - name: ACI_RESOURCE_GROUP
          value: antchu-aci-temp

Замените переменные среды значениями, полученными из предыдущих команд. Затем создайте deployment в Kubernetes:

$ kubectl create -f aci-connector.yaml

Теперь, если посмотрим состояние кластера, мы увидим ещё два новых виртуальных узла:

$ kubectl get nodes
NAME                        STATUS    ROLES     AGE       VERSION
aci-connector-0             Ready     <none>    10s       v1.6.6
aci-connector-1             Ready     <none>    10s       v1.6.6
aks-agentpool1-16617890-0   Ready     agent     9m        v1.8.2

Планирование запуска контейнеров на aci-connector-0 будет запускать контейнеры Linux; aci-connector-1 будет запускать контейнеры Windows.

Чтобы Kubernetes случайно не загрузил на них поды, для узлов ACI-коннектора был добавлен azure.com/aci:NoSchedule taint. Мы можем это увидеть, если посмотрим на свойства узла:

$ kubectl describe node aci-connector-1
Name:               aci-connector-1
Roles:              <none>
Labels:             beta.kubernetes.io/os=1
Annotations:        node.alpha.kubernetes.io/ttl=0
Taints:             azure.com/aci:NoSchedule
…

Планируем запуск контейнера Windows на ACI

Создайте файл iis-pod.yaml со следующим содержимым. В нем описывается один контейнер, в котором отображается содержимое контейнера Windows microsoft/iis:windowsservercore.

apiVersion: v1
kind: Pod
metadata:
  name: iis-winsvrcore
spec:
  containers:
  - image: microsoft/iis:windowsservercore
    imagePullPolicy: Always
    name: iis-winsvrcore
  dnsPolicy: ClusterFirst
  nodeName: aci-connector-1

Обратите внимание: мы явно указываем Kubernetes, что этот под должен запускаться на узле с именем aci-connector-1. Теперь мы создаем под:

$ kubectl create -f iis-pod.yaml
pod "iis-winsvrcore" created

И если мы запросим список наших подов, они появятся в списке:

$ kubectl get pods -o wide
NAME                             READY  STATUS    RESTARTS   AGE   IP              NODE
aci-connector-54b97586f5-l96l9   1/1    Running   0          32m   10.244.0.10     aks-agentpool1-16617890-0
iis-winsvrcore                   1/1    Running   0          2m    13.88.182.114   aci-connector-1

ACI понадобится несколько минут, чтобы загрузить образ и запустить его. В настоящее время в ACI-коннекторе есть ошибка: он покажет под в состоянии «Running», даже если под все еще создается. Мы должны увидеть статус экземпляра контейнера, выполнив команду Azure CLI:

$ az container list -o table
Name               ResourceGroup    ProvisioningState    Image                            IP:ports           CPU/Memory       OsType    Location
-----------------  ---------------  -------------------  -------------------------------  -----------------  ---------------  --------  ----------
iis-winsvrcore     antchu-aci-temp  Creating             microsoft/iis:windowsservercore  13.88.182.114:80   1.0 core/1.5 gb  Windows   westus

Когда состояние изменится на «Succeeded», мы можем перейти по IP-адресу контейнера. Получить IP можно через выполнение kubectl get -o wide или вывод команды az, указанный выше.

Обновление – 21 ноября 2017 г.

Посмотрите это видео от Ria Bhatia – менеджера, работающего в ACI и ACI Connector. Отличная демонстрация технологий, о которых мы говорили.

Оригинал: Deploying Windows Containers with Azure Container Instances (ACI) Connector for Kubernetes.