[CONTINT-4726] Add a Kubernetes objects generator#1392
Conversation
cc96530 to
e608401
Compare
4c8a424 to
62f887f
Compare
99766b8 to
378ac92
Compare
223b7a7 to
c74e6f7
Compare
3c79a09 to
9b060d3
Compare
9b060d3 to
a985704
Compare
3114027 to
926a339
Compare
| } | ||
|
|
||
| manage_resources!(create_resources, create_resources_for, number_of_instances: u32); | ||
| manage_resources!(delete_and_recreate_resource, delete_and_recreate_resource_for, number_of_instances: u32, instance_index: u32); |
There was a problem hiding this comment.
That this function is created with a macro makes this module hard to follow. I strongly prefer we do not introduce macros into lading. They are tricky to debug, make dealing with type errors a pain and are contrary to the 'naive' style of the project where indirection and abstraction is kept to a minimum.
Structurally I believe you should be able to avoid the use of macros entirely and use an internal enum with functions hung off it. Something like:
#[derive(Debug, Clone)]
pub enum Resource {
Namespace(k8s_openapi::api::core::v1::Namespace),
Pod(k8s_openapi::api::core::v1::Pod),
Deployment(k8s_openapi::api::apps::v1::Deployment),
Service(k8s_openapi::api::core::v1::Service),
}
impl Resource {
fn api<K>(&self, client: kube::Client) -> kube::Api<K>
where
K: ...
{ ... }
async fn create(
&self,
client: kube::Client,
number_of_instances: u32,
) -> Result<(), Error> { ... }
And then in create you switch on the enum and Kubernetes is written in terms of Resource which also implies you can have one Kubernetes generator handle multiple Resources instead of the current state where you have multiple Kubernetes generators that each handle one resource.
There was a problem hiding this comment.
I tried to remove the macros in a separate commit to better visualize the differences with and without them: 2686034 (#1392)
I feel that a lot of Resource methods would need to duplicate similar enum switches.
@blt would you mind reviewing 2686034 (#1392) and let me know if it’s correctly implementing your suggestion?
926a339 to
3ce5cd5
Compare
2ccf8e5 to
2686034
Compare
There was a problem hiding this comment.
Pull Request Overview
This PR introduces a new Kubernetes objects generator for performance benchmarking. The generator creates, manages, and optionally recreates Kubernetes resources to simulate load on agents monitoring Kubernetes environments.
- Adds a new
kubernetesgenerator module with support for Node, Namespace, Pod, Deployment, and Service resources - Implements resource lifecycle management including creation, deletion, and optional recreation based on max lifetime
- Provides configuration options for manifest content, instance count, and resource lifetime management
Reviewed Changes
Copilot reviewed 5 out of 7 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
lading/src/generator/kubernetes.rs |
Core implementation of the Kubernetes generator with resource management logic |
lading/src/generator.rs |
Integration of the Kubernetes generator into the main generator framework |
lading/Cargo.toml |
Added Kubernetes client dependencies (kube, kube-core, k8s-openapi, either) |
examples/lading-kubernetes.yaml |
Example configuration demonstrating various Kubernetes resource types |
CHANGELOG.md |
Documentation of the new feature |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
What does this PR do?
Add a Kubernetes objects generator.
Motivation
In order to perform performance benchmarks, we need to generate load on the agent.
A form of load for the agent is Kubernetes resources.
Related issues
Additional Notes