Using Docker in single-host environment with a minimal number of containers is relatively easy. However when scaling large number of containers across many different hosts things are not so simple anymore. Clustered Docker hosts present special management challenges that require a different set of tools. Next we will go through how Kontena leverages basic Docker usage and help orchestrating and scheduling Docker containers across multiple hosts.
Orchestration is a broad term that refers to container scheduling, cluster management, and provisioning of additional hosts.
Container scheduling refers to acts how the system will run and manage containers on Docker hosts throughout the cluster. One of the main duties of the scheduler is host selection. The user can optionally provide scheduling constraints, but the scheduler is responsible for executing on these requirements.
Cluster management is the process of controlling a group of hosts. This can involve adding and removing hosts from a cluster, getting information about the current state of hosts and containers, and starting and stopping services.
Kontena has a built-in advanced scheduler that takes care of running and managing service instances on multiple host nodes. With Kontena each service describes desired state that scheduler tries to match. This means that services will have automatic failover and rebalance when the cluster has changes that will affect services. Scheduler also understands difference between stateless and stateful services. Stateful service instances are not moved to another node.
With Kontena there are multiple ways the user can affect how the services should be scheduled. Those constraints and rules can be described with deployment strategies and scheduling conditions.
With Kontena the user can use different scheduling algorithms to order Kontena’s scheduler how service instances will be deployed to host nodes node. At the moment the following strategies are available:
High Availability (HA)
A service with ha strategy will deploy its instances to different host nodes. This means that the service instances will be spread across all nodes.
A service with daemon strategy will deploy given number of instances to all nodes. When a new node joins the grid, Kontena will deploy a new service instance automatically on it.
Service with random strategy will deploy service containers to host nodes randomly.
The user can also provide several conditions and rules to help Kontena’s scheduler to determine how and where to deploy service instances.
Wait for port
When a service has multiple instances and
wait_for_port definition, Kontena's scheduler will wait that container is responding to port before starting to deploy another instance. This way it is possible to achieve zero-downtime deploys.
The user can define the minimum number of healthy nodes that do not sacrifice overall service availability. Kontena will make sure, during the deploy process, that at any point of time this number of healthy instances are up.
When creating services, the user can direct the host(s) of where the containers should be launched based on scheduling rules.
An affinity condition is when Kontena is trying to find a field that matches given value. An anti-affinity condition is when Kontena is trying to find a field that does not match given value.
Kontena has the ability to compare values against node name, labels and service name.