Technical Vision for Zun¶
This document is a self-evaluation of Zun with regard to the Technical Committee’s technical vision.
Mission Statement¶
Zun’s mission is to provide an OpenStack containers service that integrates with various container technologies for managing application containers on OpenStack.
Vision for OpenStack¶
Self-service¶
Zun are self-service. It provides users with the ability to deploy containerized applications on demand without having to wait for human action. Zun containers are isolated between tenants. Containers controlled by one tenant are not accessible by other tenants. Quotas are used to limit the number of containers or compute resources (i.e. CPU, RAM) within a tenant.
Application Control¶
Zun allows application control of containers by offering RESTful API, CLI, and Python API binding. In addition, there are third-party tools like Gophercloud that provide API binding for other programming languages. The access of Zun’s API is secured by Keystone so applications that are authenticatable with Keystone can access Zun’s API securely.
Interoperability¶
Zun containers (and other API resources) are designed to be deployable and portable across a variety of public and private OpenStack clouds. Zun’s API hides differences between container engines and exposes standard container abstraction.
Bidirectional Compatibility¶
Zun implements API microversion. API consumers can query the min/max API version that an OpenStack cloud supports, as well as pinning a specific API version to guarantee consistent API behavior across different versions of OpenStack.
Cross-Project Dependencies¶
Zun depends on Keystone for authentication, Neutron for container networks, Cinder for container volumes. Zun aims to integrate with Placement for tracking compute resources and retrieving allocation candidates. Therefore, Placement is expected to be another dependency of Zun in the near future.
Partitioning¶
It is totally fine to deploy Zun in multiple OpenStack regions, and each region could have a Zun endpoint in Keystone service catalog. Zun also supports the concept of ‘availability zones’ - groupings within a region that share no common points of failure.
Basic Physical Data Center Management¶
Zun interfaces with external systems like Docker engine, which consumes compute resources in data center and offers compute capacity to end-users in the form of containers. Zun APIs provide a consistent interface to various container technologies, which can be implemented by different Open Source projects.
Hardware Virtualisation¶
Similar to Nova, Zun also aims to virtualize hardware resources (essentially physical servers) and provide them to users via a vendor-independent API. The difference is that Zun delivers compute resources in the form of containers instead of VMs. Operators have a choice of container runtimes which could be a hypervisor-based runtime (i.e. Kata Container) or a traditional runtime (i.e. runc). The choice of container runtime is a trade-off between tenant isolation and performance.
Plays Well With Others¶
Zun plays well with Container Orchestration Engines like Kubernetes. In particular, there is an OpenStack provider for Virtual Kubelet, which mimics Kubelet to register itself as a node in a Kubernetes cluster. The OpenStack provider leverages Zun to launch container workloads that Kubernetes schedules to the virtual node.
Infinite, Continuous Scaling¶
Zun facilitates infinite and continuous scaling of applications. It allows users to scale up their applications by spinning up containers on demand (without pre-creating a container host or cluster). Containers allow sharing of physical resources in data center at a more fine-grained level than a VM thus resulting in a better utilization of resources.
Built-in Reliability and Durability¶
Unlike VMs, containers are usually transient and allowed to be deleted and re-created in response to failure. In this context, Zun aims to provide primitives for deployers to deploy a highly available applications. For example, it allows deployers to deploy their applications across different availability zones. It supports health check of containers so that orchestrators can quickly detect failure and perform recover actions.
Customizable Integration¶
Zun is integrated with Heat, which allows users to ‘wire’ containers with resources provided by other services (i.e. networks, volumes, security groups, floating IPs, load balancers, or even VMs). In addition, the Kubernetes integration feature provides another option to ‘wire’ containers to customize the topology of application deployments.
Graphical User Interface¶
Zun has a Horizon plugin, which allows users to consume Zun services through a graphical user interface provided by Horizon.
