VerticaDB operator
The VerticaDB operator automates error-prone and time-consuming tasks that an OpenText™ Analytics Database on Kubernetes administrator must otherwise perform manually. The operator:
-
Installs Vertica
-
Creates an Eon Mode database
-
Upgrades Vertica
-
Revives an existing Eon Mode database
-
Restarts and reschedules DOWN pods
-
Scales subclusters
-
Manages services for pods
-
Monitors pod health
-
Handles load balancing for internal and external traffic
The VerticaDB operator is a Go binary that uses the SDK operator framework. It runs in its own pod, and is cluster-scoped to manage any resource objects in any namespace across the cluster.
For details about installing and upgrading the operator, see Installing the VerticaDB operator.
Monitoring desired state
Because the operator is cluster-scoped, each cluster is allowed one operator pod that acts as a custom controller and monitors the state of the custom resource objects within all namespaces across the cluster. The operator uses the control loop mechanism to reconcile state changes by investigating state change notifications from the custom resource instance, and periodically comparing the current state with the desired state.
If the operator detects a change in the desired state, it determines what change occurred and reconciles the current state with the new desired state. For example, if the user deletes a subcluster from the custom resource instance and successfully saves the changes, the operator deletes the corresponding subcluster objects in Kubernetes.
Validating state changes
All VerticaDB operator installation options include an admission controller, which uses a webhook to prevent invalid state changes to the custom resource. When you save a change to a custom resource, the admission controller webhook queries a REST endpoint that provides rules for mutable states in a custom resource. If a change violates the state rules, the admission controller prevents the change and returns an error. For example, it returns an error if you try to save a change that violates K-Safety.
Limitations
The operator has the following limitations:
-
You must manually configure the
vm.max_map_countparameter in/etc/sysctl.confon all Kubernetes nodes to ensure Kubernetes pods inherit the correct memory map count limit. For more information on how to set the memory map limit, see Maximum memory maps configuration. -
You must manually configure TLS. For details, see Database container deployment on Kubernetes.
-
It is recommended that you do not use the Large cluster feature. If a control node fails, it might cause more than half of the database nodes to fail. This results in the database losing quorum.
-
Importing and exporting data between a cluster outside of Kubernetes requires that you expose the service with the NodePort or LoadBalancer service type and properly configure the network.
Important
When configuring the network to import or export data, you must assign each node a static IP export address. When pods are rescheduled to different nodes, you must update the static IP address to reflect the new node.
See Configuring the Network to Import and Export Data for more information.
The VerticaDB operator 2.0.0 does not use Administration tools (admintools) with API version v1. The following features require admintools commands, so they are not available with that operator version and API version configuration:
To use these features with operator 2.0.0, you must a lower server version.