Privacera Services Deployment Strategies¶
This document outlines the deployment strategies for various Privacera services, categorizing them into two main types: Recreate and RollingUpdate.
Service | Strategy |
---|---|
Audit Fluentd | RollingUpdate |
AuditServer | RollingUpdate |
Connector | Recreate |
DataServer | RollingUpdate |
Discovery | Recreate |
Discovery Consumer | RollingUpdate |
Kafka | RollingUpdate |
MariaDB | Recreate |
Ops Server | RollingUpdate |
PEG | RollingUpdate |
PKafka | RollingUpdate |
Portal | RollingUpdate |
Privacera Diagnostics | Recreate |
Privacera Services | RollingUpdate |
Privacera Usersync | Recreate |
Ranger Admin | RollingUpdate |
Ranger KMS | RollingUpdate |
Ranger Tagsync | RollingUpdate |
Ranger Usersync | RollingUpdate |
Scheme Server | RollingUpdate |
Solr | RollingUpdate |
Trino Worker | RollingUpdate |
Zookeeper | RollingUpdate |
Strategy Types¶
Recreate Strategy¶
This strategy involves a complete shutdown of all existing pods for a service before new pods are created and launched. It results in a period of downtime during the transition, as the service is unavailable until the new pods are fully operational. Common use cases:
- Services that cannot safely operate with multiple instances running simultaneously.
- Services that utilize local storage (e.g., RocksDB), where concurrent access from multiple pods could lead to data corruption.
- Database services that require single-instance operation to ensure data consistency.
RollingUpdate Strategy¶
With this strategy, new pods are gradually rolled out to replace old ones, typically one at a time or in small batches. An old pod is terminated only after its replacement is healthy and ready to serve traffic. This is designed for continuous availability, minimizing or eliminating downtime during updates. This is the default and recommended approach for many services. Common use cases:
- Services that do not maintain internal state and can scale horizontally across multiple instances.
- Services built to support multiple running instances and distribute load.
- Services where any disruption in availability is unacceptable.
For best practices on safely restarting service pods using these strategies, refer to the Recommended Way to Restart Service Pods.