the controller manager should validate the podSubnet against the node-mask
because if they are incorrect can cause the controller-manager to fail.
We don't need to calculate the node-cidr-masks, because those should
be provided by the user, if they are wrong we fail in validation.
There are some network scenarios that, in order to have high availability based
on routing protocols, you may have multiple interfaces in the host and you use
a routing protocol to configure the routing in the host.
It is common to not use global addresses on those interfaces because you don't want
them to be reachable, so you assign the global address to the loopback interface.
Loopback interfaces are always up, regardless of the states of physical interfaces.
They are not subject to interface problems, i.e., if the interface is down or flapping
you can not reach the IP despite you have connectivity through another interface.
We should consider global ip addresses on loopback interfaces when:
- the host has default routes
- there are no global IPs on those interfaces.
There can be more cases in which you have global addresses on the interfaces too,
but that will open an explosion of scenarios hard to support and to "autodetect"
It will be a cluster admin responsability to configure the network in such
scenarios.
This PR adds trailing unit tests to check the service cluster IP range and
improves the code coverage of k8s.io/kubernetes/cmd/kube-apiserver/app from
5.7% to 6.2%.
1) Dual stack IPv4/IPv6
2) Invalid IPv4, IPv6 mask
3) missing IPv4, IPv6 mask
4) invalid IP address format
The tests 2, 3, 4 are suggsted by Antonio Ojea.
A spreading test is more meaningful with a greater number of Pods. However, we cannot always expect perfect spreading. We accept a skew of 2 for 5*z Pods, where z is the number of zones.
Change-Id: Iab0de06a95974fbfec604f003b550f15db618ebd
Currently, if you have a PDB with 0 disruptions
available and you attempt to evict a non-healthy
pod, the eviction request will always fail. This
is because the eviction API does not currently
take in to account that the pod you are removing
is the unhealthy one.
This commit accounts for trying to evict an
unhealthy pod as long as there are enough healthy
pods to satisfy the PDB's requirements. To
protect against race conditions, a ResourceVersion
constraint is enforced. This will ensure that
the target pod does not go healthy and allow
any race condition to occur which might disrupt
too many pods at once.
This commit also eliminates superfluous class to
DeepCopy for the deleteOptions struct.
