Installing containers on Kubernetes with operators

The Cloud Pak for Automation operator is built from the Red Hat and Kubernetes Operator Framework, which is an open source toolkit that is designed to automate features such as updates, backups, and scaling. The operator handles upgrades and reacts to failures automatically.

Operators help you to take care of repeatable tasks by using the Kubernetes APIs and kubectl tools. Operators watch over a Kubernetes environment and use its actual state versus the defined state to decide what actions to take. The following diagram shows the control loop that occurs as a result of constantly watching the state of the Kubernetes resources.

The following concepts are key to managing operators:

Namespace deployment

At the beginning of a project, an administrator might encourage developers to use a short-lived namespace that is in their own name. These namespaces do not need to be metered. In the long term and for tracking purposes, it makes sense to divide up workloads into dedicated namespaces for your application lifecycle stages, such as development, preproduction, and production.

If you deploy all of your Cloud Pak for Automation capabilities at the same lifecycle stage into a targeted namespace, you can meter your deployments by the namespace and the platform label or swidtag. Metering uses a system of metadata annotation and aggregation of VPCs, and is critical to help you understand your deployments against entitlements.

Roles, role binding, and service accounts

The default for role-based access control (RBAC) is to deny all access unless you grant access.

A role scopes a set of operations that can be carried out on a group of resources. A service account provides an identity for processes that run in a pod, so it is necessary to grant a role to a service account for intra-cluster processes. A role binding associates a service account to a role, which in effect determines the operations that the account can run inside a namespace. An administrator can configure the role and role binding resources for each application before any operator is deployed. Each application must specify a serviceAccountName in its pod spec, and the service account must be created.

The following diagram shows the relationship between the objects that are used to grant users access to Kubernetes API resources.

The first step to use the Cloud Pak for Automation operator is to create the new custom resource definition (CRD) that the operator is meant to watch. The crd.yaml file contains the description of the custom resources for the container images, and the role.yaml and role_binding.yaml files define the access to the resources. The service_account.yaml file creates a service account with a role that has the permissions to manage the resources. The CRD specifies a configuration, but the cluster also needs controllers to monitor its state and reconcile the resource to match with the configuration. When the CRD is deployed it can then be used to control the automation containers by using Kubernetes primitives such as Services, ReplicaSets, DaemonSets, and Secrets.

To control access, you must create registry secrets and security context constraints (SCC) to set the range of allowed IDs. A shared persistence volume (PV) is needed to store files such as JDBC drivers and other files that are used by the roles.

The following diagram shows the steps that are involved and highlights the key components in controlling a deployed operator.