State Persistence/ Multi-container Patterns PDF

State Persistence/ Multi- container Patterns Outline  Introducing K8S volumes  Persistence in a Pod  Persistent Volumes / Persistent Volume Claims  Multi-container patterns:  Init Container Pattern  Sidecar Container Pattern  Lab K8S Volumes  A Volume is a...

State Persistence/ Multi- container Patterns Outline  Introducing K8S volumes  Persistence in a Pod  Persistent Volumes / Persistent Volume Claims  Multi-container patterns:  Init Container Pattern  Sidecar Container Pattern  Lab K8S Volumes  A Volume is a Kubernetes capability that persists data beyond a Pod restart  Essentially, a Volume is a directory that’s shareable between multiple containers of a Pod  Persistent Volumes are a specific category of the wider concept of Volumes. The mechanics for Persistent Volumes are slightly more complex.  The Persistent Volume is the resource that actually persists the data to an underlying physical storage K8S Volumes  The Persistent Volume Claim represents the connecting resource between a Pod and a Persistent Volume responsible for requesting the storage  The Pod needs to claim the Persistent Volume and mount it to a directory path available to the containers running inside of the Pod. A container using a temp filesystem vs a Volume A pod with volume Persistent Volumes  In many applications, the data lives far beyond the lifecycles of the applications, container, Pod, nodes, and even the clusters themselves  Data persistence ensures the lifecycles of the data are decoupled from the lifecycles of the cluster resources.  A typical example would be data persisted by a database. That’s the responsibility of a Persistent Volume. Kubernetes models persist data with the help of two primitives: the PersistentVolume and the PersistentVolumeClaim Claiming a Persistent Volume from a Pod Persistent Volumes access modes Creating a Persistent Volume Creating a Persistent Volume Claim Mounting Persistent Volume Claims in a Pod Multi-Container Kubernetes Patterns  Init Containers Pattern  Init Containers enable separation of concerns by providing a separate lifecycle for initialization-related tasks distinct from the main application containers.  Init Containers are similar to constructors in OOP, but at Pod level rather than class level  if you have one or more containers in a Pod that represent your main application, these containers may have prerequisites before starting up  These may include setting up special permissions on the filesystem, database schema setup, or application seed data installation. Init Containers  Sidecar Container Pattern  Typically, there are two different categories of containers:  The container that runs the application  Another container that provides helper functionality to the primary application  In K8S, the container providing helper functionality is called a sidecar  Among the most commonly used capabilities of a sidecar container are file synchronization, logging, and watcher capabilities  Having single-purpose reusable containers requires ways of extending the functionality of a container and a means for collaboration among containers  The Sidecar pattern describes this kind of collaboration where a container enhances the functionality of another preexisting container. Sidecar Container Pattern  A typical example used to demonstrate this pattern is with an HTTP server and a Git synchronizer.  The HTTP server container is focused only on serving files over HTTP and does not know how and where the files are coming from.  Similarly, the Git synchronizer container’s only goal is to sync data from a Git server to the local filesystem. It does not care what happens to the files once synced, and its only concern is keeping the local folder in sync with the remote Git server Sidecar Container Pattern Sidecar Container Pattern State Persistence/ Multi- container Patterns