You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Items marked with (R) are required *prior to targeting to a milestone / release*.
24
31
25
-
-[] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR)
26
-
-[] (R) KEP approvers have approved the KEP status as `implementable`
27
-
-[] (R) Design details are appropriately documented
28
-
-[] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input
29
-
-[] (R) Graduation criteria is in place
32
+
-[x] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR)
33
+
-[x] (R) KEP approvers have approved the KEP status as `implementable`
34
+
-[x] (R) Design details are appropriately documented
35
+
-[x] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input
36
+
-[x] (R) Graduation criteria is in place
30
37
-[ ] (R) Production readiness review completed
31
38
-[ ] Production readiness review approved
32
39
-[ ] "Implementation History" section is up-to-date for milestone
@@ -66,31 +73,31 @@ Currently there is some hacky workaround that set the `Hostname` on the `Service
66
73
67
74
## Proposal
68
75
69
-
The solution would be to add a new field in the `loadBalancer` field of a `Service`'s `status`, like `ingressMode`. This new field will be used by kube-proxy in order to not bind the Load Balancer's External IP to the node (in both IPVS and iptables mode). The value `VIP` would be the default one (if not set for instance), keeping the current behaviour. The value `Proxy` would be used in order to disable the the shortcut.
76
+
The solution would be to add a new field in the `loadBalancer` field of a `Service`'s `status`, like `ipMode`. This new field will be used by kube-proxy in order to not bind the Load Balancer's External IP to the node (in both IPVS and iptables mode). The value `VIP` would be the default one (if not set for instance), keeping the current behaviour. The value `Proxy` would be used in order to disable the the shortcut.
70
77
71
-
Since the `EnsureLoadBalancer` returns a `LoadBalancerStatus`, the Cloud Controller Manager can optionally set the `ingressMode` field before returning the status.
78
+
Since the `EnsureLoadBalancer` returns a `LoadBalancerStatus`, the Cloud Controller Manager can optionally set the `ipMode` field before returning the status.
72
79
73
80
### User Stories
74
81
75
82
#### Story 1
76
83
77
-
User 1 is a Managed Kubernetes user. There cluster is running on a cloud provider where the LB's behaviour matches the `VIP``ingressMode`.
84
+
User 1 is a Managed Kubernetes user. There cluster is running on a cloud provider where the LB's behaviour matches the `VIP``ipMode`.
78
85
Nothing changes for them since the cloud provider manages the Cloud Controller Manager.
79
86
80
87
#### Story 2
81
88
82
-
User 2 is a Managed Kubernetes user. There cluster is running on a cloud provider where the LB's behaviour matches the `Proxy``ingressMode`.
89
+
User 2 is a Managed Kubernetes user. There cluster is running on a cloud provider where the LB's behaviour matches the `Proxy``ipMode`.
83
90
Almost nothing changes for them since the cloud provider manages the Cloud Controller Manager.
84
91
The only difference is that pods using the load balancer IP may observe a higher response time since the datapath will go through the load balancer.
85
92
86
93
#### Story 3
87
94
88
95
User 3 is a developer working on a cloud provider Kubernetes offering.
89
-
On the next version of `k8s.io/cloud-provider`, the cloud provider can optionally set the `ingressMode` field as part of `LoadBalancerStatus`, and reflect the cloud provider load balancer behaviour.
96
+
On the next version of `k8s.io/cloud-provider`, the cloud provider can optionally set the `ipMode` field as part of `LoadBalancerStatus`, and reflect the cloud provider load balancer behaviour.
90
97
91
98
### Risks and Mitigations
92
99
93
-
1. The first risk is when using the `Proxy``ingressMode` for pod using the load balancer IP. In this case the packets will not bypass the load balancer anymore.
100
+
1. The first risk is when using the `Proxy``ipMode` for pod using the load balancer IP. In this case the packets will not bypass the load balancer anymore.
94
101
However if a user wants to to keep using the in cluster datapath, he can still use the ClusterIP of the service.
95
102
96
103
## Drawbacks
@@ -102,3 +109,43 @@ However if a user wants to to keep using the in cluster datapath, he can still u
102
109
A viable alternative may be to use a flag directly on `kube-proxy`.
103
110
When running on a cloud provider managed Kubernetes this solution is viable since the cloud provider will be able to set the right value on `kube-proxy`.
104
111
When running a self hosted cluster, the user needs to be aware of how the cloud's load balancers works and need to set the flag on `kube-proxy` accordingly.
112
+
113
+
## Design Details
114
+
115
+
API changes to Service:
116
+
- Add a new field `status.loadBalancer.ingress[].ipMode: VIP | Proxy`.
117
+
-`ipMode` defaults to VIP if the feature gate is enabled, `nil` otherwise, preserving existing behaviour for Service Type=LoadBalancer.
118
+
- On create and update, it fails if `ipMode` is set without the `ip` field.
119
+
120
+
## Test Plan
121
+
122
+
Unit tests:
123
+
- unit tests for the ipvs and iptables rules
124
+
- unit tests for the validation
125
+
- unit tests for a new util in pkg/proxy
126
+
127
+
E2E tests:
128
+
- The default behavior for `ipMode` does not break any existing e2e tests
129
+
- The default `VIP` value is already tested
130
+
131
+
## Graduation Criteria
132
+
133
+
### Alpha
134
+
135
+
Adds new field `ipMode` to Service, which is used when `LoadBalancerIPMode` feature gate is enabled, allowing for rollback.
136
+
137
+
### Beta/GA
138
+
139
+
`LoadBalancerIPMode` is enabled by default.
140
+
141
+
### Upgrade / Downgrade Strategy
142
+
143
+
On upgrade, while the feature gate is disabled, nothing will change. Once the feature gate is enabled, all the previous LoadBalancer service will get an `ipMode` of `VIP`.
144
+
If `kube-proxy` was not yet upgraded: the field will simply be ignored.
145
+
If `kube-proxy` was upgraded, and the feature gate enabled, it will stil behave as before if the `ipMode` is `VIP`, and will behave accordingly if the `ipMode` is `Proxy`.
146
+
147
+
On downgrade, the feature gate will simply be disabled, and as long as `kube-proxy` was downgraded before, nothing should be impacted.
148
+
149
+
### Version Skew Strategy
150
+
151
+
Version skew from the control plane to `kube-proxy` should be trivial since `kube-proxy` will simply ignore the `ipMode` field.
0 commit comments