EdgeX Foundry in a Kanto environment

[malavikaiplon]

Hi EdgeX community 👋,

I’m trying to run EdgeX Foundry in a Kanto environment, but I’m facing issues where the EdgeX services are not starting / not running as expected.

I’d like to understand:

Is EdgeX officially supported on Kanto (or are there known limitations)?

Are there any specific configurations, container runtime settings, or deployment patterns required to make EdgeX run successfully in Kanto?

Has anyone here successfully deployed EdgeX on Kanto, and if so, could you share the approach or references?

Any guidance, documentation, or pointers would be really helpful.
Thanks in advance!

[cloudxxx8]

No, we don't support Kanto officially.
I don't have any knowledge about this environment. Please share your test result to the community.

[malavikaiplon]

Dear @cloudxxx8

While deploying and managing the EdgeX services using Eclipse Kanto (kanto-cm) on the iotdin-imx8p (i.MX8 Plus ARM64) platform, we faced multiple issues affecting reliability and repeatability of the deployment:

Containers stuck in Created state

Several EdgeX containers were created successfully but did not transition into Running.

This resulted in partial stack deployment.

Inconsistent container lifecycle state

Some containers remained indefinitely in Created state.

A few containers moved to Stopped unexpectedly after creation.

Unexpected container termination / non-zero exit

Certain workloads stopped automatically after launch.

Example: Node-RED container stopped with exit code 143 (SIGTERM), indicating unexpected termination.

Service dependency chain not coming up fully

Since EdgeX has strict dependencies (Consul/Redis → Core services → Device/App services), failure of base services prevented the remaining containers from starting correctly.

This caused the overall EdgeX stack to remain incomplete.

Inter-container networking / service discovery issues

Even when some containers were running, communication between containers was unreliable.

Containers were not consistently able to resolve or reach dependent services (example: core services failing to connect to Consul/Redis/MQTT broker).

This indicates possible issues with the Kanto container networking layer / bridge setup / DNS/service name resolution across containers.

Repeated deployments accumulate old containers

On redeployment attempts, older container instances remained and mixed with newly created containers.

This increased troubleshooting complexity and sometimes caused name/service conflicts.

Manual intervention required for stable redeployment

To recover to a clean working state, manual intervention was required frequently.

Without this, redeployments were not consistent and led to repeated failures.

Request your guidance on best practices for:

handling containers stuck in Created state,

improving inter-container networking reliability (DNS/service discovery),

and ensuring consistent clean redeployments for EdgeX stacks on ARM64 using Eclipse Kanto.

Thanks.

[cloudxxx8]

This is a common issue of microservice deployment in the container environment, and we wrote a bootstrapping service resolve this.
Please see the ADR:
https://docs.edgexfoundry.org/4.0/design/adr/security/0009-Secure-Bootstrapping/

and refer to the docker compse setting:
https://github.com/edgexfoundry/edgex-compose/blob/v4.0.1/docker-compose.yml

We overwride the entrypoint in all the services with a script in /edgex-init folder