-
Notifications
You must be signed in to change notification settings - Fork 83
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
statefulset: Use stateful sets for posgres deployments (PROJQUAY-6672) #927
base: master
Are you sure you want to change the base?
Conversation
jonathankingfc
commented
May 30, 2024
- Swap Postgres and Clair Postgres Deployments to StatefulSets
7e3cab8
to
fb9e6ba
Compare
fb9e6ba
to
84e5ac2
Compare
@@ -1,5 +1,5 @@ | |||
apiVersion: apps/v1 | |||
kind: Deployment | |||
kind: StatefulSet |
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.
how will this work with existing deployments? On upgrade will it replace the deployment with a statefulset?
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.
Yes, it will replace the deployment with a stateful set. This is so that we do not have issues with overlapping deployments that would cause issues on the upgrade job.
replicas: 1 | ||
strategy: | ||
type: Recreate |
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.
This will switch the deployment to a rolling upgrade, which could cause the old and new pod to run at the same time. Will that cause issues?
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.
Since it is a stateful set, it will only run one pod at a time
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.
In theory, issues can occur where Quay is operating on a Clair that has a split-brain during a deployment (i.e. the security worker requests the indexing state from a new pod, sees it has changed then makes an indexing request but it goes to an old pod). In practice, this is how it works in production and we've never seen problems so I think it's probably fine but something to document.
@@ -1,5 +1,5 @@ | |||
apiVersion: apps/v1 | |||
kind: Deployment | |||
kind: StatefulSet |
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 original issue seems to be caused by the old and the new db pods being matched by the same service, making the requests against the db go to either or randomly. Does switching to stateful sets fix this issue?
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.
Yes, since their will be only one underlying pod attached to the service
/retest |
1 similar comment
/retest |
- Swap Postgres and Clair Postgres Deployments to StatefulSets
6bb30c0
to
0ba46ee
Compare
@jonathankingfc: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |