4 ms·
The link you posted highlights my exact concern with Swarm. If I use port 8080, then nobody else can use port 8080. That is a different tradeoff than Kubernet
by thockingoog 9y ago
The link you posted highlights my exact concern with Swarm. If I use port 8080, then nobody else can use port 8080. That is a different tradeoff than Kubernetes is willing to make.
Functionally, we have this in NodePort, but because it is exclusively managed, you're very unlikely to have a meaningful conflict. BUT it depends on traffic ingress being managed.
If you just want to map port 8080 on every node into your kube Service, it's more complicated than Swarm. Granted. That's because we don't think you should do that - it doesn't scale.
If you just want to map a port on every node (and you don't care which port), kube Services have you covered. Swarm's model is a nearly-direct clone of this.
- deleted 9y ago[deleted]
- sandGorgon 9y agoswarm is not limited to working with nodeport. I think i was not able to express what i was saying correctly. Swarm has an ingress mode that is "built-in". It works like the kuberenetes ingress (with currently the same limitation of source-ip mapping). Let me re-emphasize built-in. Swarm also has a load balanced nodeport mapping (called host mode). That is also built-in. In fact, what I'm trying to say is the opposite of what you are perceiving - swarm is not superior. It is actually similar to kuberenetes. However, swarm has saner built-in defaults - both ingress and overlay networks (no more flannel vs calico vs weave incompatibility issues). Kubernetes has an escape hatch for defaults - kubeadm+kompose. I keep praying that kubeadm+kompose becomes the keras for kubernetes tensorflow. Lots of defaults that lets you get started quickly.
- thockingoog 9y agoAre people happy with a built-in L7LB? I find most people are very particular about which LB they use.