You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, zarf internal registry is a single replica workload that pulls from itself.
In case of a multi node cluster:
If the registry pod gets rescheduled to a different node, it won't be able to pull its own image
If the underlying cluster is upgraded based on a node replacement strategy (e.g. eks), the registry pod gets rescheduled to a new node, hence, it won't be able to pull its own image
Describe the solution you'd like
The internal registry could be a multi replica (configurable) STS (from 1 to n, so that a consumer can pick the level of availability it need) and:
a service is created by the internal registry helm chart for each of the sts replicas, labeled so that zarf knows where to push
zarf pushes to every replica (to all the services that are properly labeled)
cluster nodes pull from any, through the nodeport
Backward compatibility is preserved by defaulting to replicaCount=1 for the internal registry STS.
The text was updated successfully, but these errors were encountered:
Currently, zarf internal registry is a single replica workload that pulls from itself.
In case of a multi node cluster:
Describe the solution you'd like
The internal registry could be a multi replica (configurable) STS (from 1 to n, so that a consumer can pick the level of availability it need) and:
Backward compatibility is preserved by defaulting to replicaCount=1 for the internal registry STS.
The text was updated successfully, but these errors were encountered: