Mar 15, 2017
Amr Abdelrazik
D2iQ
5 min read
What is a Pod?
A Pod is a an abstraction introduced in DC/OS 1.9 for running applications in either Docker containers or Mesos Containers. A traditional (micro)service application consists of one container, replicated across many app instances. A Pod on the other hand may contain one or more containers, replicated across many app instances. A Pod on the other hand may contain one or more containers, replicated across many Pod instances. Containers in each Pod instance are guaranteed to be deployed, scaled and terminated together on the same host. They also share storage and networking namespace. Pods also ensures that if a container inside a pod instance fails or does not respond to a health check, the entire pod instance gets restarted or relocated to another node.
DC/OS and Marathon users have traditionally used service groups to manage multiple applications together. Service groups allows you to organize and manage multiple applications together. You can start, stop and scale all the application in a group as a single unit, while still being able to manage each application independently. Pods do not replace service groups, they add another abstraction for deploying applications that can also be used within a service group. So now you have the flexibility of building a service group that consists of a single container application and a multi-container pod at the same time.
Use Cases for Pods
There are 2 main use cases for Pods:
- Support Services (Side Car Containers)
- Migrating legacy applications to containers
Use Case 1: Support Services (Side Car Containers)
In some cases, organizations need to include additional containers alongside the main app for some support services. Some examples of these support services are client side proxies for SSL termination, customized service discovery, log transformation services and message queueing clients. Decoupling these support services into their independent containers allows organizations to easily re-use these support services across the organization and provides the flexibility to update each service independently between applications without worrying about version conflicts. So you can have one application with the latest version of an SSL proxy like nginx, and another one with a previous version of nginx without worrying about breaking functionality between applications.
Use Case 2 : Migrating legacy applications to containers
Another benefit of Pods is simplifying the migration of traditional, VM based Monolithic applications to containers. One of the biggest challenges of transitioning to containers is that many monolithic applications are supported by collocated services that make networking and storage assumptions, because they've always been on the same host. An example of such services are backups and monitoring agents , message queueing clients, and any of the support services mentioned above. As organizations try to migrate to containers, they realize that they can no longer guarantee some of the networking and storage assumptions about these supporting services, and that they many need to refactor their original application to migrate to containers. Such refactoring dramatically increases the time and the risk of migrating to containers, sometimes discouraging organizations from approaching containers altogether for their legacy applications.
Since applications in Pods can share the networking and storage namespace across instances, Pods can provide a useful transitional step as you start breaking down your application and transitioning applications from a monolithic architecture to containers.
Blueprint for migrating legacy applications to containers with Pods
Let's see how some organizations would approach a migration project with Pods:
- The first phase usually involves packaging your applications and the supporting services in containers — you can use Docker containers or your traditional binaries using Mesos containers. In this phase, your goal is to understand what dependencies and services your applications use and to understand the best way to package them in containers. This step can be done locally on your laptop with either Docker client tools or DC/OS Vagrant.
- The second phase is testing the application on DC/OS in a pod. Because your application sub-components can still communicate with each other via local network and shared file space, you have less risk in migration and fewer moving parts to manage, increasing your probability of success.
- The third phase is operationalizing the app on DC/OS. Since your application now runs in pods on DC/OS, you can start using some operational benefits and capabilities such as the ability to scale your Pods up and down and automatic app restart on failure. You can now enjoy more flexibility in updating your app and update some sub-components independently. For example, you can choose to update your log forwarder independent of your main application, or vice versa, without worrying about breaking compatibility with existing applications that are running on the server.
Managing Pods with DC/OS UI and CLI
Pods can be managed through the DC/OS UI and the CLI
The following pod-related commands are available via the CLI:
- dcos marathon pod add [<pod-resource>]
- dcos marathon pod list [--json]
- dcos marathon pod remove [--force] <pod-id>
- dcos marathon pod show <pod-id>
- dcos marathon pod update [--force] <pod-id>
Or you can even use the GUI to deploy and manage Pods
Summary of pod capabilities:
- Can have many instances of one or more containers.
- Co-located containers within a Pod instance together on the same agent node.
- Deploys, scales and terminates as one unit.
- Shares a network namespace and the same IP with all its containers.
- Shares storage space (sandbox and ephemeral local volumes).
- Conducts Pod-level health checks
- Restart entire pod when child containers crash or health checks fail.
- Secrets support [Enterprise DC/OS only]
Here are some of the things that will be coming in the future releases of Pods:
- Start order of containers within a Pod
- Bridge Mode networking support
For more details on the DC/OS 1.9 release, please read the release notes.
