Add validation.IsValidIPForLegacyField and
validation.IsValidCIDRForLegacyField, which validate "legacy" IP/CIDR
fields correctly. Use them for all such fields (indirectly, via a
wrapper in pkg/apis/core/validation that handles the
StrictIPCIDRValidation feature gate correctly).
Change IsValidIP and IsValidCIDR to require strict parsing and
canonical form, and update the IPAddr, ServiceCIDR, and
NetworkDeviceData validation to make use of them.
Because it used both IsValidIPv4Address and ValidateEndpointIP,
EndpointSlice validation produced duplicate error messages when given
an invalid IP. Fix this by calling IsValidIP first, and only doing the
other checks if that one fails.
Also, since no one else was using the IsValidIPv4Address and
IsValidIPv6Address methods anyway, just inline them into the
EndpointSlice validation, so we don't have to worry about "should they
do legacy or strict validation" later.
Split "ifaddr"-style ("192.168.1.5/24") validation out of IsValidCIDR.
Since there is currently only one field that uses this format, and it
already requires canonical form, IsValidInterfaceAddress requires
canonical form unconditionally.
Fix some incorrect test case names.
Use t.Run() in a few more places (to facilitate using
SetFeatureGateDuringTest later).
Clarify TestPodIPsValidation/TestHostIPsValidation (and fix
weird indentation).
There is not a single definition of "non-special IP" that makes sense
in all contexts. Rename ValidateNonSpecialIP to ValidateEndpointIP and
clarify that it shouldn't be used for other validations.
Also add a few more unit tests.
This makes a bold assumption: that the errors (count and basic content)
will be the same across versions. If this turns out to be untrue, this
may need to get more sophisticated. It should fail obviously when we
hit that edge.
If apiserver is handing heavy traffic volume, it's likely to trigger
tracing events. After streaming JSON objects, the number of tracing events
are same to object number. It's unneccessary to log each write call.
This patch is to reduce tracing events.
Signed-off-by: Wei Fu <fuweid89@gmail.com>
Determine whether the ClusterTrustBundleProjection should be enabled
based on ClusterTrustBundle API discovery.
Some distributions may rely on a running kubelet in order to start
their kube-apiserver. Therefore we must delay the API discovery.
This patch delays it until the first time a clustertrustbundle is
requested from the InformerMaanager.
