@ -26,52 +26,54 @@ Problem description
===================
Currently running or deploying one container to do the operation is not a
very effective way in micro services, while multiple different containers run
as an integration has widely used in different scenarios, such as pod in Kubernetes.
The pod has the independent network, storage, while the compose has an easy way to defining
and running multi-container Docker applications. They are becoming the basic unit for
container application scenarios.
as an integration has widely used in different scenarios, such as pod in
Kubernetes. The pod has the independent network, storage, while the compose has
an easy way to defining and running multi-container Docker applications. They
are becoming the basic unit for container application scenarios.
Nowadays Zun doesn't support creating and running multiple containers as an
integration. So we will introduce the new Object `` capsule `` to realize this
function. `` capsule `` is the basic unit for zun to support service to external.
The `` capsule `` will be designed based on some similar concepts such as pod and compose.
For example, `` capsule `` can be specified in a yaml file that might be similar to the format
of k8s pod manifest. However, the specification of `` capsule `` will be exclusive to Zun. The
details will be showed in the following section.
The `` capsule `` will be designed based on some similar concepts such as pod and
compose. For example, `` capsule `` can be specified in a yaml file that might be
similar to the format of k8s pod manifest. However, the specification of
`` capsule `` will be exclusive to Zun. The details will be showed in the
following section.
Proposed change
===============
A `` capsule `` has the following properties:
* Structure: It can contains one or multiple containers, and has a sandbox
container which will support the network namespace for the capsule.
container which will support the network namespace for the capsule.
* Scheduler: Containers inside a capsule are scheduled as a unit, thus all
containers inside a capsule is co-located. All containers inside a capsule
will be launched in one compute host.
* Network: Containers inside a capsule share the same network namespace, so they
share IP address(es) and can find each other via localhost by using different
remapping network port. Capsule IP address(es) will re-use the sandbox IP.
Containers communication between different capsules will use capsules IP and
port.
containers inside a capsule is co-located. All containers inside a capsule
will be launched in one compute host.
* Network: Containers inside a capsule share the same network namespace,
so they share IP address(es) and can find each other via localhost by using
different remapping network port. Capsule IP address(es) will re-use the
sandbox IP. Containers communication between different capsules will use
capsules IP and port.
* LifeCycle: Capsule has different status:
Starting: Capsule is created, but one or more container inside the capsule is
being created.
Running: Capsule is created, and all the containers are running.
Finished: All containers inside the capsule have successfully executed and exited.
Failed: Capsule creation is failed
* Restart Policy: Capsule will have a restart policy just like container. The restart
policy relies on container restart policy to execute.
Starting: Capsule is created, but one or more container inside the capsule is
being created.
Running: Capsule is created, and all the containers are running.
Finished: All containers inside the capsule have successfully executed and
exited.
Failed: Capsule creation is failed
* Restart Policy: Capsule will have a restart policy just like container. The
restart policy relies on container restart policy to execute.
* Health checker:
In the first step of realization, container inside the capsule will send its
status to capsule when its status changed.
In the first step of realization, container inside the capsule will send its
status to capsule when its status changed.
* Upgrade and rollback:
Upgrade: Support capsule update(different from zun update). That means the
container image will update, launch the new capsule from new image, then destroy
the old capsule. The capsule IP address will change. For Volume, need to clarify
it after Cinder integration.
Rollback: When update failed, rollback to it origin status.
Upgrade: Support capsule update(different from zun update). That means the
container image will update, launch the new capsule from new image, then
destroy the old capsule. The capsule IP address will change. For Volume, need
to clarify it after Cinder integration.
Rollback: When update failed, rollback to it origin status.
* CPU and memory resources: Given that host resource allocation, cpu and memory
support will be implemented.
support will be implemented.
Implementation:
@ -81,23 +83,23 @@ Implementation:
and cgroups.
2. Support the CRUD operations against capsule object, capsule should be a
basic unit for scheduling and spawning. To be more specific, all containers
in a capsule should be scheduled to and spawned on the same host. Server side
will keep the information in DB.
3. Add functions about yaml file parser in the CLI side. After parsing the yaml,
send the REST to API server side, scheduler will decide which host to run
the capsule.
in a capsule should be scheduled to and spawned on the same host. Server
side will keep the information in DB.
3. Add functions about yaml file parser in the CLI side. After parsing the
yaml, send the REST to API server side, scheduler will decide which host
to run t he capsule.
4. Introduce new REST API for capsule. The capsule creation workflow is:
CLI Parsing capsule information from yaml file -->
API server do the CRUD operation, call scheduler to launch the capsule, from Cinder
to get volume, from Kuryr to get network support-->
API server do the CRUD operation, call scheduler to launch the capsule, from
Cinder to get volume, from Kuryr to get network support-->
Compute host launch the capsule, attach the volume-->
Send the status to API server, update the DB.
5. Capsule creation will finally depend on the backend container driver. Now choose
Docker driver first.
6. Define a yaml file structure for capsule. The yaml file will be compatible with
Kubernetes pod yaml file, at the same time Zun will define the available properties,
metadata and template of the yaml file. In the first step, only essential properties
will be defined.
5. Capsule creation will finally depend on the backend container driver. Now
choose Docker driver first.
6. Define a yaml file structure for capsule. The yaml file will be compatible
with Kubernetes pod yaml file, at the same time Zun will define the
available properties, metadata and template of the yaml file. In the first
step, only essential properties will be defined.
The diagram below offers an overview of the architecture of `` capsule `` :
@ -129,6 +131,7 @@ Yaml format for ``capsule``:
Sample capsule:
.. code-block :: yaml
apiVersion: beta
kind: capsule
metadata:
@ -163,7 +166,7 @@ Sample capsule:
cpu: 1
memory: 2GB
volumes:
- name: volume1
- name: volume1
drivers: cinder
driverOptions: options
size: 5GB
@ -183,14 +186,16 @@ ObjectMeta fields:
* lables(dict, name: string): labels for capsule
CapsuleSpec fields:
* containers(Containers array): containers info array, one capsule have multiple containers
* containers(Containers array): containers info array, one capsule have
multiple containers
* volumes(Volumes array): volume information
Containers fields:
* name(string): name for container
* image(string): container image for container
* imagePullPolicy(string): [Always | Never | IfNotPresent]
* imageDriver(string): glance or dockerRegistory, by default is according to zun configuration
* imageDriver(string): glance or dockerRegistory, by default is according to
zun configuration
* command(string): container command when starting
* args(string): container args for the command
* workDir(string): workDir for the container
@ -223,20 +228,22 @@ Volumes fields:
* driver(string): volume drivers
* driverOptions(string): options for volume driver
* size(string): volume size
* volumeType(string): volume type that cinder need. by default is from cinder config
* volumeType(string): volume type that cinder need. by default is from
cinder config
* image(string): cinder needed to boot from image
Alternatives
------------
1. Abstract all the information from yaml file and implement the capsule CRUD in
client side.
1. Abstract all the information from yaml file and implement the capsule CRUD
in client side.
2. Implement the CRUD in server side.
Data model impact
-----------------
* Add a field to container to store the id of the capsule which include the container
* Add a field to container to store the id of the capsule which include the
container
* Create a 'capsule' table. Each entry in this table is a record of a capsule.
.. code-block :: python
@ -277,29 +284,32 @@ REST API impact
---------------
* Add a new API endpoint /capsule to the REST API interface.
* Capsule API: Capsule consider to support multiple operations as container
composition.
composition.
* Container API: Many container API will be extended to capsule. Here in this
section will define the API usage range.
Capsule API:
list <List all the capsule, add parameters about list capsules with the same labels>
list <List all the capsule, add parameters about list capsules
with the same labels>
create <-f yaml file><-f directory>
describe <display the details state of one or more resource>
delete
<capsule name>
delete <capsule name>
<-l name=label-name>
<– all>
run <--capsule ... container-image>
If "--capsule .." is set, the container will be created inside the capsule.
If "--capsule .." is set, the container will be created
inside the capsule.
Otherwise, it will be created as normal.
Container API:
* show/list allow all containers
* create/delete allow bare container only (disallow in-capsule containers)
* create/delete allow bare container only
(disallow in-capsule containers)
* attach/cp/logs/top allow all containers
* start/stop/restart/kill/pause/unpause allow bare container only (disallow in-capsule containers)
* update for container in the capsule, need <--capsule> params.
Bare container doesn't need.
* start/stop/restart/kill/pause/unpause allow bare container only (disallow
in-capsule containers)
* update for container in the capsule, need <--capsule>
params. Bare container doesn't need.
Security impact
---------------