-
-
Notifications
You must be signed in to change notification settings - Fork 6
refactor!: Split into Deployment and DaemonSet #645
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
Conversation
The splits the deployment of the secret-operator as a whole into two parts: - The controller is deployed via a Deployment which ensures only a single instance of the secret-operator in controller mode is running in a Kubernetes cluster. This can potentially lead to perfomance issues and as such should be monitored going forward. - The CSI server is deployed via a DaemonSet (unchanged) as this server is needed on every node to provision requested secret volumes. This refactor is introduced in preparation for #634, in which only a single instance of the CRD conversion webhook must exist as otherwise TLS certificate verification will fail with multiple available certificates.
Release Note==== Platform improvements
===== Stackable secret-operator
The Helm Chart now deploys the secret-operator as two parts.
This separation is needed for CRD versioning and conversion by the operator.
See https://github.com/stackabletech/secret-operator/pull/645[secret-operator#645].
* The controller (which reconciles resources, maintains CRDs and provides the CRD conversion webhook) runs as a Deployment with a single replica.
* The CSI server runs on every Kubernetes cluster node via a DaemonSet (this behaviour is unchanged).
* The Helm values are adjusted in accordance to the changes above.
See the secret-operator https://github.com/stackabletech/secret-operator/blob/25.11.0/CHANGELOG.md[changelog] for a complete overview of these changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Rust code change LGTM.
I let you and @NickLarsenNZ decide about the helm structure and values.yaml, as he did related things for listener-operator in the past
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
* refactor: Split into Deployment and DaemonSet The splits the deployment of the secret-operator as a whole into two parts: - The controller is deployed via a Deployment which ensures only a single instance of the secret-operator in controller mode is running in a Kubernetes cluster. This can potentially lead to perfomance issues and as such should be monitored going forward. - The CSI server is deployed via a DaemonSet (unchanged) as this server is needed on every node to provision requested secret volumes. This refactor is introduced in preparation for #634, in which only a single instance of the CRD conversion webhook must exist as otherwise TLS certificate verification will fail with multiple available certificates. * chore: Add changelog entry * chore: Update comment * refactor: Adjust values.yaml file to be closer to listener-operator * chore: Adjust changelog entry
This was accidentally introduced in #645.
This was accidentally introduced in #645.
The splits the deployment of the secret-operator as a whole into two parts:
This refactor is introduced in preparation for #634, in which only a single instance of the CRD conversion webhook must exist as otherwise TLS certificate verification will fail with multiple available certificates. The Helm values.yaml structure is similar to the structure introduced in stackabletech/listener-operator#334.
Follow-up research: Look into Leases which seems to be a Kubernetes native way of enforcing that only a single instance of an application is running/does a particular piece of work in a cluster.
This is in line with what listener-operator is already doing
Author
Reviewer
Acceptance