I’m not sure I agree that those tools can handle concerns like autoscaling, A/B or Blue/Green deployments out of the box. Are they even strictly speaking orchestration tools anyway? My understanding is that they are configuration management tools, where part of your configuration is the state of your deployment environment (what tools are installed, etc.). Orchestration implies constant awareness of the environments current state, and reacting to both that state and external events (shifting load around, spinning up new instances, replacing crashed instances, scaling instances, etc.). That said, containers don’t necessarily help or hurt you with any of the above. Releases don’t solve any of those problems, but they aren’t meant to anyway.

Most likely if you need to deploy service on orchestration platform like Kubernetes you need to pack it with container. Kubernetes automatically deploy services when needed or when service die.
AWS has https://aws.amazon.com/ecs/
Google has https://cloud.google.com/container-engine/
But I don’t have any experience with this.

Clustering Elixir nodes on Kubernetes

Simplest version is to hit the AWS EC2 API when you deploy and get a list of relevant instances. Use that to populate the hosts list.

We package our projects in a Docker containers, push them to Docker Hub and then deploy them to Kubernetes cluster. Cluster itself can be scaled via k8s Horizontal Pod Autoscaler combined with AWS AutoScaling Groups.

Also we have some sort of generator for our projects, you can use it to extract configuration samples: Nebo15/renew.