EV-6336: feat(istio): waypoint pull secret support for private registries#4483
EV-6336: feat(istio): waypoint pull secret support for private registries#4483electricjesus wants to merge 4 commits intomasterfrom
Conversation
Add ImagePullSecrets field to GlobalConfig and populate it from Installation pull secrets when rendering istiod Helm values. This makes istiod inject imagePullSecrets references into waypoint pod specs it creates, enabling image pulls from private registries.
Add a new controller that watches for istio-waypoint Gateway resources and copies pull secrets from the operator namespace to waypoint namespaces. This ensures waypoint pods can pull images from private registries. Secrets are tracked with a label for cleanup when gateways are removed or the Istio CR is deleted.
electricjesus
changed the title
|
|
||
| // WaypointPullSecretLabel is the label applied to secrets copied by this controller | ||
| // for tracking and cleanup purposes. | ||
| WaypointPullSecretLabel = "operator.tigera.io/istio-waypoint-pull-secret" |
There was a problem hiding this comment.
Curious why a label is the right call here instead of using owner references? If there's a reason it would be good to expand on that in the comment.
There was a problem hiding this comment.
Went with labels here since we need to find and clean up these secrets across namespaces; not just on Gateway deletion, but also when pull secrets get removed from Installation or the Istio CR gets deleted. MatchingLabels makes that easy. Owner refs would only cover the Gateway-deletion case via GC, and we'd still need some way to track secrets for the other cleanup paths. Similar to how ESGatewaySelectorLabel works in the logstorage controller.
| return fmt.Errorf("istio-controller failed to create periodic reconcile watch: %w", err) | ||
| } | ||
|
|
||
| if err := waypoint.Add(mgr, opts); err != nil { |
There was a problem hiding this comment.
Hm, a bit of a new pattern here (I think all the other "sub" controllers are just added in the same place as main controllers).
Not necessarily against this, though.
There was a problem hiding this comment.
it was just easier for me to understand this format, but also happy to go with the established pattern. Let me know what your preference would be as a maintainer 😅
…et cleanup Replace manual cleanupAllSecrets/cleanupStaleSecrets methods with a single NewPassthrough(toCreate, toDelete) call. This follows the existing codebase pattern for managing object lifecycle through the component handler. The explicit len(pullSecrets)==0 early return is removed — the mainline reconcile logic now handles this naturally: when no secrets are needed, toCreate is empty and all existing labeled secrets flow into toDelete. Also expand the WaypointPullSecretLabel comment to explain why labels are used instead of owner references (cross-namespace cleanup needs).
3 participants
Description
Jira: EV-6336
When users create an Istio waypoint Gateway (
gatewayClassName: istio-waypoint) in their namespace, istiod automatically creates a waypoint Deployment there. On clusters with private registries (like AKS withgcr.io/unique-caldron-775), the waypoint pod fails withImagePullBackOffbecause the pull secret only exists in the operator namespace and istiod doesn't injectimagePullSecretsinto waypoint pod specs.This PR fixes the issue with two changes:
Part 1: Pass imagePullSecrets to istiod via Helm values
ImagePullSecretsfield toGlobalConfigin the Istio render packageglobal.imagePullSecretsin istiod Helm values from Installation pull secretsimagePullSecretsreferences into waypoint pod specs it createsPart 2: New waypoint sub-controller
istio-waypointGateway resources across all namespacesoperator.tigera.io/istio-waypoint-pull-secretlabel for cleanupBoth parts are no-ops when no pull secrets are configured (
omitempty/ early return).Testing:
Components affected:
pkg/render/istio,pkg/controller/istio,internal/controllerRelease Note
For PR author
make gen-filesmake gen-versions