use headless service for upload server#4052
Conversation
apparently there's no k8s API that says "kube-proxy has synced iptables rules for this service on all nodes" so pod readiness/healthz (even endpointslices) could all report success but the client would still face a connection refused. we faced something similar in virtctl kubevirt#3545 arguably, a headless service was the right fit for us anyway and cuts the above overhead out of the equation. Signed-off-by: Alex Kalenyuk <[email protected]>
| IntVal: 8443, | ||
| }, | ||
| Protocol: corev1.ProtocolTCP, | ||
| Port: 8443, |
There was a problem hiding this comment.
Why do we change the exposed port to 8443 instead of 443?
There was a problem hiding this comment.
this is a no op for headless, there will be no remapping
There was a problem hiding this comment.
Right, no port translation... I wonder if some users rely on this somehow (although I doubt it due to the proxy).
There was a problem hiding this comment.
yeah definitely hyrums law territory, thought about this too. if anyone did, they can still use their own services
I'd argue that it shouldn't be problematic since the upload-server Pod is transient and bound to the lifetime of an upload. |
Acedus
left a comment
There was a problem hiding this comment.
I think this is good, thanks!
|
/cc @0xFelix |
|
@akalenyu Let's hope so! 😁 |
|
Fine with me. Getting rid of the cluster IP is fine for this case but endpointslices still have to be created and that may not happen right away either |
Yeah good point. I haven't seen that play out but I agree it's completely possible. |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mhenriks The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
latest CDI release includes kubevirt/containerized-data-importer#4052 which finally allows us to trust the service/pod readiness (more info in the linked PR) Signed-off-by: Alex Kalenyuk <[email protected]>
|
/cherrypick release-v1.64 release-v1.63 release-v1.62 release-v1.61 |
|
@akalenyu: new pull request created: #4122 DetailsIn response to this:
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. |
Since the upload service became headless (kubevirt#4052), DNS resolves directly to the upload server pod IP. In OVN-Kubernetes clusters where the target namespace uses network segmentation, the pod's default network interface is locked down. The k8s.ovn.org/open-default-ports annotation opens port 8443 on the default interface, allowing the upload proxy to connect. The annotation is harmless on non-OVN clusters where it is simply ignored. Assisted-by: Claude Opus 4.6 <[email protected]> Signed-off-by: Ram Lavi <[email protected]>
Since the upload service became headless (kubevirt#4052), DNS resolves directly to the upload server pod IP. In OVN-Kubernetes clusters where the target namespace uses network segmentation, the pod's default network interface is locked down. The k8s.ovn.org/open-default-ports annotation opens port 8443 on the default interface, allowing the upload proxy to connect. The annotation is harmless on non-OVN clusters where it is simply ignored. Assisted-by: Claude Opus 4.6 <[email protected]> Signed-off-by: Ram Lavi <[email protected]>
latest CDI release includes kubevirt/containerized-data-importer#4052 which finally allows us to trust the service/pod readiness (more info in the linked PR) Signed-off-by: Alex Kalenyuk <[email protected]>
Since the upload service became headless (kubevirt#4052), DNS resolves directly to the upload server pod IP. In OVN-Kubernetes clusters where the target namespace uses network segmentation, the pod's default network interface is locked down. The k8s.ovn.org/open-default-ports annotation opens port 8443 on the default interface, allowing the upload proxy to connect. The annotation is harmless on non-OVN clusters where it is simply ignored. Assisted-by: Claude Opus 4.6 <[email protected]> Signed-off-by: Ram Lavi <[email protected]>
|
/cherry-pick release-v1.64 @akalenyu FYI following our conversation |
|
@RamLavi: new pull request could not be created: failed to create pull request against kubevirt/containerized-data-importer#release-v1.64 from head kubevirt-bot:cherry-pick-4052-to-release-v1.64: status code 422 not one of [201], body: {"message":"Validation Failed","errors":[{"resource":"PullRequest","code":"custom","message":"A pull request already exists for kubevirt-bot:cherry-pick-4052-to-release-v1.64."}],"documentation_url":"https://docs.github.com/rest/pulls/pulls#create-a-pull-request","status":"422"} DetailsIn response to this:
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. |
oh sorry was not aware you already cherry-picked. Thanks!! |
* Extract upload server port into a common constant Replace hardcoded 8443 references in the upload controller with common.UploadServerPort to prevent silent breakage if the port ever changes. Assisted-by: Claude Opus 4.6 <[email protected]> Signed-off-by: Ram Lavi <[email protected]> * Add open-default-ports annotation to upload server pod Since the upload service became headless (#4052), DNS resolves directly to the upload server pod IP. In OVN-Kubernetes clusters where the target namespace uses network segmentation, the pod's default network interface is locked down. The k8s.ovn.org/open-default-ports annotation opens port 8443 on the default interface, allowing the upload proxy to connect. The annotation is harmless on non-OVN clusters where it is simply ignored. Assisted-by: Claude Opus 4.6 <[email protected]> Signed-off-by: Ram Lavi <[email protected]> --------- Signed-off-by: Ram Lavi <[email protected]>
#4135) * Extract upload server port into a common constant Replace hardcoded 8443 references in the upload controller with common.UploadServerPort to prevent silent breakage if the port ever changes. Assisted-by: Claude Opus 4.6 <[email protected]> Signed-off-by: Ram Lavi <[email protected]> * Add open-default-ports annotation to upload server pod Since the upload service became headless (#4052), DNS resolves directly to the upload server pod IP. In OVN-Kubernetes clusters where the target namespace uses network segmentation, the pod's default network interface is locked down. The k8s.ovn.org/open-default-ports annotation opens port 8443 on the default interface, allowing the upload proxy to connect. The annotation is harmless on non-OVN clusters where it is simply ignored. Assisted-by: Claude Opus 4.6 <[email protected]> Signed-off-by: Ram Lavi <[email protected]> --------- Signed-off-by: Ram Lavi <[email protected]> Co-authored-by: Ram Lavi <[email protected]>
#4136) * Extract upload server port into a common constant Replace hardcoded 8443 references in the upload controller with common.UploadServerPort to prevent silent breakage if the port ever changes. Assisted-by: Claude Opus 4.6 <[email protected]> Signed-off-by: Ram Lavi <[email protected]> * Add open-default-ports annotation to upload server pod Since the upload service became headless (#4052), DNS resolves directly to the upload server pod IP. In OVN-Kubernetes clusters where the target namespace uses network segmentation, the pod's default network interface is locked down. The k8s.ovn.org/open-default-ports annotation opens port 8443 on the default interface, allowing the upload proxy to connect. The annotation is harmless on non-OVN clusters where it is simply ignored. Assisted-by: Claude Opus 4.6 <[email protected]> Signed-off-by: Ram Lavi <[email protected]> --------- Signed-off-by: Ram Lavi <[email protected]> Co-authored-by: Ram Lavi <[email protected]>
What this PR does / why we need it:
apparently, there's no k8s API that says
"kube-proxy has synced iptables rules for this service on all nodes"
so, pod readiness/healthz (even endpointslices) could all report success,
but the client would still face a
connection refused(this is causing unnecessary restarts in the k8s 1.35 bump PR)
we faced something similar in virtctl too
#3545
arguably, a headless service was the right fit for us anyway
and cuts the above overhead out of the equation.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes #3851
Special notes for your reviewer:
Not sure if there's a backwards compatibility consideration in here,
since upload pods are not usually carried over an upgrade
Release note: