unit of scheduling, deployment, and runtime isolation for a group of containers. All containers in a Pod are always scheduled to the same host, deployed together whether for scaling or host migration purposes, and can also share filesystem, networking, and process namespaces. This joint lifecycle allows the containers in a Pod to interact with each other over the filesystem or through networking via localhost or host inter‐ process communication mechanisms if desired (for performance reasons, for example). As you can see in Figure 1-2, at the development and build time, a microservice cor‐ responds to a container image that one team develops and releases. But at runtime, a microservice is represented by a Pod, which is the unit of deployment, placement, and scaling. The only way to run a container—whether for scale or migration—is through the Pod abstraction. Sometimes a Pod contains more than one container. One such example is when a containerized microservice uses a helper container at runtime, as Chapter 15,  Sidecar  demonstrates later. Containers and Pods and their unique characteristics offer a new set of patterns and principles for designing microservices-based applications. We looked at some of the characteristics of well-designed containers; now let’s look at some of the characteris‐ tics of a Pod: • A Pod is the atomic unit of scheduling. That means the scheduler tries to find a host that satisfies the requirements of all containers that belong to the Pod (there are some specifics around init containers, which we cover in Chapter 14,  Init Container ). If you create a Pod with many containers, the scheduler needs to find a host that has enough resources to satisfy all container demands combined. This scheduling process is described in Chapter 6,  Automated Placement . • A Pod ensures colocation of containers. Thanks to the collocation, containers in the same Pod have additional means to interact with each other. The most com‐ mon ways for communication include using a shared local filesystem for Figure 1-2. A Pod as the deployment and management unit 6  |  Chapter 1: Introduction