By Allen Sun, Senior Engineer at Alibaba Group
Pouch's vision is to advance container ecosystem and promote container standards OCI (Open Container Initiative), so that container technologies could become the foundation for application development in the Cloud era.
Pouch can pack, deliver, and run any applications. It provides applications with a lightweight runtime environment with strong isolation and minimal overhead. Pouch isolates applications from varying runtime environment, and minimizes operational workload. Meanwhile, Pouch minimizes the effort for application developers to write Cloud-native applications, or to migrate legacy ones to a Cloud platform.
Features
Here we listed several important features of Pouch:
• Security: Pouch is designed to be secure by default. It includes a lot of security features, such as hypervisor-based container technology, lxcfs, patched Linux kernel and so on.
• P2P distribution: Pouch utilizes Dragonfly, a P2P-base distribution system, to achieve lightning-fast container image distribution.
• Rich container: Besides the common ways of running container, Pouch includes a rich container mode, which integrates more services, hooks, and many others container internals to guarantee container's running like usual.
• Kernel compatibility: Enables OCI-compatible runtimes to work on old kernel versions, like Linux kernel 2.6.32+.
• Simplicity: You can set up Pouch in just a few steps.
From these features, we could conclude that Pouch is designed to fit very large-scale and production application scenarios. Container technology brings convenience to pack applications, but applications in containers are less secure as compared to applications in VMs. It will definitely be a concern of decision makers to choose container technology on the market. However, Pouch is developed by Alibaba, one of the largest e-commerce company in the world. Alibaba has faced a wide variety of security issues and have successfully coped with these issues. A lot of these issues are solved using hypervisor-based container and security-patched kernels.
P2P image distribution is one of the most practical thoughts we can think of for businesses as large as Alibaba. Tools like Dragonfly are the essentials in large companies. Unlike P2P image distribution, rich container is the one that confuses many at first glance. It works in the opposite way as compared with the ones that the container community advocates.
Pouch’s reason is quite simple; no one is willing to adopt a technology at once if it appears to be invasive, even if it brings huge benefits. This also confirms Pouch’s practical point of view. Kernel Compatibility is the reality almost every enterprise would face, but community seems to consider it less. How to make it in current kernel system is the key point that may be revealed in the future.
Architecture
Knowing the feature of Pouch and the benefits it brings, we take a deep dive into its architecture. Pouch has two kinds of architectures from two dimensions: ecosystem architecture and inner component architecture.
Ecosystem architecture: illustrates how Pouch fits into the container ecosystem
The ecosystem architecture may be a little bit complicated at first glance. Take it easy. We can get a thorough understanding of it from the following three dimensions.
Runtime Layer
Runtime layer is located on the top-right in the architecture picture. This dimension mainly focuses on OCI-compatible runtimes supported in Pouch. These runtimes unify specifications for standards on operating system process and application containers. Currently, Pouch supports four kinds of OCI-compatible runtimes:
• runC
• runlxc
• runV
• clear containers
With runC, Pouch creates common containers like other container engine does, for example Docker. With runlxc, Pouch creates containers based on LXC. runlxc helps a lot when users need to run containers on a wide variaty of Linux kernels with the ability to be compatible with kernel 2.6.32+. Hypervisor-based containers have many application scenarios as well. Pouch will support it with runV and clear container.
All these four runtimes mentioned above are supported under containerd. Containerd takes over all detailed container management, including creation, start, stop, deletion and so on.
Orchestration Layer
Pouch is always active on supporting Kubernetes since the first day of its conception. We illustrate this part on the top half of the architecture diagram. First, Pouch will integrate cri-containerd inside, so Kubernetes can easily dominate Pouch to manage Pod. The workflow will pass cri-containerd, containerd client, containerd, runC/runV and pod. When configuring network of Pod, cri-containerd will take advantage of network plugins that implement CNI interface.
Container Layer
We support not only Pod in Kubernetes cluster, but also simple container management for users. This is especially useful for developers. In other words, Pouch supports single container API. In this way, workflow passes pouchd, containerd client, containerd, runC/runV and container. On the aspect of network, Pouch uses libnetwork to construct container's network. What's more, lxcfs is also used to guarantee the isolation between containers and between containers and host.
Component architecture: describes the interactions between various components inside Pouch.
Pouch CLI
There are lots of different commands encapsulated in Pouch CLI, like create, start, stop, exec and so on. Users can interact with Pouchd by Pouch CLI. When executing a command, Pouch CLI will translate it into Pouchd API calls to satisfy users' demand. Pouch Client API is a well-encapsulated package in Pouch CLI. It is very easy for others to integrate Pouch Client Package into third-party software. And this package currently only supports Golang language. When calling Pouchd via Pouch Client Package, the communication is over HTTP.
Pouchd
Pouchd is designed decoupled from the very beginning. It makes Pouchd quite easy to understand. And it helps a lot for us to hack on Pouch. In general, we treat that Pouchd can be split into the following pieces:
• HTTP server
• bridge layer
• Manager(System/Network/Volume/Container/Image)
• ctrd
HTTP Server receives API calls directly and replies to client side. Its job is to parse requests and construct correct struct, which is supposed to be passed to bridge layer, and to construct response no matter server succeeds in handling request or fails.
bridge layer is a translation layer which handles objects from client to meet managers or containerd's demand and handles objects from managers and containerd to make response compatible with Moby's API.
Manager is main processor of Pouchd. It deals proper object from requests, and does the corresponding work. There are five managers currently in Pouchd: container manager, image manager, network manager, volume manager and system manager.
ctrd is containerd client in Pouchd. When managers need to communicate with container, ctrd is the right thing to do this work. Managers call functions in ctrd and send request towards containerd. In addition, when state of container changes, containerd is the first component to be aware of this, and ctrd has container watch goroutines to detect this and update inner data stored in cache.
Conclusion
Although Pouch technology is widely used in Alibaba, there is still a long road ahead for a fully stable and open source version of Pouch. We will focus our efforts on developing Pouch together with the community.
Personal Profile:
Allen Sun, Senior Engineer at Alibaba Group, is currently responsible for the open source construction of the Pouch container project at Alibaba. He has been involved in cloud computing for over 5 years, and is one of the first batch of researchers and practitioners of container technology. Allen played a central role in the evangelism of container technology. He is the author of the book The Source Code Analysis of Docker and a personal advocate of the open source spirit, as well as a Maintainer of the Docker Swarm Project.
You can visit Allen's LinkedIn page through this link.
