Add a --publish option to container k8s create - #2122
Open
mikluko wants to merge 2 commits into
Open
Conversation
1 task
Publishes node ports to the host, so NodePort services get a stable host endpoint instead of the node's vmnet IP, which changes across recreations. Specs go through the runtime's existing `Parser.publishPorts`, so the format matches `container run --publish`. `clusterPort()` becomes `reservedHostPorts()` + `clusterPort(excluding:)`: the API server allocation skips user-requested host ports, and the internal API spec stays first so the kubeconfig transform keeps selecting it. Host port claims are keyed by (port, protocol), the granularity `[PublishPort].hasOverlaps()` collides on, and carry the container holding them along with its runtime status. A running holder is a hard error naming it; a stopped holder is a warning, since nothing is listening on the port yet that container cannot start again while the cluster owns it. The scan covers plain containers as well as clusters, so a port held by `container run -p` is reported at create time rather than as a bind failure at node boot. The PORTS column renders the host address and non-TCP protocol it previously dropped, and collapses ranges, so specs differing only in address or protocol no longer print identically.
mikluko
force-pushed
the
k8s-create-publish
branch
from
August 18, 2026 21:24
99b1fd2 to
227959f
Compare
|
👍 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #2121.
Type of Change
Motivation and Context
container k8s createpublishes only the internally allocated API server port; NodePort services are reachable solely via the node's vmnet IP, which is dynamic across recreations. Anything wanting a stable host endpoint (an ingress controller on fixed NodePorts, a local dev domain resolving to loopback) has no supported path, while the runtime's publish machinery already carries the capability. Details in #2121.This adds a repeatable
-p/--publish [host-ip:]host-port:container-port[/protocol]option tok8s create:Parser.publishPorts— no new format or parser.K8sHelper.clusterPort()is split intoreservedHostPorts()+clusterPort(excluding:): the API server allocation now excludes user-requested host ports, user specs that collide with another cluster's published host port fail legibly at create time, and the internal API spec stays first so the kubeconfig transform keeps selecting it.Testing
make testgreen (763 tests, 82 suites), including 7 new swift-testing cases for spec parsing/composition inTests/K8sPluginTests/K8sPublishPortsTests.swift. Verified live on macOS: a cluster created with--publish 8080:30080 --publish 8443:30443lists6446->6443,8080->30080,8443->30443(allocator correctly skipping another cluster's 6445), and traffic through the published host port reaches the NodePort.docs/command-reference.mdupdated.