The orchestration of containers is where the hard part comes in. If an application was designed to use containers as a large monolithic stack that performs all the tasks required for the subsystem to execute, then deploying those containers becomes a pretty easy task. However, this also defeats the purpose of using containers and microservices, which is to decouple the components into small services that interact with each other or other services. As a subsystem is broken down into many separate primitive microservices, the ability to coordinate those services, made up of one or many containers, becomes very difficult. Some services will be relatively small and will only be used sparingly, while others will be very high volume and require strict scaling and high availability configurations In addition, the deployment of new containers to the cluster is critical and usually needs to be done with little or no downtime, making a service that performs those updates very valuable.

There are many types of container orchestration tools on the market, and each cloud vendor will have one or more managed versions, or an organization can choose to set up and maintain their own orchestration tools, depending on their requirements. One of the most popular orchestration services is Kubernetes, which can run on any cloud platform, on-premises, or a hybrid of both. There are reasons to use a cloud vendor's container orchestration service over a third-party tool, most notably the native interaction of the containers and other cloud services provided by the vendor. However, even now cloud vendors are deploying their own managed Kubernetes services as well. Here are some of the key concepts from a Kubernetes deployment:

• Kubernetes master: This is responsible for maintaining the desired state for your cluster.
• Kubernetes node: Nodes are the machines (VMs, physical servers, and so on) that run your applications and cloud workflows. The Kubernetes Master controls each node; you'll rarely interact with nodes directly.
• Pod: This is the basic building block of Kubernetes; the smallest and simplest unit in the Kubernetes object model that you create or deploy. A pod represents a running process on your cluster.
• Service: An abstraction that defines a logical set of pods and a policy by which to access them, sometimes called a microservice.
• Replica controllers and ReplicaSets: These ensure that a specified number of pod replicas are running at any one time. In other words, they make sure that a pod or a homogeneous set of pods is always up and available.
• Deployment: Provides declarative updates for pods and ReplicaSets.
• DaemonSet: Ensures that all (or some) nodes run a copy of a pod. As nodes are added to the cluster, pods are added to them. As nodes are removed from the cluster, those pods are garbage collected. Deleting a DaemonSet will clean up the pods it created.