Endless capacity node for Kubernetes
A few months ago, I told you about the release of the new Azure Container Instance Service (Azure Container Instances, ACI), which makes it as easy as possible to deploy containers. Today we will talk about the connector Azure Container Instances for Kubernetes, which allows you to deploy instances of the Azure Container service in clusters Kubernetes.
This connector is experimental and should not be used for real projects.
1. Containers for rapid deployment .
2. DevOps with Kubernetes and VSTS. Part 1: Local history.
3. DevOps with Kubernetes and VSTS. Part 2: Cloud history.
4. A node with infinite capacity for Kubernetes.
')
This approach allows you to almost instantly allocate the necessary resources to the cluster, eliminating the administrator from having to manage the VM infrastructure and allowing him to continue to use the Kubernetes API. In a Kubernetes cluster, you can simultaneously use virtual machines and container instances, thereby taking advantage of both technologies.
Roughly speaking, the ACI Connector connector mimics the Kubelet interface as follows:
After the connector is registered as a node with the name aci-connector, you can specify nodeName: aci-connector in the hearth configuration to launch it through the Azure Container Instances service. Pods, in the configuration of which this node is not specified, are started according to the schedule in the normal mode. Below are instructions for using the ACI Connector and the Kubernetes scheduler using restrictions and tolerances (taints and tolerations) .
In addition to the examples , the following Kubernetes functions are currently supported if they are defined in the hearth manifest. As the aci-connector connector expands, this list will change.
The following Kubernetes functions are currently not supported by the aci-connector connector:
The ACI Connector will create each container instance in the specified resource group. A new resource group can be created with the following command:
Edit examples / aci-connector.yaml and specify the name of the resource group in the ACI_RESOURCE_GROUP environment variable.
The Service Principal is required to create resources in your Azure subscription using the ACI Connector. You can create a Service Principal using the Azure CLI in accordance with the instructions below.
Find a subscriptionId using the Azure CLI:
Using az, create a service principal that will operate on your subscription:
Edit the examples / aci-connector.yaml file and enter the environment variables using the above values:
If the supplier is not registered, register it using the command:
First, specify values in the values.yaml file located in the / charts / aci-connector directory.
Then you can set the chart:
Values can also be set from the command line, with all the values specified in the values.yaml file being overwritten:
Notice that under deployed on the node aci-connector. Now it should be available through the specified public IP address.
In the example in nginx-pod, the hostname is hard coded, but you can also use the Kubernetes scheduler.
The aci virtual node has a limit (taint) (azure.com/aci) with a default NoSchedule effect. This means that the defaults do not run on the aci node unless they are explicitly placed there.
However, the Kubernetes scheduler may include a sub, which tolerates this restriction, in the schedule for the aci node.
Reference to the example of the hearth with this tolerance.
Using this hearth is easy:
Note that if there are other nodes in your cluster, this one is not necessarily placed in the Azure Container Instances service.
To force the deployment of Azure Container instances under the service, you can explicitly specify NodeName, as in the first example, or you can delete all other nodes in the cluster with the command kubectl delete nodes <node name>. The third option is to deploy other workloads in a cluster; in this case, the scheduler will be required to schedule your task through the Azure Container Instance Service API.
Canary assemblies are connector versions that are periodically created from the main branch. Since these assemblies are not official releases, their stability is not guaranteed, but they allow you to test the latest features.
To use the latest version of Canary, you can install the update package for your aci-connector connector and update the container tag using the following command:
This connector is experimental and should not be used for real projects.
A series of articles "We are talking about containers":
1. Containers for rapid deployment .
2. DevOps with Kubernetes and VSTS. Part 1: Local history.
3. DevOps with Kubernetes and VSTS. Part 2: Cloud history.
4. A node with infinite capacity for Kubernetes.
')
This approach allows you to almost instantly allocate the necessary resources to the cluster, eliminating the administrator from having to manage the VM infrastructure and allowing him to continue to use the Kubernetes API. In a Kubernetes cluster, you can simultaneously use virtual machines and container instances, thereby taking advantage of both technologies.
Work principles
Roughly speaking, the ACI Connector connector mimics the Kubelet interface as follows:
- registers with Kubernetes as a node with unlimited resources;
- sends pods to execution by the Azure Container instances service instead of the nodes on the virtual machines.
After the connector is registered as a node with the name aci-connector, you can specify nodeName: aci-connector in the hearth configuration to launch it through the Azure Container Instances service. Pods, in the configuration of which this node is not specified, are started according to the schedule in the normal mode. Below are instructions for using the ACI Connector and the Kubernetes scheduler using restrictions and tolerances (taints and tolerations) .
Requirements
- Running the az command line client - install Azure CLI 2.0 .
- Kubernetes cluster with a working kubectl - configure Kubernetes cluster in Azure .
Current opportunities
In addition to the examples , the following Kubernetes functions are currently supported if they are defined in the hearth manifest. As the aci-connector connector expands, this list will change.
- Environment Variables
- Teams
- ImagePullSecret
- Azure Files Shared as volumes
Current restrictions
The following Kubernetes functions are currently not supported by the aci-connector connector:
- ConfigMaps
- Secrets
- ServiceAccounts
- Volumes
- kubectl logs
- kubectl exec
How to quickly try
- Edit the examples / aci-connector.yaml file and specify the environment variables.
- Start the ACI Connector with the command kubectl create -f examples / aci-connector.yaml.
- Wait for the kubectl get nodes command to display the aci-connector node.
- Run under NGINX via ACI with the command kubectl create -f examples / nginx-pod.yaml.
- Open under NGINX using its public address.
Step-by-step instruction
Create a resource group
The ACI Connector will create each container instance in the specified resource group. A new resource group can be created with the following command:
$ az group create -n aci-test -l westus { "id": "/subscriptions/<subscriptionId>/resourceGroups/aci-test", "location": "westus", "managedBy": null, "name": "aci-test", "properties": { "provisioningState": "Succeeded" }, "tags": null } Edit examples / aci-connector.yaml and specify the name of the resource group in the ACI_RESOURCE_GROUP environment variable.
Create a Service Principal
The Service Principal is required to create resources in your Azure subscription using the ACI Connector. You can create a Service Principal using the Azure CLI in accordance with the instructions below.
Find a subscriptionId using the Azure CLI:
$ az account list -o table Name CloudName SubscriptionId State IsDefault ----------------------------------------------- ----------- ------------------------------------ ------- ----------- Pay-As-You-Go AzureCloud 12345678-9012-3456-7890-123456789012 Enabled True Using az, create a service principal that will operate on your subscription:
$ az ad sp create-for-rbac --role=Contributor --scopes /subscriptions/<subscriptionId>/ { "appId": "<redacted>", "displayName": "azure-cli-2017-07-19-19-13-19", "name": "http://azure-cli-2017-07-19-19-13-19", "password": "<redacted>", "tenant": "<redacted>" } Edit the examples / aci-connector.yaml file and enter the environment variables using the above values:
- AZURE_CLIENT_ID: enter the application identifier appId.
- AZURE_CLIENT_KEY: enter the password.
- AZURE_TENANT_ID: specify the tenant.
- AZURE_SUBSCRIPTION_ID: Enter subscriptionId for subscription id.
Make sure the Microsoft.ContainerInstance provider is registered
$ az provider list -o table | grep ContainerInstance Microsoft.ContainerInstance NotRegistered If the supplier is not registered, register it using the command:
$ az provider register -n Microsoft.ContainerInstance $ az provider list -o table | grep ContainerInstance Microsoft.ContainerInstance Registered Install the ACI Connector
$ kubectl create -f examples/aci-connector.yaml deployment "aci-connector" created $ kubectl get nodes -w NAME STATUS AGE VERSION aci-connector Ready 3s 1.6.6 k8s-agentpool1-31868821-0 Ready 5d v1.7.0 k8s-agentpool1-31868821-1 Ready 5d v1.7.0 k8s-agentpool1-31868821-2 Ready 5d v1.7.0 k8s-master-31868821-0 Ready,SchedulingDisabled 5d v1.7.0 Install the ACI Connector with Helm (optional)
First, specify values in the values.yaml file located in the / charts / aci-connector directory.
Then you can set the chart:
$ helm install --name my-release ./charts/aci-connector Values can also be set from the command line, with all the values specified in the values.yaml file being overwritten:
$ helm install --name my-release --set env.azureClientId=YOUR-AZURECLIENTID,env.azureClientKey=YOUR-AZURECLIENTKEY,env.azureTenantId=YOUR-AZURETENANTID,env.azureSubscriptionId=YOUR-AZURESUBSCRIPTIONID,env.aciResourceGroup=YOUR-ACIRESOURCEGROUP,env.aciRegion=YOUR-ACI-REGION ./charts/aci-connector Install the NGINX example
$ kubectl create -f examples/nginx-pod.yaml pod "nginx" created $ kubectl get po -w -o wide NAME READY STATUS RESTARTS AGE IP NODE aci-connector-3396840456-v75q2 1/1 Running 0 44s 10.244.2.21 k8s-agentpool1-31868821-2 nginx 1/1 Running 0 31s 13.88.27.150 aci-connector Notice that under deployed on the node aci-connector. Now it should be available through the specified public IP address.
Using the Kubernetes Scheduler
In the example in nginx-pod, the hostname is hard coded, but you can also use the Kubernetes scheduler.
The aci virtual node has a limit (taint) (azure.com/aci) with a default NoSchedule effect. This means that the defaults do not run on the aci node unless they are explicitly placed there.
However, the Kubernetes scheduler may include a sub, which tolerates this restriction, in the schedule for the aci node.
Reference to the example of the hearth with this tolerance.
Using this hearth is easy:
$ kubectl create -f examples/nginx-pod-tolerations.yaml Note that if there are other nodes in your cluster, this one is not necessarily placed in the Azure Container Instances service.
To force the deployment of Azure Container instances under the service, you can explicitly specify NodeName, as in the first example, or you can delete all other nodes in the cluster with the command kubectl delete nodes <node name>. The third option is to deploy other workloads in a cluster; in this case, the scheduler will be required to schedule your task through the Azure Container Instance Service API.
Canary build usage
Canary assemblies are connector versions that are periodically created from the main branch. Since these assemblies are not official releases, their stability is not guaranteed, but they allow you to test the latest features.
To use the latest version of Canary, you can install the update package for your aci-connector connector and update the container tag using the following command:
$ kubectl set image deploy/aci-connector aci-connector=microsoft/aci-connector-k8s:canary Source: https://habr.com/ru/post/338686/
All Articles