Shipa provisioners are responsible for creating and scheduling units for applications and node-containers. Currently, Shipa supports its own internal provisioner and Kubernetes.
Provisioners are also responsible for knowing which nodes are available to create units, register new nodes, and remove old nodes.
Provisioners are associated with frameworks. Shipa uses frameworks to find out which provisioner is responsible for each application. A single Shipa installation can manage different frameworks with different provisioners at the same time.
Shipa's provisioner uses MongoDB to store metadata of existing nodes and containers on each node and 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 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, add new nodes, and Shipa can 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 with different metadata from those that already exist.
You can register a Kubernetes cluster in Shipa that points to the Kubernetes API server. The Shipa Kubernetes provisioner uses Kubernetes itself to manage its nodes and containers. Shipa doesn’t store anything in its internal storage related to nodes and containers that are part of a Kubernetes cluster.
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.
You can scale your Kubernetes cluster in the background as usual, and Shipa will automatically identify the newly added or removed nodes
The following Kubernetes versions were tested with Shipa's 1.2 release:
- Kubernetes 1.14.x to 1.19.x
Updated about a month ago