Shipa provisioners are responsible for creating and scheduling units for applications and node-containers. Currently, Shipa supports its own internal provisioner as well as Kubernetes as an option.
Provisioners are also responsible for knowing which nodes are available for the creation of units, registering new nodes and removing old nodes.
Provisioners are associated to pools. Shipa uses pools to find out which provisioner is responsible for each application. A single Shipa installation can manage different pools with different provisioners at the same time.
This is Shipa's default provisioner.
Shipa's provisioner uses MongoDB to store metadata of existing nodes and containers on each node as well as to track images as they are created on each node. To accomplish this, Shipa talks directly to the Docker API on each. The Docker API must be allowed to receive connections from the Shipa API using HTTP or HTTPS.
Shipa relies on the default BusyBody node-container to monitor containers on each node and report back which containers are unavailable or that have had their address changed by Docker restarting them. The Shipa provisioner is then responsible for rescheduling those containers on new nodes.
There is no need to register a cluster to use the Shipa provisioner. With the Docker API running, simply add new nodes and Shipa can to use them.
When units are scheduled on nodes, those application containers receive high availability prioritization. Shipa creates each new container on the node with the fewest containers from the application. If there are multiple nodes with no containers from the application being scheduled, Shipa creates new containers on nodes that have different metadata from those that already exist.
Register a Kubernetes cluster in Shipa that points to the Kubernetes API server. The Shipa Kubernetes provisioner uses Kubernetes to manage nodes and containers. Shipa doesn’t store anything in its internal storage related to nodes and containers.
Scheduling is controlled exclusively by Kubernetes, for each application/process and Shipa creates a Deployment controller. Changes to the application like adding and removing units are executed by updating the Deployment with rolling update configured using the Kubernetes API. Node containers are created using the DaemonSets.
A Service controller is created for every Deployment, allowing for direct communication between services without the need to go through a Shipa router.
New nodes can be added using the normal Shipa workflow described in theAdding New Nodes topic on the Managed Nodes page. However, Shipa creates a Node resource using the Kubernetes API. Shipa assumes that the new node already has a kubelet process running on it, and that it is accessible to the Kubernetes API server.
The following Kubernetes versions were tested with the Shipa's 1.0 release:
- Kubernetes 1.10.x to 1.17.x
Updated 21 days ago