feat(chart): Simplify config ports, probes, lifecycle hooks for Nodes #2077
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Thanks for contributing to the Docker-Selenium project!
A PR well described will help maintainers to quickly review and merge it
Before submitting your PR, please check our contributing guidelines, applied for this repository.
Avoid large PRs, help reviewers by making them as simple and short as possible.
Description
feat(chart): Simplify config ports, probes, and lifecycle hooks for Nodes
Motivation and Context
Configuration of Nodes
Container ports and Service ports
By default, Node will use port
5555
to listen on container (following this) and expose via Service. You can update this value via.port
in respective node type. This will be used to setSE_NODE_PORT
environment variable to pass to option--port
when starting the node and update in Service accordingly.By default, if httpGet probes are enabled, it will use
.port
value in respective node type unless you override it via e.g..startupProbe.port
.readinessProbe.port
or.livenessProbe.port
in respective node type.In a node container, there are other running services can be exposed. For example: VNC, NoVNC, SSH, etc. You can easily expose them on container via
.ports
and on Serviceservice.ports
in respective node type.Probes
By default,
startupProbe
is enabled andreadinessProbe
andlivenessProbe
are disabled. You can enable/disable them via.startupProbe.enabled
.readinessProbe.enabled
.livenessProbe.enabled
in respective node type.By default, probes are using
httpGet
method to check the node state. It will use.port
value in respective node type unless you override it via e.g..startupProbe.port
.readinessProbe.port
or.livenessProbe.port
in respective node type.Other settings of probe support to override under
.startupProbe
.readinessProbe
.livenessProbe
in respective node type.You can easily configure the probes (as Kubernetes supports) to override the default settings. For example:
Settings common for both
job
anddeployment
scalingTypeThere are few settings that are common for both scaling types. These are grouped under
autoscaling.scaledOptions
.In case individual node should be scaled differently, you can override the upstream settings with
.scaledOptions
for each node type. For example:Settings when scalingType with
deployment
By default,
autoscaling.terminationGracePeriodSeconds
is set to 3600 seconds. This is used when scalingType is set todeployment
. You can adjust this value, it will affect to all nodes.In case individual node which needs to set different period, you can override the upstream settings with
.terminationGracePeriodSeconds
for each node type. Note that override value must be greater than upstream setting to take effect. For example:When scaling using deployments the HPA choose pods to terminate randomly. If the chosen pod is currently executing a test rather
than being idle, then there is
terminationGracePeriodSeconds
seconds before the test is expected to complete. If your test isstill executing after
terminationGracePeriodSeconds
seconds, it would result in failure as the pod will be killed.During
terminationGracePeriodSeconds
period, there ispreStop
hook to execute command to wait for the pod can be shut down gracefully which can be defined in.deregisterLifecycle
_helpers
template with nameseleniumGrid.node.deregisterLifecycle
render value for podlifecycle.preStop
. By default, hook to execute the script to drain node and wait for current session to complete if any. The script is stored in node ConfigMap, more details can be seen in confignodeConfigMap.
preStop
hook which is applied for all nodes viaautoscaling.deregisterLifecycle
.deregisterLifecycle
for each node type. If you want to disable upstream hook in a node, pass the value asfalse
.lifecycle
itself, it would take the highest precedence to override the above use cases.For other settings that KEDA ScaledObject spec supports, you can set them via
autoscaling.scaledObjectOptions
. For example:Settings when scalingType with
job
Settings that KEDA ScaledJob spec supports can be set via
autoscaling.scaledJobOptions
.Types of changes
Checklist