Deploy Windows Containers to Azure Container Instances (ACI). Kubernetes Connector

Azure Container Instances (ACI) allow you to run containers without worrying about infrastructure. We can give the image of the container, and ACI will happily launch the container and even provide an external IP address. When manual intervention is required only when containers start, this is called serverless containers. ACI is great for batch workloads or long-term containers where we don’t want to deal with infrastructure.

ACI provides a low-level infrastructure building block for launching containers. We can think of it as a VM (virtual machine), but instead of launching a virtual machine image, it runs the container image.

One interesting example of how ACI can be used in conjunction with a container orchestra is the experimental ACI connector for Kubernetes. When it is installed in a Kubernetes cluster, the ACI connector creates virtual nodes in the cluster. They behave like nodes with unlimited capacity. On them we can schedule the launch of hearths (pods), but in fact they will run as groups of containers in ACI.

Perhaps one day, the ACI Connector will become the basis for enabling “serverless Kubernetes” ... to build a cluster in the Kubernetes Azure Container Service (AKS) that does not have physical nodes

Windows container support has recently been added to the ACI Connector for Kubernetes, and today we will look at how to use the ACI Connector to launch Windows containers.

Configure Azure Container Service for Kubernetes Cluster (AKS)

Creating a managed Kubernetes cluster in Azure using AKS is incredibly easy. Run these Azure CLI commands:

$ 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 

This creates a resource group and an AKS resource. We set the agent pool size to 1, its location in eastus and the Kubernetes version 1.8.2 .
After the cluster is ready, we can use the Azure CLI to install the latest Kubernetes CLI ( kubectl ) and load the configuration file for our cluster:

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

Now we see one node in the cluster.

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

Installing an ACI Connector for Kubernetes

Create a resource group

Before installing the ACI connector, you must create a resource group into which the ACI resources will be deployed:

 $ 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 } 

Note the identifier for the new resource group.

Creating a primary service

Then you need to create a primary service that the ACI connector will use to create container instances, manage and delete them in the newly created resource group. The primary service must be assigned the role of contributor to the resource group. To create a primary service and assign roles to it, we run the following command using the full identifier of the resource group in the previous step:

 $ 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>" } 

Notice the return values ​​for the appId , password and tenant properties.

Installing an ACI Connector

The ACI Connector is available as an image on the Docker Hub . To get Windows support, you need to use the assembly canary. Create the following aci-connector.yaml file. It defines deployment Kubernetes with one container that launches the container from the 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 

Replace environment variables with values ​​from previous commands. Then create a deployment in Kubernetes:

 $ kubectl create -f aci-connector.yaml 

Now, if we look at the cluster status, we will see two more new virtual nodes:

 $ 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 

Scheduling container launch on aci-connector-0 will launch Linux containers; aci-connector-1 will launch Windows containers.

In order for Kubernetes not to accidentally download pods on them, azure.com/aci:NoSchedule taint was added for the ACI connector azure.com/aci:NoSchedule taint . We can see this if we look at the properties of the node:

 $ 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 … 

We are planning to launch a Windows container on ACI

Create a file iis-pod.yaml with the following contents. It describes a single container, which displays the contents of the 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 

Note: we explicitly indicate to Kubernetes that this one should run on a node named aci-connector-1 . Now we create under:

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

And if we request a list of our pods, they will appear in the list:

 $ 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 will take several minutes to load the image and launch it. Currently, there is an error in the ACI connector: it will show under the «Running» state, even if it is still being created. We need to see the status of the container instance by running the Azure CLI command:

 $ 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 

When the status changes to «Succeeded» , we can navigate to the IP address of the container. You can get IP by executing kubectl get -o wide or outputting the az command specified above.

Update - November 21, 2017

Watch this video from Ria Bhatia, a manager working for the ACI and ACI Connector. An excellent demonstration of the technologies we talked about.

Original: Deploying Windows Containers with Azure Container Instances (ACI) Connector for Kubernetes .