Require network API objects to have IPv4 addresses #16807
Conversation
danwinship
added
component/networking
kind/bug
openshift-merge-robot
added
the
approved
openshift-ci-robot
added
the
size/L
|
Will tightening validations lead to breakage of a cluster that would otherwise limp along? If a user has invalid values in these fields, what impact will it have when they upgrade? |
|
If ClusterNetwork is IPv6, you can start the master, but you won't be able to successfully start any nodes. (Even if you created the IPv6 HostSubnets by hand, the nodes would just fail a few steps later, trying to add IPv6 addresses to an IPv4 iptables rule.) It might currently be possible to create a cluster with an IPv4 ClusterNetwork but an IPv6 ServiceNetwork, but only if you didn't actually use services, since pods wouldn't be able to connect to IPv6 service addresses, and services wouldn't be able to point to IPv4 pod addresses. And because the alleged IPv6 support in kube-proxy is a lie; looking more closely, there are bunches of IPv4-isms, like using It might be possible to limp along with an IPv6
|
danwinship
force-pushed
the
validate-ipv4
branch
from
db603ee
to
0a2f33c
Compare
| return nil, fmt.Errorf("invalid IP address: %s", ip) | ||
| } | ||
| if bytes.To4() == nil { | ||
| return nil, fmt.Errorf("must be an IPv4 address: %s", ip) |
There was a problem hiding this comment.
Don't include the value in the error message, it's already included in the validation output.
| return nil, err | ||
| } | ||
| if ipnet.IP.To4() == nil { | ||
| return nil, fmt.Errorf("must be an IPv4 network: %s", cidr) |
danwinship
force-pushed
the
validate-ipv4
branch
from
0a2f33c
to
f98ead5
Compare
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: danwinship, smarterclayton The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
|
Fixes #16660 |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
2 similar comments
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
Automatic merge from submit-queue. |
https://bugzilla.redhat.com/show_bug.cgi?id=1500664 points out problems that occur if you specify an IPv6 EgressIP. In fact, we shouldn't be allowing IPv6 addresses for any network API objects:
ClusterNetwork.Network/ClusterNetwork.ClusterNetworks[].CIDRmust be IPv4 because we only support an IPv4 SDN right now, for multiple reasons throughout kube and the SDN code. (Among other things, the HostSubnet allocator implicitly assumes IPv4, so while it's currently possible to start up a master with an IPv6clusterNetworkCIDRvalue, it won't ever succeed in allocating any HostSubnets, so no nodes will ever successfully start up.)ClusterNetwork.ServiceNetworkmust be IPv4 because kube-proxy only supports all-IPv4 or all-IPv6, and service rules must be able to refer to pod IPs, and since those are IPv4, then service IPs must be IPv4 too.HostSubnet.HostIPmust be IPv4 because the node's IP address is used in kube-proxy rules, which per the above must be IPv4 onlyHostSubnet.Subnetmust be IPv4 because it's a subset of the cluster network, which is IPv4HostSubnet.EgressIPsmust be IPv4 because they are used for NATting in iptables rules.NetNamespace.EgressIPsmust be IPv4 because they have to match some hostsubnet'sEgressIPs.EgressNetworkPolicyPeer.CIDRSelector... well, ... actually I guess these don't need to be IPv4; it's pointless to specify an IPv6 value here since pods don't have IPv6 connectivity, but nothing will break if you do.So this PR requires all of the above except
EgressNetworkPolicyPeer.CIDRSelectorto be IPv4.