-
Notifications
You must be signed in to change notification settings - Fork 1
Description
This is a feature request. Feel free to debate the need, concepts, technical choices, security practices or cost management approaches if your experience and competences enables you to.
🔬 The need / existing limitation
The kompose
support within the SDK is a good thing to quickly try challenges from an existing non-ideal setup (at least we consider this approach a workaround toward a proper SDK migration, with much more control over what's going on).
Nonetheless, the technical choices behind Kompose ties it to the need of deploying things quickly so migration can be experimented, thus avoid rushing headfirst into Kubernetes.
For this reason--and others-- the ports exposed by a container are all packed into a single core/v1:Service
GVK. Then, when deciding on the exposure strategy by our SDK, if at least one port should be exposed through a NodePort
then all are.
📝 Description of a path toward the feature
A proper solution to this issue would be to unpack the Service and create one per port, as we do in the ExposedMultipod
.
Then, modify the service pulumi.ResourceTransform
(2nd at the time or writing).
The impact is (1) a better control over the exposed port; (2) avoid the consumption of all NodePorts if not required; and (3) an overall improved security posture and isolation of instances.
💻 How to implement it ?
To implement this, I propose to operate inside the kompose
function directly. That way every operation (i.e. check and provision) deals with the same data without having to implement a new strategy.
It also keeps the semantics valid: "kompose is the function that consumes a docker compose YAML manifest and returns a set of Kubernetes resources to deploy it", just operationally slightly altered for the above reasons 😉