[🚀 Feature]: Implement Selenium Grid Helm charts v1.0.0

[VietND96]

Feature and motivation

Upgrade chart major release from v0.x.x to v1.x.x

Expanding Helm charts bundle to support and simplify deployment of Selenium Grid server to Kubernetes cluster with the following design.

• Individual chart
  • Each component (including the standalone image) will have an individual chart to deploy independently.
  • Component Individual chart will be imported as sub-chart in Grid umbrella chart
• The chart selenium-grid will be an umbrella chart with chart dependencies, including Hub (or isolated components) and Nodes. This chart creates the resources needed to deploy Selenium Grid to the Kubernetes cluster only.
• A new umbrella chart, selenium-grid-solution with chart dependencies, including selenium-grid, and other tools chart (e.g. KEDA, ingress-nginx, prometheus-stack, etc.). This chart deploys to cluster the Selenium Grid server with other solutions such as autoscaling, observability, monitoring, etc.
• Chart selenium-grid-solution also provides specific configuration files based on different environments or deployment scenarios.

Usage example

Organizing Helm charts to manage and deploy across environments without duplicating charts.

[github-actions[bot]]

@VietND96, thank you for creating this issue. We will troubleshoot it as soon as we can.

---

Info for maintainers

Triage this issue by using labels.

If information is missing, add a helpful comment and then I-issue-template label.

If the issue is a question, add the I-question label.

If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label.

If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, MSEdgeDriver, W3C), add the applicable G-* label, and it will provide the correct link and auto-close the issue.

After troubleshooting the issue, please add the R-awaiting answer label.

Thank you!

[amardeep2006]

I see your proposal plan to publish node chart separately. Does it mean it may open doors to have flexibility to deploy different versions of browser nodes at same time in same namespace (two separate deployments of node chart in same namespace). I am just checking if one can deploy chrome version 128 and 129 pods at the same time in same grid. If someone takes the pain to build images themselves using backward compatibility feature then it may be rule out mismatch of selenium server on hub/router and nodes. I am also not sure how autoscaling logic will react to it. It may be very complex or may be very simple but triggering few thoughts here.

[piotrlaczykowski]

You can also add it to artifacthub to easily see difference between versions

[VietND96]

@amardeep2006, yes, it may be very complex or may be very simple. When creating this, I try to achieve that each component has its own chart and can be deployed independently. If an advanced user has more requirements than the standard selenium-grid (e.g more nodes with multiple versions, etc.), they can create their own chart with importing components as sub-charts and reuse values as much as possible. The current selenium-grid chart will be lightweight, it only contains templates to create resources needed for a Grid in K8s. The highest level would be a solution chart, where importing selenium-grid and other tools charts to deploy the Grid with other things are configured and ready to use. Ideally, we will provide a high capability for reuse and customization. However, we only maintain the standard that we provided. For the kind of combination created by the users, they need to manage it.