Installing the Trilio Controller Cluster
Last updated
Last updated
Trilio is providing a binary installation tool, which is creating the Kubernetes cluster, downloads all images in their latest version, and ensures a clean state of the whole environment.
Move the binary into the /usr/bin directory
The binary provides the following options:
deploy ==> Fresh deployment, expects only the base VMs to be present
redeploy ==> Deletes the entire Trilio Controller Cluster including its Kubernetes base, before redeploying based on the last available configuration.
cleanup ==> Deletes the entire Trilio Controller Cluster including the Kubernetes base
reset ==> deletes and redeploys the Trilio Controller Cluster without changing the Kubernetes base
reset should only be done from the same node that was used to run the initial deployment. running the reset option on other nodes will not execute any steps.
The Trilio binary is taking a deployment file in json format.
The following information need to be provided inside the deployment.json
number of nodes ==> How many nodes will the Trilio Controller Cluster consist of. Default and minimum is 3 nodes, but can be increased in steps of 2 if required.
virtual_ip_for_keepalived ==> This is IP is used by the Kubernetes to ensure that all nodes are still working and keeping the Kubernetes Masternodes in sync
ingress_ip ==> IP under which the Trilio Controller Cluster is reachable
For each VM that is part of the cluster:
node_ip ==> IP under which the VM is reachable for the deployment binary
username ==> root
password ==> password that allows the provided user to ssh into the VM
The provided user requires root permissions on the VMs
An example deployment.json can be seen below
Once the deployment.json has beed created the Trilio binary can be started using the following command.
Wait for the binary to finish.
Once the procedure finished check the status of the containers using
The output will look similar to the following.
The wlm containers will be in the status CrashLoopBackOff at this point. This is the expected behavior. The containers will go into a running state after the configuration has finished.