Edge Conductor is a framework to create, manage and operate Kubernetes clusters for Internet of Things (IOT) workloads

  • By Intel Corporation
  • Last update: Oct 7, 2022
  • Comments: 0

Edge Conductor

Welcome to Edge Conductor

Intel Edge Conductor provides complete end-to-end manageability and infrastructure orchestration for all edges across various IoT verticals such as retail, health care, manufacturing, banking and entertainment. It is designed and built from ground up using modular microservices-based software stack focusing on heterogeneous needs of IoT verticals. The two main functional components are manageability and infrastructure orchestration. It also provides additional value-add such as policy engine, security, AI/ML capabilities, telemetry, automation and can interoperate with any Kubernetes distribution.

Contents of this guide

Edge Conductor Documentation

The following links will guide you through the Edge Conductor documents, including running a simple Get Started application and trying some tutorials.

Edge Conductor Deployment Models

Edge Conductor can be used to deploy Kubernetes clusters in several different ways. All of the deployment methods rely on a "Day-0" host machine, which is a dedicated system that runs the Edge Conductor tools that download, build and provision the required software. (Day-0 is a lifecycle term used in network automation and cloud deployment, where the high-level task on Day-0 is installation, Day-1 is configuration, and Day-2 is optimization. Here it indicates the host system used for installing the Edge Conductor tools.)

All Edge Conductor deployment methods also rely on a management console to operate and administer the cluster.

  • Virtual cluster: All nodes in the cluster are virtualized as container images and Kubernetes is deployed on the user’s local machine. The Day-0 host and management console are also the user's local machine. This deployment model is implemented using "kind" as described below.

  • On-premise cluster: All nodes in the cluster are actual physical (or virtual) machines. The Day-0 and management console functions are performed on machine(s) outside the cluster. This deployment model is implemented using either Rancher RKE or the Cluster API as described below.

  • Existing cluster: All nodes in the cluster have already been provisioned and are running Kubernetes, for example as in a StarlingX, VMWare Tanzu or OpenShift cluster or similar Kubernetes deployment. In this model only services are deployed and managed by the Edge Conductor tools. The Day-0 machine and management cluster are assumed to already exist.

Download and Build Edge Conductor Code

  1. Get the code using one of the following methods:

    • Get the code from git repo:

      git clone https://github.com/intel/edge-conductor.git edge-conductor
    • Unzip the code package, for example, edge_conductor_<version>.tar.gz:

      tar zxvf edge_conductor_<version>.tar.gz
      ln -sf edge_conductor_<version> edge-conductor
  2. Build the code:

    cd edge-conductor

    You will see output similar to:

    make -C api/schemas
    make -C api/proto build
    go mod tidy
    go run build/plugingenerator.go
    go vet ./pkg/... ./cmd/...
    Going to format and build code.
    go build -v -o _workspace/bin/conductor cmd/conductor/main.go

    If make is successful, no ERROR messages are displayed on the console.

    With the make command, binary files are generated under _workspace folder and configuration files are also copied to _workspace.

  3. Change to the _workspace directory, which is created after make completes:

    cd _workspace

    The file structure generated under the _workspace folder is:

    ├── bin
    ├── config
    ├── experienceKit
    ├── conductor -> bin/conductor
    ├── kubectl -> bin/kubectl
    └── workflow

Run ./conductor help to see command line usage.

Refer to Get Started to continue with common tasks such as deploying a target cluster, deploying services on the target cluster, and stopping Edge Conductor services.

HW Requirements for Edge Conductor Day-0 Host

The Day-0 host should meet the following minimal hardware requirements:

  • CPU: 2 or more cores
  • Memory: 2 gigabytes (GB) or greater.
  • Storage: 10 GB or greater available storage is required to build and run the Day-0 environment.
  • Internet connection: Internet connectivity is necessary to download and use some features.

Node Requirements:

  • CPU: 2 or more cores
  • Memory: 2 gigabytes (GB) or greater.
  • Storage: 10 GB or greater available storage is required to build and run the Day-0 environment.
  • Internet connection: Internet connectivity is necessary to download and use some features.

OS and System Requirements for Edge Conductor Day-0 Host

  • Ubuntu 18.04+
  • make 4.1+
  • unzip 2.11+
  • DockerCE
    • 20.10.3+ (for DockerCE v20)
    • After you install DockerCE, configure a user group so you can use Docker without the sudo command. For details, follow Post-installation steps for Linux.
  • git 2.33.0+
  • sudo

Additional software:

Proxy setup:

  • Be sure to set your proxies correctly. Some environments require network proxies for Docker operations (e.g. docker pull, docker push, docker run, and so on).
  • For http_proxy/HTTP_PROXY and https_proxy/HTTPS_PROXY, you must test they are actually working. Also note that the no_proxy/NO_PROXY list MUST NOT contain spaces between the addresses.


Frequently asked questions.

How do I access the Portainer Web UI on KIND cluster?

The latest KIND release doesn't support LoadBalancer, so the External-IP for the Portainer service Web UI will always be pending as shown below:

$ kubectl get pod,svc -n portainer
NAME                            READY   STATUS    RESTARTS   AGE
pod/portainer-fc654c454-g4qvl   1/1     Running   26         3h26m

NAME                TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                         AGE
service/portainer   LoadBalancer   <pending>     9000:31343/TCP,8000:32344/TCP   3h26m

To access the Portainer service in this situation, use the kubectl port-forward command to forward a local port to Portainer service port 9000, which is used for the Web UI.

For example, the following command will forward the access request from localhost 5990 port to Portainer service at 9000:

$ kubectl port-forward -n portainer service/portainer 5990:9000
Forwarding from -> 9000

When the port-forwarding is running (shown by the log message Forwarding from ...), you can access the to visit the Portainer web UI and create the initial admin account.

NOTE: If there's no client accessing the forwarded port for a while (50 seconds), the port-forwarding will stop automatically.

NOTE: If you do not create your admin account in 5 minutes after the service is launched, then the Portainer service will restart itself automatically. (See the Portainer issue reported here: portainer/portainer#2475)

Copyright (C) 2022 Intel Corporation

SPDX-License-Identifier: Apache-2.0