bind/unbind does not delete unused deployments

[ahmetb]

Repro steps:

1. kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080
2. kubectl expose deploy hello-server
3. kubehost bind hello-server

Now I have deployments both hello-server and hello-server-hostport

➜ kubectl get deploy
NAME                    DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
hello-server            1         1         1            1           11m
hello-server-hostport   1         1         1            1           1m

Is this expected?

As a user, I expect my deployment to be modified in-place by kubehost. Having two deployments (without continuously mirroring them automatically) is unexpected to me.

Similarly, kubehost unbind hello-server leaves the unused deployment around.

[WilliamDenniss]

Your deployment and service are not modified at all with the bind and unbind commands, which was quite intentional (and desirable). NB. upgrade and downgrade will change the type of the Service, but that's the only change that is made with those.

Modifying the Deployment to use hostPort instead of creating a new deployment using hostPort to direct traffic to your clusterIP service was one design option we had, however it changes the model a lot, specifically:

• You can't practically have more than 1 replica (specifically, each replica would need an available hostPort, so with 10 replicas you'd need 10 nodes)
• The Service you created with expose would not used at all in that scenario (as traffic ingresses to the container directly), which would make kubehost behave very differently to exposing with a LoadBalancer. We wanted to reduce the difference is in the architecture between LoadBalancer and exposing with kuehost.

Think of the hello-server-hostport deployment as the "load balancer" that exposes the service to the world and gets the traffic into the cluster. Just like how GCLB serves this same functionality with service type=LoadBalancer. The difference is production-readiness, and where the logic sits, with kubehost placing this functionality inside the cluster, whereas the GLCB sits outside.

What I like about this though is that there is some equivalence in functionality (though not production readiness or stability), as you still have your same deployment, and your service, just as before; only the method for ingressing the traffic changed.