What’s In an Orchestrator? What Orchestrators Are and What They Aren’t
Container orchestrators such as Kubernetes and Swarm are a core component of production Docker environments. Understanding what an orchestrator is designed to help you do—and what they aren’t designed to do—is crucial for using orchestrators effectively.
Orchestrators existed before containers came along. But the rise of Docker fed newfound interest in orchestration because orchestrators are essential for scaling within a containerized environment.
This is because orchestrators automate processes that would often be impossible for human admins to perform by hand. Without orchestration tools, you would not be able to create a large-scale environment with containers spinning up and down constantly.
That’s container orchestrators in a nutshell. Now, let’s take a more specific look at what orchestrators do and don’t do.
What Container Orchestrators Do
Modern container orchestrators—Kubernetes, Swarm and Marathon, for example—perform the following tasks:
- Starting and stopping individual containers in order to ensure the availability of a service or application.
- Balancing loads between different nodes in your infrastructure to keep traffic flowing smoothly.
- Making storage systems available to services within your container environment.
- Managing secrets and authentication.
- Providing automated service discovery for your containerized application.
- Providing self-healing by detecting some types of failures and restarting or moving workloads in response.
The specific functionality of orchestrators varies depending on which one you use, of course. But in general, they all do the above.
What Container Orchestrators Don’t Do
Perhaps more important than understanding what orchestrators do is recognizing their limitations. Orchestrators are not designed to be your main solution for the following:
- Security. While orchestrators can help automate authentication and secrets management, they aren’t security tools. They don’t do anomaly detection or attempt to prevent exploits.
- Monitoring. Orchestrators do basic monitoring of a containerized environment in order to detect problems related to load balancing or failing nodes. But they’re not an all-around monitoring solution. They don’t provide detailed visibility into your environment or help you to understand complex performance problems.
- PaaS. Orchestrators are not complete PaaS platforms. They don’t provide all of the functionality you need to build, deploy and manage an application. In other words, Kubernetes is not Heroku.
- Storage systems. While orchestrators can mount storage systems for your containerized services to use, orchestrators themselves don’t provide persistent storage. You need to configure that separately.
- Image registries. Container image registries are separate components of your software stack. The orchestrator doesn’t provide image hosting.
- Container engines. Last but not least, don’t confuse the orchestrator with the engine that actually runs your containers. You still need Docker or another container engine installed if you want to run containers. Kubernetes, Swarm and other orchestrators manage your containers by starting, stopping and load-balancing them, but they don’t create the actual containers.
Conclusion
The simplest way to understand orchestrators is to think about them as provisioning tools. Allocating and managing resources within your infrastructure is their main job.
That’s a hugely important job, but it’s not the only task that matters. A healthy container environment needs to include much more than just an orchestrator, and you should not try to use your orchestrator to cover areas (like monitoring and security) that it was not designed to handle in any type of sophisticated way.
