Init containers would be something like object constructors; DaemonSets would be similar to daemon threads that run in the background (like the Java Garbage Collec‐ tor, for example). A Pod would be something similar to an Inversion of Control (IoC) context (Spring Framework, for example), where multiple running objects share a managed lifecycle and can access each other directly. The parallel doesn’t go much further, but the point is that containers play a funda‐ mental role in Kubernetes, and creating modularized, reusable, single-purpose con‐ tainer images is fundamental to the long-term success of any project and even the containers’ ecosystem as a whole. Apart from the technical characteristics of a con‐ tainer image that provide packaging and isolation, what does a container represent and what is its purpose in the context of a distributed application? Here are a few sug‐ gestions on how to look at containers: In addition to all these characteristics, a proper container image is modular. It is para‐ meterized and created for reuse in the different environments it is going to run. But it is also parameterized for its various use cases. Having small, modular, and reusable container images leads to the creation of more specialized and stable container images in the long term, similar to a great reusable library in the programming lan‐ guage world. Looking at the characteristics of containers, we can see that they are a perfect match for implementing the microservices principles. A container image provides a single unit of functionality, belongs to a single team, has an independent release cycle, and provides deployment and runtime isolation. Most of the time, one microservice cor‐ responds to one container image. However, most cloud-native platforms offer another primitive for managing the life‐ cycle of a group of containers—in Kubernetes it is called a Pod. A  Pod  is an atomic Pods Distributed Primitives  |  5 • A container image is the unit of functionality that addresses a single concern. • A container image is owned by one team and has a release cycle. • A container image is self-contained and defines and carries its runtime dependencies. • A container image is immutable, and once it is built, it does not change; it is configured. • A container image has defined runtime dependencies and resource requirements. • A container image has well-defined APIs to expose its functionality. • A container runs typically as a single Unix process. • A container is disposable and safe to scale up or down at any moment.