The Vertica operator automates error-prone and time-consuming tasks that a Vertica 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 Vertica operator is a Go binary that uses the SDK operator framework. It runs in its own pod, and is namespace-scoped to limit any failures to the objects in its namespace.
To install the operator, see Installing the VerticaDB Operator.
Monitoring Desired State
Each namespace is allowed one operator pod that acts as a custom controller and monitors the state of the custom resource objects within that namespace. 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
The verticadb-operator Helm chart includes 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 a error. For example, it returns an error if you try to save a change that violates K-Safety.
The operator has the following limitations:
- You must manually configure TLS. For details, see Containerized Vertica on Kubernetes.
- Vertica recommends that you do not use the Large Cluster feature. If a control nodes fails, it might cause more than half of the database nodes to fail. This results in the database losing quorum.
- Backup and Restore is a manual process.
- Autoscaling is not supported.
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.
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.