Container orchestrators

A container orchestrator connects Cloud Management Platform (CMP) to a cluster so that blueprints can deploy and manage containerized objects

  4 minute read  

Two technologies are supported: Kubernetes and OpenShift. A hosted service such as Google Kubernetes Engine or Azure Kubernetes Service is added as a Kubernetes orchestrator. Once a cluster is connected, a blueprint can include a container object, and CMP deploys it to the cluster and manages it alongside the rest of the resource.

Add a container orchestrator

Managing container orchestrators needs the containerorchestrator.manage permission.

  1. Go to Admin > Container Orchestrators.
  2. Select Add, then choose a technology.
  3. Fill in the connection details, then select Save.

Connection details

Field Description
Name The name under which the orchestrator is listed.
Protocol, IP address, Port How CMP reaches the cluster’s API.
Account username, Password An account authorized to run commands on the cluster. OpenShift labels the username field Username and requires both.
Environments The environments in which this orchestrator is available.

The rest of the form depends on the technology:

  • Kubernetes offers an Authentication Type of Password, Bearer Token, or Certificate, and reveals the corresponding credential fields for the chosen type. A URL Path Prefix is available for clusters served under a path.
  • OpenShift offers SSL Verification, which is off by default. Turn it on to verify the cluster’s certificate.

Verify and sync a cluster

Open an orchestrator to reach Edit, Verify Connection, Sync Container Resources, and Delete. Syncing queues a job that reads the cluster’s namespaces, deployments, nodes, and pods, which then appear on the Deployments, Nodes, and Pods tabs.

Add containers to a blueprint

On a blueprint’s Build tab, select Container Object. Each container object carries a config file and the cluster it deploys to.

Kubernetes objects are deployed from a YAML config file. CMP can generate one from parameters you set, which is limited to the Pod object type and a few parameters, or you can supply your own by upload or from a remote URL. For other object types, write the config file yourself; see the Kubernetes documentation.

Deploy new cluster on the container object determines where it lands. When disabled, you choose one or more existing clusters to deploy to. When enabled, CMP creates a cluster in a new environment and deploys the object to it. This requires a build item earlier in the blueprint to produce the cluster.

Templating a config file

When you supply your own config file, CMP scans it for variables written as {{ variable }} and creates a file input for each one it finds. An administrator sets default values for those inputs when editing the build item, and a user can override them on the order form. CMP substitutes the values before deploying.

Standard context such as {{ group }} and {{ job }} is also available. Adding namespace: {{ group.kubernetes_namespace }} under the config file’s metadata section, for example, takes the namespace from a kubernetes_namespace parameter on the ordering user’s group.

View, edit, and delete containers

A resource deployed with container objects gains a Kubernetes tab listing what was created. With the Change Attributes permission for that resource, you can also edit a deployed object’s YAML, similar to using kubectl edit.

Deleting the resource deletes its container objects. CMP also tries to delete sub-objects, such as the pods created by a deployment, though it cannot detect the children of every object type. Objects created outside CMP are not shown.