Component Registration and License Initialization
Purpose: Automatically discover and register new workload components.
Process:
- The License Controller listens to resource modification events of LicenseClient CRD on the Kubernetes API Server.
- The License Server reads the component identifier from CRD and collects configurations and other information.
- The License Server writes the license information and quota configurations to the License Database and then updates the CRD status to Registered.
- The License Server sends a notification of the registration result via the event mechanism.
Periodic Usage Collection
Purpose: Periodically collect the resource usage information on components.
Process:
- The scheduler of the License Server triggers a collection task every five minutes.
- The License Server obtains the list of all registered LicenseClient resources from Kubernetes.
- The License Server concurrently calls the collection APIs exposed by workload components to obtain the constraint item usage information (such as the CPU usage, memory usage, and number of instances).
- The License Server aggregates collection results, calculates the quota utilization values, and writes them to the License Database by time.
- The License UI reads data from the database and displays the data in statistical reports and trend charts.
License Check for Scale-Out
Purpose: Check whether the quota is sufficient before component scale-out.
Process:
- A workload component initiates a scale-out request (containing the component ID, target number of instances, and other information).
- The License Server verifies the validity of the request.
- The License Server queries the total quota for the component and the current usage from the License Database.
- The License Server performs a quota check.
If the sum of the scale-out amount and the current usage does not exceed the total quota, the request is allowed. Otherwise, the request is rejected. - The License Server returns the result (allowed or rejected) and records audit logs.
Quota Policy and Alarms
Alarm rules:
- Warning (reaching 80%): The message is in yellow. It is recommended to perform scale-out promptly.
- Alarm (reaching 100%): The message is in red. Scale-out is not allowed, and the issue needs to be solved immediately.
Notification channels: site message, mail, SMS message, and announcement.
Administrator operations:
- Log in to the License UI to view the real-time usage, historical trends, and alarm status.
- Modify the component quota, adjust the alarm threshold, and set a validity period.
- The License Server listens to policy modification events and loads new configurations in real time.
- All modification operation records are stored in the License Database for auditing and tracking.
Key Design Principles
| Principle | Description |
|---|---|
| Driven by events | Automatically trigger the registration process based on CRD events. |
| Asynchronous concurrency | Concurrently call component APIs during collection to improve efficiency. |
| Quota priority | Check the quota before scale-out to prevent resource overuse. |
| Multi-level alarms | Provide warnings and alarms and send notifications to the administrator promptly. |
| Full auditing | Generate logs for all operations (registration, collection, check, and modification). |
| Real-time synchronization | Enable policy modifications to take effect immediately without the need to restart the system. |
Core Data Flow
CRD modification event
|
Listen by the server > Read configurations > Write configurations to the database > Update the CRD status
|
Trigger scheduled collection
|
Obtain the component list by the server > Call collection APIs concurrently > Aggregate the usage data > Write data to the database
|
Check based on alarm rules > Trigger a notification (platform announcement/email/WeChat message)
|
Display on the UI > View/Configure by the administrator > Modify the policy > Synchronize new configurations by the server