DB Pods Scheduling Policy

Description:

The DB Affinity Rules epic aims to give database administrators greater control over how their database workloads are distributed within a Kubernetes cluster. By setting Kubernetes affinity and anti-affinity rules, users can optimize performance, enhance resilience, and better utilize resources based on their specific database components and architecture.

This epic encompasses three key aspects of managing affinity rules across the database lifecycle: creating a shared policies that can be re-used by many DB clusters, selecting the needed policy during database creation, modification within an existing database’s components, and quick status monitoring from the database overview page. Together, these features provide a comprehensive toolkit for setting and maintaining customized workload distribution policies for database clusters, tailored to the unique requirements of each supported database engine (MySQL, MongoDB, and PostgreSQL).

The whole feature specification with use-cases and technical details is available here: https://www.notion.so/percona/Assigning-DB-cluster-Pods-to-Nodes-Affinity-v-2-1c9674d091f380c29d05d1a068222566?pvs=4

Objectives:

1. Seamless Pod Scheduling Policy Configuration:
   Everest Admin can define affinity and anti-affinity rules beforehand. This ensures that users who are not aware about all peculiarities of Affinity configuration are still able to use this feature. At the same time Everest Admin ensures that the database's workload distribution is optimized from the outset, allowing users to set rules for each component (e.g., DB nodes, Proxies, Config Servers) based on their specific database engine and sharding configuration.

2. Post-Creation Affinity Rule Management in Components Tab:
   Recognizing that workload requirements may evolve, users can access and select another affinity policy in the Components tab of an existing database. This functionality mirrors the setup available in the creation wizard, with additional flexibility to adjust, fine-tune, or revert rules at any point after deployment. This enables administrators to react to changing cluster demands, such as scaling, rebalancing, or high-availability needs.

3. Affinity Status Monitoring in Overview Tab:
   For quick visibility into the current affinity configuration, a summary field labeled Pod Scheduling Policy appears in the Advanced Configuration widget on the database overview page. This field dynamically reflects the affinity status as Default or Custom—indicating whether the current setup is still at its initial configuration or has been customized. A direct link enables one-click navigation to the Components tab, facilitating fast adjustments as needed.

Scope:

• Supported Database Engines: MySQL, MongoDB, and PostgreSQL.

• Components Available for Affinity Configuration:

  • MySQL and PostgreSQL: DB nodes, Proxies

  • MongoDB: DB nodes, with additional options for Proxies and Config Servers when sharding is enabled

• Affinity Rule Types: Node Affinity, Pod Affinity, and Pod Anti-Affinity

• Rule Prioritization: Required or Preferred, with weighted priority for Preferred rules

Expected Outcomes:

This epic will give administrators the flexibility to:

• Configure affinity rules tailored to their database’s architecture, aligning with Kubernetes best practices.

• Monitor and update affinity configurations as database requirements change.

• Easily navigate between status monitoring and detailed configuration to ensure database clusters are optimized for both performance and reliability.

By delivering this functionality, the DB Pods Scheduling Policy epic enhances the control administrators have over their database environments, empowering them to meet organizational demands for efficiency, availability, and cost-effectiveness within Kubernetes clusters.

Design (Figma link):

https://www.figma.com/design/yqprW09jvELb9a5edQofVM/Create-Edit-Database?node-id=1900-39558&t=wN48QcoBWRZnJzqw-1