-
Notifications
You must be signed in to change notification settings - Fork 323
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request: support for taints and tolerations to KubeArmor deployments in Helm charts. #1720
Comments
@daemon1024 Can I working on this? Thanks. |
@tico88612 Just to provide some context.
|
Hi @daemon1024 I've added the toleration fields for But I was thinking about the CRD part. Should I add KubeArmor/pkg/KubeArmorOperator/api/operator.kubearmor.com/v1/kubearmorconfig_types.go Lines 50 to 53 in ecdea89
Because it's different from other CRD designs (Prometheus Operator) that I'm referring to, I want to make sure it's feasible to go in this direction. Prometheus Operator CRD (Alertmanager): https://github.com/prometheus-operator/prometheus-operator/blob/3e7eb79e25ac497fd44753261e23cbed9faa36f5/pkg/apis/monitoring/v1/alertmanager_types.go#L166-L167 |
Nice.
Yep this looks like the place to add, please reflect the changes where the operator deploys them as well. Thanks 🙌🏽 |
We would like to request support for taints and tolerations to KubeArmor deployments in Helm charts.
Is your feature request related to a problem? Please describe the use case.
Currently, the KubeArmor deployments like kubearmor-relay, kubearmor-operator, and kubearmor-controller deployed via Helm charts do not support taints and tolerations. This limitation restricts the ability to deploy KubeArmor components on tainted nodes within Kubernetes clusters, particularly in environments with specialized node configurations or security requirements.
Describe the solution you'd like
We would like to request that the Helm charts for KubeArmor deployments to include options for specifying taints and tolerations. This feature would allow users to deploy KubeArmor components on specific nodes that have been tainted to restrict pod scheduling, thus enhancing the flexibility and security posture of Kubernetes clusters using KubeArmor.
Describe alternatives you've considered
As an alternative, users could manually edit the deployment YAML files generated by Helm to include taints and tolerations, but this approach is less maintainable and error-prone, especially during Helm chart upgrades or re-deployments. Integrating taints and tolerations directly into the Helm charts would provide a more robust, user-friendly, and maintainable solution.
The text was updated successfully, but these errors were encountered: