Provisioners on tsuru are responsible for creating and scheduling units for
applications. Initially tsuru supported only one
docker. This begin changing with tsuru release 1.2 as
support for Kubernetes as provisioners, now it is the default provisioner.
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 and tsuru will use pools to find out which provisioner is responsible for each application. A single tsuru installation can manage different pools with different provisioners at the same time.
kubernetes provisioner uses Kubernetes to
manage nodes and containers, tsuru also doesn’t store anything in its internal
storage related to nodes and containers. It’s first necessary to register a
Kubernetes cluster in tsuru which must point to the
Kubernetes API server.
Scheduling is controlled exclusively by Kubernetes, for each application/process tsuru will create 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 also created for every Deployment, this allows direct communication between services without the need to go through a tsuru router.
Tsuru supports some Kubernetes-specific configurations, check tsuru.yaml docs for more details.
These are the Kubernetes versions that were tested with each tsuru release:
- tsuru <=1.6.2: kubernetes 1.8.x to 1.10.x
- tsuru >=1.7.0: kubernetes 1.10.x to 1.12.x
- tsuru >=1.9.0: kubernetes 1.14.x to 1.18.x