Terminology

Navigation:  »No topics above this level«

Terminology

Previous pageReturn to chapter overviewNext page

Node - a server in KuberDock cluster where users' pods and containers are located. Each node can have only one Kube Type (multiple Kube Types per node will be supported hereafter). KuberDock administrator can add and control the nodes using KuberDock web-interface.

 

Kube - an abstract minimal set of resources allocated to a container.

 

Kube Type - a particular set of resources predefined for each container.

 

For example, single Kube can have:

 

0.1 of CPU core (which means 10% of one CPU core);

128MB of RAM;

1GB of disk space;

10GB of traffic (under development).

 

Then a container with 10 Kubes would have10 times more resources:

 

1 CPU core;

1280MB of RAM;

10GB of disc space;

100 GB of traffic (under development).

 

Kubes can be of multiple types. Such setup allows service provider to sell different sets of resources at different prices, as well as resources based on different hardware.

Different KuberDock nodes can support different Kube Types.

 

For example, a provider might want to have SSD Kube Type defined for the nodes with SSD drives, or high memory nodes for servers with a lot of memory on them.

 

Pod - a collocated group of containers running with a shared context. Containers within one pod share the same Pulbic IP, restart policy and Kube Type, they are connected to each other via 127.0.0.1 IP.

 

A pod models an application-specific "logical host" in a containerized environment. It may contain one or more applications which are relatively tightly coupled - in a pre-container world, they would have executed on the same physical or virtual host.

 

Container Image - an application image with all the necessary data for it to run. Images can be retrieved from Docker Hub registry or other registries.

 

Container - a virtualized, isolated environment for applications to run within a pod.

 

Pod IP - IP address of KuberDock internal network pod, that is used for connection to other pod owned by the same user.

 

Restart policy - defines if a container in the pod should be restarted, after it has been executed:

 

Never - if you don't need to restart a container automatically;

Always -  if you need to restart a container in case of it terminated with error, or when application inside a container terminated causing container to stop;

OnFailure - if you need to restart a container only if its exit code equals "0" (container terminated with an error).

 

User roles - user access level to KuberDock:

 

Admin - a user with administrator access level;

User - standard KuberDock user access level;

Trial User - a user with limited access level, provides the same credentials as standard KuberDock user, but with limited number of Kubes (no more than 10 Kubes per user).

LimitedUser - a user with no ability to create new pods and containers.