The obvious and old method for this purpose is through logging. It is a good practice for containers to log any significant events to system out and system error and have these logs collected to a central location for further analysis. Logs are not typically used for taking automated actions, but rather to raise alerts and further investiga‐ tions. A more useful aspect of logs is the postmortem analysis of failures and detect‐ ing unnoticeable errors. Apart from logging to standard streams, it is also a good practice to log the reason for exiting a container to  /dev/termination-log . This location is the place where the con‐ tainer can state its last will before being permanently vanished. Figure 4-1 shows the possible options for how a container can communicate with the runtime platform. Containers provide a unified way for packaging and running applications by treating them like black boxes. However, any container that is aiming to become a cloud- native citizen must provide APIs for the runtime environment to observe the con‐ tainer health and act accordingly. This support is a fundamental prerequisite for automation of the container updates and lifecycle in a unified way, which in turn improves the system’s resilience and user experience. In practical terms, that means, as a very minimum, your containerized application must provide APIs for the differ‐ ent kinds of health checks (liveness and readiness). Even better-behaving applications must also provide other means for the managing platform to observe the state of the containerized application by integrating with trac‐ ing and metrics-gathering libraries such as OpenTracing or Prometheus. Treat your application as a black box, but implement all the necessary APIs to help the platform observe and manage your application in the best way possible. The next pattern,  Managed Lifecycle , is also about communication between applica‐ tions and the Kubernetes management layer, but coming from the other direction. It’s about how your application gets informed about important Pod lifecycle events. Figure 4-1. Container observability options Discussion  |  39