update proposal

Signed-off-by: Patrik Cyvoct <patrik@ptrk.io>

keps/sig-network/20191205-kube-proxy-IP-node-binding.md

@@ -1,5 +1,5 @@
 ---
-title: Give the ability to the LoadBalancer provisioner to disable the LB IP binding
+title: Give the ability to the LoadBalancer provisioner or a user to disable the LB IP binding
 authors:
   - "@Sh4d1"
 owning-sig: sig-network
@@ -14,14 +14,14 @@ approvers:
   - TBD
 editor: TBD
 creation-date: 2019-12-05
-last-updated: 2019-12-06
+last-updated: 2019-12-21
 status: provisional
 see-also:
 replaces:
 superseded-by:
 ---
 
-# Give the ability to the LoadBalancer provisioner to disable the LB IP binding
+# Give the ability to the LoadBalancer provisioner or a user to disable the LB IP binding
 
 ## Table of Contents
 
@@ -57,7 +57,8 @@ Currently there is some hacky workaround that set the `Hostname` on the `Service
 
 ### Goals
 
-* Expose an option (ideally for at least the cloud controller manager) to disable the actual behaviour of kube proxy
+* Expose an option (ideally for at least the cloud controller manager) to disable the actual behaviour of kube proxy by default for all services.
+* Expose an annotation or a label on the `Service` to give the user the ability to enable/disable this feature on specific service.
 
 ### Non-Goals
 
@@ -66,26 +67,9 @@ Currently there is some hacky workaround that set the `Hostname` on the `Service
 
 ## Proposal
 
-Right now several options are possible:
+The idea is to add a new well known annotation or label `service.kubernetes.io/disable-lb-bypass` (not the definitive name). This label/annotation will be able to controle the `kube-proxy` behaviour for a specific service and the rules associated (especially disable the LB bypassing, leading all request going through the LB's IP to effectively go though the LB).
 
-* Add a flag to kube proxy to change the behaviour for all external IPs
-* Add a field to `LoadBalancerIngress` to disable the actual behaviour for a specific service
-* Add a new field to the `Service` object to disable the actual behaviour for a specific service
+This change on its own is not enough since it will force the user to add this label/annotation on service that requires disable LB bypass. 
 
-I have the following proposals:
-
-Proposal 1:
-- Add a `LoadBalancerDisableIPBinding *bool` field to the `ServiceSpec` (will gladly change the name)
-- This variable will stay `nil` until the service is changed to a `LoadBalancer` type.
-- When the `Service` changes to LB, the cloud controller will query the cloud controller manager to get the default value (through a new method in the interface) if it's still `nil`.
-- The kube-proxy will be able to see the `LoadBalancerDisableIPBinding` and act upon it on wheras the IP should be bound to the nodes or not.
-
-Proposal 2:
-- Add a new annotation `service.kubernetes.io/disable-lb-ip-binding`
-- When the cloud controller receives a LoadBalancer service, if this field is not set, set it as the default returned by the Cloud Controller Manager (through a new method in the interface)
-- The kube-proxy will be able to see the annotations and act upon it on wheras the IP should be bound to the nodes or not. 
-
-Proposal 3:
-- Add a new annotation `service.kubernetes.io/disable-lb-ip-binding`
-- Add a flag to kube-proxy to set the default behaviour for binding load balancers IP
-- The kube-proxy will be able to see the annotations and act upon it on wheras the IP should be bound to the nodes or not. 
+The second idea is to add a new method to the Cloud Controller Manager LoadBalancer interface (`DisableLBBypass(ctx context.Context) bool` for instance) that returns the default behaviour for the given cloud provider. Then the cloud controller will call this method when the `Service` becomes a `LoadBalancer` service, and setting the previous label/annotation to the desired value is the user did not already specify it.
+Finally the `kube-proxy` will be able to take the decision to bypass the LB or not base on the value of this label/annotation.