Reading Time: 2 minutes
A container orchestrator schedules, runs, and supervises containerized application processes, usually across a cluster of hosts. Orchestrators usually provide a way to run applications as long lived services as well as ephemeral jobs. Services model applications where some number of instances should always be running such as a web application or api servicing http requests in an ecommerce application. Jobs model application processes triggered by an event that requires some processing and runs to completion such as a nightly batch job or an ad-hoc data analysis.
Logically, most container orchestrators and clusters look like this in late 2019, container cluster nodes are in light green:
Containerized applications are usually modeled by declaring the application’s components in a configuration file. This file is often referred to as an application deployment descriptor and it is specific to the orchestrator. The container image format and runtime is almost always provided by Docker.
The orchestrator is responsible for:
- interpreting the application deployment descriptor to determine what services or jobs need to be run
- scheduling the desired number of application’s containers onto the cluster’s hosts
- running the containers on the cluster’s hosts
- supervising the application containers by checking their health, restarting, or rescheduling as appropriate
- deploying updates to the application when the application definition is updated
The scheduling, supervising, and deploying responsibilities are the core tricky bits. The scheduling responsibility is particularly important to avoiding problems with noisy neighbors and worker node resource exhaustion.
Container orchestrators schedule containers by finding a worker node that can run a given application container that satisfies the:
- container’s declared resource requirements for memory, cpu, I/O, etc
- container’s declared affinity/anti-affinity constraints for running on a particular node, i.e. the container must run in a particular security zone
- the cluster or service’s policy for spreading and/or packing container hosts to balance availability and utilization
When the orchestrator does not have good information about what resources an application needs, the critical scheduling process will be ineffective. Orchestrators do not magically infer who much resources your application containers need.
The orchestrator may also:
- advertise or integrate those containers with higher-level network infrastructure such as load balancers, api gateways, DNS, or service discovery mechanisms
- collect and publish application resource usage metrics
- collect and publish orchestrator process and resource usage metrics
- collect and publish application logs to a centralized store
- auto scale the containers backing a service up or down in response to load
Network integration, log publishing, and auto scaling also tend to be tricky bits.
There are a number of container orchestrators available in the market, including: simple custom solutions, Hashicorp Nomad, Docker Swarm, Amazon Elastic Container Services, Kubernetes, and Pivotal CloudFoundry.
The way container orchestrators integrate with collaborating systems for deployment, networking, observability, and more varies widely. There may even be significant differences between releases of “the same” orchestrator as orchestrator APIs evolve or when that orchestrator runs on one set of infrastructure or another (particularly Kubernetes). These differences matter a lot as they result in work for compute platform, release, and other service provider roles.
The next posts will describe how these container orchestrators differ and try to help you understand which ones might be best for you and your own application compute platform strategy.
Update – Here are the follow-up posts in this series on container orchestrators:
- Container orchestrators are the same but different, Docker Swarm
- What is different about Elastic Container Service (ECS)
- What is different about Kubernetes
- Choose Container Orchestrators Strategically
Stephen
#NoDrama
