December 5, 2017 at 09:00

Deploy Windows containers on Azure Container Instances (ACI). Connector for Kubernetes

Original author: Anthony Chu
  • Transfer
  • Tutorial


Azure Container Instances (ACIs) let you run containers without worrying about infrastructure. We can give an image of the container, and ACI will happily launch the container and even provide it with an external IP address. When manual intervention is only necessary when starting containers, 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 running containers. We can think of it as a VM (virtual machine), but instead of launching a virtual machine image, it launches a container image.


One interesting example of how ACI can be used in conjunction with a container band 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 power. We can plan the launch of pods on them, but in fact they will run as groups of containers in ACI.


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


Windows container support was recently added to the ACI Connector for Kubernetes, and today we’ll look at how to use the ACI Connector to run Windows containers.


Configure Azure Container Service for Kubernetes Cluster (AKS)


Creating a Kubernetes managed cluster in Azure using AKS is incredibly simple. 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 eastusand the Kubernetes version 1.8.2.
Once the cluster is ready, we can use the Azure CLI to install the latest Kubernetes ( kubectl) CLI 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 ACI resources will be deployed:


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

Note the identifier of the new resource group.


Primary Service Creation


Then you need to create the primary service, which 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 in the resource group. To create a primary service and assign roles to it, we run the following command using the full resource group identifier in the previous step:


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

Note the return values ​​of the properties appId, passwordand tenant.


Install ACI Connector


The ACI connector is available as an image on the Docker Hub . To get Windows support, you need to use the canary assembly. Create the following file aci-connector.yaml. It defines deploymentKubernetes with one container, which starts the container from the image 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: 
        - name: AZURE_CLIENT_KEY
          value: 
        - name: AZURE_TENANT_ID
          value: 
        - name: AZURE_SUBSCRIPTION_ID
          value: 
        - name: ACI_RESOURCE_GROUP
          value: antchu-aci-temp

Replace the environment variables with the values ​​obtained from previous commands. Then create deploymentin Kubernetes:


$ kubectl create -f aci-connector.yaml

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


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

Planning to launch containers on aci-connector-0will launch Linux containers; aci-connector-1will run windows containers.


To prevent Kubernetes from accidentally loading pods on them, an ACI connector has been added for the nodes 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:              
Labels:             beta.kubernetes.io/os=1
Annotations:        node.alpha.kubernetes.io/ttl=0
Taints:             azure.com/aci:NoSchedule
…

We plan to launch a Windows container on ACI


Create a file iis-pod.yamlwith the following contents. It describes a single container that displays the contents of a Windows container 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

Please note: we explicitly tell Kubernetes that this under should be run on a node with a name 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 hearths, 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 download the image and run it. There is currently an error in the ACI connector: it will show under in state «Running», even if under is still being created. We should 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 state changes to «Succeeded», we can go to the IP address of the container. You can get IP through the execution kubectl get -o wideor output of the command azindicated above.



Update - November 21, 2017


Check out this video from Ria Bhatia, ACI and ACI Connector Manager. A great demonstration of the technologies we talked about.




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

Tags:

Also popular now: