Skip to content

Aembit provides different deployment options that you can use to deploy Aembit Edge Components in your environment. Each of these options provides similar features and functionality. The steps for each of these options, however, are specific to the deployment option you select.

This page describes the process to deploy Aembit Edge Components to Kubernetes cluster using Helm.

To deploy Aembit Edge Components to your Kubernetes cluster, you must follow these steps:

  1. Prepare Edge Components
  2. Add and install the Aembit Edge Helm chart
  3. Annotate Client Workloads
  4. Optional configurations

You also have the option to upgrade the Aembit Edge Helm chart.
To further customize your deployments, see the available optional configurations.

  1. Make sure you run all commands from your local terminal with kubectl configured for your cluster.

  2. Verify that you have set your current context in Kubernetes correctly:

    Terminal window
    kubectl config current-context

    If the context output is incorrect, set it correctly by running:

    Terminal window
    kubectl config use-context <your-cluster-context>
  1. Log into your Aembit Tenant and go to Edge Components -> Deploy Aembit Edge.

  2. In the Prepare Edge Components section, create a new Agent Controller or select an existing one.

    Deploy Aembit Edge Page

  3. If the Agent Controller you selected does have a Trust Provider configured, skip ahead to the next section.

    Otherwise, click Generate Code.

    This creates a temporary <Device_Code> that Aembit uses to authorize your Agent Controller.

Follow the steps in the Install Aembit Edge Helm Chart section:

  1. Add the Aembit Helm repository to your local Helm configuration by running:

    Terminal window
    helm repo add aembit https://helm.aembit.io
  2. Install the Aembit Helm chart by running the following command, making sure to replace:

    • <Tenant_Id> with your tenant ID (Find this in the Aembit website URL: <Tenant_ID>.aembit.io)

    • <Device_Code> with the code you generated in the Aembit web UI if your Agent Controller doesn’t have a Trust Provider configured

    Also, this is the time to add extra Helm configurations options to the installation that fit your needs.

    Terminal window
    helm install aembit aembit/aembit \
    -n aembit \
    --create-namespace \
    --set tenant=<Tenant_Id>,agentController.DeviceCode=<Device_Code>

For Aembit Edge to manage your client workloads, you must annotate them with aembit.io/agent-inject: "enabled" so that the Aembit Agent Proxy can intercept network requests from them.

To add this annotation to your client workloads, you can:

  • Modify your client workload’s Helm chart by adding the following annotation in the deployment template and applying the changes:

    template:
    metadata:
    annotations:
    aembit.io/agent-inject: "enabled"
  • If using ArgoCD, update your GitOps repository with the annotation and sync the changes.

  • Directly modify your deployment YAML files to include the annotation in the pod template metadata section and applying your changes:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
    name: your-application
    spec:
    template:
    metadata:
    annotations:
    aembit.io/agent-inject: "enabled"

To stay up to date with the latest features and improvements, follow these steps to update and upgrade the Aembit Edge Helm chart:

  1. From your local terminal with kubectl configured for your cluster, update the Aembit Helm chart repo:

    Terminal window
    helm repo update aembit
  2. Upgrade the Helm chart:

    Terminal window
    helm upgrade aembit aembit/aembit -n aembit

The following sections contain optional configurations that you can use to customize your Kubernetes deployments.

For Kubernetes versions 1.29 and higher, Aembit supports init-container-based Client Workloads. This starts the Agent Proxy as part of the init containers.

To enable native sidecar configurations, do the following:

  1. Make sure you add the required Client Workload annotation.

  2. Set the Helm chart value agentProxy.nativeSidecar=true during chart installation by adding the following flag:

    Terminal window
    --set agentProxy.nativeSidecar=true

The Edge Components you deploy as part of this process have environment variables that you can configure to customize your deployment further. See Edge Component environment variables reference, for all available configuration options.

The Aembit Helm Chart includes configurations that control the behavior of Aembit Edge Components (both Agent Controller and Agent Proxy). See Helm chart config options, for all available configuration options.

To deploy a Resource Set using Kubernetes, you need to add the aembit.io/resource-set-id annotation to your Client Workload deployment and specifying the proper Resource Set ID. For example:

Terminal window
aembit.io/resource-set-id: f251f0c5-5681-42f0-a374-fef98d9a5005

Once you add the annotation, the Aembit Edge injects this Resource Set ID into the Agent Proxy. This configuration enables the Agent Proxy to support Client Workloads in this Resource Set.

For more information, see Resource Sets overview.

Delaying pod startup until Agent Proxy has registered

Section titled “Delaying pod startup until Agent Proxy has registered”

By default, Agent Proxy allows Client Workload pods to enter the Running state as soon as proxying ports become available, even if registration with Aembit Cloud isn’t yet complete. While in this pre-registration state, Agent Proxy operates in Passthrough mode and can’t inject credentials into Client Workloads. As a result, you may have to retry application requests.

To delay the Client Workload pod startup until registration completes, set the AEMBIT_PASS_THROUGH_TRAFFIC_BEFORE_REGISTRATION Agent Proxy environment variable to false.

This causes the postStart lifecycle hook to wait until Agent Proxy has registered with the Aembit Cloud service before entering the Running state.

If registration fails to complete within 120 seconds (due to misconfiguration or connectivity issues) the pod fails to start and eventually enters a CrashBackOff state. To override how long the Client Workload pods wait during postStart, set the Agent Proxy AEMBIT_POST_START_MAX_WAIT_SEC environment variable to specify the maximum wait time in seconds.

Important limitation

Due to a known Kubernetes issue, pod deletion doesn’t correctly interrupt the postStart hook. As a result, deleting a pod that’s waiting for Agent Proxy registration takes the full AEMBIT_POST_START_MAX_WAIT_SEC duration, even if you’ve set the pod’s terminationGracePeriodSeconds to a lower value.

See Edge Component environment variables reference, for a description of the AEMBIT_PASS_THROUGH_TRAFFIC_BEFORE_REGISTRATION and AEMBIT_POST_START_MAX_WAIT_SEC configuration options.