Skip to content

Commit 952a767

Browse files
committed
updates
1 parent cf97fd5 commit 952a767

File tree

1 file changed

+61
-12
lines changed
  • keps/sig-network/3705-cloud-node-ips

1 file changed

+61
-12
lines changed

keps/sig-network/3705-cloud-node-ips/README.md

Lines changed: 61 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -13,6 +13,7 @@
1313
- [Changes to <code>--node-ip</code>](#changes-to-)
1414
- [Changes to the <code>provided-node-ip</code> annotation](#changes-to-the--annotation)
1515
- [Changes to cloud providers](#changes-to-cloud-providers)
16+
- [Example of <code>--node-ip</code> possibilities](#example-of--possibilities)
1617
- [Test Plan](#test-plan)
1718
- [Prerequisite testing updates](#prerequisite-testing-updates)
1819
- [Unit tests](#unit-tests)
@@ -159,9 +160,10 @@ specify both IPs that you want it to use.
159160

160161
### Changes to `--node-ip`
161162

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).
165167

166168
Additionally, the fact that kubelet does not currently pass
167169
"`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.
181183
back to the other family if there are no IPs of this family" behavior
182184
that "`0.0.0.0`" and "`::`" imply.)
183185

184-
```
185-
<<[UNRESOLVED IPvX capitalization ]>>
186-
187-
Should it be `IPv4`/`IPv6` or `ipv4`/`ipv6`?
188-
189-
<<[/UNRESOLVED]>>
190-
```
191-
192186
Additionally, we will update the code to allow including "`IPv4`" and
193187
"`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.
195190

196191
[kubernetes #111695]: https://github.com/kubernetes/kubernetes/issues/111695
197192

@@ -241,6 +236,60 @@ cloud-provider-specific changes should be needed; we should be able to
241236
make the needed changes in the `cloud-provider` module, and then the
242237
individual providers just need to revendor to the new version.
243238

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+
244293
### Test Plan
245294

246295
<!--

0 commit comments

Comments
 (0)