Container Orchestrators

What is a Container Orchestrator?

A container orchestrator is a connection to a system that is capable of installing and coordinating containers. CloudBolt supports one container orchestrator currently: Kubernetes. If you are interested in support for other container orchestrators or have other needs for managing containers, please contact us at support@cloudbolt.io.

Creating New Container Orchestrators

CloudBolt Admins can create new container orchestrators by:

  1. Click Admin
  2. Click Container Orchestrators.
  3. Click Add a container orchestrator.
  4. Choose a technology
  5. Provide the details CloudBolt needs to connect to your technology
  6. Click Create
  7. After this, one can add containers to Blueprints in CloudBolt to deploy new Kubernetes objects when users order a blueprint.

Adding Containers to a Blueprint

Kubernetes objects are deployed from a YAML-formatted specification known as a config file. CloudBolt can automatically generate this config file from parameters you define, or you can provide your own file via upload or a remote URL.

Auto-generated config files are currently limited to the Pod object type and a few parameters. For other object types, please see examples in the Kubernetes documentation for how to create a config file.

Templating with Config Files

When you provide your own config file, you can templatize it using file inputs. CloudBolt will automatically scan the file contents for template style variables like {{ variable }} and will automatically create file inputs for each variable it discovers. Then, an admin can set default values for those file inputs when editing the Blueprint Item where the config file is used. When a user goes to order the blueprint containing the Kubernetes object, that default value will be used unless they enter a different value on the order form. Before actually using the config file to deploy the Kubernetes object, CloudBolt will substitute the given values into it and use the result as the specification.

In addition to file inputs, you have access to {{ group }}, {{ job }}, {{ blueprint_context }} and other standard CloudBolt context. See Action Context for more details.

As an example of using CloudBolt context, here is how you could assign a Kubernetes namespace to a CloudBolt group:

  1. Under Admin > Parameters, create a parameter with a name of kubernetes_namespace.
  2. Add the parameter to your group and add your Kubernetes namespace as an option.
  3. Under the metadata section of your YAML file, add namespace: {{ group.kubernetes_namespace }}

Viewing and Editing Containers

If you deploy a resource with Kubernetes objects, a Kubernetes tab will appear on the resource’s detail page listing the objects that were created. If you have the Change Attributes permission for the resource, you can also edit the YAML definition of the deployed object, similar to the kubectl edit command line tool.

All Kubernetes objects for an entire cluster can viewed and edited from the Deployed Objects tab on the container orchestrator’s detail page. This page is only available to CloudBolt admins. Objects deployed outside of CloudBolt cannot be viewed at this time.

Container Deletion

When you delete a resource, CloudBolt will also delete any container objects that were associated with that resource. CloudBolt will also make an effort to delete any sub-objects, such as Kubernetes Pods created as part of a Deployment. However, there may be some object types where sub-objects can’t be detected. If you encounter this, please contact us at support@cloudbolt.io.