Best practices – Azure IoT Edge deployments with Azure Kubernetes Service

Today I am talking about some best practices in regards of Azure IoT Edge deployments with Azure Kubernetes Service.

Just a short recap about the IoT Edge deployment options with Kubernetes. The connection between Kubernetes and the Azure IoT Hub is established via the IoT Edge Virtual Kubelet Provider. The IoT Edge VK Provider consists of two containers. The Virtual Kubelet that receives the Kubernetes YAML template file and hands it over to the Edge Provider. The Edge Provider translates the YAML template to the schema that the IoT Hub understands and sends the deployment template then to the IoT Hub.

So, the deployment takes place outside of Kubernetes and that is important to understand the best practices in this specific scenario.

Before going into the best practices look at my previous blog post, if you need more details about the scenario of managing IoT Edge deployments with AKS.

-> https://www.danielstechblog.io/deploy-arm-based-container-images-with-azure-kubernetes-service-on-your-azure-iot-edge-devices/

Since the deployment process lies outside of Kubernetes, we don’t need the default rolling update configuration for IoT Edge deployments. That said we can define maxSurge with 0 and maxUnavailable with 100% in our Kubernetes YAML template. This configuration ensures that the pods with the old configuration get delete first before the new ones are instantiated.

...
  strategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 100%
...

The Azure IoT Hub handles the IoT Edge deployments the same way when a new release is available. The Edge Agent on the edge device deletes the running containers first and then applies the new configuration.

Setting maxSurge to 0 and maxUnavailable to 100% also ensures that IoT Edge deployments are applied evenly across several connected IoT Hubs via different IoT Edge VK Providers. Having the values not set as mentioned above it can be that one IoT Edge VK Provider gets both pods deployed when replicas are defined in the Kubernetes YAML template file.

...
spec:
  replicas: 2
...

Another configuration parameter that ensures reliability and deployment speed is setting terminationGracePeriodSeconds for containers to 0.

...
    spec:
      containers:
      - name: tempsensor
        image: mcr.microsoft.com/azureiotedge-simulated-temperature-sensor:1.0
      - name: function
        image: xxx.azurecr.io/blink:0.0.2-arm32v7
      - name: streamanalytics
        image: mcr.microsoft.com/azure-stream-analytics/azureiotedge:1.0.0
      terminationGracePeriodSeconds: 0
...

Normally you would not do that in a Kubernetes deployment. Instead you would leave it at the default value to guarantee a smooth termination of the pod. But in the IoT Edge scenario a pod represents only a configuration object and not a real running pod with containers.

One last recommendation is to package your Kubernetes YAML templates for the IoT Edge deployment as Helm charts and use them for the deployment process.

Following the recommendations can improve the deployment experience of your IoT Edge deployments with Azure Kubernetes Service.

Facebooktwittergoogle_pluslinkedinmail