![\"\"](\"https:\/\/lh5.googleusercontent.com\/1XqojkVC0CET1yKCJqZ3-0VWxJ3W8Q74zPLlqnn6eHSJsjHOiBTB7EGUX5o_BOKumgfkxVdgBeLyoyMfMIXwVm9p2QXkq_RRy2mDJG1qEExJDculYL5PciYcWfPAKxF2-DGIdiLw\")
<\/p>\nToday, almost all applications can run in containers. But creating a cloud-native application that automates the operation and management of containerized applications through a cloud-native platform such as Kubernetes requires extra work.
\nCloud native applications need to consider failures; even when the underlying architecture fails, it needs to run reliably.
\nTo provide such functionality, a cloud-native platform like Kubernetes needs to impose some contracts and constraints on running applications.
\nThese contracts ensure that applications can run under certain constraints, allowing the platform to automate application management.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
| Container Design Principles |<\/p>\n
The seven principles described here relate to both the build time and the runtime, two types of concerns.<\/p>\n
Build time
\n1) Single focus: Each container only addresses one point of interest and is done very well.
\n2) Self-contained: A container only relies on the Linux kernel. Additional library requirements can be added when building the container.
\n3) Mirror invariance: Containerized applications mean invariance, and once the build is complete, there is no need to rebuild from the environment.
\nRuntime
\n4) Highly observable: Each container must implement all the necessary APIs to help the platform observe and manage the application in the best possible way.
\n5) Lifecycle consistency: A container must be able to get event information from the platform and react accordingly.
\n6) Process tractability: The life of a containerized application must be as short as possible so that it can be replaced by another container at any time.
\n7) Runtime Restrictions: Each container must declare its own resource requirements and limit resource usage to the required range.<\/p>\n