13
13
- [ Changes to <code >--node-ip</code >] ( #changes-to- )
14
14
- [ Changes to the <code >provided-node-ip</code > annotation] ( #changes-to-the--annotation )
15
15
- [ Changes to cloud providers] ( #changes-to-cloud-providers )
16
+ - [ Example of <code >--node-ip</code > possibilities] ( #example-of--possibilities )
16
17
- [ Test Plan] ( #test-plan )
17
18
- [ Prerequisite testing updates] ( #prerequisite-testing-updates )
18
19
- [ Unit tests] ( #unit-tests )
@@ -159,9 +160,10 @@ specify both IPs that you want it to use.
159
160
160
161
### Changes to ` --node-ip `
161
162
162
- The most obvious required change is that we need to allow dual-stack
163
- ` --node-ip ` values in clusters using external cloud providers (but
164
- _ not_ in clusters using legacy cloud providers).
163
+ The most obvious required change is that we need to allow
164
+ comma-separated dual-stack ` --node-ip ` values in clusters using
165
+ external cloud providers (but _ not_ in clusters using legacy cloud
166
+ providers).
165
167
166
168
Additionally, the fact that kubelet does not currently pass
167
169
"` 0.0.0.0 ` " and "` :: ` " to the cloud provider creates a compatibility
@@ -181,17 +183,10 @@ require that the cloud provider pick a node IP of a specific family.
181
183
back to the other family if there are no IPs of this family" behavior
182
184
that "` 0.0.0.0 ` " and "` :: ` " imply.)
183
185
184
- ```
185
- <<[UNRESOLVED IPvX capitalization ]>>
186
-
187
- Should it be `IPv4`/`IPv6` or `ipv4`/`ipv6`?
188
-
189
- <<[/UNRESOLVED]>>
190
- ```
191
-
192
186
Additionally, we will update the code to allow including "` IPv4 ` " and
193
187
"` IPv6 ` " in dual-stack ` --node-ip ` values as well (in both cloud and
194
- non-cloud clusters).
188
+ non-cloud clusters). This code will have to check the status of the
189
+ feature gate until the feature is GA.
195
190
196
191
[ kubernetes #111695 ] : https://github.com/kubernetes/kubernetes/issues/111695
197
192
@@ -241,6 +236,60 @@ cloud-provider-specific changes should be needed; we should be able to
241
236
make the needed changes in the ` cloud-provider ` module, and then the
242
237
individual providers just need to revendor to the new version.
243
238
239
+ ### Example of ` --node-ip ` possibilities
240
+
241
+ Assume a node where the cloud has assigned the IPs ` 1.2.3.4 ` ,
242
+ ` 5.6.7.8 ` , ` abcd::1234 ` and ` abcd::5678 ` , in that order of preference.
243
+
244
+ ("SS" = "Single-Stack", "DS" = "Dual-Stack")
245
+
246
+ | ` --node-ip ` value | New? | Annotation | Resulting node addresses |
247
+ | ----------------------| ------| ------------------------| --------------------------|
248
+ | (none) | no | (unset) | ` ["1.2.3.4", "5.6.7.8", "abcd::1234", "abcd::5678"] ` (DS IPv4-primary) |
249
+ | ` 0.0.0.0 ` | no | (unset) | ` ["1.2.3.4", "5.6.7.8", "abcd::1234", "abcd::5678"] ` (DS IPv4-primary) |
250
+ | ` :: ` | no | (unset) | ` ["1.2.3.4", "5.6.7.8", "abcd::1234", "abcd::5678"] ` (DS IPv4-primary * ) |
251
+ | ` 1.2.3.4 ` | no | ` "1.2.3.4" ` | ` ["1.2.3.4"] ` (SS IPv4) |
252
+ | ` 9.10.11.12 ` | no | ` "9.10.11.12" ` | (error, because the requested IP is not available) |
253
+ | ` abcd::5678 ` | no | ` "abcd::5678" ` | ` ["abcd::5678"] ` (SS IPv6) |
254
+ | ` 1.2.3.4,abcd::1234 ` | yes* | ` "1.2.3.4,abcd::1234" ` | ` ["1.2.3.4", "abcd::1234"] ` (DS IPv4-primary) |
255
+ | ` IPv4 ` | yes | ` "IPv4" ` | ` ["1.2.3.4"] ` (SS IPv4) |
256
+ | ` IPv6 ` | yes | ` "IPv6" ` | ` ["abcd::1234"] ` (SS IPv6) |
257
+ | ` IPv4,IPv6 ` | yes | ` "IPv4,IPv6" ` | ` ["1.2.3.4", "abcd::1234"] ` (DS IPv4-primary) |
258
+ | ` IPv6,5.6.7.8 ` | yes | ` "IPv6,5.6.7.8" ` | ` ["abcd::1234", "5.6.7.8"] ` (DS IPv6-primary) |
259
+ | ` IPv4,abcd::ef01 ` | yes | ` "IPv4,abcd::ef01" ` | (error, because the requested IPv6 IP is not available) |
260
+
261
+ Notes:
262
+
263
+ - In the ` --node-ip :: ` case, kubelet will be expecting a
264
+ single-stack IPv6 or dual-stack IPv6-primary setup and so would
265
+ get slightly confused in this case since the cloud gave it a
266
+ dual-stack IPv4-primary configuration. (In particular, you would
267
+ have IPv4-primary nodes but IPv6-primary pods.)
268
+
269
+ - ` --node-ip 1.2.3.4,abcd::ef01 ` was previous valid syntax when
270
+ using no ` --cloud-provider ` , but was not valid for cloud kubelets.
271
+
272
+ If the cloud only had IPv4 IPs for the node, then the same examples would look like:
273
+
274
+ | ` --node-ip ` value | New? | Annotation | Resulting node addresses |
275
+ | ----------------------| ------| ------------------------| --------------------------|
276
+ | (none) | no | (unset) | ` ["1.2.3.4", "5.6.7.8"] ` (SS IPv4) |
277
+ | ` 0.0.0.0 ` | no | (unset) | ` ["1.2.3.4", "5.6.7.8"] ` (SS IPv4) |
278
+ | ` :: ` | no | (unset) | ` ["1.2.3.4", "5.6.7.8"] ` (SS IPv4 * ) |
279
+ | ` 1.2.3.4 ` | no | ` "1.2.3.4" ` | ` ["1.2.3.4"] ` (SS IPv4) |
280
+ | ` 9.10.11.12 ` | no | ` "9.10.11.12" ` | (error, because the requested IP is not available) |
281
+ | ` abcd::5678 ` | no | ` "abcd::5678" ` | (error, because the requested IP is not available) |
282
+ | ` 1.2.3.4,abcd::1234 ` | yes* | ` "1.2.3.4,abcd::1234" ` | (error, because the requested IPv6 IP is not available) |
283
+ | ` IPv4 ` | yes | ` "IPv4" ` | ` ["1.2.3.4"] ` (SS IPv4) |
284
+ | ` IPv6 ` | yes | ` "IPv6" ` | (error, because no IPv6 IPs are available) |
285
+ | ` IPv4,IPv6 ` | yes | ` "IPv4,IPv6" ` | (error, because no IPv6 IPs are available) |
286
+ | ` IPv6,5.6.7.8 ` | yes | ` "IPv6,5.6.7.8" ` | (error, because no IPv6 IPs are available) |
287
+ | ` IPv4,abcd::ef01 ` | yes | ` "IPv4,abcd::ef01" ` | (error, because the requested IPv6 IP is not available) |
288
+
289
+ In this case, kubelet would be even more confused in the
290
+ ` --node-ip :: ` case, and some things would likely not work.
291
+ By contrast, with ` --node-ip IPv6 ` , the user would get a clear error.
292
+
244
293
### Test Plan
245
294
246
295
<!--
0 commit comments