-
Notifications
You must be signed in to change notification settings - Fork 172
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
Expose PVC accessMode as variable #1664
Conversation
✅ Deploy Preview for zarf-docs canceled.
|
We have pod affinity defined because this is node-attached storage and even a deployment rollout can break it if you don't tie the pod to the same node. HPA is no different than deployment rollout and does not require RWX. |
Reopening this PR after some |
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
Twas missing |
Description
When attempting to upgrade our EKS Node AMIs in AWS, we noticed that the Zarf Registry deployment was unable to horizontally scale across nodes which needed to restart. We believe the culprit is the
accessMode
specification for the PersistentVolumeController. In order for multiple pods to have access to the same PersistentVolume, theaccessMode
must be set to "ReadWriteMany".This PR proposes that when autoscaling is enabled for the Zarf Registry, theaccessMode
is set to "ReadWriteMany" by default; when autoscaling is disabled, it is set to "ReadWriteOnce". Due to the additional work required (i.e. using an existing PersistencVolumeController with a storage class compatible with RWX), we also propose thatautoscaling
be disabled by default.This PR exposes the
REGISTRY_PVC_ACCESS_MODE
variable for thezarf-registry
portion of the init package.Related Issue
Type of change
Checklist before merging